Associating Classes with Themselves

You may need to show that two instances of the same class can be associated with each other. In certain tests, for example, crash dummies are lined up in a row with one dummy as the leader and the rest as followers. During the test, the lead dummy blocks the dummies lined up behind it. Each dummy then has an association—block—to the next dummy behind it. Such an association relates instances of the same class—and is known as a reflexive association.

When diagramming reflexive associations, remember to do the following:

Draw an association.

You need an association that comes out of a particular class and goes back into the same class.
Name the association.

Make sure you name the association so it reads like a sentence.
Add multiplicity.

Consider the multiplicity at each end of the association.
Provide roles.

To lend clarity to the diagram, add role names to describe what different instances of the same class do in the association.

You would read the diagram in Figure 4-11 as follows: “A crash dummy blocks zero or more instances of CrashDummy in the role of follower. Further, a crash dummy may be blocked by one crash dummy in the role of leader.”

Figure 4-11: A reflexive association.

To read the blocks association shown in Figure 4-11, you would read in the reverse direction, like this:

“A crash dummy (class name) is blocked by (association name in the reverse direction) zero or one (multiplicity) instances of CrashDummy (class name) in the role of leader (role name).”

Reading reflexive associations

Reflexive associations can be tricky to diagram, which can also make them tricky to read. Here’s how to keep them focused:

For the sake of clarity, always use at least one role name in the diagram.
Be careful when you read the role names in reflexive associations: They have to be read in both directions. We use the following template:
“(A or One) (class name) (association name) (multiplicity) instances of (class name) in the role of (role name).”

We always start the reading of associations with the word A or One.
Don’t read the multiplicity close to the starting class, only the multiplicity at the other end of the association.

Notice we did not use the role name of follower or the multiplicity of 0..* in this example. Why, you ask? Because it’s not true in every case that a crash dummy in the role of follower is blocked by the one crash dummy in the role of leader. The other dummies can be blocked, but only by dummies other than the leader. So, because there can be only one leader dummy, the multiplicity is 0..1 rather than 1.

Constraining associations

Under some special circumstances, you may want to say more about the association than just its name, roles, and multiplicity. For instance, suppose you want to say that the association must be an ordered set of instances instead of an unordered set—that a reflexive association shall not have cycles. You can do so by using UML to specify any constraints that must be imposed on the links of an association. As with all constraints in UML, you place the text that names the constraint or limitation in curly brackets { }.

For example, Figure 4-12 shows that the follower dummies are ordered in relation to the leader dummy. That means there is a first follower, a next follower, and on down the line to the last follower. Notice that the word {ordered} is surrounded by the curly brackets used to indicate a constraint.

click to expand
Figure 4-12: Association with constraint notation.

Figure 4-12 shows another important constraint called no cycles This is especially useful for reflexive associations. The no cycles constraint means you cannot have a dummy in the role of leader that is also in the role of a follower. We don’t want a circle of dummies.