The air cargo example that you 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 1. Fact model

According to this Vocabulary, an aircraft is related to a cargo shipment through a flight plan.  In other words, it is the flight plan 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 flight plan; or, no aircraft may carry a cargo shipment without a flight plan. Similarly, no cargo shipment can be transported by an aircraft without a flight plan. These facts constitute business rules in and of themselves and constrain creation of other rules because they define the Vocabulary you 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 your Vocabulary created, you 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 write your rule using the root-level terms in the Vocabulary. In the following figure, column #1 (the true Condition) is the rule you should be most interested in. The false condition in column #2 was added simply to show a logically complete Rulesheet.

Figure 2. Expressing the rule using root-level Vocabulary terms

You 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. Each box represents a real-life example (or instance) of the Aircraft term from your Vocabulary.

Figure 3. The Cargo Company's 3 Aircraft

These aircraft give the company the ability to schedule 3 cargo shipments each night. Another business rule is implied:– “an Aircraft cannot be scheduled for more than one flight per night”. This rule is not addressed now because it is not relevant to the discussion}. On a given night, the cargo shipments look like those shown. Again, like the Aircraft, these cargo shipments represent specific instances of the generic Cargo term from the Vocabulary.

Figure 4. The three cargo shipments for the night of June 25th

Finally, the sample business process manually matches specific aircraft and cargo shipments together as three flight plans, as shown below. This organization of data is consistent with the structure and constraints implicit in the Vocabulary.

Figure 5. The three FlightPlans with their related Aircraft and Cargo instances

You can construct a Ruletest (in the following figure) so that the company's actual data is evaluated by the rule. Because the rule used root-level Vocabulary terms in its construction, you use root-level terms in the Ruletest:

Figure 6. Test the rule using root-level Vocabulary terms

Running the Ruletest:

Figure 7. 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. You already know that there are only three Flightplans. And you also know, from examination of Figure 5, that the combination of aircraft N1003 and cargo 625C does not appear in any of the three Flightplans. So, why was this combination, one that does not actually exist, evaluated? For that matter, why did the rule fire nine times when only three sets of Aircraft and Cargo were present? The answer is in the way the rule was defined, and in the way the rules engine evaluated it.

The Ruletest has 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. Because 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. Progress uses cross-product when describing this outcome.

Figure 8. All possible combinations of Aircraft and Cargo

One pair, the combination of manifest 625B and plane N1003 (shown as the red arrow in the preceding figure), is illegal, because 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) are not represented by real flight plans either. So why did Studio perform three times the necessary evaluations?  It is because the rule, as implemented in Figure 2, does not capture the essential elements of scope and context.

You want your rule to express the fact that you are only interested in evaluating the Cargo—Aircraft pair for each FlightPlan, not for all possible combinations. How do you express this intention in your rule? You use the associations included in the Vocabulary.

Refer to the following figure:

Figure 9. Rule expressed using FlightPlan as the Rule Scope
Here, the rule was rewritten using the aircraft and cargo terms from inside the FlightPlan term.
Note: Inside means that the Aircraft and Cargo terms that appear when the FlightPlan term is opened in the Vocabulary tree, as shown by the orange highlights in Rule expressed using FlightPlan as the Rule Scope.
This is significant. It means that you 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, only those cargo shipments in the context of actual flight plans should be evaluated. To put it differently, the rule's application is limited to only those cargo shipments assigned to a specific aircraft using a specific flight plan. 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, you indicate mandatory traversals of the associations between FlightPlan and the other two terms, Aircraft and Cargo.This instructs the rules engine to evaluate the rule using the intended context. When writing rules, it is important to understand the context of a rule and the scope of the data to which it will be applied.