Guidelines: Class Diagram
Topics
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.
- The most important design subsystems, classes, interfaces, and their relationships. Diagrams of this type can function as a design 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 and generalization hierarchies.
- Important structures of entity classes, 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.
