Object-Oriented Software Engineering

Using UML, Patterns, and Java

Chapter 5
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 :-
 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 a subsystem decomposition
and a clear description of each of these strategies.

04/17/2021 PBY Aschalew T

 Cont’
 System design results in the following products:
 Design goals-describing the qualities of the system that developers should
optimize
 Software architecture-
-describing the subsystem decomposition in terms of subsystem responsibilities,
-dependencies among subsystems,
-subsystem mapping to hardware,&
-major policy decisions such as control flow, access control, and data storage.
 Boundary use cases-describing the system configuration, startup, shutdown, and
exception handling issues.

04/17/2021 PBY Aschalew T

 Cont’
 The design goals are derived from the nonfunctional requirements.
 Design goals guide the decisions to be made by the developers when trade-offs are
needed.
 The subsystem decomposition constitutes the bulk of system design.
 Developers divide the system into manageable pieces to deal with complexity
 System Design Concepts
Topics
I. Subsystems and Classes
II. Services and Subsystem Interfaces
III. Coupling and Cohesion
IV. Layers and Partitions
V. Architectural Styles

04/17/2021 PBY Aschalew T

 Subsystems and Classes
 The distinction between application domain and solution domain.
 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.

04/17/2021 PBY Aschalew T

 Cont’
 A subsystem typically corresponds to the amount of work that a single developer or
a single dev’t team can tackle.
 By decomposing the system into relatively independent subsystems, concurrent
teams can work on individual subsystems with minimal communication overhead.
 In the case of complex subsystems, we recursively apply this principle and
decompose a subsystem into simpler subsystems.

04/17/2021 PBY Aschalew T

 Cont’
 For example, In Accident management system
 It can be decomposed into a DispatcherInterface subsystem, realizing the user
interface for the Dispatcher;
 A FieldOfficerInterface subsystem, realizing the user interface for the FieldOfficer;
 An IncidentManagement subsystem, responsible for the creation, modification, and
storage of Incidents;
 ResourceManagement subsystem, responsible for tracking available Resources (e.g.,
FireTrucks and Ambulances);
 A MapManagement for depicting Maps and Locations;
 A Notification subsystem, implementing the communication between FieldOfficer
terminals and Dispatcher stations.

04/17/2021 PBY Aschalew T

 Cont’

04/17/2021 PBY Aschalew T

 Cont’
 Subsystem decomposition depicted with UML component.
 In the above component diagram components are depicted as rectangles with the
component icon in the upper right corner.
 Dependencies among components can be depicted with dashed stick arrows.
 In UML, components can represent both logical and physical components.
 A logical component -corresponds to a subsystem that has no explicit run-time
equivalent, for example, individual business components that are composed
together into a single run-time application logic layer.

04/17/2021 PBY Aschalew T

 Cont’
 A physical component corresponds to a subsystem that as an explicit run-time
equivalent, for example, a database server.
 Several programming languages (e.g., Java and Modula-2) provide constructs for
modeling subsystems (packages in Java, modules in Modula-2).
 In other languages, such as C or C++, subsystems are not explicitly modeled, so
developers use conventions for grouping classes (e.g., a subsystem can be
represented as a directory containing all the files that implement the subsystem).
 Whether or not subsystems are explicitly represented in the programming language,
developers need to document carefully the subsystem decomposition as subsystems
are usually realized by different teams.

04/17/2021 PBY Aschalew T

 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.

04/17/2021 PBY Aschalew T

 Cont’
 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.
 Provided and required interfaces can be depicted in UML with assembly
connectors, also called ball-and-socket connectors.
 The provided interface is shown as a ball icon (also called
lollipop) with its name next to it.
 A required interface is shown as a socket icon.

04/17/2021 PBY Aschalew T

 Cont’

 The dependency between two subsystems is shown by connecting the

corresponding ball and socket in the component diagram.
 The following diagram depicts the dependencies among the FieldOfficerInterface,
DispatchterInterface and Resource Management subsystems.
 The FieldOfficerInterface requires the Resource Update Service to update the
status and location of the FieldOfficer.
 The DispatcherInterface requires the Resource Allocation Service to identify
available resources and allocating them to new Incidents.

 The ResourceManagement subsystem provides both services.

04/17/2021 PBY Aschalew T

 Cont’

 Note that we use the ball-and-socket notation when the subsystem decomposition
is already fairly stable and that our focus has shifted from the identification of
subsystems to the definition of services.

04/17/2021 PBY Aschalew T

 Cont’
 The definition of a subsystem in terms of the services it provides helps us focus on
its interface as opposed to its implementation.
 When writing a subsystem interface, one should strive to minimize the amount of
information provided about the implementation.

04/17/2021 PBY Aschalew T

 Coupling & 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, modifications to one subsystem is likely to
have impact on the other.
 A desirable property of a 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.
 Note that reducing coupling is not an end in itself.
 High coupling is an issue only if it is likely that any subsystem changes.

04/17/2021 PBY Aschalew T

 Cont’

04/17/2021 PBY Aschalew T

 Cont’
 Example of reducing the coupling of subsystems (UML component diagram,
subsystems FieldOfficerInterface, DispatcherInterface, and Notification omitted
for clarity).
 Alternative 1 depicts a situation where all subsystems access the database directly,
making them vulnerable to changes in the interface of the Database subsystem.
 Alternative 2 shields the database with an additional subsystem (Storage).
 In this situation, only one subsystem will need to change if there are changes in
the interface of the Database subsystem.
 The assumption behind this design change is that the Storage subsystem has a
more stable interface than the Database subsystem.

