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
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:
- association (also called acquaintance),
- aggregation (also called composition), and
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
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.
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
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
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
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.