Once a year, during the
business rules symposium, vendors of rule engines can show how they implement a general use case that contains many business rules. This use case is known as the UServ Product Derby. You can read the specifications
here.
A few years ago I was actively involved with the implementation using Aion (from CA). Last year I put together the web front-end for Corticon. And recently I've been examining the implementation from Microsoft with WF rules.
Microsoft's example (download
here) illustrates the
technical feasibility of using WF rules. Although this example shows that it's technical possible, it does not highlight the business rules management, rule audit trail and rule traceability.
For me it was a nice opportunity to see if the Rule Manager from Acumen Business could visualize the rules and perform rule verification on the policy to discover if the actual implementation was logically correct.
We start this blog series with a closer look at the 'Driver's Eligibility' policy as defined in the
use case. After a few adjustments on the Rule Manager, I produced this report (
PDF,
XPS) from Microsoft's example implementation.
The part that got my attention right away was the discovered contradiction.
On first look, the rule DA_7 is rather complicated. It is a typical programmer's construction to use a
not (expr and expr)Such a statement has probably a few nanoseconds advantage on your processor. However do we really want the business user to decipher this statement by applying
De Morgan's law?
Just keep it simple stupid. Where possible,
avoid negated nested expressions and split or-statements in multiple rules.You might wonder if we found an error with the rules example? The example should work fine, however the example uses rule priorities to ensure that rule DA_7 (priority -1) , is executed after DA_8 (priority 0). The problem that I have with rule priorities is that you throw away the declarative features of a rule engine. Suddenly the rule writer has to be aware of priority values in order to achieve the desired result.
Also note that DA_7 does not halt the rules engine. In a case where we have a male driver of 71 years old, the rules engine first assign 'Senior' to the Driver class, and consecutively overwrites this value with 'Typical Driver'. Now we also have to make sure that rule 'DA_3' must be executed after DA_7 and DA_8. If DA_3 would fire before, we make the incorrect conclusion that a 71 year old senior is eligible without checking his training certificate.
A second problem related to the priority and overwriting conclusions is that a rule audit report would show incorrect results. So please
use rule priorities careful. We will show below that the Driver Eligibility policy actually don't require priorities.
Finally, the generated rule graph shows two disjoint rule networks. We have to wonder what happened with the rules that determine the 'Training Certification'. Also how is the DUI related to the Training Certificate? It seems that the example is not a complete implementation of the specification. Visualizing a rule policy in a complete rule graph does make the business rules code review an easy task.
Again, Microsoft example was only illustrating the technical aspects of WF rules. And the example shows how you can achieve First Order Logic with WF rules. (For All Drivers do...)
I changed the Driver Eligibilty policy to remove the contradiction and remove the priorities to keep the rules 100% declarative. We let the rules engine decide which rule should be executed next. Here is a produced report of my rewrite (
PDF,
XPS).
There are no disjoint rule graphs, no self contradictions within the rules, and no rule anomalies among rules. We do discover some incompleteness. E.g. is a Female of 24 years old eligible?
This incompleteness can be a misinterpretation of the use case specification, or an actual incompleteness in the specification. But with this rule report it's very easy to get these issues clarified.
