Chapter Six

Object Oriented System Design

 Introduction
⚫ System design is the transformation of an analysis model into
a system design model.
⚫ During system design, developers define the design goals of
the project and decompose the system into smaller
subsystems that can be realized by individual teams.
⚫ Developers also select strategies for building the system, such
as:
⚫ the hardware/software strategy,
⚫ the persistent data management strategy,
⚫ the global control flow,
⚫ the access control policy, and
⚫ the handling of boundary conditions.
⚫ The result of system design is a model that includes
subsystem decomposition and a clear description of each of
these strategies.
⚫ System design is decomposed into several
activities, each addressing part of the overall
problem of decomposing the system:
− Identify design goals: Developers identify and
prioritize the qualities of the system that they
should optimize.
− Design the initial subsystem decomposition:
Developers decompose the system into smaller
parts based on the use case and analysis models.
− Refine the subsystem decomposition to
address the design goals: The initial
decomposition usually does not satisfy all design
goals. Developers refine it until all goals are
satisfied.
 System design concepts
⚫ Subsystems and Classes
⚫ In order to reduce the complexity of the application domain, we
identified smaller parts called “classes” and organized them
into packages.
⚫ Similarly, to reduce the complexity of the solution domain, we
decompose a system into simpler parts, called “subsystems,”
which are made of a number of solution domain classes.
⚫ A subsystem is a replaceable part of the system with well
defined interfaces that encapsulates the state and behavior of
its contained classes.
⚫ A subsystem typically corresponds to the amount of work that
a single developer or a single development team can tackle.
⚫ By decomposing the system into relatively independent
subsystems, concurrent teams can work on individual
subsystems with minimal communication overhead.
Services and Subsystem Interfaces
⚫ A subsystem is characterized by the services
it provides to other subsystems.
⚫ A service is a set of related operations that
share a common purpose.
⚫ A subsystem providing a notification service,
for example, defines
⚫ operations to send notices,

⚫ look up notification channels, and

subscribe and unsubscribe to a channel.

⚫ The set of operations of a subsystem that are
available to other subsystems form the
subsystem interface.
⚫ The subsystem interface includes
⚫ the name of the operations,

⚫ their parameters,

⚫ their types, and their return values.

⚫ System design focuses on defining the

services provided by each subsystem that is,
enumerating the operations, their parameters,
and their high-level behavior.
⚫ Object design will focus on the application
programmer interface (API), which refines and
extends the subsystem interfaces.
⚫ The API also includes the type of the
parameters and the return value of each
operation.
 Coupling and Cohesion
⚫ Coupling is the number of dependencies between two
subsystems.
− If two subsystems are loosely coupled, they are relatively
independent, so modifications to one of the subsystems will have
little impact on the other.
− If two subsystems are strongly coupled, a modification to one
subsystem is likely to have impact on the other.
− A desirable property of subsystem decomposition is that
subsystems are as loosely coupled as reasonable.
− This minimizes the impact that errors or future changes in one
subsystem have on other subsystems.
⚫ Cohesion is the number of dependencies within a subsystem.
If a subsystem contains many objects that are related to each
other and perform similar tasks, its cohesion is high.
− If a subsystem contains a number of unrelated objects, its
cohesion is low. A desirable property of subsystem decomposition
is that it leads to subsystems with high cohesion.
System design activities: From objects to
subsystems
⚫ System design consists of
transforming the analysis model into
the design model while taking in to
account the nonfunctional
requirements described in the
requirements analysis document.
⚫ Identifying Design Goals
⚫ The first step of system design.
⚫ Identifies the qualities that our system should
focus on.
⚫ Many design goals can be inferred from the
nonfunctional requirements or from the
application domain.
⚫ Others will have to be elicited from the client.
⚫ It is, however, necessary to state them
explicitly such that every important design
decision can be made consistently following
the same set of criteria.
⚫ Example Design goals for MyTrip
⚫ Reliability: MyTrip should be reliable [generalization
of nonfunctional requirement 2].
⚫ Fault Tolerance: MyTrip should be fault tolerant to
loss of connectivity with the routing service
[rephrased nonfunctional requirement 2].
⚫ Security: MyTrip should be secure, i.e., not allow
other drivers or non authorized users to access a
driver’s trips [deduced from application domain].
⚫ Modifiability: MyTrip should be modifiable to use
different routing service [anticipation of change by
developers].
⚫ Identifying Subsystems
⚫ The initial subsystem decomposition should be derived
from the functional requirements.
⚫ For example, in the MyTrip system, we identify two
major groups of objects:
⚫ those that are involved during the PlanTrip use
case and
⚫ those that are involved during the ExecuteTrip
use case.
⚫ The Trip, Direction, Crossing, Segment, and
Destination classes are shared between both use
cases.
⚫ This set of classes is tightly coupled as it is used as a
whole to represent a Trip.
⚫ Another heuristic for subsystem identification is to keep
functionally related objects together.
⚫ Heuristics for grouping objects into
subsystems:
⚫ Assign objects identified in one use case
into the same subsystem.
⚫ Create a dedicated subsystem for objects
used for moving data among subsystems.
⚫ Minimize the number of associations
crossing subsystem boundaries.
⚫ All objects in the same subsystem should
be functionally related.
 Documenting system design
