Page 202 -
P. 202
7.1 Object-oriented design using the UML 185
7.1.4 Design models
Design or system models, as I discussed in Chapter 5, show the objects or object classes
in a system. They also show the associations and relationships between these entities.
These models are the bridge between the system requirements and the implementation
of a system. They have to be abstract so that unnecessary detail doesn’t hide the rela-
tionships between them and the system requirements. However, they also have to
include enough detail for programmers to make implementation decisions.
Generally, you get around this type of conflict by developing models at different
levels of detail. Where there are close links between requirements engineers, design-
ers, and programmers, then abstract models may be all that are required. Specific
design decisions may be made as the system is implemented, with problems resolved
through informal discussions. When the links between system specifiers, designers,
and programmers are indirect (e.g., where a system is being designed in one part of
an organization but implemented elsewhere), then more detailed models are likely to
be needed.
An important step in the design process, therefore, is to decide on the design
models that you need and the level of detail required in these models. This depends
on the type of system that is being developed. You design a sequential data-process-
ing system in a different way from an embedded real-time system, so you will need
different design models. The UML supports 13 different types of models but, as I
discussed in Chapter 5, you rarely use all of these. Minimizing the number of mod-
els that are produced reduces the costs of the design and the time required to com-
plete the design process.
When you use the UML to develop a design, you will normally develop two kinds
of design model:
1. Structural models, which describe the static structure of the system using object
classes and their relationships. Important relationships that may be documented
at this stage are generalization (inheritance) relationships, uses/used-by rela-
tionships, and composition relationships.
2. Dynamic models, which describe the dynamic structure of the system and show
the interactions between the system objects. Interactions that may be docu-
mented include the sequence of service requests made by objects and the state
changes that are triggered by these object interactions.
In the early stages of the design process, I think there are three models that are
particularly useful for adding detail to use case and architectural models:
1. Subsystem models, which that show logical groupings of objects into coherent
subsystems. These are represented using a form of class diagram with each sub-
system shown as a package with enclosed objects. Subsystem models are static
(structural) models.