6.1 Associations

Definition: An association is the abstraction of a set of domain relationships that hold systematically between different kinds of conceptual entities, abstracted as classes, in the domain.

Author WRITES Book

Publisher PRODUCES AND MARKETS Book

Customer PURCHASES Book

The association is stated in terms of the classes abstracted from the domain.

Associations are shown on the class diagram as lines drawn between the two participating classes. The lines on the diagram are labeled with the association names, association ends, and multiplicities.

6.1.1 Association Names

Each association has a name. The name is an arbitrary identifier that can be meaningful to the association or can simply be a label, such as R12 for the "twelfth relationship." Executable UML uses relationship names to identify the association unambiguously.

(We call these names relationship numbers and we will use them to identify associations and as a discriminator in generalization hierarchies.)

6.1.2 Association Meanings

Each association's meaning is expressed in terms of an association end. Not surprisingly, given its name, an association end is a string that appears at the end of an association. The string may be a role or a verb phrase.

Roles.

Each of the two classes in an association has a role. Write the role names next to the relevant classes as shown in Figure 6.1.

Figure 6.1. Class Diagram with Association Names and Roles

Verb phrases.

In some cases it may be difficult to identify a role name that is distinct from the name of the related class. A more meaningful way to state the association is to write its meaning in terms of verb phrases. By convention, the phrase is placed next to the direct object of the sentence, as you can see in Figure 6.2.

Figure 6.2. Associations Using Verb Phrases

Using verb phrases has the distinct advantage of providing more descriptive text on the class diagram, and it avoids the search for role names different from the class names, or just leaving the role name blank.

Many UML models you'll see use only role names, and sometimes only one role name at that.

Because one of the purposes of Executable UML is to capture and formalize knowledge, we will use verb phrases in this book.

We use relationship numbers to uniquely identify each association.

6.1.3 Multiplicity

Associations involving only two objects can be characterized by the number of instances that participate in each instance of the domain relationship. This is represented in UML as a multiplicity, a range defining the number of participating instances.

The values for a range can be between zero and an "indefinite number."

Executable UML defines exactly four multiplicities: 1..1, 1..*, 0..1, and 0..*. The first two the ones that start with one are unconditional (or mandatory, if you prefer) because at least one instance must participate, and the last two the ones that start with zero are conditional.

In the examples in Figure 6.3, the association between Book and Author is unconditional; one is not an Author unless he has written a Book and every Book has at least one credited Author. (The model ignores the idea of anonymously authored books. If it didn't, we would use a conditional association.)

Figure 6.3. Associations with Multiplicities

The Book Customer association is conditional: A Customer is someone who has purchased books; but, there can be books that no one purchases.

How to Model Two

UML class diagrams allow specific numbers in a multiplicity expression, such as the notion that a piece of paper has exactly 2 sides or a credit card account may have up to four persons (1..4) responsible for the account.

This usage is not recommended for two reasons: First, the related objects may play different roles and should instead be represented by separate associations. For example, the sides of a sheet of paper are related to each other in meaningful ways that may need to be captured. For an extended discussion of this example, see Executable UML: How to Build Class Models [1].

Second, the specific multiplicity may be an artifact of some existing practice or restriction, and not fundamental. Thus a simple "many" is actually the most general and most correct solution. What is special about having four people on the credit card account? Either it's arbitrary, in which case we should use multiplicity * instead of 4, or there are rules in the domain that need to be captured.