Category list

Understanding the Roles That Classes Can Play

When objects get together, sometimes they behave differently in different relationships. You could say they have multiple personalities. We use the term role to describe in a single name how a class behaves in association to another class.

For example, consider one of your authors as if he were an object (he won’t mind): He plays the role of Husband in the relationship with his wife—and in quite a different relationship to his job, he plays the role of Chief Technologist . (Sometimes he plays the role of Crash Dummy .) He plays many roles, depending on who or what he’s associating with. The same is true of objects in UML.

When adding roles to your association, consider the following:

A name is shown on the association line next to the class that plays some role in relationship to another class.
You use roles to help clarify the nature of the behavior that an instance exhibits when it’s linked to an instance of another class.

UML2 In versions of UML previous to UML 2, the name at the end of an association was called a role . In UML 2, the word role has disappeared, replaced by association end name . To be precise, a name at an “association end” indicates what kind of behavioral participation the instances of one class (at that end) perform in relationship to instances of the class that occupies the other end of the association. That specific kind of behavioral participation is, in effect, a role—so the idea that objects play roles in relationship to other objects still makes sense to us. Therefore, as a practical matter, we use the word role instead of “association end name.”

The Cell class in Figure 4-8 has two different roles in relationship to the Plane class. An instance of a cell may play the role of “current cell” in association with one plane, and a “route element” in relation to another plane that has already moved through that “current cell” to another cell.

click to expand
Figure 4-8: Class diagram with roles.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

You can think of a role as the name of an attribute belonging to the class on the opposite side of an association. The role “current cell” is an attribute of the class Plane . Even though the diagram doesn’t show it, the class Plane has attributes currentCell and routeElement (as in Figure 4-9). The data type for each of these attributes is the class Cell .

Tip Association names are important to the readers of your diagrams. Role names are important to the code generators of your UML modeling tools. We recommend you provide role names on your class diagrams whenever you can; it makes for better code generation.

Figure 4-9: The Plane class with role-name attributes.

Tip Diagrams for modeling objects and classes come in two flavors—class diagrams and instance diagrams. The class diagram shows the static structure of classes and their associations. The object diagram shows objects (that is, instances) and their links. You use class diagrams most of the time—but now and then an instance diagram helps clarify a class diagram by providing an example. You build class diagrams to communicate the structure and behavior of each class. To show which classes can interact, you associate them together. When other developers have trouble understanding the meaning of your class diagram, use a instance diagram to show specific objects linked together. The instance diagram illustrates your class diagram.

When we put together the class diagram in Figure 4-8, for example, some developers didn’t understand what we meant . So we built a sample instance diagram (shown in Figure 4-10). Note that Figure 4-8 shows a Plane class associated with ( located in ) a Cell class—and the Cell class plays the role of currentCell . Figure 4-10 illustrates the meaning of these associated classes by showing an instance of Plane ( p12 ) linked to only one instance of the C ell class ( c45-23 ). Here cell c45-23 plays the role of the current cell, showing where plane p12 is at this point in time.