Task: Transform Rules |  |
Transform the rule to avoid ambiguity and make them more atomic
Disciplines: Rule Analysis
Purpose
The goal of the this task is to transform the rule in an artifact the business user can understand, and rule writer can understand, implement, test and maintain.
Relationships
Roles | Primary Performer: Rule Analyst | Additional Performers:
Inputs | Mandatory: Fact Model Logical Data Model Rule Description Document | Optional: None
Outputs | Fact Model Logical Data Model Rule Description Document
Main Description
Rule Analyst has to study the rule discovered and try to transform it so that the implementation and the management of the rule will be more easy. This includes transfoming the rule in atomic element using a syntax without ambiguity, remove redundant rules, conflicting rules, and finally try to redefine the scope of the rule by searching by non-handled cases. At this stage rule analyst can build some rule template which are built from rules that have the same set of conditions with some little variations: adding new value in test condition, or new condition.
Steps
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.
Illustrations
Examples | Rule Atomicity
Key Considerations
This activity will also be done during the implementation of the rule set, but it is started during the analysis, so we are detailing it in this context.
More Information
Guidelines | Boolean logic or algebra
ABRD Practice Copyright.