Ordinal Relationship - modelint/shlaer-mellor-metamodel GitHub Wiki

Unlike Association and Generalization Relationships, an Ordinal Relationship is not formalized with referential attributes.

Instead, an Ordinal Relationship is formalized with one of its Identifiers where one of its component Identifier Attributes serves as a ranking attribute on the relationship.

A ranking attribute must be defined with a Type that supports the greater/less than comparison operations.

In the example below, OR1 is formalized by Identifier I composing the Height and Tower stack Identifier Attributes.

Here the ranking attribute is Height since distances can be compared to yield a sequential vertical order.

One perspective on an Ordinal Relationship is associated with ascending values while the other corresponds to descending values.

In a simple Ordinal Relationship, we can use a single attribute identifier to establish a total ordering on all instances of the class.

images/relationship-subsystem/ordinal-relationship-10.png

We could have used a reflexive Binary Association instead, but we would have difficulty nailing down some important constraints. A 1:1 would require the sequence to wrap around like a ring. A 1c:1c would account for the highest and lowest cases, but would simultaneously leave open the possibility of gaps in the sequence. There's nothing about a 1c:1c Binary Association multiplicity pair that says that the 'c' case must be the highest and lowest Priority values only.

Note also that by using an Identifier, we are assured that no two instances are at the same ranking position. In our example, there can be no two Alert Level instances sharing the same Priority value.

Furthermore, we take advantage of the 'RANK' relational operation to implement an action like the following which selects the Alert Level instance with the highest priority:

highest priority alert .= Alert Level(-^Priority)  // rank in descending order and return lowest priority instance reference (priority 1)

Now we can find the next lowest priority like so:

downgraded priority = highest priority alert/OR13/less urgent // returns instance ref (priority 2)

In many cases we want to model a partial ordering instead. In other words, we want to break our population down into mutually exclusive ordered subsets.

This can be accomplished by formalizing our Ordinal Relationship with a multi attribute identifier as shown in the next example:

images/relationship-subsystem/ordinal-relationship-20.png

Here we order 'Floorsby their vertical height. ButFloors' are constructed independently within each Tower Stack. Each Tower Stack requires its own local ordering of Floor instances. There can be two 'Floor' instances at the same height in different 'Tower Stacks', but within a single 'Tower Stack', no two 'Floor' instances can have the same height. It's a physical impossibility.

To formalize this rule, we formalize our Ordinal Relationship with a multiple attribute Identifier. Only one of the component attributes of this Identifier is our ranking attribute, Height. The other component (you could have more) establishes our partial ordering within the Floor class as shown.

Our Ordinal Relationship ensures that there are no Floors at the same level within a Tower Stack and that there is a complete ordering within each Tower Stack. A similar constraint using a Binary Association is more complex.

Now imagine that we are defining an action to support the traversal of an elevator 'Cabin' within a Tower Stack.

next highest floor .= my floor/OR1/higher  // Get the next highest floor

Even more useful, assume we've added a boolean 'Stop requested' attribute to 'Floor' and we want the next highest level in our 'Tower Stack' where this attribute holds a true value. We could write something like this:

nearest requested floor above .= my floor/OR1/higher/~/(Stop requested)  // ~ means keep 'hopping' in that direction until condition is met

Identifiers

  1. Rnum + Domain

Attributes

Ascending perspective

The meaning of increasing values is described by this perspective.

For example higher in the context of the elevator example above is associated with increasing Height values.

Type: Phrase Name, based on Name

Descending perspective

The meaning of decreasing values is described by this perspective.

For example lower in the context of the elevator example above is associated with decreasing Height values.

Type: Phrase Name, based on Name