Chapter 8: Relationships

At this point, we've looked at classes, their attributes, and their operations. In the Interaction diagrams, we began to look at how classes communicate with one another. Now, we'll focus on the relationships between the classes.

A relationship is a semantic connection between classes. It allows one class to know about the attributes, operations, and relationships of another class. In order for one class to send a message to another on a Sequence or Collaboration diagram, there must be a relationship between the two classes.

In this chapter, we'll take a look at the different types of relationships that can be established between classes and between packages. We'll discuss the implications of each type of relationship and explore how to add the relationship to your Rose model.

∙

Adding association, dependency, aggregation, and generalization relationships to a Rose model through a Class diagram

∙

Adding relationship names, stereotypes, role names, static relationships, friend relationships, qualifiers, link elements, and constraints

∙

Setting multiplicity, export control, and containment

Relationships

This section includes a description of the five types of relationships you can use in a Rose model. We'll also take a look at how to find relationships. Much of the work in finding relationships has already been done by this point in the process. Here, we formally look at relationships and add them to the model. Relationships are shown on Class diagrams.

Types of Relationships

There are five types of relationships you can set up between classes: associations, dependencies, aggregations, realizes relationships, and generalizations. We'll take a close look at each of these types of relationships later in this chapter, but let's talk about them briefly here.

Associations are semantic connections between classes. They are drawn on a Class diagram with a single line, as shown in Figure 8.1.

Figure 8.1: Association relationship

When an association connects two classes, as in the above example, each class can send messages to the other in a Sequence or a Collaboration diagram. Associations can be bidirectional, as shown above, or unidirectional. In UML, bidirectional associations are drawn either with arrowheads on both ends or without arrowheads altogether. Unidirectional associations contain one arrowhead showing the direction of the

301

Chapter 8: Relationships

navigation.

With an association, Rose will place attributes in the classes. For example, if there is an association relationship between a Flight class and a Customer class, Rose would place a Customer attribute inside Flight to let the flight know who the passengers are, and a Flight attribute inside Customer to let the customer know which flight they are on.

Associations can also be labeled to further clarify them. For example, the relationship between a server page and client page is labeled with the stereotype <<build>>, indicating that the server page builds the client page. There are other stereotypes available for associations that we will discuss later in this chapter.

Dependencies also connect two classes, but in a slightly different way than associations. Dependencies are always unidirectional and show that, although one class does not instantiate the other, it does need to send messages to the other class. In other words, although object A does not instantiate and "own" object B, it does need to send messages to object B. Rose will not generate attributes for the classes in a dependency relationship.

Dependency relationships are also needed when a class is needed as a parameter or return type in an operation of a class. Going back to the airline example, if there is a dependency from Flight class to Customer class, a Customer attribute will not be created in the Flight class. Dependencies are shown with dashed arrows, as shown in Figure 8.2.

Figure 8.2: Dependency relationship

Aggregations are a stronger form of association. An aggregation is a relationship between a whole and its parts. For example, you may have a Car class, as well as an Engine class, a Tire class, and classes for the other parts of a car. In this case, a Car object will be made up of an Engine object, four Tire objects, and so on. Aggregations are shown as a line with a diamond next to the class representing the whole, as shown in Figure 8.3.

Figure 8.3: Aggregation relationship

Realizes relationships are used to show the relationship between a class and its interface, between a package and its interface, between a component and its interface, or between a use case and a use case realization. The relationship connects a publicly visible interface (interface class or use case) to the detailed implementation of the interface (class, package, or use case realization). In other words, this relationship helps separate an interface from its implementation.

A realization relationship looks slightly different when using the icon stereotype display for the interface rather than the label stereotype display. Figure 8.4 includes both options.

302

Chapter 8: Relationships

Figure 8.4: Realizes relationship

Generalizations are used to show an inheritance relationship between two modeling elements (actors, use cases, classes, or packages). Most object−oriented languages directly support the concept of inheritance. Inheritance allows one class to inherit all of the attributes, operations, relationships, and semantics of another modeling element. In UML, an inheritance relationship is known as a generalization, and is shown as an arrow from the child class to the parent class, as shown in Figure 8.5.

Figure 8.5: Generalization relationship

Finding Relationships

To find relationships, you can examine the model elements you've created so far. Much of the relationship information has already been outlined in the Sequence and Collaboration diagrams. Now, you can revisit those diagrams to get association and dependency information. You can then examine your classes to look for aggregations and generalizations.

To find relationships, you can do the following:

1.

Begin by examining your Sequence and Collaboration diagrams. If Class A sends a message to Class B on a Sequence or Collaboration diagram, there must be a relationship between them. Typically, the relationships you find with this method are associations or dependencies.

2.

Examine your classes and look for any whole−part relationships. Any class that is made up of other classes may participate in an aggregation.

3.

Examine your classes to look for generalization relationships. Try to find any class that may have different types. For example, you may have an Employee class. In your company, there are two

303