⚫ System design is documented in the System Design
Document (SDD).
⚫ It describes design goals set by the project, subsystem
decomposition (with UML class diagrams),
hardware/software mapping (with UML deployment
diagrams), data management, access control, control
flow mechanisms, and boundary conditions.
⚫ The SDD is used to define interfaces between teams of
developers and serve as a reference when
architecture-level decisions need to be revisited.
⚫ The audience for the SDD includes the project
management, the system architects (i.e., the
developers who participate in the system design), and
the developers who design and implement each
subsystem.
➢ The first section of the SDD is an
Introduction.
⚫ Its purpose is to provide a brief overview
of the software architecture and the
design goals.
⚫ It also provides references to other
documents and traceability information
(e.g. related requirements analysis
document, references to existing systems,
constraints impacting the software
architecture).
➢ The second section, Current software
architecture, describes the architecture of
the system being replaced.
− If there is no previous system, this section
can be replaced by a survey of current
architectures for similar systems.
− The purpose of this section is to make
explicit the background information that
system architects used, their assumptions,
and common issues the new system will
address.
➢ The third section, Proposed system
architecture, documents the system
design model of the new system. It is
divided into seven subsections:
✓ Overview presents a bird’s-eye view of the
software architecture and briefly describes the
assignment of functionality to each subsystem.
✓ Subsystem decomposition describes the decomposition
into subsystems and the responsibilities of each. This is
the main product of system design.
✓ Hardware/software mapping describes how subsystems
are assigned to hardware and off-the-shelf components. It
also lists the issues introduced by multiple nodes and
software reuse.
✓ Persistent data management describes the persistent
data stored by the system and the data management
infrastructure required for it.
⚫ This section includes the description of data
schemes, the selection of a database, and the
description of the encapsulation of the database.
✓ Access control and security describes the
user model of the system in terms of an
access matrix. This section also describes
security issues, such as the selection of an
authentication mechanism, the use of
encryption, and the management of keys.
✓ Global software control describes how the
global software control is implemented. It
describes how requests are initiated and how
subsystems synchronize. This section should
list and address synchronization and
concurrency issues.
✓ Boundary condition describes the start-up,
shutdown, and error behavior of the system.
⚫ The fourth section, Subsystem services,
describes the services provided by
each subsystem.
− The interface of each subsystem is derived
from this section and detailed in the Object
Design Document
 An overview of object design
⚫ Object design includes four groups of
activities:
− Reuse: components identified during system
design are used to help in the realization of
each subsystem.
⚫ Class libraries and additional components are
selected for basic data structures and services.
⚫ Design patterns are selected for solving common
problems and for protecting specific classes from
future change.
⚫ components and design patterns need to be
adapted before they can be used.
⚫ Interface specification: the subsystem
services identified during system design
are specified in terms of class interfaces,
including operations, arguments, type
signatures, and exceptions.
− Additional operations and objects needed to
transfer data among subsystems are also
identified.
− The result of service specification is a
complete interface specification for each
subsystem.
− The subsystem service specification is often
called subsystem API (Application
Programmer Interface)
⚫ Restructuring: Restructuring activities
manipulate the system model to increase
code reuse or meet other design goals.
✓ During restructuring, we address design
goals such as maintainability,
readability, and understandability of the
system model.
⚫ Optimization: Optimization activities address
performance requirements of the system
model.
✓ This includes changing algorithms to
respond to speed or memory
requirements,
✓ reducing multiplicities in associations to
speed up queries,
 Object design concepts
⚫ Reuse Concepts: Solution Objects, Inheritance,
and Design Patterns
⚫ Application objects, also called “domain objects,”
represent concepts of the domain that are relevant
to the system.
⚫ Solution objects represent components that do
not have a counterpart in the application domain,
such as persistent data stores, user interface
objects, or middleware.
⚫ During analysis, we identify entity objects and their
relationships, attributes, and operations.
⚫ Most entity objects are application objects that

are independent of any specific system.

 Managing object design
⚫ There are two primary management challenges during
object design:
⚫ Increased communication complexity:
− The number of participants involved during this phase of
development increases dramatically.
− The object design models and code are the result of the
collaboration of many people.
− Management needs to ensure that decisions among these
developers are made consistently with project goals.
⚫ Consistency with prior decisions and documents:
− Developers often do not appreciate completely the
consequences of analysis and system design decisions
before object design.
− Since developers question to reevaluate some of the
decisions in the design model, management challenge is to
maintain a record of these revised decisions and to make
sure all documents reflect the current state of development.
 Documenting object design
⚫ Object design is documented in the Object
Design Document (ODD).
⚫ It describes object design trade-offs made by
developers, guidelines they followed for
subsystem interfaces, the decomposition of
subsystems into packages and classes, and
the class interfaces.
⚫ The ODD can also be used as a reference
during testing.
⚫ The audience for the ODD includes system
architects (i.e., the developers who participate
in the system design), developers who
implement each subsystem, and testers.
⚫ There are three main approaches to documenting
object design:
⚫ Self-contained ODD generated from model: write and
maintain a UML model and generate the document
automatically.
− This document would duplicate any application objects
identified during analysis. And this will create redundancy
with RAD.
− Moreover, the ODD duplicates information in the source
code and requires a high level of effort whenever the code
changes.
⚫ ODD as extension of the RAD: maintains consistency
between the RAD and the ODD becomes much easier
as a result of the reduction in redundancy.
− This document might add information that is irrelevant to
the client and user.
⚫ ODD embedded into source code: embed the ODD into
the source code.