This decision modeling case study examines how the Corticon provides a way to automate a decision about whether a customer pre call is required or not.
Determine if a pre call is required for a customer delivery?
To make this decision we will need some rules.
Here are some sample rules provided by a customer
We will walk through the entire process of modeling these rules, including the discovery of errors, ambiguities and incompleteness using Corticon Studio.
The business object in this example is simply a Shipment which will have a number of attributes.
The data model to support the decision will be modeled in the Corticon vocabulary:
Figure 1 Shipment Business Object
This helps to make sure the data model makes sense
This can be done in the Corticon Testing tool which is built into Corticon.
We can also set up some expected results to verify that our rules are producing the answers we expect.
We’ll see during the demo how Corticon will automatically compare the actual and expected results and flag any variations once the rules have filled in the output column
Figure 2 Sample Test Data
There are no hard and fast rules about how to divide up the rules into groups, but a good way to start is to group the rules according to the main attribute that they are determining.
The book “The Decision Model” has some good guidelines on how to organize rules.
For our simple two rule example a single rule sheet is going to be adequate but more complex problems may require a rule flow that joins up all the individual rule sheets that are needed.
Going back to our original simplified set of two rules:
Here’s what the rule sheets might look like
Figure 3 Rules Modeled as Specified
If we run the test cases this is what we will get:
Figure 4 Test Results
Black indicates that the output agrees with the expected result. So for case 1 we got the right answer.
However red indicates that the output differs from the expected results.
So in case 3 we expected to get yes (because the shipment is perishable) but we got no.
When case 3 is selected, the corresponding rule statement will be highlighted below.
You can see that for case 3, two rules fired. The first one got the right answer, but then a second rule fired and overwrote the correct answer with the wrong answer.
This is a rule conflict.
Also notice that case 4 did not get a result at all. This means that there are missing rules in the rule sheet.
Unless we create a large number of test cases its quite likely that we might miss both of these situations.
Corticon has a better way to find these problems:
Back in the rulesheet we can use this button to automatically check for rule conflicts:
Figure 5 Conflicts Detected
This conflict occurs because (as written) both rules can file (when the shipment is perishable and the revenue is under $1000) and their results are different. If the results had been the same then it would not be a logical conflict.
To resolve this we need to make rule 2 more specific. In fact it should probably only apply when the shipment is not perishable. If we make that change then there will be no conflict:
Figure 6 Conflicts Resolved
Next we can use the completeness checker button to find the missing rules:
Figure 7 Completeness Checker Finds Missing Rules
The rule author still needs to determine the appropriate action in each case and add an appropriate rule statement:
Figure 8 Actions and Rule Statements
Figure 9 Final Test Results
The first decision we examined had a very simple data structure that was flat and the rules applied only to the data elements of that record
In this next section we’ll look at a more complex decision that involves rules that do matching between collections of objects.
The decision to be made is whether the shipments on a truck match the orders that the customer is expecting.
Figure 10 Vocabulary with Multiple Business Objects
Figure 11 Sample Data
Some possible business rules might be:
The rules should determine the following
Figure 12 Rule Statements
The natural language form of the rules
Figure 13 Natural Language Form
The Corticon expression form of the rules
Figure 14 Corticon Expression Form
Notice that this rule sheet has an extra section entitled “Scope”. This is what distinguishes Corticon from all other decision tables. It’s the key to writing rules that can operate on collections of data rather than single items of data.
Corticon has a rich set of operators for working with collections:
Figure 15 Collection Operators
In this rule sheet we make use of the ->exists operator to check if there is a shipment on the truck corresponding to the details of the customer order.
Figure 16 Use of the Exists Operator
Download PDF version.