D
Introduction to UML
Unified Modeling Language, or UML, is the industry standard for diagrams visualizing class hierarchies, subsystem interactions, sequence diagrams, and so on. This book uses UML for its class diagrams. Explaining the entire UML standard warrants a book in itself, so this appendix is just a brief introduction to only those aspects of UML that are used throughout this book, which are class diagrams. There are different versions of the UML standard. This book uses UML 2.
TYPES OF DIAGRAMS
UML defines the following collection of types of diagrams:
- Structural UML diagrams
- Class diagram
- Component diagram
- Composite structure diagram
- Deployment diagram
- Object diagram
- Package diagram
- Profile diagram
- Behavioral UML diagrams
- Activity diagram
- Communication diagram
- Interaction overview diagram
- Sequence diagram
- State diagram
- Timing diagram
- Use case diagram
Because this book only uses class diagrams, that is the only type of diagram that is discussed further in this appendix.
CLASS DIAGRAMS
Class diagrams are used to visualize individual classes and the relationships between different classes, both are discussed in the next sections.
Class Representation
A class is represented in UML as a box with a maximum of three compartments, containing the following:
- The name of the class
- The data members of the class
- The methods of the class
Figure D-1 shows an example.
MyClass has two data members—one of type string, the other of type float—and it has two methods. The plus and minus signs in front of each member specify its visibility. The following table lists the most commonly used visibilities.
| VISIBILITY | MEANING |
+ |
public member |
- |
private member |
# |
protected member |
Depending on the goal of your class diagram, sometimes details of members are left out, in which case a class is represented with a box, as shown in Figure D-2. This can, for example, be used if you are only interested in visualizing the relationships between different classes without details of members of individual classes.
Relationships Representation
UML 2 supports six different kinds of relationships between classes. I discuss these relationships in the following sections.
Inheritance
Inheritance is visualized using a line starting from the derived class and going to the base class. The line ends in a hollow triangle on the side of the base class, depicting the is-a relationship. Figure D-3 shows an example.
Realization/Implementation
A class implementing a certain interface is basically inheriting from that interface (is-a relationship). However, to make a distinction between generic inheritance and interface realization, the latter is visualized similar to inheritance but using a dashed line instead of a solid line, as shown in Figure D-4. The ListBox class is derived from UIElement, and implements/realizes the Clickable and Scrollable interfaces.
Aggregation
Aggregation represents a has-a relationship. It is shown with a line with a hollow diamond shape on the side of the class that contains the instance or instances of the other class. In an aggregation relationship, you can also optionally specify the multiplicity of each participant in the relationship. The location of the multiplicity, that is, on which side of the line you need to write it, can be confusing at first (see Figure D-5). In this example, a Class can contain/aggregate one or more Students, and each Student can follow zero or more Classes. An aggregation relationship means that the aggregated object or objects can continue to live when the aggregator is destroyed. For example, if a Class is destroyed, its Students are not destroyed. Figure D-5
The following table lists a few examples of possible multiplicities.
| MULTIPLICITY | MEANING |
N |
Exactly N instances |
0..1 |
Zero or one instance |
0..* |
Zero or more instances |
N..* |
N or more instances |
Composition
Composition is very similar to aggregation, and is visually represented almost the same, except that a full diamond is used instead of a hollow diamond. With composition, in contrast to aggregation, if the class that contains instances of the other class is destroyed, those contained instances are destroyed as well. Figure D-6 shows an example. A Window can contain zero or more Buttons, and each Button has to be contained by exactly one Window. If the Window is destroyed, all Buttons it contains are destroyed as well.
Dependency
A dependency visualizes that a class depends on another class. It is depicted as a dashed line with an arrow pointing toward the dependent class. Usually, some text on the dashed line describes the dependency. To come back to the car factory example of Chapter 29, a CarFactory is dependent on a Car because the factory creates the cars. This is visualized in Figure D-7.
Association
An association is a generalization of an aggregation. It represents a binary link between classes, while an aggregation is a unidirectional link. A binary link can be traversed in both directions. Figure D-8 shows an example. Every Book knows who its authors are, and every Author knows which books she wrote.
