Decision Management (ODM,ADS)

I'm trying to find an elegant way to implement a decision making algorithm that allow easy maintenance because the conditions for the decision making might change often.

I'm going to try and be more specific with an example here :

Let's say I'm trying to manage a team of Cooking chefs in a restaurant kitchen.

Every chef knows how to cook 3 types of pies : Apple pie, pumpkin pie and raspberry pie and 2 types of pizza : cheese pizza and bacon pizza. They all know how to cook everything.

Now, I would like to send orders to these chief regarding what's coming for the clients.

The conditions are :

A chief can only cook one pie at a time. If I order a chef to cook an apple pie for example, I cannot order him to cook a raspberry pie or a pumpkin pie unless the apple pie is done or I send an cancel request for the apple pie.

I can ask a chef to cook up to 5 pizzas at a time, given it's for different clients.

I woud like to create an algorithm that returns the set of orders I'm allowed to send to a specific chef, regarding what he already is cooking.

I'm working with c++. I could write a simple switch/case statement, but the maintenance would not be easy if conditions change or new pies are added, and so...

I'm kinda stuck and really don't see how I could encapsulate the conditions and decision making to decrease couplign beetween conditions and to allow easy maintenance on the conditions of pie cooking.

How would you handle complexe decision making algorithm implementation?

If you are looking for an easy way to manage the data then one way would be to store the data in a single decision table. I have used this technique more than once to initialise small amounts of tabular data within a rule project.

For a very simplistic and easy implementation I would have a single condition column that evaluates true for each row. If you specify the condition as 'true is <a boolean>' with a title of 'Active?' then it gives you a checkbox for each chef with an easy way to deactivate any particular chef. Then the first action column would have the name of the chef followed by columns for each of the possible recipes. The action cells would specify how many (0 or more) the chef can make at any one time. You would need to create a suitable object model to store these values for each chef and implement some custom actions to stored the values correctly for each chef. Purists would probably say this is a misuse of decision tables but I always try to make things as simple as possible for the business users to change the rules.

This table only declares the data so you would need further rules/code to calculate the valid combinations from the initialised model e.g. up to 5 pizzas or one pie. This approach should be OK for small numbers of chefs and recipes as you can add extra columns to add a new recipe types and extra rows for additional chefs. The list of recipes could be defined as a dynamic domain so that only valid names can be used in the rules.

Choosing from many permutations/options is more usually handled by optimisation tools such as IBM CPLEX but if you only have a small amount of data and you are not looking for the "best" solution (e.g. using all chefs evenly or keeping as many order options open as possible) then rules can be used.