Managing Change and Complexity - Static Rule Analysis and Semantic Queries
One of the fascinating things about ILOG is that you bump into engineers in the hallways with very deep knowledge of specific domains: from the mathematical programming geniuses that work on the CPLEX optimization products, to engineers that have spent 10+ years researching graphical layout algorithms for large-scale visualization, or that have deep expertise in building natural language parsers. One such group, working on the JRules product, are our static analysis experts. This team’s mission is to take a set of rules and automatically detect potential logic errors or warn of suspicious usage of rules.
Customers use static rule analysis to help ensure the logical integrity of a set of rules, while the rules are undergoing daily edits by a team of Policy Managers. Static rule analysis provides a safety-net, allowing the policy managers to make changes with confidence. It also tends to promote good usage of rules, as it can help prevent common anti-patterns, such as heavily order-dependent rules, or rules that subsume other rules.
The Semantic Query technology is built on top of the results of semantic rule analysis. This is a technology that I find fascinating and is state-of-the-art. Semantic queries allow a customer to use a simple query language to ask interesting semantic questions of a Rule Project, such as “Which rules apply to customers aged 35 or less?”.
Using some simple (contrived) examples I will show the sophistication of the static rule analysis technology shipped in JRules. If you’d like to experiment with these rules you can download the JRules trial, and the Rule Project I created while writing this post.
Rule Project used to demonstrate Static Rule Analysis
Types of Checks
JRules static analysis supports the following checks:
- Rule never applies
- Rule may cause domain violation
- Rule is self-conflicting
- Rule makes other rule redundant
- Rules are conflicting
- Rules have equivalent conditions
- Rules are equivalent
There are two types of checks, those that operate on a single rule independent of other rules (checks 1-3) and those that operate on a set of rules (checks 4-7). The single-rule checks are applied automatically while editing rules in Rule Studio, whereas the more computationally costly inter-rule checks are accessible through an HTML report in both Rule Studio and Rule Team Server. Details of these checks are available in the JRules documentation. Unlike other vendors, we choose to implement these checks using a deep semantic analysis of the rules, and do not rely on shallow and error-prone syntactic or textual analysis.
I will describe some of the more interesting checks below.
Rule Never Applies
Writing a rule whose conditions are logically false is always a bad idea! Such a rule will never be fired by the rule engine and is merely cluttering the Rule Project. Usually rules that never apply are created by copy/paste errors or other typographical errors. In the example above, the sloppy rule author (me!) probably meant “any of the following conditions…”!
The second rule is never applicable because Customer.age has been specified as a positive integer using a domain (see below).
Rule May Cause Domain Violation
Any attribute in the Business Object Model (the model you write rules against) can have a domain associated with it. A domain can be an enumeration or a valid numeric range for example. In the sample Rule Project I have specified that the Customer.age attribute has a valid range from [0,150] (from 0 to 150 inclusive) and the Customer.salary attribute has a range from [0,1000000]. The domain for Result.score is [0,100]. JRules therefore warns me that assigning Customer.salary to Result.score may result in “unsafe execution”. Not only can JRules detect these cases, but it can also explain when and why they occur:
The rule below shows the deep domain analysis that is occurring — even though Customer.age is assigned to Result.score (and the domain for Customer.age is larger than that of Result.score) no domain violation is reported due to the conditional check for “age < 30" in the rule:
Rule Makes Other Rule Redundant
The first rule makes the second rule redundant. However more complex cases are also possible. As you can see in the examples below, these would be difficult to detect using a simple search or naive syntactic analysis.
Rules are Conflicting
Conflicting rules are defined as two rules whose actions set different values to the same BOM attribute/member. They are very hard to detect manually, especially once you have hundreds of rules.
The natural-language explanation facility is extremely useful in these cases, as they can be tricky to understand by just looking at the rules. For example:
Even people with a programming background find Boolean algebra tricky, and it can take a while to find these cases manually! How about this conflict for example?
Rules are Equivalent
The Rules are Equivalent check detects rules that are exactly logically equivalent — almost always an error. For example, the two rules below are logically equivalent:
Example Semantic Queries
Whereas “checks” are a safety-net and reactive in nature, Semantic Queries allow you to become pro-active in how you manage and evolve your Rule Project. For example, for audit purposes it may be very interesting to determine the list of rules that may fire on customers that live in California, or the list of rules that can cause a Customer’s credit score to be less than 200. Using Semantic Queries the policy manager can perform regular impact analysis to understand the relationships between rules, and the data that cause rules to fire.
May Apply When
The “May Apply When” style query retrieves all the rules that are not prevented from firing for a specific semantic condition (in this case, when “Customer.salary > 20000″). I.e. in this case many rules are returned, even rules that do not check the customer salary because they may fire.
May Become Applicable
In contrast to, “May Apply When”, “May Become Applicable” only returns the rules that will fire for a specified semantic condition, and that tests one of the supplied attributes. In this case a single “Wealthy” rule is returned as this is the only rule that specifically tests the Customer.salary attribute:
May Lead to a State
“May Lead to a State” queries are used to retrieve the rules based on their modifications to attributes - including the values that may have been assigned. In the example above we query for the rules that may be responsible for assigning a customer a score between 50 and 80.
