11.5. Roles
Each end of an association is called a role. Roles may optionally have:
name
multiplicity expression
navigability
Multiplicity is examined next, and the other two features are discussed in later chapters.
Multiplicity
Multiplicity defines how many instances of a class A can be associated with one instance of a class B (see Figure 11.3).
Figure 11.3. Multiplicity on an association.
For example, a single instance of a Store can be associated with “many” (zero or more, indicated by the * ) Item instances.
Some examples of multiplicity expressions are shown in Figure 11.4.
Figure 11.4. Multiplicity values.
The multiplicity value communicates how many instances can be validly associated with another, at a particular moment, rather than over a span of time. For example, it is possible that a used car could be repeatedly sold back to used car dealers over time. But at any particular moment, the car is only Stocked-by one dealer. The car is not Stocked-by many dealers at any particular moment. Similarly, in countries with monogamy laws, a person can be Married-to only one other person at any particular moment, even though over a span of time, they may be married to many persons.
The multiplicity value is dependent on our interest as a modeler and software developer, because it communicates a domain constraint that will be (or could be) reflected in software. See Figure 11.5 for an example and explanation.
Figure 11.5. Multiplicity is context dependent.
Rumbaugh gives another example of Person and Company in the Works-for association [Rumbaugh91]. Indicating if a Person instance works for one or many Company instances is dependent on the context of the model; the tax department is interested in many; a union probably only one. The choice usually practically depends on whom we are building the software for, and thus the valid multiplicities in an implementation.