04/17/2021 PBY Aschalew T

 Cont’

 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 a subsystem decomposition is that it leads to subsystems with
high cohesion.

04/17/2021 PBY Aschalew T

 System Design Activities: From Objects to Subsystems

 System design consists of transforming the analysis model into the design model that
takes into account the nonfunctional requirements described in the requirements
analysis document.
 Identifying Design Goals
 The definition of design goals is the first step of system design.
 It 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.
 important design decision can be made consistently following the same set of
criteria.

04/17/2021 PBY Aschalew T

 Cont’
 For example, in the light of the nonfunctional requirements for MyTrip, a route
planning system for car drivers.
 We identify reliability and fault tolerance to connectivity loss as design goals.
 We then identify security as a design goal, as numerous drivers will have access to
the same trip planning server.
 We add modifiability as a design goal, as we want to provide the ability for drivers to
select a trip planning service of their choice.

04/17/2021 PBY Aschalew T

 Cont’

 In general, we can select design goals from a long list of highly desirable qualities.
 Criteria to identify design goal organized into five groups:-
 performance, dependability, cost, maintenance, and end user criteria.
 Performance, dependability, and end user criteria are usually specified in the
requirements or inferred from the application domain.
 Cost and maintenance criteria are dictated by the customer and the supplier.

04/17/2021 PBY Aschalew T

 Cont’

 Performance criteria include the speed and space requirements imposed on the
system.
 Should the system be responsive, or should it accomplish a maximum number of
tasks?
 Is memory space available for speed optimizations, or should memory be used
sparingly?

04/17/2021 PBY Aschalew T

 Cont’

 Dependability criteria determine how much effort should be expended in

minimizing system crashes and their consequences.
 How often can the system crash?
 How available to the user should the system be?
 Should the system tolerate errors and failures?
 Are security risks associated with the system environment?
 Are safety issues associated with system crashes?

04/17/2021 PBY Aschalew T

 Cont’

 Cost criteria include the cost to develop the system, to deploy it, and to administer it.
 Note that cost criteria not only include design considerations but managerial ones, as
well.
 When the system is replacing an older one, the cost of ensuring backward
compatibility or transitioning to the new system has to be taken into account.
 Maintaining backward compatibility with a previous system can add to the
development cost while reducing the transition cost.

04/17/2021 PBY Aschalew T

 Cont ’

 Maintenance criteria determine how difficult it is to change the system after

deployment.
 How easily can new functionality be added?
 How easily can existing functions be revised?
 Can the system be adapted to a different application domain?
 How much effort will be required to port the system to a different platform?
 These criteria are harder to optimize and plan for, as it is seldom clear how successful
the project will be and how long the system will be operational.

04/17/2021 PBY Aschalew T

 Cont’

 End user criteria include qualities that are desirable from a users’ point of view,
but have not yet been covered under the performance and dependability criteria.
 Is the software difficult to use and to learn?
 Can the users accomplish needed tasks on the system?

04/17/2021 PBY Aschalew T

 Finding subsystems during system design is similar to finding objects during
Identifying Subsystems

analysis.
 Abbotts’s heuristics, are applicable to subsystem identification.
 The initial subsystem decomposition should be derived from the functional
requirements.
 Another heuristic for subsystem identification is to keep functionally related
objects together.

04/17/2021 PBY Aschalew T

 An Overview of System Design Activities

04/17/2021 PBY Aschalew T

 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 & 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.

04/17/2021 PBY Aschalew T

 Cont’

 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.
 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.
 Divided into seven parts:

04/17/2021 PBY Aschalew T

 Cont’

I. Overview presents a bird’s-eye view of the software architecture and briefly

describes the assignment of functionality to each subsystem.
II. Subsystem decomposition -describes the decomposition into subsystems and the
responsibilities of each. This is the main product of system design.
III. 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.
IV. Persistent data management describes the persistent data stored by the system
and the data management infrastructure required for it.
V. Access control and security describes the user model of the system in terms of an
access matrix.
-Describes security issues, such as the selection of an authentication mechanism,
the use of encryption, and the management of keys.

04/17/2021 PBY Aschalew T

 Cont’

VI. Global software control describes how the global software control is implemented.
-Describe how requests are initiated and how subsystems synchronize
-should list and address synchronization and concurrency issues.
VII. Boundary conditions describes the start-up, shutdown, and error behavior of the
system.
• (If new use cases are discovered for system administration, these should be included
in the requirements analysis document, not in this section.)
 The fourth section, Subsystem services, describes the services provided by each
subsystem.
 The SDD is written after the initial system decomposition is done;

04/17/2021 PBY Aschalew T

 Cont’

04/17/2021 PBY Aschalew T

 After several iterations of analysis and system design, the developers are usually left
An Overview of Object Design

with a puzzle that has a few pieces missing.

 These pieces are found during object design.
 The object design model can then be partitioned into sets of classes that can be
implemented by individual developers.

04/17/2021 PBY Aschalew T

 Cont’

 Object design includes four groups of activities :-

 Reuse. Off-the-shelf components identified during system design are used to help in
the realization of each subsystem.
 Interface specification. During this activity, the subsystem services identified during
system design are specified in terms of class interfaces, including operations,
arguments, type signatures, and exceptions.
 Restructuring. Restructuring activities manipulate the system model to increase code
reuse or meet other design goals.
 Optimization. Optimization activities address performance requirements of the
system model.

04/17/2021 PBY Aschalew T

04/17/2021 PBY Aschalew T
 Reading assignment

Object design concepts

Object design activities
Managing object design
Documenting object design.

04/17/2021 PBY Aschalew T