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:
| # | Solution | Comments |
|---|---|---|
| (1) |
x = 3 - x |
You are a mathematician but not a programmer |
| (2) |
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] |
| (3) |
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 as
or
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 one
It 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 one
it 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.
OpenRules - Decision Intelligence Software 
Jacob,
Some comments based on the CODASYL decision table standard:
– DecisionTable Swap is a single-hit table. Only one rule fires. Normally rules do not overlap, but if you allow overlapping rules, the (possible) inconsistency is solved using the precedence convention (first hit applies).
– With DecisionTable1 Swap and DecisionTable2 Swap you intend multiple-hit tables. Usually this is clear from the table, but in this case it might require an extra indication, because the tables are identical to the first one.
Although the standard does not talk about executing rules between rule evaluations in this case (it does in other cases), it can be derived that DecisionTable 1 Swap is the intended multiple-hit table: because the standard talks about an inclusive-or relationship to relate the rules of a table to a case, but does not imply sequence.
DecisionTable 2 is an interesting alternative, introducing sequence (and possible side effects), but a little counterintuitive as a decision table…
Jan
Jan, thank you for your comments and for your valuable multi-year contribution to tabular decision modeling – our users would appreciate your list of artwork at http://goo.gl/4yuB6.
For years OpenRules supports different single-hit and multi-hit decision tables following your terminology. We even allow our users to construct their own types of decision tables using rules templates. The actual implementation of tables with built-in types “DecisionTable”, “DecisionTable1”, and “DecisionTable2” is done using predefined templates that users also are free to modify. I expect that when an preliminary version of DMN is available we will quickly provide rules templates to support any naming convention for different DT types. Our multi-year practice shows that we cannot limit ourselves to single-hit DTs, that I believe is intact with your approach. I wonder what are your preferences for explicit identification of different DT types? For example, instead of the keyword “DecisionTable1” we may use “DecisionTableMultiHit”, instead of the keyword “DecisionTable2” we may use “DecisionTableSequence”, etc. Alternatively, we may add additional parameters after the decision table name, e.g. “DecisionTable Swap MultiHit” with omitted “SingleHit” as the default.
Jacob, these table types are certainly fine. I like the idea of specific keywords. Other suggestions from your experience are always welcome.
A mathematician would never write x=3-x, since he would write y=3-x.
If you would recognize that there is a difference between the “old x” and the “new x”, and name them differently, then this story would become so much more simple…
Of course, the Olympiad organizers used “mathematician” with a negative connotation pointing to the fact that 30 years ago mathematicians frequently boasted that they can do programming with “their left hand” without actual understanding of the assignment operator. Also note the irony about a programming instructor.
Pingback: Alternatives to ‘If-Then’ Statements |