Guidelines:  Class Diagram

SWEN 5135 Configuration Management

Topics

• Explanation
• Use

Explanation

Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information.

A class diagram is presented as a collection of (static) declarative model elements, such as classes, packages, and their relationships, connected as a graph to each other and to their contents. Class diagrams may be organized into (and owned by) packages, showing only what is relevant within a particular package.

Use

The following class structures are suitable for illustration in class diagrams, but you will not use all of them in all situations. Each class structure should have its own class diagram.

• The most important classes and their relationships. Diagrams of this type can function as an object model summary and are of great help in reviewing the model. These diagrams are likely to be included in the logical view of the architecture.
• Functionally related or coherent classes.
• Classes that belong to the same package.
• Important aggregation hierarchies.
• Important structures of entity objects, including class structures with association, aggregation and generalization relationships. If possible you should create a class diagram that contains all the classes of the long-lived objects and their relationships. This kind of diagram is especially useful in reviewing what is stored in the system, and the storage structures.
• Packages and their dependencies, possibly illustrating their layering.
• Classes that participate in a specific use-case realization.
• A single class, its attributes, operations, and relationships with other classes.

You should present each class in at least one diagram. Sometimes you can better understand the model if a class appears several times in the same view, for example, if you want to discriminate between different objects of the class.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process