SAMARA UNIVERSITY

College of Engineering &Technology

Department of Computer Science
Regular Program
Object Oriented Software Engineering
Chapter Five
Object Oriented System Design
 Outline
5.1. An overview of system design
5.2. System design concepts
5.3. System design activities: From objects to subsystems
5.4. Documenting system design
5.5. An overview of object design
5.6. Object design activities
5.7. Documenting object design

02/09/2021 O-O Software Engineering 2

 5.1. An overview of system design (1)

• System design is the transformation of the analysis model into

a system design model.
• Requirements = What the system is supposed to do.
• Design = How the system is built.
• Goal: Design the classes that we need to implement the system
• Design is a creative process
• Good design usually simplifies the implementation and
maintenance of a project

02/09/2021 O-O Software Engineering 3

 An overview of system design (2)

Figure 5-1 The activities of system design (UML activity diagram).

02/09/2021 O-O Software Engineering 4
 5.2. System design concepts (1)

• During system design, we define the subsystems in terms of the

services they provide.
 Subsystems and classes
 Services and subsystem interfaces
 Coupling and coherence
 Layers and partitions
 Software architecture

02/09/2021 O-O Software Engineering 5

 5.2.1. Subsystems and classes
• 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
• Several programming languages
(e.g., Java and Modula-2) provide
constructs for modeling subsystems
(packages in Java,
modules in Modula-2).

Figure 5-2 Subsystem decomposition for an accident management system

02/09/2021 O-O Software Engineering 6
 5.2.2. 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
02/09/2021 O-O Software Engineering 7
 5.2.3. Coupling and coherence (1)
• Coupling is the strength of dependencies between two subsystems.
• If two subsystems are loosely coupled, they are relatively
independent, and thus, 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 possible. This minimizes the
impact that errors or future changes have on the correct operation
of the system.

02/09/2021 O-O Software Engineering 8

 5.2.3. Coupling and coherence (2)
• Coherence is the strength of dependencies within a subsystem. If a
subsystem contains many objects that are related to each other and
perform similar tasks, its coherence is high.
• If a subsystem contains a number of unrelated objects, its coherence is low.
• A desirable property of a subsystem decomposition is that it leads to
subsystems with high coherence.
• In general, there is a trade-off between coherence and coupling. We can
always increase coherence by decomposing the system into smaller
subsystems. However, this also increases coupling as the number of
interfaces increases

02/09/2021 O-O Software Engineering 9

 5.2.4. Layers and partitions (1)
• This can be done by a “divide-and-conquer” approach, where we
recursively divide parts until they are simple enough to be
handled by one person or one team.
• layering and partitioning, two techniques for relating
subsystems to each other.
• Layering allows a system to be organized as a hierarchy of
subsystems, each providing higher level services to the
subsystem above it by using lower level services from the
subsystems below it.
• Example: the OSI reference model
02/09/2021 O-O Software Engineering 10
 5.2.4. Layers and partitions (2)

• Partitioning organizes subsystems as peers that mutually

provide different services to each other
• For example, an onboard system for a car could be
decomposed into a travel service, giving real-time directions to
the driver, an individual preferences service, remembering a
driver’s seat position and favorite radio station, and vehicle
service, keeping track of the car’s gas consumption, repairs,
and scheduled maintenance.
• Each subsystem depends loosely on each other but could
often operate in isolation.
02/09/2021 O-O Software Engineering 11
 5.2.5 Software architecture
• Overall structure of the software, how software is decomposed
and organized into components—and the interfaces between
those components
• The first artifact that can be analyzed to determine how well its
quality attributes are being achieved,
• serves as the project blueprint.
• serves as the vehicle for communication
• A software architecture includes the system decomposition,
the global control flow, error-handling policies and inter-
subsystem communication protocols
02/09/2021 O-O Software Engineering 12
 Architecture View Model
• A model is a complete, basic, and simplified description of software
architecture which is composed of multiple views from a particular
perspective or viewpoint.
• A view is a representation of an entire system from the perspective of a
related set of concerns. It is used to describe the system from the
viewpoint of different stakeholders such as end-users, developers,
project managers, and testers
• 4+1 view model It is a multiple view model that addresses different
features and concerns of the system. It standardizes the software
design documents and makes the design easy to understand by all
stakeholders.
02/09/2021 O-O Software Engineering 13
 4 + 1 view model of software architecture
• A logical view, which shows the key abstractions in the system as
objects or object classes.
• A process view, which shows how, at run-time, the system is
composed of interacting processes.
• A development view, which shows how the software is decomposed
for development.
• A physical view, which shows the system hardware and how software
components are distributed across the processors in the system.
• Related using use cases or scenarios (+1)

02/09/2021 O-O Software Engineering 14

 Architectural patterns
• Each pattern describes a problem which occurs over and over again in our
environment and then describes the core of the solution to that problem, in such a
way that you can use this solution a million times over, without ever doing it in the
same way twice”. These are:
 Pipe and Filter Architectures
 Model-View-Controller (MVC)
 Layered architecture
 Repository architecture
 Client-server architecture (fat-client, thin-client)
 Peer-to-peer architecture
 Master-Slave Architecture
 Distributed component architectures
02/09/2021 O-O Software Engineering 15
 Pipe and Filter Architectures
• Subsystems process data received from a set of inputs and send results to
other subsystems via a set of outputs.
• The subsystems are called filters, and the associations between the
subsystems are called pipes.
• Each filter only knows the content and the format of the data received on the
input pipes, not the filters that produced them.

Figure 5-3 Traditional compiler model

02/09/2021 O-O Software Engineering 16

 Model-View-Controller (MVC) (1)
