Chapter 4

Structure

Purpose • To describe structural relations between classes and ob-

jects in a problem domain.

Concepts Class structures

• Generalization: A general class (the super class) describes
properties common to a group of specialized classes (the
subclasses).
• Cluster: A collection of related classes.
Object structures
• Aggregation: A superior object (the whole) consists of a
number of objects (the parts).
• Association: A meaningful relation between a number of
objects.

Principles • Study abstract, static relations between classes.

• Study concrete, dynamic relations between objects.
• Model only the necessary structural relations.

Result • A class diagram with classes and structures.

In the structure activity, we focus on relations between classes and objects.

Our task is to model abstract, general relations between classes, as well as
concrete, specific relations between objects.
In the class activity, we selected classes for our problem-domain model
and characterized each class by its events. In the structure activity, we ex-
tend this description by adding structural relations between classes and ob-
jects. The movement from the class activity to the structure activity corre-
sponds to the way in which humans define and use language constructs. In
natural language, we define concepts by relating them to other concepts.
The result of the structure activity is a class diagram. The class dia-
gram provides a coherent problem-domain overview by describing all struc-

69
70 ________________________________________________________________ Structure

1
Customer

0..∗

0..∗
Appointment
1

1
1 1..∗
Employee Day Schedule
1

1..∗
Apprentice Assistant
Time Period

Work Free Other

Figure 4.1: Class diagram for the Hair Salon System (Chapter 20)

tural relations between the classes and objects in our model. Figure 4.1
shows an example of a class diagram.

4.1 Object-Oriented Structures

When we extend our problem-domain model with object-oriented struc-
tures, we continue to employ the fundamental distinction between object
and class introduced in Chapter 3.
On the concrete object level, we ask: What are the specific relations be-
tween objects in the problem domain? To answer this, we view a phenome-
non in the problem domain as an object, with certain properties that deter-
mine its identity, state, and behavior. For example, we might consider a
person as a company employee, but not as a family member or a person
with a particular hobby. In viewing this person as an employee object, we
focus on her name, address, department, and salary. At the same time we
ignore such properties as spouse, children, hobbies, political opinion, and so
on. This illustrates how, through what is denoted as abstraction, we simpli-
Object-Oriented Structures ________________________________________________ 71

fy an object to capture only selected properties related to the problem do-

main. One such property is the object’s relation to other objects. To describe
this, we apply two kinds of object structures: aggregation structures, which
describe the relation between an object and its component objects; and asso-
ciation structures, which describe other meaningful object relations.
On the abstract class level, we ask: What is the conceptual relation be-
tween two or more classes in our problem-domain model? Compared to an
object, a class is a further abstraction that captures selected properties of a
group of objects. The class is a description of properties and behavioral pat-
terns that are common to all the objects in that group. To describe the con-
ceptual relations among classes, we apply two kinds of class structures:
generalization structures, which describe a number of classes as specializa-
tions of a more general class; and cluster structures, which group collec-
tions of related classes.
All object-oriented structures are described on the class level by certain
connections among classes in a class diagram. As Figure 4.2 shows, the
class diagram uses the graphical notation for a class. Figure 4.2(a) shows
the notation for a class with a related collection of objects. Below, we also
deal with examples of classes that have no related objects; these are called
abstract classes. We include them only for descriptive reasons, using italics
to signify their name in notation, as Figure 4.2(b) shows.

Class name Class name

(a) with objects (b) without objects

Figure 4.2: Graphical notation of a class

Even though we describe class and object structures together in the class
diagram, there is an important and decisive difference in their semantics.
Class structures express static, conceptual relations between classes. They
connect classes, and that relation does not change unless we change the de-
scription itself. The object structures, on the other hand, express dynamic,
concrete relations between objects. These relations can change dynamically
without any implied changes in the description.
We divide the structure activity into three subactivities, as Figure 4.3
shows. In the first subactivity, we combine our problem-domain knowledge
with the different structure types to produce candidates for structural rela-
tions among the selected classes and objects. In the second subactivity, we
explore the relevance of several general patterns to enhance our problem-
domain model. In the third subactivity, we evaluate and select the required
structural relations from our group of candidates.
72 ________________________________________________________________ Structure

Find candidates for

Event Table structure

Explore
patterns Evaluate
systematically

Class diagram

