As a response to the DMCommunity.org challenge, I will describe an OpenRules-based implementation of the highly popular use case known as “UServ Product Derby”. The use case deals with automobile insurance problems including eligibility and pricing decisions for a hypothetical insurance company “UServ”. Its detailed description can be found here. Our implementation may be considered as another complex-enough example of the DMN approach.

We will call our decision “DetermineAutoInsuranceEligibilityAndPremium”. On the very high our decision model may be presented using the following decision requirement diagram:

This diagram was created directly in Excel file and all elements have hyperlinks to the proper implementations in different xls-files. Our decision deals with 3 information sources:

• Client
• Drivers
• Cars

One client may contain multiple drivers and cars included into its insurance policy.

We implemented the above top-level decision using the following OpenRules table of the type “Decision”:

As you may see, the second sub-decision “CalculateClientPremium” will be executed only when the condition “Client Eligibility Rating Is Eligible” is true. Again, as everywhere, the calls to other decisions and decision tables  are linked to their Excel implementations making it very convenient to navigate through xls-files and tables.

The specification document describes two types of rules that knowledge sources for these two sub-decisions:

• Eligibility and premium calculation rules that should be applied to all drivers and all cars
• Eligibility and premium calculation rules that should be applied to the entire client’s policy.

1. Decision “DetermineClientEligibilityRating”

After analyzing the entire sub-decision “DetermineClientEligibilityRating” we may describe it using the following diagram:

This section describes the implementation of all eligibility decisions and decision tables as they were presented in the specification going through the above DRD in the bottom-up way. The DRD for the second sub-decision “CalculateClientPremium” will be described in the section 2.

1.1. Automobile Eligibility for One Car

The decision “DefineAutoEligibilityRating” consists of 3 sub-decisions:

1.1.1 Define Potential Theft Rating

Here is its specification description:

Here is the proper OpenRules implementation in Excel:

As you may see, here we decided to use a MultiHit decision table as some rules (such as “If Auto Price is More than 45,000 then High”) may override previously executed rules.

1.1.2. Define Potential Theft Rating

Here is its specification description:

Here is the proper OpenRules implementation in Excel:

Here again we used a MultiHit decision table  setting first the default rating “Extremely High” that may be overridden as High, Moderate or Low and them Extremely High again. In the included Car Features, we are using different types of air bags listed through commas.  It seems to be very close to the above plain English description.

1.1.3. Define Auto Eligibility

Here is its specification description:

 Here is the proper OpenRules implementation in Excel:

The default rating “Eligible” may be overridden inside this multi-hit decision table.

1.1.3. Decision “Define Auto Eligibility Rating”

The described 3 decision tables are combined in the following decision:

1.2. Driver Eligibility for One Driver

The decision “DefineDriverEligibilityRating” consists of 3 sub-decisions:

1.2.1 Define Age Category and Training Certification

Here is its specification description:

In OpenRules we presented these rules as two separate decision tables:

Here we used single-hit decision tables (the default one). For example, in the first table we put the category “Regular” into the last rule that will be executed only when all previous rules fail.

1.2.2 Define Driving Record Category

Here is its specification description and OpenRules implementation:

1.2.3 Decision”DefineDriverEligibilityRating”

Now we may combine the above 4 decision tables into one decision:

1.3. Eligibility Scoring

A client’s eligibility for auto insurance is determined by a scoring system based on the risk ratings for various categories. The lower the score, the better the eligibility rating.

1.3.1 Define Auto Eligibility Score

Each car may contribute to the Client Eligibility Score according to the following rules:

The rules for one car are presented in OpenRules as follows:

1.3.2 Define Driver Eligibility Score

Each driver may contribute to the Client Eligibility Score according to the following rules:

The rules for one driver are presented in OpenRules as follows:

1.3.3 Define Client Eligibility Rating and Score for ALL drivers and ALL cars

Now we can define eligibility ratings  and accumulate eligibility scores for ALL drivers and ALL cars using the following  OpenRules decision table:

Here the first rule simply initializes the Client Eligibility Score with zero.   OpenRules includes a special standard action “ActionRulesOnArray” that executes the rules defined in the sub-column “Rules” (e.g. “DefineDriverEligibilityRating”) for all elements of the array defined in the sub-column “Array of Objects” (e.g. “Drivers”) that have a known type defined in the sub-column “Object Type” (e.g. “Driver”). This way we execute all previously defined rules for all drivers and all cars.

