Class Diagrams


The class diagram depicts the public interface of a single class and the other classes it uses or is used by. An example of two classes as they appear in a class diagram is shown in the figure below.

Composite Pattern Example of Two Classes

Each class is shown as a divided rectangle whose topmost portion contains the name of the class. Below the name of the class, the methods of the class's public interface are given. In this example, the Shape class has three public methods (MoveTo, Draw, and Erase), while the Circle class has four methods (MoveTo, Draw, Erase, and Radius). Finally, if appropriate, the bottom portion contains key instance variables of the class. Note the distinction made between abstract classes and concrete classes. The name and methods of abstract classes are written in italics, and those of concrete classes appear in the normal font. An abstract class corresponds to a C++ class that contains one or more pure virtual methods. Recall that an abstract class defines an interface that must be completed by a derived, concrete class. There are no objects of the abstract class.

The class diagram allows four different relationship among classes to be represented. They are:

  • inheritance,
  • association (also called acquaintance),
  • aggregation (also called composition), and
  • creation.

It is important to remember that these are relationships among classes, not among objects of these classes.

The inheritance relationship is shown in the following class diagram, which indicates that the concrete classes Rectangle and Circle (and others, denoted by the ellipsis) are derived from the Shape class.

Representing Inheritance

For simplicity, the diagram showing inheritance only gives the names of the classes; the more complete class representation showing the public interface and private instance variables would normally be given. Notice again that italics are used in the name of the Shape class to connote that it is an abstract class.

An aggregation (or composition) relation is shown by an arrow from the composing class to the composed class. For example, the Circle class has a private data member of type Location that records the center of the circle. This data member is not shared between Circle objects, and would be drawn as shown in the figure below.

Representing Aggregation

Both single-instance and multiple-instance relationships can be represented in class diagrams. The relationship between the Circle class and the Location that represented the center of the Circle is an example of a single-instance relationship, for each Circle has exactly one center. A multiple-instance relationship occurs in the Canvas class that maintains a collection of Shape currently appearing on the Canvas. As shown below, a small, filled circle at the point of the arrowhead is used to indicate a multiple-instance relationship. This relationship is read as "A Canvas contains many Shapes."

Representing a Multiple-Instance Relationship

An association or acquaintance relationship is used to denote sharing among classes. For example, a Rectangle or a Circle may both use the same instance of a "Pen" class to implement their Draw and Erase methods. In this case, a simple solid line with an arrow is used to show the relationship. The example of the Rectangle, Circle and Pen classes would be drawn as shown in the following figure.

Representing Sharing

It is important to understand the difference between composition (specifically, the form of composition that was earlier termed aggregation) and association (acquaintance). With composition, the composed object is viewed as a part of the composing object in the same sense that a wheel is a part of an automobile. However, the driver of the automobile is not a part of the automobile although an automobile object may know about (be associated with) its driver.

The last relationship between classes is that of creation. This relationship is evident when objects of one class (the created class) may be generated as a result of the computation of another class (the creating class). For example, a Pen object in the above figure may be created by an object of the PenPalette class. The PenPalette class may read information form a configuration file or interact with the user to determine the characteristics of the Pen object that it creates. The creation relation is shown by a dotted line in the following figure.

Representing a Creation Relationship

Occasionally, the significance of the relationship between classes is conveyed more fully by showing a key fragment of an algorithm that illustrates how the relationship is used. For example, the earlier diagram, titled "Representing a Multple-Instance Relationship," showed that the Canvas class has several Shapes, but this diagram did not help the reader to understand the purpose behind this relationship. A typical reason for the relationship is that when told to Draw itself, a Canvas object would direct each of the Shapes contained within it to Draw themselves. Such an explanation helps to deepen the reader's understanding of why the Canvas class has several Shapes and how it manipulates them.

An algorithm annotation can be added to a class diagram by placing the algorithm fragment in a separate box and connecting this box to a method of the appropriate class. This is illustrated in the following figure.

Representing a Code Fragment

Algorithm annotation must, of course, be used with restraint. Cluttering a class diagram with nonessential algorithmic details undermines the purpose of the diagram. Such unnecessary annotations add volume without aiding understanding of the class structure.

The individual relationships presented above can be collected together in a single diagram as shown in the following figure.

A Complete Example

This class diagram shows that a Canvas has (by composition/aggregation) several Shapes, each of which may be an subclass of the abstract Shape class. The Draw method of the Canvas class will call the Draw method of each composed Shape. Since Shape is an abstract class, the Draw method applied to a Shape will actually be done by some object that is a (unknown to the Canvas class) subclass of Shape. Different subclasses of Shape can share the same Pen that is produced by the PenPalette class.


©1998 Prentice-Hall, Inc.
A Simon & Schuster Company
Upper Saddle River, New Jersey 07458

Legal Statement