Assigning Archetypes and Creating Associations - Practices
This article provides an overview of the practical application of object-oriented analysis and design (OOAD) design concepts and the Unified Modeling Language (UML). It†is taken from chapter two of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN:†1590591259)
Now that the Coad archetypes have been added to the model, you can proceed to label your classes with the appropriate archetypes and create meaningful associations between the classes following the guidelines of the DNC.
To assign an archetype, simply select a class in the diagram and change its stereotype value to the appropriate archetype name on the Stereotype drop-down list. For the classes currently in your class diagram you should use the values shown in Table 2-5.
Design with ArgoUML
Table 2-5. Archetype Selection
A session is something you want to
track for business purposes.
People are role players in the
context of a session.
A person presenting a session
plays the role of a presenter.
A person attending a session plays
the role of an attendee.
A room is a place that plays a role
in the context of a session.
Is the role played by a room in the
context of a session.
Is the role played by the material
and content in the context of
The material being presented.
Now that youíve defined the archetypes that your classes fall into, you can add color to your classes by using the Style tab and selecting the appropriate color for each of the archetypes using the Fill drop-down list. Table 2-6 shows a quick summary of the archetypes, their color, and the position of the color in the Fill drop-down list in the version of ArgoUML that youíre using.
Table 2-6. Coad Archetypes and Their Corresponding Colors
Position in Drop-Down List
After choosing the Archetypes and corresponding colors you can make simple connections in your model following the basic archetypes relationship, which tells you that a PPT plays a role in the context of an m-i. This forms chains of PPT-role-m-i in your model. In the current case you have the following:
Itís now easy to see the pattern. In the case of the presenter role you can read the pattern as follows: ďA person plays the role of a presenter in the context of a session.Ē Now proceed to associate the classes by clicking the Association icon in the toolbar, and then click one class and drag the cursor to the other class in the desired association. If you select an association you can change the name of the association as well as assign a stereotype to the association. All associations are one-to-one associations by default. To change the cardinality of either end of an association, right-click the association line closer to the end you want to affect, and select one of the options under the Multiplicity submenu. You can also change the nature of the association to be a composite or aggregate from the Aggregate submenu. Association directionality can also be changed from the same context menu by using the Navigability submenu.
Donít worry too much about getting all multiplicity and cardinalities of the relationships in the domain model right the first time or even in there at all. This can lead to analysis paralysis.
The resulting class diagram should resemble Figure 2-10.
Figure 2-10.Archetypes, color, and the DNC applied to the partial model
At this point you can further simplify the model by correlating the model with the structural information and with the needs of the system in order to maintain certain information. For example, in the case of the Room- SessionLocation-Session and the Presentation-ContentToBe Presented-Session legs of the diagram, you can drop both the SessionLocation and the ContentToBePresented roles because you donít need that level of detail or flexibility in the model. Therefore, you can directly connect the Green and the Pink elements in both legs of the diagram. The resulting simplified diagram is shown in Figure 2-11.
Figure 2-11.Simplified class diagram
After repeating this discovery and refinement process to the other moment-intervals identified, youíll see the domain model shown in Figure 2-12. As you can see the strategy boils down to finding the pink, then yellow, then blue and green archetypes. Then for each leg of the model you should remove any classes where complexity outweighs the flexibility provided by the class. In the case of an analysis model, remove the class only if the meaning and understanding of the model is unaffected by the removal of the class. For a design model determine if the class can be collapsed onto one of the associated classes or if it can be removed altogether without affecting the functionality of the system or component.
Figure 2-12.The TCMS domain model class diagram
The beauty of the DNC, archetypes, and color technique is that they all greatly enhance the expressiveness of a model, imparting a level or dynamism to an otherwise static class diagram.