Using roles in the Vocabulary can often help to clarify rule context. To illustrate this point, a slightly different example will be used. The UML class diagram for a new (but related) sample Vocabulary is as shown:

Figure 1. UML Class Diagram without Roles

As shown in this class diagram, the entities Person and Aircraft are joined by an association. However, can this single association sufficiently represent multiple relationships between these entities? For example, a prior Fact Model might state that “a pilot flies an aircraft” and “a passenger rides in an aircraft”. Both pilot and passenger are descendants of the entity Person. Furthermore, some instances of Person may be pilots and some may be passengers. This is important because it suggests that some business rules may use Person in its pilot context, and others may use it in its passenger context. How do you represent this in the Vocabulary and rules in Corticon Studio?

Assume that you want to implement two new rules:

These rules are called cross-entity because they include more than one entity (both Aircraft and Person) in the expression. Unfortunately, with the Vocabulary as it is, you have no way to distinguish between pilots and passengers, so there is no way to unambiguously implement these two rules. This class diagram, when imported into Corticon Studio, looks like this:

Figure 2. Vocabulary without roles

However, there are several ways to modify this Vocabulary to allow you to implement these rules.

Use Inheritance

Use two separate entities for Pilot and Passenger instead of a single Person entity. This may often be the best way to distinguish between pilots and passengers, especially if the two types of Person reside in different databases or different database tables (an aspect of deployment that rule modelers may not be aware of). Also, if the two types of Person have some shared and some different attributes (Pilot may have attributes like licenseRenewalDate and typeRating while Passenger may have attributes like farePaid and seatSelection), then it may make sense to set up entities as descendants of a common ancestor entity (such as Employee).

Add an attribute to Person

If the two types of Person differ only in their type, then you can add a personType (or similar) attribute to the entity. In some cases, personType will have the value of pilot, and sometimes it will have the value of passenger. The advantage of this method is that it is flexible: in the future, a Person of type manager or bag handler or air marshal can easily be added. Also, this construction may be most consistent with the actual structure of the employee database or database table, and maintains a normalized model. The disadvantage comes when the rule modeler needs to refer to a specific type of Person in a rule. While this can be accomplished using any of the filtering methods discussed in Rule Writing Techniques, they are sometimes less convenient and clear than the final method, discussed next.

Use roles

A role is a noun that labels one end of an association between two entities. For example, in our Person–Aircraft Vocabulary, the Person may have more than one role, or more than one kind of relationship, with Aircraft. An instance of Person may be a pilot or a passenger; each is a different role. To illustrate this in our UML class diagram, we add labels to the associations as follows:

Figure 3. UML class diagram with roles

When the class diagram is imported into Corticon Studio, it appears as the Vocabulary below:

Figure 4. Vocabulary with roles

Notice the differences between the two preceding Vocabularies In Vocabulary with Roles, Aircraft contains 2 associations, one labeled passenger and the other pilot, even though both associations relate to the same Person entity. Also notice that the cardinalities of both Aircraft—Person associations have been updated to one-to-many.

Written using roles, the first rule is illustrated below. There are a few aspects of the implementation to note:
  • Use of aliases for Aircraft and Aircraft.pilot (plane and pilotOfPlane, respectively). Aliases are just as useful for clarifying rule expressions as they are for shortening them.
  • The rule Conditions evaluate data within the context of the plane and pilotOfPlane aliases, while the Action posts a message to the plane alias. This enables you to act on the Aircraft entity based upon the attributes of its associated pilots. Note that Condition row b uses a special operator (->size) that counts the number of pilots associated with a plane. This is called a collection operator, and is explained in detail in the section on Collections.
Figure 5. Rule #1 implemented using roles

To demonstrate how Corticon Studio differentiates between entities based on rule scope, construct a new Ruletest that includes a single instance of Aircraft and 2 Person entities, neither of which has the role of pilot.

Figure 6. Ruletest with no Person entities in pilot role

Although there are two Person entities, both of whom are members of the Flight Crew department, the system recognizes that neither of them have the role of pilot (in relation to the Aircraft entity), and therefore generates the violation message shown.

If you create a new Input Ruletest, then this time with both persons in the role of pilot, you see a different result, as shown:

Figure 7. Ruletest with both Person entities in role of pilot

Finally, the rules are tested with one pilot and one passenger:

Figure 8. Ruletest with one Person entity in each of pilot and passenger roles

Despite the presence of two Person elements in the collection of test data, only one satisfies the rules' scope: pilot associated with aircraft. As a result, the rules determine that one pilot is insufficient to fly a 747, and the violation message is displayed.

These same concepts apply to the DC-10/Passenger business rule, which is not implemented.