Overlapping Rules

The rules that are defined for a Decision Table with a Hit Policy of 'U' (signifying Unique) must be discrete and not overlap. This is an easy thing to overlook, even for experienced Decision Modelers, and particularly when a table becomes complicated and has a large number of inputs and rules. It is common for overlap errors to be introduced with the use of range expressions in FEEL (Friendly Enough Expression Language) using brackets (round and square) which have different meanings.

Overlapping rules are permitted in Decision Tables with other Hit Policies defined, for example:

• A table with a Hit Policy of A (Any) can have overlapping rules, as long as all overlapping rules have the same Output Value
• A table with a Hit Policy of P (Priority) can have overlapping rules even when the output values are different
• A table with a Hit Policy of C (Collect) can have overlapping rules even when the output values are different

Using our illustration from the previous section, we will show a simple example of overlapping caused by an error in the use of FEEL expression brackets, as we have just discussed. This screen capture shows an error of two rules overlapping each other, where the problem is a little bit more difficult to identify. The error is introduced because Rule-#2 includes the use of a square bracket, which can effectively be rewritten as 'Sales Value >= 10,000 and Sales Value <= 50,000'. The issue arises because Rule-#1  also covers the case where 'Sales Value = 50,000'  so Rule-#1 and Rule-#2 are overlapping.

Once again we can use Enterprise Architect's built-in validation facility to help us identify any violations. In an analogous way to the completeness rules, the validator can find the errors that, if the table were any more complex, would be difficult to find. This illustration shows the violation generated to the System Output window identifying the rules and the values that are in violation.