Figure 4.3: Subactivities in modeling the problem-domain structure

The structure activity is experimental in two ways. First, the structure

activity reveals weaknesses in our selection of classes and objects. Some
classes may turn out to be superfluous; more typically, some classes will
grow into more complex groups of structurally related classes and force us
to redo the class activity. Second, the structure activity itself is character-
ized by frequent changes among its three subactivities. We jump back and
forth between generating candidates, exploring patterns, and systematical-
ly evaluating the usefulness of both. This iterative character also applies to
the four types of structural relations, which experienced system developers
work with all at once. For the sake of clarity, we present them here one at a
time.

4.2 Structures between Classes

There are two types of class structures: generalization and cluster. Gener-
alization structures gather the common properties and behavioral patterns
of different classes into more general classes. Cluster structures collect sev-
eral classes in a class diagram under one overall concept.

Generalization Structure
A generalization structure is a relation between two or more specialization
classes and a more general class:
Generalization: A general class (the super class) describes properties
common to a group of specialized classes (the subclasses).
Structures between Classes _______________________________________________ 73

For example, the classes “Taxi” and “Private Car” might be specializations
of the general class “Passenger Car,” as Figure 4.4 shows. Similarly, the
class “Vehicle” might be a further generalization of the classes “Passenger
Car” and “Truck.”
We call a specialized class a subclass and a generalized class a super
class. Linguistically, we express specialization with the formulation “is-a.”
You can use this to verify the correctness of a generalization candidate. We
must, for example, be able to say that “a taxi is a passenger car.” Figure 4.4
shows the graphical notation for a generalization structure. A generaliza-
tion structure is drawn as an arrow from the subclass to the super class. If
several arrows point to the same class, you can join the arrows as Figure
4.6 shows. The class diagram is easier to understand if all the arrows con-
sistently point upwards, implying that generalization classes are above
their specializations.

Passenger Car

Taxi Private Car

Figure 4.4: Generalization structure

The set of objects in each of the specialized classes is a subset of the set of
objects in the general class, and all subsets are mutually exclusive. This re-
lationship can be expressed in another way: Everything that holds true for
the general class also holds true for the specialized classes, whereas the
properties of a specialization class may only hold true for that particular
class.
The generalization structure expresses inheritance: Specialized classes
inherit the properties and behavioral pattern of the general class. Given
this, the general properties apply to all objects at the specialized level, in
addition to their own specialized properties. (We discuss problems that
arise with inherited behavioral patterns in Chapter 5.)
In some cases, we want to describe properties at an abstract level, even
if the problem domain contains no objects at that level. Figure 4.5 shows an
example in which the problem domain contains only employees and custom-
ers. Because the “Person” class contains no concrete objects, it is abstract,
but it is useful for describing properties that are common to and inherited
by both the employee and customer classes.
74 ________________________________________________________________ Structure

Person

Customer Employee

Figure 4.5: Application of an abstract super class

The typical generalization structure is hierarchical in that any subclass

is a specialization of exactly one super class. However, multiple inherit-
ance—in which a class inherits properties from two or more super classes—
can improve our model in some cases. Figure 4.6 shows an example, using a
model with three types of accounts: basic account, checking account, and
loan. In addition, there is a service account that inherits the properties and
behavioral patterns from both the checking account and loan classes.

Account

Basic Account Checking Account Loan

Service Account

Figure 4.6: Different types of accounts with multiple inheritance

Cluster Structure
A cluster is a collection of classes that helps us achieve and provide a prob-
lem-domain overview:
Cluster: A collection of related classes.
A cluster conveys an overall understanding of a problem domain by divid-
ing it into smaller subdomains. The graphical notation is a file folder that
encloses the classes. Figure 4.7 shows an example of a model for an automo-
bile register. As the figure shows, a cluster is usually named after a central
Structures between Objects________________________________________________ 75

«cluster» «cluster»
Cars People

Car Owner

Engine Passenger car Clerk

Cylinder Taxi

Figure 4.7: Cluster structure

class: the “Cars” cluster consists of all classes pertaining to types of cars
and their components. Another cluster is composed of the classes describing
people associated with the cars. These two clusters summarize the model’s
basic structure.
Classes within a cluster are usually connected by either a generaliza-
tion structure or an aggregation structure. For example, this is the case
with the “Cars” cluster in Figure 4.7. Relations between classes from differ-
ent clusters are usually association structures. In Figure 4.7, “Owner” and
“Car” in two different clusters are related through an association structure.

