Section 2.6. Relationships

2.6. Relationships

Classes in isolation would not provide much insight into how a system is designed. UML provides several ways of representing relationships between classes. Each of UML relationship represents a different type of connection between classes and has subtleties that aren't fully captured in the UML specification. When modeling in the real world, be sure that your intended viewers understand what you are conveying with your various relationships. We say this both as a warning to the modeler and as a slight disclaimer that the following explanations are our interpretation of the UML specification. For example, the debate over when to use aggregation versus composition is ongoing. To help determine which relationship is most appropriate, we offer a short phrase for each type that may help make the distinction. Again, the important thing is to be consistent within your model.

2.6.1. Dependency

The weakest relationship between classes is a dependency relationship. Dependency between classes means that one class uses, or has knowledge of, another class. It is typically a transient relationship, meaning a dependent class briefly interacts with the target class but typically doesn't retain a relationship with it for any real length of time.

Dependencies are typically read as "...uses a...". For example, if you have a class named Window that sends out a class named WindowClosingEvent when it is about to be closed, you would say "Window uses a WindowClosingEvent."

You show a dependency between classes using a dashed line with an arrow pointing from the dependent class to the class that is used. Figure 2-21 shows a dependency between a class named Window and a class named WindowClosingEvent.

Figure 2-21. Window's dependency on WindowClosingEvent

You can likely assume from Figure 2-21 that Window doesn't retain a relationship with a WindowClosingEvent for any real length of time. It simply uses them when needed and then forgets about them.

2.6.2. Association

Associations are stronger than dependencies and typically indicate that one class retains a relationship to another class over an extended period of time. The lifelines of two objects linked by associations are probably not tied together (meaning one can be destroyed without necessarily destroying the other).

Associations are typically read as "...has a...". For example, if you have a class named Window that has a reference to the current mouse cursor, you would say "Window has a Cursor". Note that there is a fine line between "...has a..." and "...owns a..." (see "Aggregation" later in this section). In this case, Window doesn't own the Cursor; Cursor is shared between all applications in the system. However, Window has a reference to it so that the Window can hide it, change its shape, etc. You show an association using a solid line between the classes participating in the relationship. Figure 2-22 shows an association between Window and Cursor.

Figure 2-22. Association showing Window "has a" Cursor

2.6.2.1. Navigability

Associations have explicit notation to express navigability. If you can navigate from one class to another, you show an arrow in the direction of the class you can navigate to. If you can navigate in both directions, it is common practice to not show any arrows at all, but as the UML specification points out, if you suppress all arrows you can't distinguish nonnavigable associations from two-way associations. However, it is extremely rare to use a nonnavigable association in the real world, so this is unlikely to be a problem.

You can explicitly forbid navigation from one class to another by placing a small X on the association line at the end of the class you can't navigate to. Figure 2-23 shows an association between a class named Window and a class named Cursor. Because you can't navigate from an instance of Cursor to an instance of Window, we explicitly show the navigability arrow and an X where appropriate.

Figure 2-23. Association between Window and Cursor showing you can't navigate from Cursor to Window

2.6.2.2. Naming an association

Associations may be adorned with several symbols to add information to your model. The simplest is a solid arrowhead showing the direction in which the viewer should read the association. It is common to include a short phrase along with the arrowhead to provide some context for the association. The phrase used with the association doesn't typically generate into any form of code representation; it is purely for modeling purposes. Figure 2-24 shows the solid arrowhead on the Window to Cursor association.

Figure 2-24. Shows how to read the association between Window and Cursor

2.6.2.3. Multiplicity

Because associations typically represent lasting relationships, they are often used to indicate attributes of a class. As mentioned in the "Attributes by Relationship" section, you can express how many instances of a particular class are involved in a relationship. If you don't specify a value, a multiplicity of 1 is assumed. To show a different value, simply place the multiplicity specification near the owned class. See "Attribute Multiplicity" for the allowable multiplicity types. Note that when you use multiplicity with an association, you don't use square brackets around the values. Figure 2-25 shows an association with explicit multiplicity.

Figure 2-25. A simple association showing four Buttons in a Window

The properties related to multiplicity may be applied to associations as well. See "Properties" for the names and definitions of allowed properties.

2.6.3. Aggregation

