Class diagrams

introduction class diagrams use cases interaction packages state and activity discussion

Class diagrams represent (ideally) the conceptual structure of the system. Class diagrams typically consist of class descriptions and relations or associations between these. Class descriptions may be given as types, interfaces or actual classes, including attributes, methods and even visibility specifications. There is considerable liberty in how much detail is provided in either class descriptions or relations. As a rule of thumb, omit details as much as possible.

slide: Class diagrams

Special relations between classes are generalization or inheritance (indicated with the triangle in the diagram left in slide class-diagrams) and aggregation or containment (indicated with the diamond). In this example, just think of a compound as containing a number of instances of the type of which the compound is derived. The aggregation relation is often referred to as a has-a relation, which is, however, not appropriate when the object contained is actually used for delegation as discussed in chapter 2.

The diagrams on the right indicate how to depict arbitrary associations. Think for example of the relation between Employer and Employee classes. Clearly, in this case the role each class has with respect to the other class follows from the class name itself. In other cases it may be helpful to indicate the role explicitly.

When the association between classes is more complex, an explicit association class may be introduced, for example a class specifying a work contract, to describe the association in more detail.

Class diagrams may be refined further by adding annotations to the class descriptions and the relations. For example, relations may be more precisely defined by adding multiplicities (1,*,0..1,m..n, to indicate respectively one, many, optional or bounded). Class descriptions may be refined by adding notes, drawn as a box with a flattened edge, containing descriptive text.

The UML also allows for adding constraints, between curly brackets, and for the definition of so-called stereotypes, indicated by angular brackets as in <>, which represent generic constraints.