A Few Terms
Here are a few terms that we will be using to annotate our 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. We will be using the Poseidon Community Edition tool to draw the class diagram. You can use any tool that you are comfortable with.
Click here for a larger image.
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
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.
Summary
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 next part in this article, we will take up a practical example, 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 articlewriters@novusware.com.
IE 7
Firefox 2.0
