Software Engineering

Chapter 6-
Object Oriented System
Design
Prepared by:
Misganaw Abeje
University of Gondar
College Of Informatics
Department of computer science
Misganaw.Abeje13@[Link]
 Outline
1. An overview of system design.
2. System design concepts.
– Subsystems
– Service and Subsystem Interface
– Properties of subsystem: cohesion and coupling
– Techniques of Subsystem: Layering and partitioning
– Architectural style
3. System design activities: From objects to subsystems
– Identifying Design Goal
– Identifying Subsystem
– Mapping of subsystem to hardware
– Identifying and Storing Persistent Data
BY: MA – Providing Access Control
BY: MA
 6. Overview of System Design
 System design is the transformation of an analysis model into a system
design model.
 Analysis: Focuses on the application domain (user point of view),
 Design focuses on the solution domain (developer point of view).
 During system design, developers define:
– Design goals of the project
– Decompose the system into smaller subsystems that can be realized by
each teams.
– Developers also select strategies for building the system, such as the
hardware/software strategy, the persistent data management strategy,
access control policy , and the global control flow
 The result of system design is a model that includes a subsystem
decomposition, design goals and a clear description of each of
these strategies.
BY: MA
 6.1 How the Analysis Models influence System Design

 Nonfunctional Requirements
=> Definition of Design Goals
 Functional model
=> Subsystem Decomposition
 Object model
=> Hardware/Software Mapping, Persistent Data Management
 Dynamic model
=> Identification of Concurrency, Global Resource Handling,
Software Control

BY: MA
 The following figure Depicts the relationship of system
design with other software engineering activities.

BY: MA
 6.2. System Design Concepts

 In this section we describe System Design Concepts:

– Subsystems in terms of the services they provide.
– Subsystem interface: in terms of the operations it
provides.
– Properties of subsystems: coupling and cohesion.
– Techniques of decomposition of the system into
subsystems, which is layering and partitioning.
– Architectural Style.

BY: MA
 6.2 Subsystems

 In order to reduce the complexity of the application domain,

we identified smaller parts called “classes” and organized
them into packages.
 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.

BY: MA
  Subsystem
– Collection of classes, associations, operations, events and
constraints that are closely interrelated with each other
– The objects and classes from the object model are the
“seeds” for the subsystems
– In UML subsystems are modeled as component
diagram.
 A subsystem typically corresponds to the amount of work
that a single developer or a single development team can
tackle.

BY: MA
  For example, the accident management system we previously
described can be decomposed into a :
– DispatcherInterface subsystem, realizing the user interface for the
Dispatcher;
– FieldOfficerInterface subsystem, realizing the user interface for
the FieldOfficer;
– IncidentManagement subsystem, responsible for the creation,
modification, and storage of Incidents;
– ResourceManagement subsystem, responsible for tracking
available Resources (e.g., FireTrucks and Ambulances);
– MapManagement subsystem for depicting Maps and Locations;
– Notification subsystem, implementing the communication between
BY: MA
FieldOfficer terminals and Dispatcher stations.
  This subsystem decomposition is depicted using UML components.
 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.
– A physical component corresponds to a subsystem that as an
explicit run-time equivalent, for example, a database server.
BY: MA
BY: MA
 2.2 Services and Subsystem Interfaces

 Service is a set of related operations that share a common

purpose. The origin (“seed”) for services are the use cases from
the functional model. Services are defined during system design.
 A subsystem is characterized by the services it provides to other
subsystems.
 for example: A subsystem providing a notification service,
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.
BY: MA
  System design focuses on defining the services provided
by each subsystem, that is, enumerating the operations,
their parameters, and their high-level behavior.
 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.
 The dependency between two subsystems is shown by
connecting the corresponding ball and socket in the
BY: MA
BY: MA
 2.3 Properties of Subsystem: Coupling and Cohesion

 There are two properties of subsystem coupling and cohesion.

 Coupling is the measures 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 [Link]
minimizes the impact that errors or future changes in one
subsystem have on other subsystems.
BY: MA
  For example, the IncidentManagement subsystem issues SQL
queries to store and retrieve records Incidents database.
 This leads to a situation with a high coupling among the Database
subsystem and the three client subsystems (i.e.,
IncidentManagement, ResourceManagement, and MapManagement)
as any change in the way the data is stored will require changes in
the client subsystems.
 For example, if we change database vendors we will have to change
the subsystems to use a different dialect of the query language.
 To reduce the coupling among these four subsystems, we decide to
