The decision table verification and validation has come to a point where it is time to take a pause on adding new features, but I’m hoping to continue the work before the end of this year. One big missing feature is finding missing ranges and reporting about incomplete decision tables.
This blog entry will be an update to a previous entry that can be found here.
Features that made it into the next Final release
The features are currently in so any future release will include them. Here is a simple demo video showing the V&V issue panel and how it works in real time.
The different issue levels are:
- Error – Serious fault. It is clear that the author is doing something wrong. Conflicts are a good example of errors.
- Warning – These are most likely serious faults. They do not prevent the dtable from working, but need to be double checked by the dtable author. Redundant/subsumptant rules for example, maybe the actions need to happen twice in some cases.
- Info – The author might not want to have any conditions in the dtable. If the conditions are missing each action gets executed. This can be used to insert a set of facts into the working memory. Still it is good to inform that the conditions might have been deleted by accident.
The verification and validation looks for the following issues:
Redundancy
To put it simple: two rows that are equal are redundant, but redundancy can be more complicated. The longer explanation is: redundancy exists when two rows do the same actions when they are given the same set of facts.
Redundancy might not be a problem if the redundant rules are setting a value on an existing fact, this just sets the value twice. Problems occur when the two rules increase a counter or add more facts into the working memory. In both cases the other row is not needed.
Subsumption
Subsumption exists when one row does the same thing as another, with a sub set of the values/facts of another rule. In the simple example below I have a case where a fact that has the max deposit below 2000 fires both rows.
The problems with subsumption are similar to the case with redundancy.
Conflicts
Conflicts can exists either on a single row or between rows.
A single row conflict prevent the row actions from ever being executed.
 |
| Single row conflict – second row checks that amount is greater than 10000 and below 1 |
Conflict between two rows exists when the conditions of two rules are met with a same set of facts, but the actions set existing fact fields to different values. The conditions might be redundant or just subsumptant.
The problem here is, how do we know what action is made last? In the example below: Will the rate be set to 2 or 4 in the end? Without going into the details, the end result may be different on each run and with each software version.
 |
| Two conflicting rows – both rows change the same fact to a different value |
Deficiency
Deficiency gives the same kind of trouble that conflicts did. The conditions are too loose and the actions conflict.
For example:
If the loan amount is less than 2000 we do not accept it.
If the person has a job we approve the loan.
The problem is, we might have people with jobs asking for loans that are under 2000. Sometimes they get them, sometimes they do not.
Missing Columns
In some cases, usually by accident, the user can delete all the condition or action columns.
When the conditions are removed all the actions are executed and when the actions columns are missing the rows do nothing.
 | |
| The action columns are missing |
 |
| The condition columns are missing |
