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 the WF rules example does show that it’s technical possible, it does a poor job on making these rules accessible and understandable by business users.
For me it was a nice opportunity to see if the Rule Manager from Acumen Business could actually show the rules and perform rule verification on the policy to discover any anomalies. 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 with the unfriendly name ‘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 is simple stupid. Where possible, avoid negated rule expressions and split or-statements in multiple rules.
You might wonder if we found an error with the rules example? The example works fine, however Microsoft uses rule priorities to ensure that rule DA_7 (priority -1) , is executed before DA_8 (priority 0). The problem that I have with rule priorities is that you throw away the declarative feature of the 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. So in a case where we have a male driver of 71 years old Microsoft rule engine will first assign ‘Typical Driver’ to the Driver class, and overwrites this value with ‘Senior’. Not very elegant, because now we also have to make sure that rule ‘DA_4’ must be executed after DA_7 and DA_8. If DA_4 would fire before, we make the incorrect conclusion that a 71 year old senior is eligible without checking his training certificate. Can somebody explain the word declarative? It’s obvious that we lost the baby with the bath water. So please only use priorities if you really have to. And we will show below that these few rules really don’t require rule priorities.
Finally, we see two disjoint rule networks in the Rule Network Graph! We have to wonder what happened with the rules that determine the ‘Training Certification’. And also how the DUI is related to the Training Certificate? Did they use the same specification?
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 will write in a later blog entry, how we are solving the First Order Logic with the Rule Manager.
If we would have just followed the Use case business rules specification, it’s all not that difficult. I always try to stay as close to the initial definition. 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 is probably my misinterpretation of the use case specification. But with this report it’s very easy to get these few issues clarified.