|
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.
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.
|
