Task: Transform Rules

Refine Rule as Atomic

A rule is atomic if it cannot be further decomposed without losing meaning. Atomicity is desired for understandability, ease of maintenance

Make sure each rule has one result
When expressed an inference rule or an action enabler, do not allow ANDs on the right hand side; break the rule
- IF A THEN do(B) AND do(C) can be rewritten as two rules IF A THEN do(B) and IF A THEN do(C)
When expressing an inference rule or an action enabler, do not allow ORs on the left hand side; break the rule
- IF A OR B THEN do(C) can be rewritten as two rules IF A THEN do(C) and IF B THEN do(C)
When expressing constraints and guidelines, do not allow for ANDs
- A driver must be 25 years old or older AND must have good credit rating
- A driver must be 25 years old or older; a driver must have good credit rating
Make sure that each rule contains only necessary conditions; don't over-constrain the rule applicability

Remove redundant rules

This step is important to avoid developing complex rule sets. Redundant rules are

Duplicated rules
Duplicated through some transformations (renaming, inversion of conditions, etc.)
Redundancies among rules that create a common data value or a common truth value, or initiate a common action

This step is made simpler if we make the rules atomic, for otherwise, we will be lost in the equivalence of complex logical formulas (e.g. If NOT (A AND B) is equivalent to IF (NOT A) OR (NOT B)). There are for sure more subtle forms of redundancy: IF A AND B THEN C is equivalent to IF (NOT C) THEN (NOT A) OR (NOT B). Some time changing the order of conditions can help to highlight same rules: IF A AND B THEN C is the same as IF B AND A THEN C

Remove inconsistency rules

Overlapping rules are partially redundant because they are not semantically equivalent but they point to problems: One rule may say IF A AND B THEN C, the other says IF A THEN C. The question is, is B really needed to infer C? One of the two rules should be eliminated.

It is also possible to get semantically equivalent conditions, contradictory conclusions: two rules like IF A THEN B; and IF A THEN NOT(B) are leading us to have two conflicting rules, probably coming from two different sources. Typically, this is symptomatic of the fact that we are missing some necessary conditions in either rule (or both, e.g.: IF A AND C THEN B; IF A AND D THEN NOT(B))

Another standard case is around the same conclusions derived from contradictory conditions: rules like IF A THEN B; and IF NOT (A) THEN B: Logically, this means that the conclusions should always be true. This is symptomatic of the fact that the condition is really not relevant to the conclusion

Ensure completeness among rules

We are often considering three kinds of completeness:

Make sure that all the possibilities are covered for a given rule pattern. If you have a rule that says "loans for value greater than 250,000 $ should be approved by the branch manager", it does not tell us who must/can approve loans of value less than 250,000 $
Make sure that all derived data in the object model has corresponding computation or inference rules. This involves computed attributes, qualifications (e.g. customer status, account type, etc.)
Make sure that integrity and cardinality constraints are somehow represented. Either in the object model or in rules

Analyze rule volatility

This a good timing to ask the business user how often the rule will change once we did the rule transformation.

Understand rule dependencies, rule sharing

A rule R1 depends on a rule R2 if the enforcement of R2 results into a situation where R1 is relevant (or needs to be enforced). A simple common example, is a rule R2 which is creating new data, or is modifying existing data that is tested by R1.

Understanding dependencies help determine the likely "execution" sequence of rules. The execution sequence is useful for rule analysis to detect undesirable dependencies to plan rule testing. For the implementation the execution sequence is useful to understand how the results will look like: some rule engine tools will determine that sequence automatically, and on the fly (chaining). If we implement business rules in a procedural fashion, we need to understand the execution sequence to enforce it

Some of the undesirable dependencies include circular dependencies leading to infinite loops. Others will cause us to re-evaluate rule jurisdiction

When the work is done the last step is to look at how rule can be shared between process flow. Rule sharing is an important step of the analysis. It can be done once we have progressed in the rule set implementation. Rule re-factoring activity can help on implementing some rule sharing pattern.