4.3 Structures between Objects

There are two types of object structures: aggregation and association. Both
structures capture dynamic relations between objects in the problem do-
main. We describe the object structures in the class diagram as structural
relations between two or more classes. The structures are described on the
class level, with an assigned multiplicity property specifying that some ob-
jects from the related classes can be connected.

Aggregation Structure
An aggregation structure is a relation between two or more objects. It ex-
presses that one object is a fundamental and defining part of the other:
76 ________________________________________________________________ Structure

Car

1 1 1
1 1 4..∗

Body Engine Wheel

1 1
1..∗ 2..∗

Cam Shaft Cylinder

Figure 4.8: Aggregation structure

Aggregation: A superior object (the whole) consists of a number of

inferior objects (the parts).
An aggregation structure is drawn as a line between the classes of the
whole and the parts, where the line is annotated with a rhomb at the class
that models the whole.
Figure 4.8 shows an example of an aggregation structure. In this mod-
el, objects of the “Cam Shaft” class can be part of an object of the “Engine”
class, and an object of the “Car” class can aggregate an object of the “En-
gine” class. The opposite of aggregation is decomposition. In this figure, for
example, a car can be decomposed into objects from the “Body,” “Engine,”
and “Wheel” classes.
As Figure 4.8 shows, we specify multiplicity with a single number or a
range between two numbers. The numbers can be either absolute values or
variables. You can read the multiplicity as follows: Every engine has be-
tween two (2) or more (*) cylinders, while every cylinder is part of precisely
one (1) engine. The multiplicity is always read from the middle of the con-
nection out toward the related objects.
Linguistically, we express aggregation with the formulation “has-a,”
such as, “a car has an engine.” Similarly, we express decomposition as a “is-
part-of” or “is-owned-by” relation, such as, “the engine is a part of the car.”

Association Structure
An association structure is also a relation between two or more objects, but
it differs from aggregation in that associated objects are not a defining
property of an object:
Find Candidates for Structure _____________________________________________ 77

Association: A meaningful relation between a number of objects.

An association structure is drawn as a simple line between the relevant
classes. We describe association multiplicity in the same way as we de-
scribe aggregation. Because the association structures do not imply rank-
ing, you can place the related classes anywhere in the class diagram.
Association is often used when aggregation would imply a too strong re-
lation. For example, we may want to model a problem domain where a car
is owned by one or more people, and a person owns zero or more cars (see
Figure 4.9). It makes no sense to say that an object from the car or person
classes contains objects from the other class as its parts. Moreover, the per-
son who owns a car is neither a defining property of a car, nor the reverse.
Therefore, the relation between objects from the two classes is described as
an association structure and not as an aggregation structure.
Linguistically, we can express association with the formulation “knows”
or “associated-with.”

0..∗
Car 1..∗
Person

Figure 4.9: Association structure

It is not always clear which properties a given association structure repre-

sents. We solve this by explicitly naming the association structure. We
might call an association structure between a person and a car “ownership,”
for example, to emphasize the relationship that the structure represents.
Also, in a motor vehicle register, for example, two different associations be-
tween cars and people might be necessary: “owned by” and “used by.” In
this case, naming is required, because two association structures between
the same two classes would otherwise be impossible to understand. Howev-
er, in most cases, if we’re thinking about naming an association structure,
it is usually because we have missed a class that would represent the rela-
tion. Instead of naming the association, we can introduce that class. This is
the basic idea behind the relation pattern we describe below.

4.4 Find Candidates for Structure

We model structural relations in much the same way as we select classes
and events. We start by generating candidates for structural relations be-
tween the model’s classes. This is based on the following principles:
Principle: Study abstract, static relations between classes.
78 ________________________________________________________________ Structure

Principle: Study concrete, dynamic relations between objects.

We generate candidates based on the four types of structures we introduced

above.

Identify Generalizations
To generate candidates for generalization structures, we use approaches
similar to the ones we use for class selection.
In the first approach, we take every pair of selected classes and deter-
mine whether one of the two is a generalization of the other. If so, the gen-
eralization class events must be a subset of the specialization class events.
In the second approach, we determine if a relevant generalization class
exists for pairs of selected classes. For example, if our model contains cus-
tomers and suppliers, we might make a “business partner” generalization
class to contain common properties of the two original classes.
Our third approach is to take each of the selected classes and attempt
to define a relevant generalization or specialization. For example, if our
model contains employees, we can distinguish between different types of
employees according to the type of work they do. We express this by intro-
ducing several new classes that are specializations of the employee class.

