Class Relationships

Classes, by themselves, aren't particularly useful. It’s the relationships among classes that provide the foundation for the structure of a new system. The following sections explore how you use the UML to illustrate various kinds of class relationships.

An association is a simple structural connection between classes.

You might think of an association as representing a “peer” relationship. (You look at other kinds of relationships that involve “parents” and “children,” and “parts” and “the whole,” later in the chapter.) Instances of classes involved in an association will most likely be communicating with each other at program execution time, but all we’re concerned with here is the fact that these instances have some attachment to each other. (By the way, an instance of an association— in other words, a structural connection between objects—is called a link.)

There are two basic kinds of associations: binary associations and n-ary associations.

A binary association, which exists between two classes, appears as a straight line that connects them. Figure 2-1 shows some example associations between classes.

Figure 2-1.  Binary associations

An n-ary association, which exists among three or more classes, appears as a set of lines connected to a central diamond, as shown in Figure 2-2.

Figure 2-2.  N-ary association

The n-ary association is considered something of an advanced modeling construct; you’re much more likely to see—and use—plain binary associations in your models.

An association is assumed to be bidirectional, which means that you can navigate from either class to the other one. However, you can specify that navigation can only occur from one class to another by using a feathered arrow, as shown in Figure 2-3.  

Figure 2-3.  One-way navigation between classes

Establishing the navigation arrow on this association means that a Customer has access to his or her Password, but no one can in turn use a Password to identify a Customer.

You can add several kinds of details, or adornments, to an association. These adornments include the following:

• An association can have a name that indicates the nature of the relationship. If a name is present, there can also be a triangle that points in the direction in which you should read the name. See Figure 2-4.

Figure 2-4.  Named association

• An association can contain roles, which are the faces that classes present to other classes. As shown in Figure 2-5, roles generally appear in pairs.

Figure 2-5.  Association roles

You read an association with role names from a class to the role immediately next to it to the class on the other side of the association. In other words, you would read this association in one direction as “Reviewer writes Review” and in the other direction as “Review is written by Reviewer.”

A class can play the same role or different roles within different associations.

• An association can show multiplicity. See the section “More About Attributes” in Chapter 1 for more on this topic. Figure 2-6 shows two examples of association multiplicity.

Figure 2-6.  Association multiplcity

When an association has multiplicities attached to it, you read from a class to the value next to the other class, across the association. So, in Figure 2-6, one Account can be associated with many Billing Info objects, but each Billing Info object is associated with only one Account.