UML class and object diagrams

UML class diagrams display classes, their properties, and relationships between classes. The principal relationships in class diagrams are discussed below.

Object diagrams display instances of classes, and can be regarded as “snap-shots” of the object-system (or a part of it) in a chosen situation. Object dia-grams display connections between object instances, not between their respective classes. Therefore, inheritance relationships are not displayed. Booch, Jacobson, and Rumbaugh state that object and instance are “largely synony-mous”. They believe that an association may be also an instance, although it is not an object (Booch et al. 1999: 185). Here, object diagrams are described more briefly than are class diagrams, because they have minor importance as com-pared with class diagrams in this study.

Other structural diagrams and/or dynamic diagrams in general are not described here. Apart from one sample interaction, presented in Chapter 9, they were not considered necessary for this study.

Central features of UML diagrams are described with simple examples. Each example shows a UML statement. In practice, typical UML diagrams contain more than two or three classes or objects. On the other hand, an entire class structure or object system is usually broken into several small diagrams for the sake of clarity, or because of practical limitations imposed by available display area or computer screen resolution.

4.5.1 Class and its properties

In UML diagrams, a class is shown in a rectangular box containing the name of the class and its properties. Properties are separated from the class name with a horizontal line. Attributes and operations are typically separated from each other by a vertical line.

Figure 4-1 shows an example diagram containing a single class. The class is named CMNSymbol. It has four attributes (“origin”, “size”, “dimensions”, and

“value”) and two operations (“draw” and “play”). In addition to name, attributes, and operations, UML also allows a fourth category, called responsibilities. How-ever, a class can be displayed by using only the class name.

CMNSymbol

draw play origin size dimensions value

Figure 4-1: Class

4.5.2 Association and aggregation

An association between two classes is shown with a line connecting the classes as in figure 4-2. Associations may have properties called adornments such as name, role or multiplicity. In UML terminology, aggregation is described as an adornment of association (Booch et. al. 1999: 143). Figure 4-2 states that the class A is associated with the class B. On the instance level, the figure states that an A object (i.e., an instance of the class A) is associated with an instance of class B. Since no adornments are presented in the diagram, an A object may be associated with an undefined amount of B’s (instances of B) and vice versa.

Figure 4-3 shows an example of an aggregation. The latter is illustrated by an open diamond shape at the “whole end” of a whole-part relationship. In the example, B is part of A. The roles of A and B are as follows: A is the aggregate, and B is the part. The diagram states that an instance of class A may contain an unspecified amount of instances of class B, while each instance of B may be part of an unspecified amount of instances of A.

The multiplicity adornment defines the amount of instances of a specific class allowed at each end of an association. Figure 4-4 shows an aggregation with a multiplicity adornment. The association in the figure can be read as “a 1-to-4 aggregation exists between A and B.” Figure 4-4 determines that A has exactly four instances of class B as its parts. Respectively, B is (always, if addi-tional class diagrams are not given) part of one (and only one) instance of class A. Multiplicity may specified by giving an exact value, a list of discrete values (e.g. “0,1,2”), a range (e.g. “0-5”), or an asterisk (“*”) denoting an arbitrary amount.

A role adornment states that an object refers to its associate object by that name. Figure 4-5 shows an association of a class named Person with itself. A

Figure 4-2: Association

B A

role name is shown at both end of the association. The association states that a Person (i.e. an instance of the class Person) is associated with another Person and refers to that other person as “parent”. The other person, in turn refers to the first Person as “child”.

An association may be given a name as an adornment. A name may be used, for example, if there is a need to refer to a particular association among other associations.

A special case of a one-to-many aggregation is called composition. In this case, a part may be part of one object only; moreover, the part can not exist with-out the whole. Figure 4-6 shows an example of a composition between classes A and B. There, an instance of a class B is part of an instance of class A. The exist-ence of instances of B is dependent on the existexist-ence of A’s instance(s). If the instance of A is deleted, then the B’s respective instance is deleted with it (Booch et al. 1999: 147, 459-460).

Figure 4-3: Aggregation

B A

Figure 4-4: Aggregation with a multiplicity adornment

B

A ^{1 4}

4.5.3 Inheritance

Inheritance is illustrated in UML with an arrow symbol. A large, open arrow head is at the generalization end of the relationship. Figure 4-2 shows an exam-ple inheritance structure with a superclass A and two of its subclasses: B and C.

Both classes B and C inherit the properties of class A. An instance of class B will have the properties of both A and B. In turn, an instance of C will have the properties of both A and C.

Some programming languages support a feature called multiple inheritance.

There, a class may have more than one direct superclass. Figure 4-8 shows class C, which inherits classes A and B. A and B could, in turn, have a common super-class. Languages that support multiple inheritance should also include a way to handle potential conflicts that arise when parallel superclasses share the same properties. There the programmer should be able to control which of the con-flicting properties are inherited from the individual superclasses.

Person ^child

parent

Figure 4-5: Association with role adornments

Figure 4-6: Composition

B

A ¹

4.5.4 Other relationships and features

UML specifies a number of other relationships, including dependency and asso-ciation class. Assoasso-ciation class is a class that gives additional properties to an association. An association class is used when an association is considered to be so complex that it requires the use of properties that are logically part of the association and not part of the associated classes (Booch et al. 1999: 147-148).

Dependency is used for defining a connection between two things, where a change in one thing will reflect on or in the other (Booch et al. 1999: 63). This

Figure 4-7: Inheritance

A

C B

C

B A

Figure 4-8: Multiple inheritance

relationship is shown with a dashed arrow pointing out the direction of the dependency.

4.5.5 Object diagrams

Object diagrams are used for showing instance-level relationships. An object diagram serves as a demonstration tool showing a “snapshot” of a hypothetical or real situation of the object system at runtime.

Object-diagrams may include several instances of the same class. As opposed to class diagrams, association and aggregation relationships are both replaced with links (drawn with solid lines) connecting objects. Inheritance rela-tionships are typically not shown, since many programming languages imple-ment inheritance as a compile time construct rather than a runtime feature. Even with prototype-based languages, such as SELF, inheritance structures are not often relevant when the runtime behavior of the system is demonstrated.

In Figure 4-9, an example object diagram is shown. The diagram is an instance-level equivalent of the class diagram of Figure 4-5. The objects are dis-played as boxes. Objects can be distinguished from class symbols by the colon symbol that separates the object identifier and the class name, and by the hori-zontal line under the identifier/name string. The example shows that the object

“jill” of class “Person” is a “child” of Person “john” and “john” is a “parent” of

“jill”. As noted above, instance names are commonly, although not exclusively, denoted with an initial lower case letter, while class names have an initial upper case letter.

jill: Person john: Person

parent child

Figure 4-9: Object diagram