Identify Aggregations
To find candidates for aggregation structures, we again systematically ex-
amine selected classes individually and in pairs.
In the first approach, we examine each pair of classes to see if the ob-
jects of one class might be a decomposition of the objects of the other class.
In the second approach, we determine if it is relevant to aggregate the
objects from each pair of classes into objects from a newly created whole-
class.
Our third approach is to determine if we can decompose each class into
a few relevant classes that do not yet exist in our model. Alternatively, we
consider aggregating the objects of a selected class into a new class.
You can use aggregation structures to describe a relatively broad spec-
trum of structural relations. For example, aggregation has a specific appli-
cation in block-structured programming languages, where a block aggre-
gates its constituent elements. In this case, the parts cannot exist without
the whole, since the block’s elements are typically created and destroyed at
the same time as the block itself. Such a “hard” definition of aggregation is
not particularly useful in object-oriented analysis. The parts in an aggrega-
tion structure will often live the first or last part of their lives independent
of the whole. Thus, we often have a defining relationship that conveys a
Find Candidates for Structure _____________________________________________ 79

softer definition of aggregation. There are three typical applications of ag-

gregation structures:
• Whole-Part, in which the whole is the sum of the parts; if we add or
remove any part, we change the whole fundamentally.
• Container-Content, in which the whole is a container for the parts; if
we add or remove any content, we do not change the fundamental
properties of the whole.
• Union-Member, in which the whole is an organized union of members.
We do not change the union fundamentally by adding or removing a
few members. However, there is a lower limit on the number of mem-
bers, as it is artificial to model a union without members.
In an aggregation structure, the whole is considered to be superior to its
parts. This is reflected in the class diagram through the vertical placement
of the classes.

Identify Associations
To generate candidates for association structures, we look at the remaining
class pairs to see if they can be meaningfully related. We should describe
associations whenever we must administrate, monitor, or control relations
between objects that are not otherwise related in the model.

Identify Clusters
To increase a class diagram’s clarity, we can explicitly group and name col-
lections of classes. This organizes conceptually related classes into clusters.
Figure 4.10 shows an example of a class diagram that gives a simple and
overall description of a problem domain.

«cluster»
Employees
«cluster» «cluster»
Customers Schedules
«cluster»
Appointment

Figure 4.10: Clusters in the Hair Salon System (Chapter 20)

80 ________________________________________________________________ Structure

Clusters are expressions of subdomains within the problem domain; we

can use them during analysis to enhance clarity. They also help us achieve
clarity in the resulting model when other structures have been defined. You
can use other structures as a starting point for generating cluster candi-
dates. Generalization and aggregation structures represent a close connec-
tion between the structure’s classes and the objects. On the other hand, as-
sociation structures typically represent a looser connection. It is therefore
natural to include classes that are connected with generalization and ag-
gregation structures in the same clusters.
Although you might be tempted to include a class in two different clus-
ters, it is not allowed. If you can’t determine membership, you should create
a new cluster for the class in question.

4.5 Explore Patterns

Object-oriented patterns provide a source of inspiration that complements
the systematic generation of candidates for structural relations. A pattern
is a generalized description of a problem and a related solution. Thus, you
can apply patterns to solve specific problems during problem-domain mod-
eling. A rich pattern collection is also useful as a catalog of ideas for model-
ing phenomena in a problem domain. Here, we present four patterns that
are particularly concerned with structure.

The Role Pattern

We use the role pattern to model a situation in which a single person can
have several different roles in the problem domain.
The diagram on the left of Figure 4.11 shows an example of a company
in which a person can be either an employee, a customer, or both. We model

Person Person
1 1
1..∗ 0..∗

Role Role

Employee Customer Role1 Role2 ••• Rolen

Figure 4.11: The role pattern

Explore Patterns _________________________________________________________ 81

this by generalizing employees and customers into persons. A person then

