Hit Policies

The term 'Hit Policies' refers to the way rules are chosen in a Decision Table during the execution of the model. A Decision Table typically contains a number of rules, and in the top left hand corner of the table there is a box that contains a single letter indicating which Hit Policy is applied (and therefore how the rules will be selected). The default is that rules in Decision Tables do not overlap, but if the rules do overlap (meaning that more than one rule could match a given set of input values) the Hit Policy indicator is required in order to recognize the table type and allow the decision logic to be unambiguously understood. Hit Policies can be divided into two groups based on the number of rules that match:

• A single rule is selected (Unique, Any, Priority,  First)
• Multiple rules are selected (Output Order, Rule Order, Collect)

Don't be too concerned about what each of these means as we will discuss them shortly and propose some basic recipes for choosing one Hit Policy over another - if in doubt choose the Unique (U) policy as it is the default and is the most commonly used. Enterprise Architect supports all the defined Hit Policies, and the validation facility - which we will learn about in the next section - uses the Hit Policy to determine whether the rules in a Decision Table have gaps or overlaps.

Choosing the correct Hit Policy is critical for the successful specification of the logic level of a Decision Model. As with many other things in modeling, there are Hit Policies that are in practice used more frequently because they turn out to be the best way to express a particular decision, others that are used infrequently and others that a rarely used at all. The Hit Policies include a letter code, name and a description, as shown here.

Single Rule Hit Policies:

• Unique (U): no overlap is possible and all rules are disjoint; only a single rule can be matched (this is the default)

• Any (A): there might be overlap, but all the matching rules show equal output entries for each output, so any match can be used

• Priority (P): multiple rules can match, with different output entries; this policy returns the matching rule with the highest output priority

• First (F): multiple (overlapping) rules can match, with different output entries; the first hit by rule order is returned

Multiple Hit Policies:

• Output order (O): returns all hits in decreasing output priority order

• Rule order (R): returns all hits in rule order

• Collect (C): returns all hits in arbitrary order; an operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs

Collect operators are:

• + (sum): the result of the Decision Table is the sum of all the distinct outputs

• < (min): the result of the Decision Table is the smallest value of all the outputs

• > (max): the result of the Decision Table is the largest value of all the outputs

• # (count): the result of the Decision Table is the number of distinct outputs

Unique

A table with a Unique (U) Hit Policy defines a set of non-overlapping rules, meaning that the rules are mutually exclusive or, in formal set terminology, disjoint. For a given set of inputs, one and only one rule will match, and a single set of applicable outputs will result. It is therefore a 'single hit single output' policy. It is undoubtedly the most commonly seen of all the Hit Policies because of its broad based application to a number of logic contexts, the fact that each rule can be reasoned about independently, and it is easy for business and non-technical stakeholders to understand.

The rule order is in free-variation, meaning that the order of the rules does not affect the outcome of the decision. This has the added benefit of allowing the rules to be ordered in a way that maximizes the overall understanding of the decision logic and also allows rules to be developed and reasoned about as independent entities.

Any

A table with an Any (A) Hit Policy defines a set of possibly overlapping rules, with the provision that if they do overlap then the output values are the same. It is therefore a single hit single output policy such that as soon as a rule matches all the input values the result will be returned, as any subsequent match (which could occur) will result in the same output values. The Any policy, like Unique, is quite commonly used and its main advantage - and the reason it is used instead of Unique - is that it reduces the need to introduce conditions to exclude the condition of rules that would otherwise result in the same outcome. It is therefore always possible to create an equivalent table with a Unique Hit Policy, but the table with an Any policy will most often be preferred because it is easier to understand and also is not as tedious to create, as there is no need to ensure that every permutation of input values matches one and only one rule.

In this example the order of the rules has been defined to facilitate the readability of the table, making the logic more transparent. Notice that the first three rules have the same outcome and have been ordered to make the logic of the table more transparent.

When a table that would otherwise use a Unique policy is seen to have a lot of repetitive rules with the same outcomes, consider using an Any Hit Policy. One of the benefits of this Hit Policy is that it makes the Decision Tables easier to understand and the logic more transparent.

Priority

A table with a Priority (P) Hit Policy defines a set of overlapping rules, meaning that the rules might have differing outputs. It is therefore a single hit/single output policy such that as soon as a rule matches all the input values the result will be returned, as any subsequent match (which could occur) will result in the same output values. The Priority policy, like Any, is quite commonly used, and its main advantage and the reason it is used instead of Any is it supports situations where there is an enumerated list of output values. The order in which the results are listed in the Output column is what determines the rule order and the rule that is selected is the one with the highest priority.

First

A table with a First (F) Hit Policy defines a set of possibly overlapping rules with the provision that the order of the rules specifies which rule should be hit. This means that for a given set of inputs the first rule in the table order whose inputs match will be fired and its output will result. It is therefore a single hit single output policy. It is not commonly used and a number of proponents and experienced Decision Modelers prefer not to use it at all, given that it contravenes a best practice rule that the order of rules in a Decision Table should not influence the result. It is, however, quite useful with tables that have a small number of rules and where there are some highly important and perhaps less frequently occurring conditions that would logically override any more-frequently occurring, less important input conditions.