1.3.4 Adjust Eligibility Score based on the Client Segment

We also need to adjust the eligibility score as described in the specification:

or in OpenRules:

1.3.5 Define Client Eligibility Rating

Finally, according to the specification:

or in OpenRules:

1.4. Decision “DetermineClientEligibilityRating”

Now the final decision “DetermineClientEligibilityRating” simply executes decisions described above in the sections 1.1, 1.2, and 1.3:

2. Decision “CalculateClientPremium”

After analyzing the entire sub-decision “CalculateClientPremium” we may describe it using the following decision requirement diagram:

2.1. Define Combined Auto Premium for One Car

To calculate auto premium for one car, we need to execute 3 steps described below.

2.1.1 Define Auto Premium

According to the specification:

or in OpenRules:

2.1.2 Define Auto Discount

According to the specification:

or in OpenRules:

2.1.3 Apply Auto Discount

To apply the discount calculated in the decision variable “Auto Discount Percentage” to the variable “Auto Premium” we may use the following expression indie the decision table:

 

Comment. In OpenRules expressions you may write $R{Auto Premium} to refer to real variables or $I{name} for integer variables, or simply ${name} for text variable. Any commonly used arithmetic and logical operators, standard Java or third party functions could be also freely used in OpenRules expressions.

2.1.4 Define Combined Auto Premium

We may execute 3 previous decision tables as follows:

2.2. Define Driver Premium for One Driver

The specification states how to calculate a driver premium for each driver in the client’s policy:

In OpenRules we may represent these rules as follows:

2.3. Summarizing Auto and Driver Premiums

We will need the following decision tables to accumulate Client’s premiums from different cars and drivers:

2.4. Calculating Auto and Driver Premiums for ALL Cars and ALL Drivers

Similarly to what we done to find a combined eligibility for all cars and all drivers, we will apply the following table to do it for premiums:

The first rule initializes the decision variables “Client Driver Premium”, “Client Base Premium”, and “Client Auto Premium”. Then the next 4 rules calculate these variables by applying previous rules to all cars and drivers in the client’s policy.

2.5. Defining and Adjusting Client Total Premium

The Client Total Premium can be defined as a sum of the Client Auto Premium and Client Driver Premium:

Now we need to adjust this variable as specified:

These rules are naturally implemented in OpenRules as follows:

2.6 Calculate Client Premium

The final premium calculation can be done by executing the following decision:

4. Glossary

In all decision tables above we freely introduced decision variable inside column titles for conditions and conclusions. Then we collected all of them (using Excel’s Copy+Paste)in the following OpenRules glossary:

The first column represents business names of decision variables as they are being used inside rules. The second column represent business concepts (Driver, Car, Client) to which these variables belong.  The third column represents technical names (no spaces) used to map the decision variables to attributes inside implementation objects corresponding to business concepts.

4. Repository

We organized all decisions, rules, and test cases inside one repository of Excel files:

Decisions and rules can be found in the sub-folder “rules”; test cases – in the sub-folder “tests”. You may download all these files by adding their names to the following URL:

http://openrules.com/xls/UServ/rules/filename.xls

In the main file Decision.xls we described this repository in the Environment table:

The “include” such as “../tests/Scenario4.xls” point to the used test case.

The “include.java” point to the Java package that provide a data interface for business concepts Driver, Car, and Client.

5. Test Cases

The specification provide 4 test cases. We presented these cases using OpenRules Data tables. For example, the first test case is described as:

In OpenRules they are presented in Excel as follows:

See all test scenarios:

• Scenario1.xls
• Scenario2.xls
• Scenario3.xls
• Scenario4.xls

6. Java Interface

We decided to use Java classes for data representation. To do that, we simple created under Eclipse IDE 3 Java classes: Car, Driver, and Client. We added all attributes by copy+paste from the Glossary and then generated all getters, setters and print-methods using Eclipse. All these 3 classes are simple Java beans with no logic.

To create and execute an OpenRules Decision we are using a simple Java launcher:

7. Execution Results 

After the decision execution for the Scenario1.xls we received the following results described in the file “results.txt“. You may also be interested to analyze the execution reports in HTML that show which rules were actually executed.

8. Availability

We’ve implemented this use case within a few days and haven’t had enough time to really validate its correctness. After some additional improvements and thorough testing, we plan to include this decision project “UServ” into the next standard OpenRules installation for public downloads.