aggregates one or more roles, where each role is either employee or custom-
er.
This structure lets a person change roles dynamically over time. For ex-
ample, a person may start as a customer and later be hired as an employee.
In this case, we would first establish a person object and assign a customer
role, and later add an employee role.
The right side of Figure 4.11 shows the general role pattern. A person
object aggregates zero or more role objects, where each role object is from
one of the classes Role1, Role2,... Rolen. Properties and behavior common to
all the role classes are described in the abstract class “Role.”
If the different role classes have nothing in common, we use a simpli-
fied pattern variation without a separate role class, as Figure 4.12 shows.

Person

1 1
1..∗ 1..∗
Employee Customer
Role Role

Figure 4.12: A simple variant of the role pattern

Another simplification of the role pattern is shown in Figure 4.5. This vari-
ant describes customers and employees as two specializations of a general
class. This variant provides a simple definition of the concepts, but it is dif-
ficult to use if some objects can be both customers and employees or if they
can switch dynamically between the two categories.

The Relation Pattern

A typical modeling problem is the desire to relate two objects to each other
through a relation that carries its own properties. We can model this by as-
signing a name to the association, but the relation pattern is a better solu-
tion.
The top of Figure 4.13 shows an example, in which we modeled the
ownership relation between a car and its owner. The person aggregates a
number of ownership objects and each of them relates to exactly one car.
During its lifetime, a car might have several owners.
The general form of the relation pattern is shown at the bottom of Fig-
ure 4.13. The purpose of the pattern is to relate two parties to each other.
82 ________________________________________________________________ Structure

Person
1
0..∗

Ownership 1..∗ 1 Car

Party1
1
0..∗

Relation 0..∗ 1 Party2

Figure 4.13: The relation pattern

The relation is owned by a “Party1” object and associated to a “Party2” ob-

ject. Objects from both parties can have many relations, but each of them
must be represented by exactly one relation object.
There are two other variations on the relation pattern. In the first, both
of the related parties aggregate the relation object. This indicates that they
both own the relation. The second variant is to have both parties connected
to the relation object through an association. This would indicate a loose re-
lation.

The Hierarchy Pattern

Many problem domains include objects that are organized into a hierarchy
with two or more levels and relationships exist among objects on different
levels.
The left side of Figure 4.14 shows an example where all students are or-
ganized into classes, and all classes are organized into semesters. A student
belongs to exactly one class and the class has many students.
The right side of the figure shows the general version of the hierarchy
pattern. When we use this pattern, we must decide what the elements are
and how many levels of hierarchy to organize them in. In Chapter 19, we
show an advanced application of this pattern in the “Program” cluster of
the Conference Planning System.
A useful variation on the hierarchy pattern is one in which objects at
one level can belong to several objects on the level above. In this situation,
the elements of the hierarchy are not mutually exclusive.
Explore Patterns _________________________________________________________ 83

Semester Leveln
1 1
0..∗ 0..∗

Class Leveln-1
1 1
0..∗ 0..∗

•••
Student

Level1
1
0..∗

Element

Figure 4.14: The hierarchy pattern

The Item-Descriptor Pattern

The left side of Figure 4.15 illustrates a solution to a classical domain-mod-
eling problem: the distinction between items and their description. The ex-
ample is taken from a library. Books have descriptions and keywords to fa-
cilitate search, and numbers to determine where they are located in the
library. For each book, there is at least one copy. Each copy has its own
identity and is treated as a separate entity, but all copies share the proper-
ties described by the related book object.
The right side of Figure 4.15 shows the general version of the item-de-
scriptor pattern. An object from the overall class “Descriptor” defines spe-
cific properties shared by all the related objects from the “Item” class.

Book Descriptor
1 1
0..∗ 0..∗

Copy Item

Figure 4.15: The item-descriptor pattern

84 ________________________________________________________________ Structure

The item-descriptor pattern is particularly useful in systems that ad-

ministrate different kinds of descriptions, such as contracts, insurance poli-
cies, and product specifications.

4.6 Evaluate Systematically

It is easy to generate many candidates for structural relations between
classes. It is much more difficult to produce a simple and comprehensive
problem-domain model. You must be prepared to reformulate and refine
classes and structures several times before arriving at a satisfying solution.
This involves systematic evaluation based on the following principle:
Principle: Model only the necessary structural relations.

When we evaluate structural relations, we can benefit from the following