create a new subsystem, called Storage, which shields the
Database from the other subsystems.
 In this alternative, the three client subsystems use services provided
BY: MA
by the Storage subsystem, which is then responsible for issuing
BY: MA
  Cohesion is the measures 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.
 In general, there is a trade-off between cohesion and
coupling. We can often increase cohesion by
decomposing the system into smaller subsystems.
However, this also increases coupling as the number of
BY: MA interfaces increases.
BY: MA
 2.4 Techniques of Subsystem: Layers and Partitions

 Layers is a hierarchical decomposition of a system yields

an ordered set of layers. A layer is a grouping of
subsystems providing related services, possibly realized
using services from another layer.
 A layer is a subsystem that provides a service to another
subsystem with the following restrictions:
– A layer only depends on services from lower layers
– A layer has no knowledge of higher layers
 The layer that does not depend on any other layer is called
the bottom layer, and the layer that is not used by any other
is called the top layer.
BY: MA
  In a closed architecture, each layer can access only the
layer immediately below it. In an open architecture, a
layer can also access layers at deeper levels.
 A layer can be divided horizontally into several
independent subsystems called partitions
– Partitions provide services to other partitions on the
same layer. Partitions are also called “weakly coupled”
subsystems.
 Another approach to dealing with complexity is to partition
the system into peer subsystems, each responsible for a
different class of services.
BY: MA
BY: MA
  An example of a closed architecture is the Reference Model
of Open Systems Interconnection (OSI model):
1. The Application layer
2. The Presentation layer
3. The Session layer
4. Transport layer:
5. The Network:
6. DataLink layer :
7. Physical layer

BY: MA
  In general, a subsystem decomposition is the result of
both partitioning and layering.
 We first partition the system into top-level subsystems,
which are responsible for specific functionality or run on a
specific hardware node.
 Each of the resulting subsystems are, if complexity
justifies it, decomposed into lower- and lower-level layers
until they are simple enough to be implemented by a
single developer.

BY: MA
 2.5 Architectural Styles

 As the complexity of systems increases, the specification of

system decomposition is critical. It is difficult to modify or
correct weak decomposition once development has started,
as most subsystem interfaces would have to change.
 Subsystem decomposition: Identification of subsystems,
services, and their association to each other (hierarchical,
peer-to-peer, etc)
 Architectural Style: A pattern for a subsystem
decomposition
 Software Architecture: Instance of an architectural style.
There are different types of Architectural style
BY: MA
 2.5.1 Repository

 In the repository architectural style subsystems access and modify

a single data structure called the central repository.
 Subsystems are relatively independent (they are loosely coupled )
and interact only through the repository.
 Control flow is dictated by the repository through triggers or
by subsystems through locks and synchronization primitives.

BY: MA
  Once a central repository is well defined, we can easily
add new services in the form of additional subsystems.
 The main disadvantage of repository systems is that the
central repository can quickly become a bottleneck, both
from a performance aspect and a modifiability
aspect.
 The coupling between each subsystem and the
repository is high, thus making it difficult to change the
repository without having an impact on all subsystems.

BY: MA
 2.5.2. Model/View/Controller (MVC)

 In the Model/View/Controller (MVC) architectural style

subsystems are classified into three different types:
– Model subsystems maintain domain knowledge, Model
implements the central data structure and control objects dictate
the control flow.
– View subsystem: Responsible for displaying application
domain objects to the user
– Controller Responsible for sequence of interactions with
the user and notifying views of changes in the model
 The model subsystems are developed such that they do not
depend on any view or controller subsystem.

BY: MA
  MVC is well suited for interactive systems, especially
when multiple views of the same model are needed.
 MVC can be used for maintaining consistency across
distributed data; however it introduces the same
performance bottleneck as for other repository sty

BY: MA
 2.5. 3. Client/server

 In the client/server architectural style (Figure 6-18), a

subsystem, the server, provides services to instances of
other subsystems called the clients, which are responsible
for interacting with the user.
 The request for a service is usually done via a remote
procedure call mechanism or a common object broker
(e.g., CORBA, Java RMI, or HTTP).
 Control flow in the clients and the servers is independent
except for synchronization to manage requests or to
receive results.

BY: MA
  An information system with a central database is an example of a
client/server architectural style.
 The clients are responsible for receiving inputs from the user,
performing range checks, and initiating database transactions when
all necessary data are collected.
 The server is then responsible for performing the transaction and
guaranteeing the integrity of the data.
 Client/server systems, however, are not restricted to a single server.
