The responses to the RFP of OMG DMN (Decision Model and Notation) standard are scheduled to arrive in May of 2012. Trying to keep this process as close as possible to the everyday decision management reality, I posted several use cases at the DMN Discussion Group and tried to formulate down-to-earth questions that DMN will hopefully address. Here I want to take almost trivial rules and discuss different implementation options using decision tables.
We have already started to discuss this example in general rules management context with our friends from Sparkling Logic. So, this “trivial” problem can be described in plain English as follows:
“If a variable x is equal to 1 make it 2; and if it is equal to 2 make it 1”
Before you read further, I challenge you to represent this problem in your favorite programming language or in your favorite BR system with decision tables and without them.
Actually, many years ago this simple problem was given at an international student programming Olympiad. Here are some possible answers with comments from the organizers:
x = 3 - x
|You are a mathematician but not a programmer|
if (x == 1) x = 2; if (x == 2) x = 1;
|You are not a programmer but probably a programming instructor
[I guess because people who do not program themselves frequently teach others how to do it]
if (x == 1) x = 2; else if (x == 2) x = 1; else error("Unexpected input");
|You are a normal programmer|
From the rules management perspective, solution (1) is the worse one because looking at it you cannot recognize the initial “business” problem not mentioning that it does not allow any changes in the problem definition. A “good” solution (3) reflects thinking of a programmer who would not forget to put “else” before the second “if” like in the “bad” solution (2).
However, a business user (who is supposed to write and maintain business rules) in the most cases does not think as a programmer. I believe it is more natural for a business person not to notice a programming error in the “bad” solution (2). Carole-Ann offered this intuitive decision table as a possible solution:
She correctly noticed that everything depends on the execution logic of this simple decision table, e.g. ”the execution of this decision table in Rete mode will turn into an endless loop.”Using OpenRules you may represent this table asor
Any of these equivalent decision tables produce correct results because OpenRules table of the type “DecisionTable” is a single-hit table. It means OpenRulesEngine will execute rules from this table in the top-down order and it will stop its execution after hitting the very first true rule. So, if X is 1 then X will become 2 using the first rule and the second rule will be ignored.OpenRules also supports two other types of decision tables “DecisionTable1” and “DecisionTable2”. The table of the type “DecisionTable1” is a multi-hit table that allows rules overrides. It means that before executing any rule inside such table, OpenRules will verify all conditions and only then for all rules with true-conditions will execute their actions. In our case if we replace a previous table with this oneIt still will produce correct results. Why? Even if X is 1 then X will become 2 using the first rule. However, the second rules will not be executed as its condition was validated as false before any rules execution.And finally the table of the type “DecisionTable2” is a multi-hit table that executes rules in the top-down order one-by-one without any preliminary validation. It is very much similar to the traditional programming languages logic. So, if we replace a previous decision table with this oneit will produce invalid results. For example, if X is 1 then X will become 2 using the first rule. Then the second rule will be validated as true because a new value of X is already 2, and the second rule will make X to be equal to 1 again.Along with predefined decision tables of types DecisionTable, DecisionTable1, and DecisionTable2, OpenRules allows you to design your own decision tables by defining your own execution logic in Java snippets. Here is an example of such table:that will also produce the correct results. And finally, instead of any decision table you may simply write a snippet of Java code that will actually represent the solution (3) above. Here is an example of the proper table of the type “Method” with a Java snippet:CONCLUSION.The described representations of a very simple use case only prove the necessity of standardization of decision tables, and hopefully OMG DMN will provide such a standard.
Note. Similarly to Rete-based rule engines, the initial decision table (offered by Carole-Ann) would not work with a constraint-based rule engine either – it will quickly diagnose an attempt to assign a different value to already instantiated constrained variable.