criteria.
• Structures must be used correctly.
• Structures must be conceptually true.
• Structures must be simple.
Below, we examine these criteria in detail. Individually, they are easy to
understand and handle. But together they can be difficult to compare, and
some criteria pull in different directions. Our analysis of the Hair Salon
System (Chapter 20) contains a comprehensive example that emphasizes
the choice between different constructs.

Structures Must Be Used Correctly

A fundamental and classical error when modeling object-oriented struc-
tures is to mix generalization and aggregation. Both are potentially rele-
vant abstractions, but it makes no sense to say that “an engine is a car,” or
that “a passenger car has taxis and private cars.” Experience with object-
oriented analysis helps you avoid this error. The best advice is to use the
linguistic expression to test whether a candidate is appropriate for general-
ization or aggregation.
It is more challenging to distinguish aggregation from association be-
cause they have many common traits. An aggregation structure is a special,
stronger form of association and can thus always be expressed as an associ-
ation structure. “Has-a” or “is-part-of” are good tests for aggregation candi-
dates.
To distinguish between aggregation and association, there are two po-
tential approaches. The first is to discard aggregation completely and use
association structures exclusively. This technique corresponds to relations
Evaluate Systematically __________________________________________________ 85

in data and information models, and is recommended by some object-orient-

ed methods. Another approach is to use aggregation structures to capture
fundamental, definitive relations, and use association structures for more
fluid relations, which typically extend across the diagram. The guidelines
we offer in this chapter are based on the latter approach.
When both aggregation and association are used, you must be able to
distinguish between them in concrete situations. Our principal advice here
is to focus on the conceptual differences between the two structure types. If
that fails, the following three questions can assist you in differentiating be-
tween aggregation and association structures.
• Can the objects exist independently of each other?
• Are the objects equally ranked?
• Can the connection from an object from the one class change to other
objects from the other class?
If you answer yes to at least two of the questions, consider an association
structure. Otherwise, consider an aggregation structure. For example, look-
ing at the structures in Figure 4.6, a car and its engine cannot exist inde-
pendently over a long period, the car is superior to the engine, and we typi-
cally wouldn’t move the engine to another car. We thus select an
aggregation structure. A car and its owner can, on the other hand, exist in-
dependently of each other, they are equally ranked, and both car and owner
can change their relation to other objects of the same class. Therefore, an
association structure is most appropriate.

Structures Must Be Conceptually True

A good description of the problem domain is conceptually true. This means
that the names, concepts, and structural relations reflect the users’ under-
standing. Therefore you must carefully test your structures to ensure that
they are consistent with the users’ view of the problem domain.
This criterion does not imply that your model of structure must be iden-
tical with the users’ understanding of important problem-domain relations.
The new system can lead to further formalizations that change the defini-
tions of names and relations. Generally, your model should reflect the prob-
lem domain’s structure as it will exist under the control or administration
supported by the new system. Ideally, the problem domain should express a
future user’s understanding of the problem domain.
86 ________________________________________________________________ Structure

Structures Must Be Simple

Simplicity is a virtue. It facilitates clarity and makes the target system eas-
ier to build and use. In most cases, your model should have a few classes
and a few important relations.
You should thus avoid unnecessary generalizations and aggregations. A
class can always be generalized if we throw out a few attributes and events,
and decomposed if we simply distribute the attributes over several classes
that aggregate into a common whole. The decisive question is whether such
a construction adds anything relevant to the description. If not, there is no
justification for including it in an analysis model.
A top-down structure is typically a splendid starting point when pre-
senting a model. It is therefore important that you keep the structure’s top
level simple. This is especially important for clusters, but also, to a certain
degree, for generalizations and aggregations. If the model is easy to under-
stand on an overall level, complicated details are less problematic.
When we deal with structure, we view reality as being frozen for a time.
We should thus be especially careful not to invent too many generaliza-
tions. Generalization structures must always correspond to the users’ un-
derstanding of the problem domain. A typical description of a problem do-
main will contain only a few generalization structures, typically at the bot-
tom of the class diagram.
In summary, the model should contain only those structural class and
object connections that are required to fulfill the system definition.

