The UML Class Diagram: Part II
Relationships between active and passive entities can easily be represented using directed association. The directed association, a variation of the "vanilla" association relationship, provides easy identification of which is the container class and which is the contained class. The CourseAdministrator class can be modeled to have a directed association with the Course class. This association can be named as "manages" because the course administrator manages courses as a business activity. In addition to this, because the course administrator also manages the tutor information and topic information, we can model a directed relationship named as "manages" between the CourseAdministrator and the Course and Topic classes, respectively. We can enhance the readability of the association between CourseAdministrator and the Course, Tutor, and Topic classes by defining the multiplicity for the association—one to many, one to one, many to many, and so forth.
Figure 4.2.1 shows the class diagram for the Courseware Management System
We have completed identifying the classes for the Courseware Management System and established the relationships among the classes. Take a look at the class diagram in Figure 4.2.1. The class diagram of the Courseware Management System includes all the classes and their relationships that we identified during our analysis of the problem statement.
|Model View Controller Design|
The class diagram that we designed for the Courseware Management System defined the basic classes necessary for representing the basic structure of the system. But this is by no means a complete design if the architecture of your system is to be based on the Model View Controller (MVC) architecture. Because an MVC model defines clear separation of classes among the three layers—business, presentation, and flow control—you need to define additional classes and revise your design to include them. In case your UML tool does not support explicit partitioning of classes, you can mark classes in each of the layers using stereotypes such as <<entity>>, <<boundary>>, <<control>>, and so forth.
For example, in our case study application, we can revise the class diagram to define a new CMSController class that manages the flow of the application. The model layer primarily consists of classes relevant to the business domain. Next, the classes that we had defined can be categorized as transactional and persistent classes. The CourseAdministrator class performs most of the activities in the system. Hence, this class can be designated as a transaction class of the model layer. Similarly, the Course, Topic, Tutor, CourseCalendar, and Student classes represent persistent business data. Hence, these can be categorized as persistent classes of the model layer. Finally, you can define a set of classes that represent the presentation layer; in other words, the user interface of the system.
Forward Engineering from Class Diagrams
Forward engineering is the process of generating source code (in a specific language) from a class diagram model. The extent to which a UML class diagram can be used to generate source code depends upon the limitations of the source code language. Because UML is pictorial, and can depict a lot of details, these details could be lost in the code. Hence, before creating a complete class model, it is a good idea to be aware of the language that is going to be used, to limit the class model accordingly. Typically, the association relationships between classes are generated as member variables between the related classes in the source code. Generalization relationships are generated as inheritance relationships in the source code.
Figure 4.2.2 shows forward engineering a class diagram
The above screenshot shows the source code file generated for the CourseAdministrator Java source code file as a result of forward engineering the class diagram of the Courseware Management System case study. You need to check how forward engineering works in the tool that you use.
Reverse Engineering of Class Diagrams
Obtaining a class model from existing source code is called reverse engineering. This is generally done when it is required to understand the architecture of an existing system, either for re-engineering, or for maintenance. Reverse engineering is of great use especially when trying to figure out the static structure and organization of a complex system. Typically, classes defined as member variables in the source code are modeled as association relationships between the classes. Inheritance relationships in the source code are generated as generalization relationships between the classes.
Figure 4.2.3 shows reverse engineering a sample source code file
The above screenshot shows a class diagram generated as a result of reverse engineering a sample source code file. You need to check how reverse engineering works in the tool that you use.
In the last article, we saw how class diagrams are the basic building blocks that define the design of a system. We learned about the elements of a class diagram—classes, interfaces, and packages—and the different types of relationships among these elements, such as association, aggregation, composition, generalization, and realization.
Today, we defined a few steps to identify classes and interfaces of a system from a problem statement for designing the class diagram for the Courseware Management System case study.
In the next part in this series, we will study the Object diagram.
About the Authors
Mandar S. Chitnis, Lakshmi Ananthamurthy, and Pravin S. Tiwari are the co-founders of Novusware, Inc.. They have co-authored the book Teach Yourself BEA WebLogic Server 7.0 in 21 Days (SAMS Publishing October, 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems inc.
For any questions or queries regarding the article's contents, please contact firstname.lastname@example.org.
Page 3 of 3