Aggregation is a stronger version of association. Unlike association, aggregation typically implies ownership and may imply a relationship between lifelines. Aggregations are usually read as "...owns a...". For example, if you had a classed named Window that stored its position and size in a Rectangle class, you would say the "Window owns a Rectangle." The rectangle may be shared with other classes, but the Window has an intimate relationship with the Rectangle. This is subtly different from a basic association; it has a stronger connotation. However, it's not the strongest relationship you can have between classes. If the relationship is more of a whole part (class A "...is part of..." class B), you should look at composition.

You show an aggregation with a diamond shape next to the owning class and a solid line pointing to the owned class. Figure 2-26 shows an example aggregation between a class named Window and a class named Rectangle.

Figure 2-26. Window "owns a" Rectangle

As with the association relationship, you can show navigability and multiplicity on an aggregation line. See "Association" for examples.

2.6.4. Composition

Composition represents a very strong relationship between classes, to the point of containment. Composition is used to capture a whole-part relationship. The "part" piece of the relationship can be involved in only one composition relationship at any given time. The lifetime of instances involved in composition relationships is almost always linked; if the larger, owning instance is destroyed, it almost always destroys the part piece. UML does allow the part to be associated with a different owner before destruction, thus preserving its existence, but this is typically an exception rather than the rule.

A composition relationship is usually read as "...is part of...", which means you need to read the composition from the part to the whole. For example, if you say that a window in your system must have a titlebar, you can represent this with a class named Titlebar that "...is part of..." a class named Window.

You show a composition relationship using a filled diamond next to the owning class and a solid line pointing to the owned class. Figure 2-27 shows an example composition relationship between a class named Window and a class named Titlebar.

Figure 2-27. Titlebar "is a part of" Window

As with the association relationship, you can show navigability and multiplicity on a composition line. See "Association" for examples.

2.6.5. Generalization

A generalization relationship conveys that the target of the relationship is a general, or less specific, version of the source class or interface. Generalization relationships are often used to pull out commonality between difference classifiers. For example, if you had a class named Cat and a class named Dog, you can create a generalization of both of those classes called Animal. A full discussion of how and when to use generalization (especially versus interface realization) is the subject for an object-oriented analysis and design book and isn't covered here.

Generalizations are usually read as "...is a...", starting from the more specific class and reading toward the general class. Going back to the Cat and Dog example, you would say "a Cat...is a...Animal" (grammar aside).

You show a generalization relationship with a solid line with a closed arrow, pointing from the specific class to the general class. Figure 2-28 shows an example of the Cat to Animal relationship.

Figure 2-28. Cat specializes the Animal base class

Unlike associations, generalization relationships are typically not named and don't have any kind of multiplicity. UML allows for multiple inheritance, meaning a class can have more than one generalization with each representing an aspect of the decedent class. However, some modern languages (e.g., Java and C#) don't support multiple inheritance; interfaces and interface realization are used instead.

2.6.6. Association Classes

Often the relationship between two elements isn't a simple structural connection. For example, a football player may be associated with a league by virtue of being on a team. If the association between two elements is complex, you can represent the connection using an association class. An association class is an association that has a name and attributes, like a normal class. You show an association class like a regular class with a dashed line connecting it to the association it represents. Figure 2-29 shows a football player's relationships to a league.

Figure 2-29. Example association class

When translated into code, relationships with association classes often result in three classes: one for each end of the association and one for the association class itself. There may or may not be a direct link between the association ends; the implementation may require you to traverse through the association class to get to the opposite end of the link. In other words, FootballPlayer may not have a direct reference to FootballLeague but may have a reference to FootballTeam instead. FootballTeam would then have a reference to FootballLeague. How the relationships are constructed is a matter of implementation choices; however, the fundamental concept of an association class is unchanged.

2.6.7. Association Qualifiers

Relationships between elements are often keyed, or indexed, by some other value. For example, a bank patron may be identified by her account number, or a tax payer by his Social Security number. UML provides association qualifiers to capture such information. A qualifier is typically an attribute of the target element, though this isn't required. You show a qualifier by placing a small rectangle between the association and the source element. Draw the name of the qualifier (usually the name of an attribute) in the rectangle. Figure 2-30 shows the relationship between the IRS and a taxpayer qualified by the taxpayer's Social Security number.

Figure 2-30. An association qualifier

Notice that the multiplicity between the association qualifier and TaxPayer is 1. Obviously the IRS is associated with more than one TaxPayer, but by using qualifiers, you indicate that a socialSecurityNumber uniquely identifies a single TaxPayer within the IRS.