4.7 Principles
The structure activity can be summarized in three fundamental principles
for the description of structure in our problem-domain model:
Study abstract, static relations between classes. We use generalization
and cluster structures to describe static, conceptual relations be-
tween classes. Generalization structures express different levels of
abstraction in our model, while we use clusters to achieve clarity.
Study concrete, dynamic relations between objects. We use aggregation
and association structures to describe dynamic, concrete relations
between objects. Aggregation structures describe superior objects as
consisting of or containing subobjects, while association structures
describe other meaningful relations between objects.
Model only the necessary structural relations. The model should describe
only the structural relations that are necessary to satisfy the system
definition. In general, the model should focus on the important as-
pects and contain a minimal number of structural relations.
Exercises ________________________________________________________________ 87

4.8 Exercises

Review Questions
1. What are the two different types of class structures?
2. What are the two different types of object structures?
3. Why is multiplicity only specified on object structures?
4. Why are abstract classes sometimes included in the model?
5. What is the meaning of inheritance? How is it described?
6. What is the meaning of multiple inheritance? Why is it a problem?
7. Why are clusters useful?
8. How do you choose between aggregation and association structures?
9. What is the basic technique for describing structures between classes
and objects?
10. What is the result of the structure activity?

Problems
11. Consider a situation with five cars and eight owners. Two cars have
one owner, the rest have two owners. Draw the objects and the owner-
ship relations. Create the corresponding class diagram.
12. Provide examples of the types of aggregation structures in Section 4.4.
13. Consider the role, relation, hierarchy, and item-descriptor patterns.
Identify examples of their use in the class diagrams in Chapters 19-21.
14. Review the class diagram in Chapter 20 using the criteria for system-
atic structure evaluation from this chapter. Are the structural rela-
tions appropriately described? Suggest possible alternatives.
15. Video rental store. Continue your considerations of the system for
managing customers and their rentals in a video rental store (see Ex-
ercise 3.13). Describe structural relations between classes and objects
in a class diagram.
16. Mobile phone. Continue your considerations of the system for a simple
mobile phone (see Exercise 3.14). Describe structural relations be-
tween classes and objects in a class diagram.
17. Teaching administration. Continue your considerations of the system
for monitoring student activities in a university department (see Exer-
cise 3.15). Describe structural relations between classes and objects in
a class diagram.
18. Elevator control. Continue your considerations of the system to control
elevator movement in a building (see Exercise 3.16). Describe struc-
tural relations between classes and objects in a class diagram.
88 ________________________________________________________________ Structure

4.9 Literature
All new object-oriented methods for analysis and design emphasize the de-
scription of structure. This is due to the central role that structure plays in
our understanding of the problem domain that we wish to model. While au-
thors agree on the importance of structure, they differ from each other both
with respect to the types of structures they describe, and the notation they
use. The methods that arise from traditions in object-oriented program-
ming have a very rich understanding of structure. For example, Booch
(1994) examines a broad spectrum of structures both between classes and
between objects. The examination is, however, somewhat technically ori-
ented; it is strongly characterized by facilities found in different object-ori-
ented programming languages. Booch’s rich structural understanding is
also seen in his examples illustrating how a specific type of structure can be
expressed in different programming languages. As a basis for the analysis,
he chooses to use facilities that can be realized technically.
Coad & Yourdon (1991a) represent an entirely different approach. They
use a general description of human knowledge as a starting point, and from
this substantiate the relevance of their structure types. Analysis is about
understanding something and expressing this understanding in a specific
language. Looking at human knowledge and using it as a basis for choosing
structure types is therefore more sensible than the technical approach,
which uses programming language facilities as a starting point. For this
reason, we place ourselves closer to the structure types found in Coad &
Yourdon (1991a).
A third direction comes from data modeling. An example of this ap-
proach is Shlaer & Mellor (1988). In data modeling, relations are the basic
building blocks. Some authors have combined relations with inheritance,
such that they operate only with generalizations and associations. Every
aggregation can naturally be described as an association; in this sense, the
two structure types are adequate. However, in our view, some object rela-
tions are of a fundamental and defining character, while others are more
fluid. We therefore maintain the distinction between aggregating and asso-
ciating.
UML, as described by Rumbaugh et al. (1999), has a huge variety of no-
tations for describing structure. That is because UML is a compromise, that
must be backwards compatible with earlier notations. In this chapter we
have selected a small and powerful subset of UML’s structural mechanisms
which will enable developers to model most problems. In Chapter 18 you
will find more UML structural notations.
Patterns are described by Coad (1995), Gamma et al. (1995), and Lar-
man (1998).