With the UML, it is the relationships between classes that provide structure to what you are creating. This article explains how to use the UML to illustrate various kinds of class relationships. It is taken from chapter two of Fast Track UML 2.0 written by Kendall Scott (Apress, 2004; ISBN: 1590593200).
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.