• Separates presentation and interaction from the system data.
• The system is structured into three logical components that interact with
each other.
• The Model subsystem manages the system data and associated operations on
that data.
• The View subsystem defines and manages how the data is presented to the
user.
• The Controller subsystem manages user interaction (e.g. keypresses,
mouseclicks, etc.) and passes these interactions to the View and the Model.
• The model subsystems are developed such that they do not depend on any
view or controller subsystem.
02/09/2021 O-O Software Engineering 17
 Model-View-Controller (MVC) (2)

Figure 5-4 MVC Architecture

02/09/2021 O-O Software Engineering 18
 Layered architecture (1)
• Organizes the system in to layers with related functionality
associated with each layer.
• A layer provides services to the layer above it so the lowest-
level layers represent core services that are likely to be used
through out the system.
• Used when building new facilities on top of existing systems;
when the development is spread across several teams with
each team responsibility for a layer of functionality; when
there is a requirement for multi-level security.
02/09/2021 O-O Software Engineering 19
 Layered architecture (2)

Figure 5-4 Layered Architecture

02/09/2021 O-O Software Engineering 20

 Repository architecture (1)
• All data in a system is managed in a central repository that is accessible to
all system components. Components do not interact directly, only through
the repository.
• Use when you have a system in which large volumes of information are
generated that has to be stored for along time. You may also use it in
data-driven systems where the inclusion of data in the repository triggers
an action or tool.
• Repository architecture is typical for database management systems,
such as a payroll system or a bank system
• Modern compilers and software development environments also follow a
repository architecture
02/09/2021 O-O Software Engineering 21
 Repository architecture (2)

• Figure 5-5 Repository Architecture fore IDE

02/09/2021 O-O Software Engineering 22
 Client-server architecture (1)
• Subsystem, the server, provides services to instances of other
subsystems called the clients, which are responsible for interacting
with the user.
• Used when data in a shared database has to be accessed from a
range of locations Because servers can be replicated, may also be
used when the load on a system is variable.
• Set of stand-alone servers which provide specific services such as
printing, data management, etc.
• Set of clients which call on these services.
• Network which allows clients to access servers.
02/09/2021 O-O Software Engineering 23
 Client-server architecture (2)

• Figure 5-6 Client-Server Architecture

02/09/2021 O-O Software Engineering 24
 Reading Assignment
 Peer-to-peer architecture
 Master-Slave Architecture
 Distributed component architectures

02/09/2021 O-O Software Engineering 25

 5.3. System design activities: From objects to subsystems

• Identify design goals from the nonfunctional requirements

• design an initial subsystem decomposition
• Map subsystems to processors and components
• Decide storage
• Define access control policies
• Select a control flow mechanism
• Identify boundary conditions

02/09/2021 O-O Software Engineering 26

 Identify design goals
• List of design goals, describing the qualities of the
system that developers should optimize.
– 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.
– Design goals guide the decisions to be made by the developers
especially when trade-offs are needed.

02/09/2021 Fundamentals of software engineering 27

 The subsystem decomposition requires
• Hardware/software mapping: What is the hardware configuration of the
system? Which node is responsible for which functionality? How is
communication between nodes realized? Which services are realized using
existing software components? How are these components encapsulated?
• Data management: Which data need to be persistent? Where should
persistent data be stored? How are they accessed?
• Access control: Who can access which data? Can access control change
dynamically? How is access control specified and realized? Access control
and security are system-wide issues.
• Control flow: How does the system sequence operations? Is the system event
driven? Can it handle more than one user interaction at a time?
• Boundary conditions: How is the system initialized? How is it shut down?
How are exceptional cases detected and handled?

02/09/2021 Fundamentals of software engineering 28

 5.4. Documenting system design
1. Introduction
1.1 Purpose of the system
1.2 Design goals
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Current software architecture
3. Proposed software architecture
3.1 Overview
3.2 Subsystem decomposition
3.3 Hardware/software mapping
3.4 Persistent data management
3.5 Access control and security
3.6 Global software control
3.7 Boundary conditions
4. Subsystem services
Glossary
02/09/2021 O-O Software Engineering 29
 5.5. An overview of object design

• The activities of system development incrementally fill a gap between

the problem and the machine by identifying and defining objects that
realize part of the system
• Analysis reduces the gap between the problem and the machine by
identifying objects representing user-visible concepts
• System design reduces the gap between the problem and the machine
by defining a hardware/software platform that provides a higher level of
abstraction than the computer hardware.
• During object design, we refine the analysis and system design models,
identify new objects, and close the gap between the application objects
and off-the-shelf components
02/09/2021 O-O Software Engineering 30
 5.6. Object design activities

object design includes four groups of activities:

 Service specification ; specify the subsystem services (identified during system
design) in terms of class interfaces, including operations, arguments, type
signatures, exceptions and add missing attributes
 Component Selection; need to adjust the components we selected during system
design and we can use them, by wrapping custom objects around them or by
refining them using inheritance. Identifying application framework and class
libraries
 Restructuring; manipulate the system model to increase code reuse or meet
other design goals. collapsing classes with no significant behavior into attributes
 Optimization; address performance requirements of the system model. Delaying
expensive computations
02/09/2021 O-O Software Engineering 31
.

Figure 5-6 Activities of object design

02/09/2021 O-O Software Engineering 32
 5.7. Documenting object design

• The ODD enables developers to understand the subsystem sufficiently well that
they can use it.
• Moreover, a good interface specification enables other developers to implement
classes concurrently.
1. Introduction
1.1 Object design trade-offs
1.2 Interface documentation guidelines
1.3 Definitions, acronyms, and abbreviations
1.4 References
2. Packages
3. Class interfaces
Glossary
02/09/2021 O-O Software Engineering 33