On the World Wide Web, a single client can easily access data from
thousands of different servers (Figure 6-19).

BY: MA
BY: MA
 2.5.4 Peer-to-peer

 A peer-to-peer architectural style is a generalization of

the client/ server architectural style in which subsystems
can act both as client or as servers, in the sense that
each subsystem can request and provide services.
 The control flow within each subsystem is independent
from the others except for synchronizations on requests.
 Peer-to-peer systems are more difficult to design than
client/server systems because they introduce the possibility of
deadlocks and complicate the control flow.
 Callbacks are operations that are temporary and customized for
a specific purpose.
BY: MA
BY: MA
 2.5.5 Three-tier

 The three-tier architectural style organizes subsystems into three

layers
– The interface layer includes all boundary objects that deal with the user,
including windows, forms, web pages, and so on.
– The application logic layer includes all control and entity objects, realizing
the processing, rule checking, and notification required by the application.
– The storage layer realizes the storage, retrieval, and query of persistent
objects.

BY: MA
 2.5.6 Four-tier
 The four-tier architectural style is a three-tier architecture in which the
Interface layer is decomposed into a Presentation Client layer and a
Presentation Server layer (Figure 6-23).
 The Presentation Client layer is located on the user machines, whereas
the Presentation Server layer can be located on one or more servers.
 The four-tier architecture enables a wide range of different presentation
clients in the application, while reusing some of the presentation objects
across clients.
 For example, a banking information system can include a host of
different clients, such as a Web browser interface for home users, an
Automated Teller Machine, and an application client for bank
employees. Forms shared by all three clients can then be defined and
processed in the Presentation Server layer, thus removing redundancy
across clients.
BY: MA
BY: MA
 3. 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.
 Some of the system design activities are:
– Identifying Design Goal
– Identifying Subsystem decomposition
– Subsystem mapping into HW?SW components
– Identifying and storing persistent data
– Identifying Access control policy

BY: MA
 3.1. 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.
 In general, we can select design goals from a long list of
highly desirable qualities design criteria. These criteria are
organized into five groups: performance, dependability,
cost, maintenance, and end user criteria.

BY: MA
  Performance criteria : include the speed and space
requirements imposed on the system.
– Response time: How soon is a user request acknowledged after
the request has been issued?
– Throughput: How many tasks can the system accomplish in a
fixed period of time?
Memory: How much space is required for the system to run?
 End user criteria: include qualities that are desirable
from a users’ point of view.
– Utility: How well does the system support the work of the user?
– Usability: How easy is it for the user to use the system?

BY: MA
  Dependability criteria: determine how much effort
should be expended in minimizing system crashes and
their consequences.
– Robustness: Ability to survive invalid user input
– Reliability: Difference between specified and observed behavior
– Availability: Percentage of time that system can be used to
accomplish normal tasks
– Fault tolerance: Ability to operate under erroneous conditions
– Security: Ability to withstand malicious attacks
– Safety: Ability to avoid endangering human lives, even in the
presence of errors and failures

BY: MA
  Cost criteria: include the cost to develop the system, to
deploy it, and to administer it.
– Development cost :Cost of developing the initial system
– Deployment cost: Cost of installing the system and training the
users
– Upgrade cost :Cost of translating data from the previous system.
This criteria results in backward compatibility requirements
– Maintenance cost :Cost required for bug fixes and
enhancements to the system
– Administration cost :Cost required to administer the system

BY: MA
  Maintenance criteria: determine how difficult it is to
change the system after deployment.
– Extensibility: How easy is it to add functionality or new classes to the
system?
– Modifiability: How easy is it to change the functionality of the system?
– Adaptability: How easy is it to port the system to different application
domains?
– Portability: How easy is it to port the system to different platforms?
– Readability: How easy is it to understand the system from reading the
code?
– Traceability: of requirements How easy is it to map the code to specific
requirements?

BY: MA
 Stakeholders have different Design Goals

Low cost Functionality

Increased productivity User-friendliness
Backward compatibility Runtime Usability
Traceability of Efficiency Ease of learning
requirements Fault tolerant
Rapid development Robustness
Reliability
Flexibility
Portability
Client Good documentation
End
(Customer) User
Minimum # of errors
Modifiability, Readability
Reusability, Adaptability Developer/
Well-defined interfaces
Maintainer
BY: MA
 3.2. Identifying Subsystems

 Finding subsystems during system design is similar to finding

