Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
More examples of ambiguity in rule modeling illustrate how to account for uncertainty in Progress Corticon.
In my last post, “Clearing Up Ambiguity in Rule Modeling,” I discussed how to resolve ambiguity in business rules modeling using example from real Progress® Corticon® projects. Resolving ambiguities can be critical in decision-making instances where yes or no answers are a matter of health, welfare or financial risk.
While risk is an inevitable part of life, businesses need to be certain of what they do know, and have a grasp of the probability of certain outcomes to avoid it. Just as in life, businesses face decisions that have to account for an amount of uncertainty. But you can account for uncertainties in business rule models by mathematically aggregating certainties as different rule validations contribute to probabilities.
The sheet below has an ambiguity, since a risk rating can only hold one value.
Figure 8: Risk rating rule containing ambiguity.
Should this be flagged? Yes, because one rule will overwrite the results of the other depending on the order of execution.
Figure 2: Is there an ambiguity in this rule model?
Is there a real ambiguity here? No. Applicant.age and Applicant.hobby rules are independent—they affect different attributes. In addition, hobbies are generally independent of age. So what should we do about the next example?
Figure 3: A rules model defining an ambiguous business attribute.
Semantically this model defines a business attribute that cannot exist, because any particular age must fall into one of the three ranges defined by the conditions. So, should Corticon flag this as an ambiguity?
In the next example, we have two different attributes that are saying something about age.
Figure 4: Rule determining fitness for “young” category.
Clearly, someone cannot be under 21 and over 65 at the same time, so this cannot be an ambiguity. But Corticon does not know that, and is correct in flagging this rule as an ambiguity for the business user to resolve. The problem arises because the first and second conditions are mutually exclusive (in the real world). There is a missing business rule—the one that says that an applicant cannot be less than 21 and over 65.
We could capture the missing business rule this way:
Figure 5: Rule model with missing business rule added.
The ambiguity goes away completely if it’s modeled like this. Now we can explicitly state the previously hidden rule about not being under 21 and over 65 at the same time.
Here’s a real world example that illustrates this same problem. It comes from an actual proof of concept (POC) done several years ago. The client had rules similar to the model below.
Figure 13: Sample business role model copied from Excel into Corticon.
The customer’s rules, expressed as an Excel spreadsheet, were simply copied and pasted into Corticon. It’s not important to read the actual rules.
In this rule model, there are 42 attributes, each of which can be Y or N, and the rule sheet has 47 defined rules. How many missing rules do you think there are? Running the completeness checker on this model is somewhat amusing:
Figure 14: Corticon Studio completeness check of rule sheet.
It took Progress® Corticon® Business Rules Studio many minutes to come up with this result, but it did it. And the ambiguity checker turned up 96 ambiguities among the 47 rules!
Figure 15: Corticon ambiguity checker results.
Defining overrides would be a very painful task. Defining the sets of actions or rules to suppress false ambiguity would be completely unmanageable in this model. The lists would be so long as to be unreadable.
Apart from the fact that the rule sheet is overwhelming, the real problem is that the model was fundamentally wrong. Many of the possible scenarios wouldn’t occur in the real world. But if that’s the case, then they shouldn’t occur in the rule sheet either. The reality is that many of the attributes in this model represent the state of work on one queue or another. Work cannot be in more than one queue at any one time. In this model, the vocabulary was wrong! Restructuring the vocabulary made a huge difference.
If we were stuck with an existing (bad) data model that we might not be able to change, at least not outside of Studio, how could we solve the issues?
We have to capture somewhere in the rules the idea that queues are mutually exclusive as a real business rule, not as hidden plumbing. This can be done easily be creating a helper rule sheet—which can also be checked for ambiguity—that expresses this knowledge and simply maps from several dozen Y/N attributes into a single attribute that can take dozens of values, indicating which of the many mutually exclusive queues the work can be in.
Now the ambiguities arising from this simply vanish—we shouldn’t need a complicated solution to deal with a problem that shouldn’t be there in the first place. Otherwise, we are just making a bad situation worse. With a better vocabulary, we’d end up with much simpler rules like this:
Figure 16: A simpler business rule sheet.
We can further improve the rules by re-partitioning into smaller orthogonal ones. The visual appearance of the original with all its gaps gives us a clue how it should be divided up. For example, rules 31 to 46 appear to form a discrete set dealing with the “move to HCO.”
Figure 10: Discrete set of rules on the rule sheet that should be re-partitioned.
Any ambiguities that might arise here as a result of the different values in the second action, which is tracking which rule executed, are not true ambiguities. The important action “move to HCO” is the same in all cases.
If we could simply “hide” action 2 from the ambiguity checker we’d be fine. Unfortunately, disabling action 2 does not prevent the ambiguity checker from including it.
Stay tuned for my next post, in which I will discuss modeling rules to account for uncertainty and probability.
To stay updated on the latest tips, tricks and help from Progress Corticon developers and users, follow the Corticon Community. There you can access RulesWorld, the Corticon wiki; find the latest documentation; and speak with Corticon experts from around the world.
View all posts from Michael Parish on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.