|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.
SETTING NAVIGATION IN RATIONAL ROSE
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.
SETTING AGGREGATION CONTAINMENT IN RATIONAL ROSE
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.
CREATING DEPENDENCY RELATIONSHIPS IN RATIONAL ROSE
A dependency relationship between CourseOffering and DBCourseOffering is shown in Figure 12-5.
Figure 12-5. Dependency Relationship
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
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|