Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile 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
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
A complete cloud platform for an app or your entire digital business
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
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:
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 3: A rules model suggesting a meal when certain conditions exist.
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?
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.
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:
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.
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 for appropriate markings.