Programmers can produce better rules logic by clearing up ambiguity in business rules modeling.
In building complex computer systems, programmers must interpret specifications, typically written in English, to produce a complete and unambiguous sequence of code that implements the specification. This code may determine eligibility for welfare benefits, or make medical diagnosis or determine where planes should fly. So it’s important that the decision logic is correct.
Figure 1: Is this headline ambiguous to you?
Unfortunately, specifications written in English are often incomplete and ambiguous. Consider the example to the right:
- Is this headline meant to convey the news that Republicans harshly questioned the head of the IRS about lost emails?
- Or did the Republicans cook the IRS Chief, using emails as the fuel for the grill fire?
What is Ambiguity in Decision Making?
For decision making, ambiguity means there can be two or more interpretations for the same set of facts. I’ve illustrated some examples in Progress® Corticon® Business Rules Modeling Studio. For example, consider these rule model examples:
Figure 2: A simple rules model example.
Figure 2
- If it’s raining, let’s go to the movies.
- If it’s hot, let’s go to the beach.
Figure 3: A rules model suggesting a meal when certain conditions exist.
Figure 3
- If it’s cold, let’s have hot soup.
- If we’re on a diet, let’s have salad.
While my examples may be considered humorous, misinterpreting complex rules in a business context can have dire consequences. So how can a programmer hope to produce good code if the specification he is given is flawed at the outset?
Create Complete, Unambiguous Specifications for Business Logic
Most programming languages provide no help to the programmer in identifying ambiguities and missing logic. Extensive testing can help, but usually such errors are not detected until late in the project. Unfortunately, that can be right at the time when the business users do acceptance testing and declare, “Well, that’s not right!” By then, fixing the problem becomes very expensive.
Corticon is a tool that can be used by both the programmer and the business user to create business rule specifications that are complete from the first question to the final answer. Without the need for interpretation at key decision making points due to ambiguities of language.
Business users can define, in English, the rules, regulations, policies and other guidelines that affect the way the business must run. The user can also easily identify rule conflicts and omissions. The programmer can then take that business logic and build an application implementation that is conflict-free and complete.
Resolving Ambiguity Example
Figure 4: Decision Table 1.
Suppose we have the decision table above. Notice how much harder it is to spot ambiguities when the conditions are generic.
Did you spot this ambiguity?
Figure 5: Ambiguities spotted in Decision Table 1.
Specifically in this particular case:
Figure 6: How would you resolve this particular ambiguity in Decision Table 1?
Decision Table 1 can be resolved in a number of ways:
- Perhaps there is another attribute Thing.a5, whose value serves to distinguish the two cases. Adding that as an extra condition would remove the ambiguity.
- We could set an override for one of the two rules, if it’s always the case that one rule overrides the other.
But, what if there is no other data that serves to distinguish the two cases? The real world situation is that in some cases the result is X, and in some cases it is Z. How should we model it?
One possible way is to create two results—one for X and one for Z—and assign a probability for each.
Figure 7: Remodeled Decision Table 1 with probabilities added.
Now, whenever the conditions for Rule 2 arise we preserve the duality of the result by showing that it can be both X and Z (although with different probabilities for each).
This type of rule might arise in a medical diagnosis application where the results of lab tests a1..a4 in Case 2 are not sufficient to distinguish completely between the two possible diagnoses X and Z. Maybe at a future date we might discover a test that does accurately distinguish the two cases, and at that point in time we can update the rule.
This idea of introducing probabilities, or uncertainties, into results will be explored more fully in a future post. There I will discuss how certainties can be mathematically aggregated as different rules contribute their probabilities.
Stay tuned for my next post, in which I will present more examples of ambiguous rule models, and how to account for them.
Learn More in the Progress Corticon Community
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.