Introduction

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.

Basic Decision Modeling

Identify the Business Decision(s) to be made

Determine if a pre call is required for a customer delivery?

Collect and Review Rules needed for each decision

To make this decision we will need some rules.

Here are some sample rules provided by a customer

  • If the shipment contains perishable items then a pre call is required
  • If the customer's annual revenue is under $1000 then a pre call is not required

We will walk through the entire process of modeling these rules, including the discovery of errors, ambiguities and incompleteness using Corticon Studio.

 

Identify Business Objects (Entities)

The business object in this example is simply a Shipment which will have a number of attributes.

 

Create a Corticon Vocabulary

The data model to support the decision will be modeled in the Corticon vocabulary:

 

Figure 1 Shipment Business Object

Create Sample Data

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

 

Decide how the rules need to be grouped into Rule sheets

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.

For each rule statement create a rule column that connects the conditions to the actions

Going back to our original simplified set of two rules:

  • If the shipment contains perishable items then a pre call is required
  • If the customer's annual revenue is under $1000 then a pre call is not required

 

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:

Ambiguity Checking

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

Final Test Results

Figure 9 Final Test Results

 

 

A More Complex Decision

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.

The Vocabulary

Figure 10 Vocabulary with Multiple Business Objects

Sample Data

Figure 11 Sample Data

The Business Rules

Some possible business rules might be:

  • Is there a truck scheduled for this customer with the right item and right quantity?
  • Is there a truck scheduled for this customer with the right item but insufficient quantity?

 

The rules should determine the following

Figure 12 Rule Statements


The Rulesheet

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

Download PDF version.