Developing Class Diagrams (Design)

A Class diagram created in the Design phase provides a visual representation of each class that is contributing to a Use Case realization. Class diagrams are an essential aspect of any design effort because they directly portray the code that will be developed for a system. UML does not provide a mechanism for developing a Class diagram. However, the information needed to identify classes and their associated relationships can be derived directly from a conceptual model, if it exists, or from the objects that can be identified from the respective use case.

The Features of a Class Diagram

A Class diagram represents each class as a table with the following three sections:

• A class name that identifies the class.

• A list of attributes that describes the properties of the class.

• A list of operations that describes the behavior of the class.

For the UML notation for representing a class, refer to Figure 3.3.

The relationships between classes within a Class diagram are represented by connecting lines indicating either an association or generalization-type relationship. The type of relationship is indicated by the line style.

Association Relationships

Relationships between classes are expressed as associations with a navigability arrow indicating which direction the association can be traversed or queried. If multiplicity is not indicated, the association is assumed to be a one-to-one relationship between the classes. An example of a one-to-five through 10 association is illustrated in Figure 3.16.

Figure 3.16. An example of a one-to-five through 10 association between two classes.

When the association between two classes is not obvious, a role name can be used to uniquely identify one end of an association. In most cases, the class or an attribute name that clarifies the association can be used as the role name. Figure 3.17 illustrates how the multiplicity and role names can be placed on an association.

Figure 3.17. The UML notation for using multiplicity and role names together on the same association.

When using role names and multiplicity with associations, the class diagram can become quite complicated to read. It is important when reading an association between two classes that you read from one specific direction (class), using the navigability arrow to follow the association to the target role and multiplicity. For example, the associations illustrated in Figure 3.18 can be described as follows :

Figure 3.18. An example of reading an association with a multiplicity and role name.

• A lecturer teaches many (zero or more) courses.

• Each course has many (zero or more) lecturers and between 10 and 20 students.

• A student takes many (zero or more) courses.

To support the design of object-oriented systems, UML supports three special types of associations in the context of Class diagrams: Reflexive , Aggregation, and Composition associations.

A Reflexive association describes an association relationship between objects of the same class. Such a recursive association is shown as an association that originates and terminates at the same class. For example, Figure 3.19 illustrates a reflexive association where a person manages many persons in the role of staff and a person is managed by zero or one person in the role of manager.

Figure 3.19. An example of a Reflexive association.

An Aggregation association describes an association between a class (the container class) that can be aggregated from other classes (aggregate classes). An Aggregation association is drawn with an open diamond tip pointing to the container class from the aggregate classes. A feature of the container class is that it has the aggregate class as an attribute, but does not control the life span of the aggregate class. An example of an Aggregation association is illustrated in Figure 3.20, where a computer is an aggregation of the CPU, disk, memory, and video card classes.

Figure 3.20. An example of an Aggregation association.

A Composition association is a stronger form of Aggregation association in that it implies the container class cannot exist without its composite (aggregate) classes. A composition relationship is drawn as a filled diamond tip pointing to the container class. An example of a Composition association is illustrated in Figure 3.21, where a book cannot exist without a cover.

Figure 3.21. An example of a Composition association.

Generalization Relationships

Generalization relationships support the concept of inheritance (reuse) in UML Class diagrams, where common attributes and operations are factored out of similar classes and assigned to a broader superclass (base class). Classes that inherit the attributes and operations of a superclass are known as subclasses (derived classes). A subclass can override the inherited attributes and operations, or add its own attributes and operations to them.

Note

The process of defining subclasses is known as specialization and is applicable in Use Case diagrams to represent inheritance.

In UML a generalization relationship is indicated with an arrow head pointing at the superclass. Figure 3.22 illustrates a generalization relationship where an Animal class is the superclass and the Dog and Person classes are its subclasses.

Figure 3.22. An example of a generalization association.