The UML Class Diagram: Part 1, Page 2
A Few Terms Related to Class Diagrams
There ar a few terms that can be used to annotate class diagrams. You should be familiar with them:
- Responsibility of a class: It is the statement defining what the class is expected to provide.
- Stereotypes: It is an extension of the existing UML elements; it allows you to define new elements modeled on the existing UML elements. Only one stereotype per element in a system is allowed.
- Vocabulary: The scope of a system is defined as its vocabulary.
- Analysis class: It is a kind of a stereotype.
- Boundary class: This is the first type of an analysis class. In a system consisting of a boundary class, the users interact with the system through the boundary classes.
- Control class: This is the second type of an analysis class. A control class typically does not perform any business functions, but only redirects to the appropriate business function class depending on the function requested by the boundary class or the user.
- Entity class: This is the third type of an analysis class. An entity class consists of all the business logic and interactions with databases.
Creating a Class Diagram
Class diagrams can be modeled by using any UML tool that supports class diagrams. In this article, the Poseidon Community Edition tool will be used to draw the class diagram. You can use any tool that you are comfortable with.
Figure 4.1.3—a screen shot of the Poseidon tool
The screen shot of the Poseidon tool in Figure 4.1.3 shows the different options to model class diagrams and establish relationships among the packages, classes, and interfaces.
Some additional features that you can check in your modeling tool are:
- Support for forward and reverse engineering for class diagrams. A few sophisticated modeling tools also integrate with standard IDEs with support for round-trip engineering.
- Documentation and report generation features
Dos and Don'ts of Class Diagrams
Classes in a class diagram should be descriptive and must be named after business entities. Using business entities as names ensures greater readability of class diagrams.
Relationships between classes may not be apparent in the first iteration. Revise and refine your class diagrams to determine possible relationships during each iteration.
Designing is an incremental process and class diagrams are updated as the system gets built. Hence, do not try to capture and freeze the class diagrams of a system in the first pass.
Class diagrams are the basic building block used to define the design of a system. Today, 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.
In the UML Class Diagram Part 2, you will learn how to apply the class diagram to the Courseware Management system, and create the class diagrams for the system.
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, Oct. 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems, Inc.
For any questions or queries regarding the article contents, please contact firstname.lastname@example.org.
Page 2 of 2