Designing Relationships

I l @ ve RuBoard

The following design decisions must be made for relationships: navigation, containment, refinement, and multiplicity implementation.


Associations and aggregations are bidirectional relationships. During design, associations are revisited to determine if bidirectionality is indeed needed. If possible, the relationship is made unidirectional (i.e., navigable in only one direction) since unidirectional relationships are easier to implement and maintain.


  1. Right-click at the end of the association or aggregation line to be made non-navigable to make the shortcut menu visible.

  2. Click to toggle the Navigation menu choice.

Several unidirectional associations are shown in Figure 12-3.

Figure 12-3. Navigation



Aggregation containment must also be added to the model. Containment may be by value or by reference. Containment by value implies exclusive ownership by the containing class and is shown by a filled diamond. Containment by reference does not mandate exclusive ownership; it is shown by an open diamond.


  1. Double-click on the aggregation line to make the Specification visible.

  2. Select the desired Detail tab for the role representing the aggregation whole.

  3. Select the desired containment radio button.

  4. Click the OK button to close the Specification.

A containment by value relationship (ProfessorCourseOptions contains AddACourseOffering) and a containment by reference relationship (ProfessorCourseOptions to ValidIDList) are shown in Figure 12-4.

Figure 12-4. Containment



An association relationship may be changed into a dependency relationship at this time. A dependency relationship implies that the object requesting the service (client) of another object (supplier) does not have intrinsic knowledge of the location of the supplier objectit must be told where the object is located. Typically, the supplier object is passed as a parameter to one of the methods of the client class or it is declared locally within a method of the client class. A dependency relationship is shown by a dashed arrow pointing from the client to the supplier.


  1. Click to select the Dependency Relationship icon on the toolbar.

  2. Click on the class playing the role of the client.

  3. Drag the dependency relationship line to the class playing the role of the supplier.

A dependency relationship between CourseOffering and DBCourseOffering is shown in Figure 12-5.

Figure 12-5. Dependency Relationship


Multiplicity Implementation

Multiplicity of one is implemented as an embedded object, a reference, or a pointer. Multiplicity of more than one typically is implemented using a container class (e.g., a set or a list). Again, the list may be an embedded object or a pointer to the container. The decision to update the model to show all the containers that are being used is a tool/project issue. I typically do not show all the containers since they tend to clutter a diagraminstead I use the code generation properties of Rose to set the correct container.

Relationship Design in the ESU Course Registration Problem

The following relationships must be designed for the Add a Course to Teach scenario:

  • ProfessorCourseOptions to AddACourseOffering

  • ProfessorCourseOptions to ValidIDList

  • AddACourseOffering to Course

  • Course to CourseOffering

  • CourseOffering to Professor

  • CourseOffering to DBCourseOffering

ProfessorCourseOptions to AddACourseOffering

As previously mentioned, the actual design of the GUI class AddACourseOffering is dependent upon the set of GUI controls chosen. The designers have chosen to make the relationship an aggregation by value relationship because the lifetimes of the two windows are dependent. The relationship is navigable from the AddACourseOffering class to the Course class.

ProfessorCourseOptions to ValidIDList

The ValidIDList is used by many of the windows to validate the input of a user ID. The designers have decided to make this relationship a unidirectional association from ProfessorCourseOptions to ValidIDList.

AddACourseOffering to Course

This is also a GUI class. The designers have chosen to make the relationship navigable from the AddACourseOffering class to the Course class.

Course to CourseOffering

This relationship is unidirectional from Course to Course Offering since all messages are in that direction. Additionally, the aggregation is by value because all communication with the Course Offering class is directed through the Course class.

This design implies that a Course and a CourseOffering do not have independent lives. As the requirements for this scenario are stated, this is okay. But let's look at the idea of a Transcript for a student. If a Transcript is just a pointer to the CourseOfferings that a student has taken, this design does not workthe CourseOffering and the Course would have to have independent lives (and the aggregation would be set to "by reference"). Thus, here is a relationship that may mature as more scenarios are designed.

CourseOffering to Professor

The design based on only this scenario would indicate that the relationship should be a dependency relationship between Course-Offering and Professor since the Professor object is a parameter of the addProfessor operation of the Course Offering class. However, another scenario for this use case is "review schedule." Here, the Professor object must know the related CourseOffering objects, which would imply that the relationship is not a dependency relationship. Finally, the "create catalog" scenario needs to know the assigned Professor for each CourseOffering. This implies that navigation from CourseOffering to Professor is needed. Based on this information, the relationship is not changedit is a bidirectional association.

CourseOffering to DBCourseOffering

This relationship may be matured into a dependency relationship because the DBCourseOffering is passed a CourseOffering object as a parameter to the save operation.

The updated class diagrams showing the relationship design are shown in Figures 12-6 and 12-7. This design will probably change as more use cases and scenarios are developed for the system.

Figure 12-6. Updated Main Class Diagram for the Interfaces Package


Figure 12-7. Updated Class Diagram


I l @ ve RuBoard

Visual Modeling with Rational Rose 2002 and UML
Visual Modeling with Rational Rose 2002 and UML (3rd Edition)
ISBN: 0201729326
EAN: 2147483647
Year: 2002
Pages: 134

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: