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.
 Each restructuring activity can be seen as a graph
transformation on subsets of a particular model.
 Some activities include: merging two similar classes from two
different subsystems into a single class, collapsing classes with
no significant behavior into attributes, splitting complex classes
into simpler ones, rearranging classes and operations to
increase the inheritance and packaging.

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,

adding redundant associations for efficiency,

rearranging execution orders,

and opening up the architecture, that is, adding access to lower
layers because of performance requirements.
 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.