skip to main content
Corticon Studio: Rule Modeling Guide : Rule scope and context : Scope and perspectives in the vocabulary tree : Roles

Try Corticon Now
Using roles in the Vocabulary can often help to clarify rule context. To illustrate this point, we will use a slightly different example. The UML class diagram for a new (but related) sample Vocabulary is as shown:
Figure 57. 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, we can see that, in practice, 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 we represent this in the Vocabulary and rules we build in Corticon Studio?
Let's examine this problem in more detail. Assume we want to implement two new rules:
We call these rules cross-entity because they include more than one entity (both Aircraft and Person) in their expression. Unfortunately, with our Vocabulary as it is, we have no way to distinguish between pilots and passengers, so there is no way to unambiguously implement these 2 rules. This class diagram, when imported into Corticon Studio, looks like this:
Figure 58. Vocabulary without Roles
However, there are several ways to modify this Vocabulary to allow us to implement these rules. We will discuss these methods and examine the advantages and disadvantages of each.

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 we may decide to simply 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, persons 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 59. UML Class Diagram with Roles
When the class diagram is imported into Corticon Studio, it appears as the Vocabulary below:
Figure 60. Vocabulary with Roles
Notice the differences between Vocabulary with Roles and Vocabulary without Roles – 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 we have updated the cardinalities of both Aircraft—Person associations to one-to-many.
Written using roles, the first rule appears 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 us 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 more detail in the following chapters.
Figure 61. Rule #1 Implemented using Roles
To demonstrate how Corticon Studio differentiates between entities based on rule scope, we will construct a new Ruletest that includes a single instance of Aircraft and 2 Person entities, neither of which has the role of pilot.
Figure 62. Ruletest with no Person entities in Pilot role
Despite the fact that 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 we create a new Input Ruletest, this time with both persons in the role of pilot, we see a different result, as shown:
Figure 63. Ruletest with both Person entities in role of Pilot
Finally, the rules are tested with one pilot and one passenger:
Figure 64. Ruletest with one Person entity in each of Pilot and Passenger roles
We see that 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 will not be implemented here.