UML Class diagrams frequently include a modeling/programming concept called inheritance, where a class can “inherit” attributes and associations from another class, for example:

Figure 1. Rose UML model showing inheritance

In this diagram, there is a UML model that includes inheritance. The solid-headed arrow indicates that the Employee class is a descendant of the Person class, and therefore inherits some of its properties. Specifically, the Employee class inherits the age and name attributes from Person. In other words, Employee has all the same attributes of Person plus two of its own, hireDate and IDnumber. Likewise, Aircraft inherits all of Equipment's attributes (acquireDate and propertyID) plus has attributes of its own, type and tailNumber.

Modeling this UML Class Diagram as a Corticon Vocabulary is straightforward.  All Entities, Attributes and Associations are created per normal practice. To incorporate the elements of inheritance, you only need to add one additional setting for each of the descendant entities, as shown:

Figure 2. Selecting Ancestor Entity for Descendant

After all descendant entities are configured to inherit from their proper ancestor entities, you can save the Vocabulary and view it in the Rule Vocabulary window:

Figure 3. Vocabulary with Inheritance

Notice that many of the term names and icons are varying shades of gray. These color codes help you to understand the inherited relationships that exist in the Vocabulary.

Inherited attributes

Attributes with names displayed in solid black type, such as Customer.loyaltyNumber in Figure 3, are native attributes of that entity.

Attributes with names displayed in dark gray type, such as Customer.age, are inherited attributes from the ancestor entity (in the case of Customer, Person).

Inherited associations

Inherited Associations are a bit more complicated. An entity can be directly associated with another entity or that entity's descendants. An entity can also inherit an association from its ancestor.

Using the example shown in Figure 2 and Figure 3 above, each of these combinations is described:

  • Customer.aircraft is a direct association between Customer and Aircraft entities.  No inheritance is involved, so the association icon is black, and the rolename is black.
  • Customer.operator (Equipment) is an association inherited from the Customer ancestor entity Person, which has a direct association with Equipment and the rolename operator in our Vocabulary. The UML class Diagram in Figure 2 shows the rolename as operates because it is more conventional in UML to use verbs as rolenames, whereas nouns usually make better rolenames in a Corticon Vocabulary. Because the association is inherited from the ancestor's direct association, the icon is dark gray, and the rolename is black.
  • Equipment (which you can see equally well in the expanded operator rolename) has several associations with Person. One of these is a direct association with the Person entity. In this case, both the association icon and the rolename are black. But, Equipment also has associations with descendants of the Person entity, specifically Employee, Customer, and Pilot. These are filtered associations, and display their rolenames in dark gray.
  • Finally, Customer has another association with operator (Aircraft) because Aircraft is a descendant of Equipment. So, the inherited dark gray icon and the filtered dark gray rolename are combined to display this association.

How to control the tree view

In cases where a Vocabulary contains inheritance (and includes the various icons and color schemes previously described), but the modelers who use it do not intend to use inheritance in their rules, the inherited associations and filtered rolenames can be hidden from view by clicking the  icon in the upper right corner of the Rule Vocabulary window, as shown:

Figure 4. Vocabulary with inheritance properties hidden

Person and Equipment are associated (using named roles), but what relationship does Employee have with Equipment or Aircraft, if any?

How to use aliases with inheritance

Any Entity, Attribute, or Association can be dragged into the Scope section for use in Rulesheets. But, if two or more terms share the same name, then they must be assigned unique alias names before they can be used in rules.

For example, in Figure 3, there are four Customer.operator.person terms in the Vocabulary due to the various forms of inheritance used by the entities and associations. If two or more of these nodes are dragged into the Scope window, they will be assigned error icons to indicate that their names are not unique, as shown:

Figure 5. Non-Unique nodes used in the Scope window
Without unique names, Corticon Studio does not know which one is intended in any rule that uses one of the nodes. To ensure uniqueness, aliases must be assigned and used in rules, as shown:
Figure 6. Uniqueness Established using an Alias

Effects of inheritance on rule execution

The point of inheritance is not to complicate the Vocabulary. The point is to be able to write rules on ancestor entities and have those rules affect descendant entities automatically.

Examples of effects of inheritance on rule execution are:
  • Inherited Conditions and Actions

    The following Rulesheet contains two rules that test the age value of the Employee entity. There are no explicit actions taken by these rules, only the posting of messages.

    Figure 7. Rules written on Employee

    A Ruletest provides an instance of Employee and an instance of Pilot. Recall from the Vocabulary that Pilot is a descendant of Employee, which means it inherits its attributes and associations. But more important from a rule execution perspective, a Pilot is also be affected by any rules that affect Employee, as shown:

    Figure 8. Inheritance in action

    Using inheritance can be an efficient and powerful way to write rules on many different types of employees (such as pilots, gate agents, baggage handlers, and mechanics) without needing to write individual rules for each.

  • Inherited Association

    A similar test demonstrates how associations are inherited during rule execution. In this case, you test Employee.hireDate to see who is qualified to operate a piece of Equipment. The += syntax used by the Action row is explained in more detail in the Rule Language Guide.

    Figure 9. Rulesheet populating the operators collection

    In the following Ruletest, there is a sample Equipment entity, one Employee, and one Pilot. Both hire dates satisfy the rule's Condition (the Pilot inheriting hireDate from its Employee ancestor as before). When Employee was added to the operators collection alias, an instance of the association between Equipment and Employee is created. But, what may be surprising is that the same occurs for Pilot, which also has an association to Equipment that it inherited from Employee.

    Figure 10. Inheriting an Association