The air cargo example that we started in the Vocabulary chapter is continued here to illustrate the important concepts of scope and context in rule design.
A quick recap of the fact model:
Figure 41. Fact Model
According to this Vocabulary, an Aircraft is related to a Cargo shipment through a FlightPlan. In other words, it is the FlightPlan that connects or relates an Aircraft to its Cargo shipment. The Aircraft, by itself, has no direct relationship to a Cargo shipment unless it is scheduled by a FlightPlan; or, no Aircraft may carry a Cargo shipment without a FlightPlan. Similarly, no Cargo shipment may be transported by an Aircraft without a FlightPlan. These facts constitute business rules in and of themselves and constrain creation of other rules because they define the Vocabulary we will use to build all subsequent rules in this scenario.
Also recall that the company wants to build a system that automatically checks flight plans to ensure no scheduling rules or guidelines are violated. One of the many business rules that need to be checked by this system is:
With our Vocabulary created, we can build this rule in the Studio. As with many tasks in Studio, there is often more than one way to do something. We will explore two possible ways to build this rule – one correct and one incorrect.
To begin with, we will write our rule using the root-level terms in the Vocabulary. In the following figure, column #1 (the true Condition) is the rule we are most interested in – we've added the false Condition in column #2 simply to show a logically complete Rulesheet.
Figure 42. Expressing the Rule Using Root-Level Vocabulary Terms
We can build a Ruletest to test the rule using the Cargo company's actual data, as follows:
The company owns 3 Aircraft, 2 747s and a DC-10, each with different tail numbers. The 3 Aircraft are shown in the following figure, example 6 in the Custom data types topic. Each box represents a real-life example (or instance) of the Aircraft term from our Vocabulary.
Figure 43. The Cargo Company's 3 Aircraft
These Aircraft give the company the ability to schedule 3 Cargo shipments each night {there is another business rule implied here – an Aircraft must not be scheduled for more than one flight per night, but we won't address this now because it is not relevant to the discussion}. On a given night, the Cargo shipments look like those shown below. Again, like the Aircraft, these Cargo shipments represent specific instances of the generic Cargo term from the Vocabulary.
Figure 44. The 3 Cargo Shipments for the Night of June 25th
Finally, our sample business process manually matches specific aircraft and cargo shipments together as three flightplans, shown below. This organization of data is consistent with the structure and constraints implicit in our Vocabulary.
Figure 45. The 3 FlightPlans with their related Aircraft and Cargo instances
We can construct a Ruletest (in the following figure)so that the company's actual data will be evaluated by the rule. Since the rule used root-level Vocabulary terms in its construction, we will use root-level terms in the Ruletest as well:
Figure 46. Test the Rule Using Root-Level Vocabulary Terms
Running the Ruletest :
Figure 47. Results of the Ruletest
Note the messages returned by the Ruletest. Recall that the intent of the rule is to verify whether a given Flightplan is in violation by scheduling a Cargo shipment that is too heavy for the assigned Aircraft. But we already know there are only three Flightplans. And we also know, from examination of The 3 FlightPlans with their related Aircraft and Cargo instances, that the combination of aircraft N1003 and cargo 625C does not appear in any of our three Flightplans. So why was this combination, one that does not actually exist, evaluated? For that matter, why has the rule fired nine times when only three sets of Aircraft and Cargo were present? The answer lies in the way we defined our rule, and in the way the Corticon Server evaluated it.
We gave the Ruletest three instances of both Aircraft and Cargo. Studio treats Aircraft as a collection or set of these three specific instances. When Studio encounters the term Aircraft in a rule, it applies all instances of Aircraft found in the Ruletest (all three instances in this example) to the rule. Since both Aircraft and Cargo have three instances, there are a total of nine possible combinations of the two terms. In the following figure, the set of these nine possible combinations is called a cross product, Cartesian product, or tuple set in different disciplines. We tend to use cross-product when describing this outcome.
Figure 48. All Possible Combinations of Aircraft and Cargo
One pair, the combination of manifest 625B and plane N1003 (shown as the red arrow in the figure above), is indeed illegal, since the plane, a DC-10, can only carry 150,000 kilograms, while the cargo weighs 175,000 kilograms. But this pairing does not correspond to any of the three FlightPlans created. Many of the other combinations evaluated (five others, to be exact) are not represented by real flight plans either. So why did Studio bother to perform three times the necessary evaluations? It is because our rule, as implemented in Figure 42, does not capture the essential elements of scope and context.
We want our rule to express the fact that we are only interested in evaluating the Cargo—Aircraft pair for eachFlightPlan, not for all possible combinations. How do we express this intention in our rule? We use the associations included in the Vocabulary.
Refer to the following figure:
Figure 49. Rule Expressed Using FlightPlan as the Rule Scope
Here, we've rewritten the rule using the aircraft and cargo terms from inside the FlightPlan term.
Note: By inside we mean the aircraft and cargo terms that appear when the FlightPlan term is opened in the Vocabulary tree, as shown by the orange circles in Rule Expressed Using FlightPlan as the Rule Scope.
This is significant. It means we want the rule to evaluate the Cargo and Aircraft terms only in the context of a FlightPlan. For example, on a different night, the Cargo company might have eight Cargo shipments assembled, but only the same three planes on which to carry them. In this scenario, three flight plans would still be created. Should the rule evaluate all eight Cargo shipments, or only those three associated with actual flight plans? From the original business rule, it is clear we are only interested in evaluating those Cargo shipments in the context of actual flight plans. To put it differently, the rule's application is limited to only those Cargo shipments assigned to a specific Aircraft via a specific FlightPlan. We express these relationships in the Rulesheet by including the FlightPlan term in the rule, so that cargo.weight is properly expressed as FlightPlan.cargo.weight, and Aircraft.maxCargoWeight is properly expressed as FlightPlan.aircraft.maxCargoWeight. By attaching FlightPlan to the terms aircraft.maxCargoWeight and cargo.weight, we have indicated mandatory traversals of the associations between FlightPlan and the other two terms, Aircraft and Cargo.This instructs Corticon Server to evaluate the rule using the intended context. In writing rules, it is extremely important to understand the context of a rule and the scope of the data to which it will be applied.
