2.3 Object diagrams

UML object diagrams are closely related to class diagrams. Because both deal with the structure and the data of the system, object diagrams are often not treated as a stand-alone notation but as a variant of class diagrams. Object diagrams are a useful and important technique for describing snapshots of a system indeed, important enough to regard and introduce this kind of diagram as a notation on its own. Object diagrams are useful for conveying certain kinds of information that class diagrams cannot. Object diagrams contain objects and, thus, describe a system on an instance level that might occur at runtime. A set of object diagrams can describe variants of object structures to the very same class diagram. A single object diagram thus describes an actual object structure, whereas a single class diagram describes a set of potential object structures.

2.3.1 Object diagram example

The object diagram in Figure 2.3 shows one sample object structure. It is consistent with the class diagram in Figure 2.1. Objects, like classes, are drawn as rectangles. However, for a clear distinction from classes, the names of objects are underlined. A name consists of two parts an object name, and its class name. For example, mary:Child is an object of class Child with the name 'mary'. Note that the object name must neither be confused with a variable referring to an object nor with the object identity; although in the implementation, these object names are often mapped to variable names. The object name in an object diagram is used to identify the object within the diagram. In a running system, the very same diagram structure may occur several times, thus allowing several objects to take the role of 'mary' 'mary' can be regarded as a prototypical object describing a role.

Figure 2.3. A sample object diagram

The object name is optional and may be used to refer to that object in the explaining text. Object names in the diagram are primarily used to distinguish instances of the same class, since one diagram may contain an arbitrary number of objects of the same class. The class name can also be left out, provided that the class of the object is clear from the context in which it is presented. Each rectangle in a diagram stands for a unique object, even if the objects are not distinguished by explicit names. Objects that are not given explicit names are called anonymous objects.

In order to clarify a certain snapshot the object attributes may show concrete values. Although subclass structures are not shown in object diagrams, the inherited attributes can be mentioned explicitly (e.g. attribute 'age' in Figure 2.3). Methods are usually not shown in an object diagram.

In the same way as an object is an instance of a class, a link is an instance of an association. According to the association in the class diagram in Figure 2.1.1, each House object has exactly one link to a Human object, namely its owner. In the opposite direction, Human (and therefore also Employee and Child) objects may have an arbitrary number of links. The given association has an arrow from class House to Human, thus allowing navigation starting from houses. This is reflected by the link carrying an arrow in that direction. Although links in standard UML are bidirectional in nature, an implementation might only allow navigation in one direction.

In this example, the role name 'owner' can be added to a link. A role name can be used in an object diagram to clarify which association a link represents. Alternatively, if an association name is given, it may also be attached to its links.

Object diagrams reflect the composition of House objects consisting of exactly one Roof object, and an arbitrary number of Door objects composition is realized by means of links to the aggregated objects. As the class diagram in Figure 2.1 does not contain navigation arrows for the composition relationships, the object diagram also does not show navigation arrows. If desired and inferable from the context of a link, the diagram may also drop association and role names.

2.3.2 Exemplar nature of object diagrams

During runtime, a system may dynamically change its structure. New objects are created, and others become obsolete and are eventually removed from the system by garbage collection. Of course, the linkage between objects changes. An object diagram only shows a snapshot of the system. A snapshot is a partial view of the system because it does not usually show all objects and links. Furthermore, it shows the structure of the system only at a particular point in time. Figure 2.4, for example, represents another object diagram consistent with the class diagram in Figure 2.1.

Figure 2.4. Another sample object diagram

Object diagrams are therefore of exemplar nature. Several of them may complement the information conveyed by a class diagram, because the latter describes all the potential snapshots. A class diagram is a constraint on snapshots in the sense that each snapshot of a system actually has to conform to the class diagram. An object diagram, instead, is useful to exemplify a particular situation, e.g. during the initialization phase, before or after a particular operation, or an erroneous state. Also, object diagrams can be used to describe the structure of a composite object or a desired object structure and they are especially useful in describing standard situations within a framework, or in describing how objects of newly added classes integrate with existing framework objects.

Several object diagrams may coexist to exemplify different situations. In the case that explicit names are given, it is even possible to specify overlapping object structures for example, in Figures 2.3 and 2.4 employee Tom owns sunset-blvd-8. It is important to keep in mind that an additional textual explanation may be needed to clarify which situation is described with these diagrams. Both may, for example, describe different situations in the life of Tom, e.g. before and after winning the lottery.

The situation captured by an object diagram does not necessarily occur while the system is running it might happen that the described object composition never occurs. On the other hand, an object structure may also occur more than once it may repeatedly occur at different points in time, or may occur several times in the same system snapshot. One of the most prominent uses for object diagrams is to describe an object structure that is created initially and that statically holds for the whole system's execution, or until its objects are deleted.

Object diagrams give a developer a useful clue about the structure of the framework to be used. Object diagrams are particularly useful in explaining framework architectures. In complex situations, or when association multiplicity of more than 1 is involved, the diagrammatic depiction of several distinct objects of the same class allows the illustration of situations that cannot be described well using class diagrams alone. Thus, object diagrams become a useful tool for the discussion of framework construction principles later in the book. Many pattern descriptions also use object diagrams to exemplify the object structures on which they operate.