Class Diagrams

Each class is shown as a 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. 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. A distinction is made between an abstract class and a concrete class. The name and methods of an abstract class are written in italics while those of a concrete class 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.

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

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 denote 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. This would be drawn as:

Both single instance and multiple instance relationships can be represented. The relationship between the Circle class and the Location that represented the center of the Circle is an example of a single instance relationship because 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 denote a multiple instance relationship. This relationship is read as "A Canvas contains many Shapes".

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 follows:

It is important to understand the difference between composition (aggregation) and association (acquaintance). With composition the composed object is viewed an 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 shows 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 (to be used in drawing Circles, Rectangles, ...) 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 as in the following:

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, an earlier diagram 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 the Canvas manipulates its Shapes.

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 class containing this algorithm fragment. This is shown in the following figure:

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

The individual relationships presented above can be collected together in a single diagram as shown here:

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.