objects during analysis.
 The initial subsystem decomposition should be derived from the
functional requirements.
 Subsystem decomposition reduces the complexity of the solution
domain by minimizing coupling among subsystems
 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.
BY: MA
 3.3. Mapping of subsystem to hardware

 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?
 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.
 Many systems run on more than one computer and depend on
access to an intranet or to the Internet.
 The use of multiple computers can address high-performance
needs and interconnect multiple distributed users.
BY: MA
  Consequently, we need to examine carefully the allocation
of subsystems to computers and the design of the
infrastructure for supporting communication between
subsystems. These computers are modeled as nodes in
UML deployment diagrams.
BY: MA
 Mapping objects into Hardware components

 Entity Objects -> Memory

– Is there enough memory to buffer bursts of requests?
 Boundary Objects -> Input/Output Devices
– Do we need an extra piece of hardware to handle the data
generation rates?
– Can the desired response time be realized with the available
communication bandwidth between subsystems?
 Control Objects -> Processor
– Is the computation rate too demanding for a single processor?
– Can we get a speedup by distributing objects across several
processors?
– How many processors are required to maintain a steady state
load?

BY: MA
 3.4. Identifying and Storing Persistent Data

 Persistent data management describes the persistent

data stored by the system and the data management
infrastructure required for it. This section typically
includes the description of data schemes, the
selection of a database.
 First, we identify which data must be persistent. The
entity objects identified during analysis are obvious
candidates for persistency.
 Note that not all entity objects must be persistent. For
example, Location and Direction are constantly
recomputed as the car moves.
BY: MA
  Persistent objects are not limited to entity objects, however,
In a multi-user system, information related to users (e.g.,
Drivers) is persistent, as well as some attributes of the
boundary objects (e.g., window positions, user interface
preferences, state of long-running control objects).
 In general, we can identify persistent objects by examining
all the classes that must survive system shutdown, either in
case of a controlled shutdown or an unexpected crash.
 Once all persistent objects are identified, we need to
decide how these objects should be stored.

BY: MA
  In general, there are currently three options for storage management:
1. Flat files: Files are the storage provided by operating systems.
2. Relational database.
3. Object-oriented database, it stores data as objects and
associations.
 UML object models can be mapped to relational databases, the mapping:
– Each class is mapped to its own table
– Each class attribute is mapped to a column in the table
– An instance of a class represents a row in the table
– One-to-many associations are implemented with a buried foreign key
– Many-to-many associations are mapped to their own tables
– Methods are not mapped

BY: MA
 3.5. Providing Access Control

 In multi-user systems, different actors have access to different

functionality and data. For example, an everyday actor may only
access the data it creates, whereas a system administrator actor
may have unlimited access to system data and users’ data.
 During analysis, we modeled these distinctions by associating
different use cases to different actors. During system design, we
model access by determining which objects are shared among
actors, and by defining how actors can control access.
 Depending on the security requirements of the system, we also
define how actors are authenticated to the system and how
selected data in the system should be encrypted

BY: MA
  We can represent the access matrix using one of three different
approaches:
– A global access table represents explicitly every cell in the
matrix as a (actor, class, operation) tuple. Determining if an actor
has access to a specific object requires looking up the
corresponding tuple.
– An access control list associates a list of (actor, operation) pairs
with each class to be accessed. Every time an object is accessed,
its access list is checked for the corresponding actor and
operation.
– A capability associates a (class, operation) pair with an actor. A
capability allows an actor access to an object of the class
described in the capability. Denying a capability is equivalent to
BY: MA denying access.
 Access Control Matrix Explained
HR Records Gary Sandy Tonya Robyn Samantha

Salary Files RWED R - ED ---- RWED RWED

Promotion List ---D R-E- RWED RWED ----

Performance
RWED RW - D ---- ---- RWE -
Reports

• As shown in this table, the matrix consists of one or more subjects (or people)
along one axis and the associated objects (or files) along the other axis. Certain
people are allowed to read (R), write (W), execute (E), and delete (D) files.
Restricted access is indicated by a dash.
• For example, you can see that Gary is allowed to delete the promotion list,
whereas Sandy is allowed to read or execute it. Tonya has full access, while
Samantha has no access whatsoever. When setting up access controls, the
systems administrator must adhere to three primary principles:
BY: MA
 Summary
 Subsystem decomposition describes the decomposition into
subsystems and the responsibilities of each.
 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 typically includes the description of data schemes, the
selection of a 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.
BY: MA
  THANK YOU !

BY: MA