Relating Many Objects (Multiplicity)

As in the real world, you can link one object to many instances of another class. Surely, if you want to have a successful business renting crash dummies to clients, your clients should be able to rent more than one dummy at a time—and a dummy should be rentable to more than one client over time. Specifying how many instances can be linked together is called multiplicity.

Remember When showing multiplicity on your association, remember to do the following:

Position the multiplicity numbers above or below the association line, close to the class.
Place multiplicity numbers at both ends of an association.
Use multiplicity to show how many things at either end of an association are potentially linked together.

Notice the 1..* symbol close to the CrashDummy class in Figure 4-4. This symbol tells you that a client rents at least one or more crash dummies. In other words the appearance of 1..* represents the idea of having one or more instances of CrashDummy that a Client rents. The 1 in the 1..* means that a client must rent at least one crash dummy. The * in 1..* indicates that a client can rent more than one crash dummy, and does not place an upper limit in the number that can be rented.

Because associations have meaning in both directions, you also place a multiplicity symbol on the association line next to the Client class. In Figure 4-4, you see that a CrashDummy can be rented by zero or more instances of Client (0..*).

click to expand
Figure 4-4: Association with multiplicity

Determining multiplicity

When you specify the multiplicity of an association, you must determine the value to place at each end of the association line. Follow these steps to make your determination:

Establish the classes that form the endpoints for the association.

In this example, the classes are Client and CrashDummy, connected by the rents association line.
Examine the characteristics of the association from the perspective of one class.

In this example, we look at the Client class and ask ourselves the following questions:
- Can a client rent zero crash dummies and still be a client? (No.)
- Must a client rent at least one dummy? (Yes.)
- Can a client rent many dummies over time? (Yes, many.)
The answers to these questions tell us that the multiplicity must be 1..* because the client must rent at least one crash dummy, and can rent many.
Place the multiplicity symbol that represents the answer to questions in Step 2 at the proper point on the UML diagram.

In this example, we place 1..* at the opposite end of the association from the Client class.
Repeat Steps 2 and 3 from the perspective of the other class.

To complete this example, we look at the association from the perspective of the CrashDummy class. We ask ourselves the following questions:
- Is it possible for MAX to never be rented? (Yes, poor MAX.)
- Must at least one client rent MAX? (No.)
- Can more than one client rent MAX over time? (Yes, although not at exactly the same time.)
The answers to these questions tell us that the multiplicity must be 0..* because a particular crash dummy may never be rented by a client, but could (over time) be rented by many clients.

Finally, we place 0..* at the opposite end of the association from the CrashDummy class.

Notice that we first look at the association from the client’s perspective—as if we had only one client. We decide to use 1..* as the multiplicity symbol and place it at the opposite end from the client class. Then we consider the multiplicity from the crash-dummy perspective. The chosen multiplicity is 0..* and we place it at the opposite end of the association from the CrashDummy class.

Representing multiplicity

Table 4-2 lists the various symbols that can use for multiplicity. To understand the table, consider the multiplicity symbol at the crash-dummy end of the rents association in Figure 4-5. You can then replace the ?? in the figure with a symbol from the table to see what that multiplicity means.

Figure 4-5: Choosing multiplicity

Table 4-2: Multiplicity Symbols
Multiplicity	Meaning Symbol
1	A Client instance must be linked with exactly one instance of CrashDummy no more and no less.
*	A Client instance may be linked with zero or more instances of CrashDummy.
0..*	A Client instance may be linked with zero or more instances of CrashDummy. This is just like using * for the multiplicity.
0..1	A Client instance may be linked with either zero or one instance of CrashDummy. This is known as the optional multiplicity.
1..*	A Client instance must be linked with at least one or more instances of CrashDummy. This is the multiplicity we chose for Figure 4-4.
5..9	A Client instance can be linked to at least 5 instances of CrashDummy but not more than 9 instances.
3,5,7	A Client instance can be linked to (and thus rent) 3 or 5 or 7 instances of CrashDummy.

Using multiplicity

The multiplicity you end up with on your diagrams varies depending on the application you develop. For instance, suppose you build an application that keeps track of all clients who ever rented dummies, whether they are renting some now or not. You would have to allow a multiplicity of zero or more for the CrashDummy class (as shown in Figure 4-6). In this situation, you have the possibility that an instance of Client rents zero crash dummies.

If your application is a simple order-entry system, you may require that a client rents at least one dummy. However, if your application is keeping track of all clients, you need to show that a client rents zero or more dummies.

Figure 4-6: Multiplicity depends on the application.

Warning When you start thinking about the multiplicity of your associations, you uncover hidden assumptions about how many objects can be linked together. When you talk with users, often they’re vague about associations and don’t consider every possible way of linking the instances of one class with the instances of another class. For example, thinking about objects that invoke each other’s behavior in a program can easily make a programmer forget to consider all the different situations. It’s left to you to discover whether an instance of one class must be linked to another—or perhaps doesn’t always require a link. Consider these details when you gather requirements and analyze the situation; it pays dividends later, when you start programming.

Some time ago, we were writing a simulation program that associated airplanes with their location on a simulated map. The location was called a cell—the map was composed of cells, and each plane was placed in a cell. As the simulation progressed, a plane would move from cell to cell. Figure 4-7 shows a UML diagram of the associations between plane and cell. A plane is currently located in exactly one cell and a plane moves through one or more cells during the simulation.

Figure 4-7: Multiplicity example with cells and planes.

What we didn’t properly appreciate at programming time was the fact that a plane had to be in a cell. We created the plane class but did not enforce any multiplicity. So, when we started to use instances of the plane class, they were not automatically assigned to a cell. When another object in our program asked a plane, Where are you? the program blew up—that’s because it was chasing a null pointer to a nonexistent cell object. (A null pointer is a program variable that is set to zero instead of to a valid address in a computer’s memory. This one was a real nuisance.) If we’d used UML, we would have discovered the need to code a link from plane to cell, right from the start, instead of having to debug and rewrite it after the fact. This is just another example of why considering the details of multiplicity is a good habit to get into.