2.1 UML overview

Nowadays, software systems, like organisms, are far too complex to be described by a single blueprint. Instead, a number of descriptions are necessary so that each can focus on a different aspect of a system. Similar to the architecture of a building, the core structure of a software system is the foundation around which all other aspects are built. Whereas a building is a static artifact, software systems mainly derive their value from their behavior. To further complicate the situation, the structure of a software system is not a concrete, touchable thing, which makes its behavior even more difficult to describe and grasp.

The various notations provided by UML are each designed to focus on individual aspects of a software system. The static structure of a piece of software is described by the most important part of UML, the class diagram. A class diagram gives an overview of the whole system it captures the structure and relationships between the components. Object diagrams are closely related to class diagrams. They are a useful and important technique to describe snapshots of a system.

UML provides several notations to describe different aspects of behavior. Sequence diagrams are among the most prominent, for they capture interactions between objects. They describe how several objects interact with each other through sending and receiving messages. They normally do not consider the state of participating objects.

Collaboration diagrams provide almost the same information, but in a different way. In our experience, collaboration diagrams often turn out to be harder to read than sequence diagrams it is more difficult to understand the overall message flow. Additionally, collaboration diagrams are more difficult to manipulate, e.g. through adding new participating objects, filtering irrelevant messages, or combining two diagrams. Thus, collaboration diagrams are not used in this book, and we do not follow the line of UML documentation that suggests using these diagrams specifically for pattern presentation.

Statechart diagrams describe the life cycle of single objects: Statecharts^[3] combine information about an object's state, including information about its behavior.

^[3] First defined by David Harel (Harel, 1987).

Other kinds of diagrams focus on workflow (activity diagrams), on the software components and their physical distribution over several computers or nodes (component diagrams and deployment diagrams), and on describing how users perceive the system (use case diagrams). None of these types of diagram is used in this book.

Although UML is a complex language offering a number of notations for various aspects of a software system, these notations are not necessarily tightly coupled. This is a problem, because it makes the consistent and systematic use of several notations within a development process more difficult. But it is also an opportunity, as it allows a focus on a subset of UML. As with natural languages, it is not necessary to understand and speak the entire UML language perfectly in order to communicate. Instead, a UML subset (or a UML profile) may focus on the essentials of the context in which it is used. In this book, the focus is on the description of the relevant aspects of a framework. We identify subsets of class, object, and sequence diagrams as our basic language. These diagrams cover the structure on a general level (class diagram) as well as on an instance level (object diagram), and the intended interactions between objects (sequence diagram). The following sections introduce the relevant features of these diagrams.