UML Class Diagrams
One part of the software design process is to record the methods corresponding to responsibilities and group these methods in classes. These classes with methods are software classes representing the conceptual classes in the conceptual models. Read this section to walk through the steps of making a class diagram.
Introduction
During creation of a collaboration diagram, we record the methods corresponding to the responsibilities assigned to a class in the third section of the class box. These classes with methods are software classes representing the conceptual classes in the conceptual models. Then based on these identified software classes, the collaboration diagrams and the original conceptual model, we can create a design class diagram which illustrate the following information:
- Classes, associations and attributes
- Methods
- Attribute type information
- Navigability
- Dependencies
Steps in Making a Design Class Diagram
Use the following strategy to create a design class diagram:
1. Identify all the classes participating in object interaction by analyzing the collaborations
2. Present them in a class diagram
3. Copy attributes from the associated concepts in the conceptual model
4. Add methods names by analyzing the interaction diagrams
5. Add type information to the attributes and methods
6. Add the association necessary to support the required attribute visibility
7. Add navigability arrow necessary to the associations to indicate the direction of the attribute visibility
8. Add dependency relationship lines to indicate non-attribute visibility
9. More:
- Enhance attributes by adding datatypes
- Determine visibility e.g. public (+), Private (–) – concept for encapsulation
Add Associations and Navigability
Each end of an association is called a role. In a design class diagram, the role may be decorated with a navigability arrow. Navigability is a property of the role which indicates that it is possible to navigate uni-directionally across the association
from objects of the source to the target class as shown in Figure 4.23.
Figure 4.23: Part of Design Class Diagram Showing Navigability
Navigability is usually interpreted as attribute visibility from the source class to the target class. During the implementation in a OOP language it is usually translated as the source class having an attribute that refers to an instance of the target
class. For example, the POST classes will define an attribute that reference a Sale instance.
DCD with Association and Navigability
Correcting all the activities done in previous units and activities, finally the design class Diagram will be as shown in Figure 4.24.
Figure 4.24: Design diagram with association and navigability
Conclusion
DCD is the final structure of the software designed. To make concepts coordinate, associations has to be considered and their multiplicity. Navigation into DCD is important to be shows as well.
UNIT SUMMARY
In this unit five "GRASP" Pattern have been explored to show its importance in Object Oriented Design. Having a Design Class Diagram in place any implementation language can be applied to implement a DCD into code. As with structured approach to have the entity relation Diagram (ERD) to be the final structure for implementation, with object-oriented the final product is a Design Class Diagram ready for implementation using any means. This module is opting to show how the DCD can be mapped with the typical object-oriented programming language. The language applied is Java, though any object oriented programming language can be applied, like C++.
Source: Ellen Ambakisye Kalinga, https://oer.avu.org/bitstream/handle/123456789/667/CSI%203104_EN%20Object%20Oriented%20Analysis%20and%20Design1.pdf?sequence=1&isAllowed=y
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.