skip to main content
Corticon Studio: Rule Modeling Guide : Collections : Special collection operators : Another example using the existential quantifier
 

Try Corticon Now
Another example using the existential quantifier
Collection operators are powerful parts of the Corticon Rule Language – in some cases they may be the only way to implement a particular business rule. For this reason, we provide another example.
Business problem: An auto insurance company has a business process for handling auto claims. Part of this process involves determining a claim’s validity based on the information submitted on the claim form. For a claim to be classified as valid, both the driver and vehicle listed on the claim must be covered by the policy referenced by the claim. Claims that are classified as invalid will be rejected, and will not be processed for payment.
From this short description, we extract our primary business rule statement:
1. A claim is valid if the driver and vehicle involved in a claim are both listed on the policy against which the claim is submitted.
In order to implement our business rule, we propose the UML Class Diagram shown below. Note the following aspects of the diagram:
*A Policy may cover one or more Drivers
*A Policy may cover one or more Vehicles
*A Policy may have zero or more Claims submitted against it.
*The Claim entity has been denormalized to include driverName and vehicleVin .
Note: Alternatively, the Claim entity could have referenced Driver.name and Vehicle.vin (by adding associations between Claim and both Driver and Vehicle), respectively, but the denormalized structure is probably more representative of a real-world scenario.
Figure 119. UML Class Diagram
This model imports into Corticon Studio as the Vocabulary shown in Figure 120
Figure 120. Vocabulary
Model the following rules in Corticon Studio as shown in Figure 121
1. For a claim to be valid, the driver’s name and vehicle ID listed on the claim must also be listed on the claim’s policy.
2. If either the driver’s name or vehicle ID on the claim is not listed on the policy, then the claim is not valid.
Figure 121. Rules Modeled in Corticon Studio
This appears very straightforward. But a problem arises when there are multiple drivers and/or vehicles listed on the policy–in other words, when the policy contains a collection of drivers and/or vehicles. Our Vocabulary permits this scenario because of the cardinalities we assigned to the various associations. We demonstrate this problem with the Ruletest in Figure 122
Figure 122. Ruletest
Notice in Figure 123 that there are 3 drivers and 3 vehicles listed on (associated with) a single policy. When we run this Ruletest, we see the results:
Figure 123. Ruletest
As we see from the Ruletest results, the way Corticon Studio evaluates rules involving comparisons of multiple collections means that the validClaim attribute may have inconsistent assignments – sometimes true, sometimes false (as in this Ruletest). It can be seen from the table below that, given the Ruletest data, 4 of 5 possible combinations evaluate to false, while only one evaluates to true. This conflict arises because of the nature of the data evaluated, not the rule logic, so Studio’s Conflict Check feature does not detect it.
Claim. driverName
Claim.policy. driver.name
Claim. vehicleVin
Claim.policy. vehicle.vin
Rule 1 fires
Rule 2 fires
Rule 3 fires
validClaim
Joe
Joe
123-ABC
123-ABC
X
True
Joe
Sue
X
False
Joe
Mary
X
False
123-ABC
987-XYZ
X
False
123-ABC
456-JKL
X
False
Let’s use the existential quantifier to rewrite these rules:
Figure 124. Rules Rewritten Using Existential Quantifier.
This logic tests for the existence of matching drivers and vehicles within the two collections. If matches exist within both, then the validClaim attribute evaluates to true, otherwise validClaim is false.
Let’s use the same Ruletest data as before to test these new rules. The results are shown below:
Notice that only one rule has fired, and that validClaim has been assigned the value of true. This implementation achieves the intended result.