Gaps in Rules

Decision rules must be complete before they are implemented into a production system or service. This is imperative because they must have complete coverage of all possible inputs. There is a catch-all condition in the form of a Default Output Entry that can be defined for a table, but many experienced modelers prefer to ensure that all inputs are logically covered. It is also common for less-seasoned modelers to exclude rules for inputs that are not possible within the context of the input domain or universe. A more experienced modeler will know that anything is possible even if the current empirical results suggest otherwise, and will therefore ensure these outlying inputs are covered by the rules. Enterprise Architect's decision table validation can be executed to find any gaps in the rule coverage. This is a profoundly useful facility, as an error in the decision logic can result in unwanted outcomes in an implementation of the rules and even, in some contexts, in catastrophic effects  This diagram shows a simple decision model of a single decision with two input data elements; it has been created to exemplify the way the validation can be used.

The second screenshot shows a partially complete decision table with just the Gold customers defined in rows. The modeler has inadvertently created rules that contain a gap. This is a simple demonstration and it should be easy for the reader to locate the gap, but in much more complex tables with many more rules and inputs it can be quite challenging to locate the issues.

We are able to use Enterprise Architect's built-in validation facility to find any errors with the logic of the rules. In this case the modeler has been remiss and not covered every valid input value. There is not a rule defined for a 'Gold' level customer with a Sales Value of '(40,000 - 50,000]'.

When the validation is run Enterprise Architect will open the output window and display the validation errors, indicating that there is in this case a 'Completeness Violation' and also which rows of the table are implicated. As stated earlier this example is deliberately trivial to demonstrate the feature and it is easy to identify the error by scanning the table rules, but with more complex tables errors can be very difficult to locate.

In this example allowed values have been entered for Customer Level, namely 'Gold, Silver, Bronze'. When defining the rules the decision analyst has forgotten to include rules for the input value of 'Bronze'.

When the validation is run the error will be reported as a gap since one of the enumerated values defined for Customer Level has no coverage at all.

The error can be corrected by adding another rule that covers the case where the Customer Level is Bronze. This would then ensure that the rules are syntactically and logically correct and when the validation was run there would be no errors and no warning generated.

The validation generated to the output window would be: