22.

2 THE SYSTEM DESIGN PROCESS

System design develops the architectural detail
required to build a system or product.
The system design process encompasses the
following activities:
• Partition the analysis model into subsystems.
• Identify concurrency that is dictated by the
problem.
• Allocate subsystems to processors and tasks.
• Develop a design for the user interface.
• Choose a basic strategy for implementing data
management.
• Identify global resources and the control
mechanisms required to access them.
611
7 Recall that OOA is an iterative activity. It is entirely
possible that the analysis model will be
revised as a consequence of design work.
System
Design
Object
design
Human interface
design
Data management
design
Task management
design
Object-oriented
analysis
FIGURE 22.3
Process flow for
OOD
What are
the steps of
the system design
process?
?
612 PART FOUR OBJECT-ORIENTED SOFTWARE
ENGINEERING
• Design an appropriate control mechanism for the
system, including task
management.
• Consider how boundary conditions should be
handled.
• Review and consider trade-offs.
In the sections that follow, design activities related to
each of these steps are considered
in more detail.
22.2.1 Partitioning the Analysis Model
One of the fundamental analysis principles (Chapter
11) is partitioning. In OO system
design, we partition the analysis model to define
cohesive collections of classes, relationships,
and behavior. These design elements are packaged
as a subsystem.
In general, all of the elements of a subsystem share
some property in common.
They all may be involved in accomplishing the same
function; they may reside within
the same product hardware, or they may manage
the same class of resources. Subsystems
are characterized by their responsibilities; that is, a
subsystem can be identified
by the services that it provides [RUM91]. When used
in the OO system design
context, a service is a collection of operations that
perform a specific function (e.g.,
managing word-processor files, producing a three-
dimensional rendering, translating
an analog video signal into a compressed digital
image).
As subsystems are defined (and designed), they
should conform to the following
design criteria:
• The subsystem should have a well-defined
interface through which all communication
with the rest of the system occurs.
• With the exception of a small number of
“communication classes,” the
classes within a subsystem should collaborate only
with other classes within
the subsystem.
• The number of subsystems should be kept low.
• A subsystem can be partitioned internally to help
reduce complexity.
When two subsystems communicate with one
another, they can establish a
client/server link or a peer-to-peer link [RUM91]. In a
client/server link, each of the
subsystems takes on one of the roles implied by
client and server. Service flows from
server to client in only one direction. In a peer-to-
peer link, services may flow in either
direction.
When a system is partitioned into subsystems,
another design activity, called layering,
also occurs. Each layer [BUS96] of an OO system
contains one or more subsystems
and represents a different level of abstraction of the
functionality required
to accomplish system functions. In most cases, the
levels of abstraction are determined
by the degree to which the processing associated
with a subsystem is visible
to an end-user.
The concepts of
coupling and cohesion
(Chapter 13) can be
applied at the
subsystem level. Strive
to achieve good
functional
independence as you
design subsystems.
What
criteria
guide us in the
design of
subsystems?
?
CHAPTER 22 OBJECT-ORIENTED DESIGN
For example, a four-layer architecture might might
include (1) a presentation layer
(the subsystems associated with the user interface),
(2) an application layer (the subsystems
that perform the processing associated with the
application), (3) a data formatting
layer (the subsystems that prepare the data for
processing), and (4) a database
layer (the subsystems associated with data
management). Each layer moves deeper
into the system, representing increasingly more
environment-specific processing.
Buschmann and his colleagues [BUS96] suggest the
following design approach for
layering:
1. Establish layering criteria. That is, decide how
subsystems will be grouped in
a layered architecture.
2. Determine the number of layers. Too many
introduce unnecessary complexity;
too few may harm functional independence.
3. Name the layers and allocate subsystems (with
their encapsulated classes) to
a layer. Be certain that communication between
subsystems (classes) on one
layer and other subsystems (classes) at another
layer follow the design philosophy
for the architecture.8
4. Design interfaces for each layer.
5. Refine the subsystems to establish the class
structure for each layer.
6. Define the messaging model for communication
between layers.
7. Review the layer design to ensure that coupling
between layers is minimized
(a client/server protocol can help accomplish this).
8. Iterate to refine the layered design.