Chapter Eleven

Object oriented System Design

 An overview of system design
 What is it? A meaningful engineering representation of something that is to
be built. Design is the abstraction of a solution; General description of the
solution to a problem.
o Explaining the idea/concept of something Usually with graphical

diagrams With the intention to build from the explanation

o The design is a representation of a product or a system with sufficient

detail for implementation

 Who does it? Software engineers with a variety of skills, ranging from
human needs to computer architecture
 Why is it important? A house would never be built without a blueprint.
Why should software? Without design the system may fail with small
changes, is difficult to test and cannot be assessed for quality.
 Reduce the time required to create the implementation and complexity

 What is the work product? A design specification

 Cont..
 Why analysis and design??
 Analysis: Focuses on the application domain and Design: Focuses on the
solution domain
From our understanding of the problem, we start building the software.

 Translate the analysis model into the design model(Map the information
from the analysis model to the design representations - data design,
architectural design, interface design, procedural design).
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
The result of system design is a model that includes a subsystem
decomposition and a clear description of each of these strategies.
 Where are we in the system development ?
 The creation of software involves four basic activities:
o Establishing the requirements, creating a design, implementing the code,
testing the implementation
 Software requirements specify the tasks that a program must accomplish
o what to do, not how to do it
 It is difficult to establish detailed, unambiguous, and complete requirements
 Careful attention to the requirements can save significant time and expense in the
overall project
 Software design and implementation??? is the process of converting the system
specification into an executable system.
 Software design
o Design a software structure that realizes the specification;

 Implementation
o Translate this structure into an executable program;
Cont..
Object-oriented analysis, design and programming are related but distinct
Analysis:

oModel the real world showing its important properties;

o Concise model of what the system will do
oOOA is concerned with developing a model of the application domain. E.g.
System Design:

oOrganize into subsystems based on analysis structure and propose architecture.

Object Design:

oBased on analysis model but with implementation details; Focus on data structures and

algorithms to implement each class; a method for decomposing software architectures

based on the objects every system or subsystem manipulates relatively independent of
the programming language used.
oOOD is concerned with developing an object-oriented system model to implement

requirements.
Implementation: Translate the object classes and relationships into a programming

language
oOOP is concerned with realising an OOD using an OO programming language such as

Java or C++
Cont..
 A software design specifies how a program will accomplish its requirements
 That is, a software design determines:
o how the solution can be broken down into manageable pieces
o what each piece will do
 An object-oriented design determines which classes and objects are needed, and
specifies how they will interact
 Low level design details include how individual methods will accomplish their
tasks
 Implementation is the process of translating a design into source code
 Novice programmers often think that writing code is the heart of software
development, but actually it should be the least creative step
 Almost all important decisions are made during requirements and design stages
 Implementation should focus on coding details, including style guidelines and
 Input and Output

 Design goals
 A set of nonfunctional requirements
 data/class design;
 use case model
 architectural design;
 sequence diagrams
 interface design;
 Object model
 component design

 Each of the element of analysis model provide necessary information

for the four design models required for design specification:
 How to use the results from the
Requirements Analysis for System Design
♦ Nonfunctional requirements =>
Activity 1: Design Goals Definition
♦ Functional model =>
Activity 2: System decomposition (Selection of subsystems based on
functional requirements, cohesion, and coupling)
♦ Object model =>
Activity 4: Hardware/software mapping
Activity 5: Persistent data management
♦ Dynamic model =>
Activity 3: Concurrency
Activity 6: Global resource handling
Activity 7: Software control
♦ Subsystem Decomposition
Activity 8: Boundary conditions
 Major design process activities
o Architectural design
o Abstract specification
o Interface design
o Component design
o Data structure design
o Algorithm design
 All design methods have the following characteristics:
o A mechanism for the translation of the analysis model into a design
representation
o A notation for representing functional components and their
interfaces
o Heuristics for refinement and partitioning
o Guidelines for quality assessment
 The software design process
Requirements
specification

Design activities

Data
Architectural Abstract Interface Component Algorithm
structure
design specification design design design
design

Data
System Software Interface Component Algorithm
structure
architecture specification specification specification specification
specification

Design pro ducts

 Design models/design Possible models
 The design is usually documented as a set of graphical models.
 The elements of design model use many of the same UML diagrams that
were used in the analysis model.
 The diagrams are refined and elaborated – more implementation specific
detail is provided;
 Architectural structure and style, components that reside within architecture,
interfaces between components and with outside world are all underlined.
 Design models show the objects and object classes and relationships between
these entities
 Static models describe the static structure of the system in terms of object
classes and relationships
 Dynamic models describe the dynamic interactions between objects.
 Sequence models that show the sequence of object interactions.
 State machine models that show how individual objects change their
state in response to events
Cont..
 Sub-system models that show logical groupings of objects into
coherent subsystems
 Other models include use-case models, aggregation models,
generalisation models, etc.
Data design model/element
Architectural design elements
Interface design elements
o The user interface (UI)
o External interfaces
o Internal interfaces between various design components
Component-level design elements
Deployment-level design elements
 What is a model and why?
 A model is a simplification of reality.
E.g., a miniature bridge for a real bridge to be built
o A model is our simplification of our perception of reality
o (that is, if it exists, otherwise it could be a mere illusion).
o communication is not about reality but about your/my/his/her
perception of reality => validation and verification hard but
needed
 A model is an abstraction of something for the purpose of
understanding, be it the problem or a solution.
 To understand why a software system is needed, what it should do,
and how it should do it.
 To communicate our understanding of why, what and how.
 To detect commonalities and differences in your perception, my
perception, his perception and her perception of reality.
 To detect misunderstandings and miscommunications.
 Design and Quality!
 Design is the stage where quality is instilled
 Design is assessed by formal review or walkthrough
 Characteristics of a good design:
o The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements desired
by the customer.!
o The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.!
o The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.!
 Design Concepts
Fundamental concepts which provide basis to design correctly:
 Abstraction

 Modularity

 Software Architecture

 Information Hiding

 Cohesion and coupling

 Abstraction and Refinement
 Abstraction:
 “Abstraction permits one to concentrate on a problem at some level of
generalization without regard to irrelevant low level details..”
 Focus on the essential and Omits tremendous amount of details
 …Focus on what an object “is and does”

Types: data, procedural and control

 Identifying important features for representation
 There are many levels of abstraction depending on how detailed the
representation is required
 Data abstraction - representation of data objects
 Procedural abstraction - representation of instructions
 Data Abstraction
door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

A named collection of data that describes a data object

 Procedural Abstraction

open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter

A named sequence of instructions with a specific and

limited function
 Modularity
 Huge software cannot be easily grasped by a software engineer.
 It takes more time to solve more difficult problem.
 “divide an conquer” strategy – it’s easier to solve complex problem
when you break it into manageable pieces. problem is broken into
manageable pieces. Solutions for the separate pieces then
integrated into the whole system
 Any complex problem can be more easily handled if it is
subdivided into pieces that can each be solved and/or optimized
independently!
 a problem takes less effort and time to solve.!
 Divide And Conquer

S1
S2

P1 P2
S5
P5
P4 P3
S3
S4
 Software Architecture

 Modules can be integrated in many ways to produce the system

 Software architecture is the overall structure of the software

 The hierarchy of components and how they interact, and the

structure of data used by the components

 Use of framework models, and possible reuse of architectural

patterns
 Architectural design
 Once interactions between the system and its environment have
been understood, you use this information for designing the system
architecture
 Layered architecture is appropriate for the weather station
o Interface layer for handling communications

o Data collection layer for managing instruments

o Instruments layer for collecting data

 Rule of thumb: there should be no more than 7 entities in an

architectural model
 Information Hiding
Encapsulation: information hiding
 Objects encapsulate:
o property
o behavior as a collection of methods invoked by messages
o state as a collection of instance variables
 Information (procedure and data) contained within a module is

inaccessible to other modules that have no need for such information

 Effective modularity is achieved by independent modules, that

communicate only necessary information

 Ease of maintenance - testing, modification localized and less likely

to propagate
 Hide details within a module

 Ensure that no other module can tamper with these hidden details
 Functional independence
 Each module should address a specific sub function of requirements
and have a simple interface.
 Functional independent modules are easier to develop, maintain,
and test;
 Error propagation is reduced and reusable modules are possible;
 Assessed using two qualitative criteria:
o cohesion;
o coupling.
 Coupling and Cohesion
 Goal: Reduction of complexity while change occurs
 Cohesion measures the dependence among classes. the degree of
interaction within a module. A measure of functional strength
o High cohesion: The classes in the subsystem perform similar tasks and

are related to each other (via associations)

o Low cohesion: Lots of miscellaneous and auxiliary classes, no

associations
 Coupling measures dependencies between subsystems. the degree of
interaction between modules’ A measure of relative interdependence
o High coupling: Changes to one subsystem will have high impact on the

other subsystem (change of model, massive recompilation, etc.)

o Low coupling: A change in one subsystem does not affect any other

subsystem
 Subsystems should have as maximum cohesion and minimum coupling as
possible:May say, good subsystem decomposition should minimize
coupling and maximize cohesion.
 System Design Activities
System Design

Boundary
Identify Design Goals Conditions
Additional NFRs Initialization
Trade-offs: Termination
Failure.
Subsystem Decomposition

Hardware/ Global Resource

Software Mapping Handling
Persistent Data
Identification of Nodes Management Access Control
Special Purpose Storing Persistent
and Security issue
Systems Objects
Buy vs Build Filesystem vs
Network Connectivity Database
System Design Activities: Identifying Design Goals/trade
off
 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.
 For example, in the light of the nonfunctional requirements for
library system described in, reliability and fault tolerance to
connectivity loss is identified as design goals.
 The system should be designed in such a way that every user is asked
for user name and password to access the system’s database or some
functionality -> security.
 Extensibility can be also identified as design goal to allow the
addition of any new service related to library system while at the
same time preserving the general structure of the system.
Cont..
The system should be reliable /trustworthy. should give fault tolerant
to loss of connectivity with service. should be se cure,i.e., not allow
non-authorized users to access a resources [deduced from application
domain]. should be modifiable to use different services [anticipation of
change by developers]
Design goals can be categorized into: performance, dependability,
cost, maintenance, and end user.
E.g. Assign one or more categories to each of the following goals:
1. Users must be given a feedback within 1 second after they issue any
command. [Performance]
2. The TicketDistributor must be able to issue train tickets, even in the
event of a network failure.[Dependability/reliability]
 Cont..
3. The housing of the TicketDistributor must allow for new buttons to be installed
in the event the number of different fares increases. [Maintenance]
4. The AutomatedTellerMachine must withstand dictionary attacks (i.e., users
attempting to discover a identification number by systematic trial).
[Dependability]
5. The user interface of the system should prevent users from issuing commands in
the wrong order. [End user]
Design Tradeoffs:
 Conceptual design involves a series of tradeoff decisions among to obtain a
compromise design which best meets the performance requirements. Both the
ambiguity/doubt in these requirements and the important tradeoff factors should
be determined.
 “Design window”: Time in which design decisions have to be made
 The concept of a tradeoff implies a tactical or strategic choice made with full
understanding of the advantages and disadvantages of each factor )
 Is a situational decision that involves lessening or losing one quality, quantity or
property of a design in return for gains in other aspects. In simple terms, a
tradeoff is where one thing increases and another must decrease.
 Typical Design Trade-offs
Throughput vs. Latency: Our project uses event based-control flow
i.e. Web server allocates a new thread for each request thereby
allowing parallel handling of requests. This increases the throughput
but checking overhead slows down.
Memory space vs. Response time: Since our system focuses on
providing fastest ambulance service to the victims of any emergency
incidents, response time is the most important factor and so more
memory can be expended to speed up the software (e.g., caching,
more redundancy, etc.)
Functionality vs. Usability : Our software incorporates
functionalities which meets the requirement specification. With SQL
server as database component, J2EE as business object and JSP as
front-end the usability of the system is fully achieved.
Cont..
 Efficiency vs. Portability: The system is efficiently designed by
which porting from one environment to another is made easy. With
Java and flat file tools, portability is much easier to support in various
environment. 
 Rapid development vs. Functionality: Traditionally the rapid
application development (RAD) approach involves compromises in
usability, features, and/or execution speed. Our system is designed to
meet the functional specification with rapid application development
approach.
 Cost vs. Reusability: Our software interfaces & components can be
reused within the system to implement the functionality for other
modules but the software is designed using Java for business logic &
SQL Server for data access which is quite expensive compare to other
data access tools.
System Design Activities: Identifying Subsystems

 Subsystem decompositions help to reduce the complexity of the

system.
 Subsystem is the 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 packages
 Service: is a set of named 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.
 Subsystem decomposition is constantly revised whenever new
issues are addressed
Cont..
 Subsystem Decomposition Heuristics:
 The initial subsystem decomposition should be derived from the functional
requirements(keep functionally related objects together).
 Consider the objects and classes in your requirements analysis models.
 A starting point is to assign the participating objects that have been identified in
each use case to the subsystems
 Try grouping objects into subsystems by assigning objects in one use case into the
same subsystem
 No more than 7+/-2 subsystems
o More subsystems increase cohesion but also complexity (more services)

 No more than 4+/-2 layers, use 3 layers (good)

 Minimizing the number of associations crossing subsystem boundaries ensure all
objects in the same subsystem are functionally related
Example of a Subsystem Decomposition

Partition
relationship Layer 1
A:Subsystem

B:Subsystem C:Subsystem D:Subsystem Layer 2

E:Subsystem F:Subsystem G:Subsystem Layer 3

 Some further criteria
 Criteria for subsystem selection: Most of the interaction should be
within subsystems, rather than across subsystem boundaries (High
cohesion).
o Does one subsystem always call the other for the service?

o Which of the subsystems call each other for service?

 Primary Question:
What kind of service is provided by the subsystems (subsystem interface)?
 Secondary Question:
Can the subsystems be hierarchically ordered (layers)?
 What kind of model is good for describing layers and partitions?
 Partitioning and layering are techniques to achieve low coupling.
 A large system is usually decomposed into subsystems using both,
layers and partitions.
Cont..
♦ Criteria for subsystem selection: most of the interaction should be
within a subsystem and not across subsystem boundaries.
 Self-contained

o Most of the interaction should be within subsystems, rather than across

subsystem boundaries
 Reusable
o Usage of the same subsystem in a different context
 Maintainable
o Understanding the purpose of a subsystem even in the future
o Make modifications easily
 Correct
o No side effects
 Goal: Reduction of Complexity
 Subsystems should have maximum cohesion and minimum coupling
 What is cohesion and coupling?
Cont..
 A subsystem has unexpected cohesion if it performs multiple,
completely unrelated actions
 Example: Subsystem for “dealing with clients”
print_next_line();
addClient();
rollbackTransaction();
openOnlineHelp();
 It’s BAD BECAUSE:
o No clear purpose

o It degrades maintainability

o A module with unexpected cohesion is not reusable

 The problem is easy to fix- Break the module into separate

modules, each performing one task
 Cont..
 A subsystem has informational cohesion if it performs a number of
actions, each with its own entry point, with independent code for
each action, all performed on the same data structure
 Example: Subsystem for creating a client record
createClient()
deleteClient()
addDateOfBirth()
addAddress()
 It’s GOOD BECAUSE:
o Exact purpose

o It increases maintainability

o High reusability
 Example: ARENA Subsystem decomposition

User Interface

Administers user
Manages advertisement Manages tournaments,
accounts
banners and sponsorships. applications, promotions.

Tournament
Advertisement User Management
For adding games,
styles, and expert
rating formulas
Component
Management User Directory

Tournament
Session
Statistics
Management Stores user profiles
Maintains state during Stores results of (contact &
matches. archived tournaments subscriptions)
 Concurrency
 Nonfunctional Requirements to be addressed: Performance, Response time,
latency, availability.
 Two objects are inherently concurrent if they can receive events at the same
time without interacting
o Source for identification: Objects in a sequence diagram that can

simultaneously receive events. Uunrelated events, instances of the same

event
 Inherently concurrent objects can be assigned to different threads of control
 To identify threads for concurrency we ask the following questions:
o Does the system provide access to multiple users?

o Which entity objects of the object model can be executed independently

from each other?

o Can a single request to the system be decomposed into multiple

requests? Can these requests and handled in parallel? (Example: a

distributed query)
 System Design Activities:
Hardware Software Mapping
This activity addresses two questions:
 What is the most appropriate hardware environment?
o How are objects and subsystems mapped on the chosen
hardware? How shall we realize the subsystems: With hardware
or with software?
 How do we map the object model onto the chosen hardware
and/or software?
o Mapping the Objects:
 Processor, Memory, Input/output
o Mapping the Associations:
 Network connections
 Mapping Objects onto Hardware
 Control Objects -> Processor
o Is the computation rate too demanding for a single processor?
o Can we get a speedup by distributing objects across several processors?
o How many processors are required to maintain a steady state load?
 Entity Objects -> Memory
o Is there enough memory to buffer bursts of requests?
 Boundary Objects -> Input/Output Devices
o Do we need an extra piece of hardware to handle the data generation rates?
o Can the desired response time be realized with the available
communication bandwidth between subsystems?
 Describe the physical connectivity

o (“physical layer in the OSI Reference Model”)

 Describes which associations in the object model are mapped to physical

connections.
 Describe the logical connectivity (subsystem associations)

o Associations that do not directly map into physical connections.

o In which layer should these associations be implemented?
 Hardware/Software Mappings in UML
 A UML component is a building block of the system. It is represented as a
rectangle with a tabbed rectangle symbol inside
 The Hardware/Software Mapping addresses dependencies and distribution
issues of UML components during system design.
 Two UML Diagram Types

o Deployment Diagram:
 Illustrates the distribution of components at run-time.
 Deployment diagrams use nodes and connections to depict the physical
resources in the system.
o Component Diagram:
 Illustrates dependencies between components
o Used to model the top-level view of the system design in terms of
components and dependencies among the components.
o Show how the software components are wired together in the overall
application.
 System Design Activities:
Data Management

 Some objects in the system model need to be persistent:

o Values for their attributes have a lifetime longer than a single
execution
 A persistent object can be realized with one of the
following mechanisms:
o File system
o Database
Cont..
 When should you choose a file?
o For extensive data (images)

o For lots of raw data (core dump, event trace)

o Temporary Data that is kept only for a short time

 When should you choose a database?

o Data that require access at fine levels of details by multiple users

and/or applications (concurrent access)

o Data that must be ported across multiple platforms

(heterogeneous systems)
o Rollback and Transactions play an important aspect
 Mapping Object Models
 UML object models can be mapped to relational
databases
 The mapping:
o Each class is mapped to its own table
o Each class attribute is mapped to a column in the table
o An instance of a class represents a row in the table
o One-to-many associations are implemented with a buried
foreign key
o Many-to-many associations are mapped to their own tables
 Methods are not mapped
 System Design Activities :
Access Control
 In multi-user systems different actors usually have different access
rights to different functionality and data
 How do we model these accesses?
o During analysis we model them by associating different use cases

with different actors

o During system design we model them determining which objects

are shared among actors.

 Access Matrix
 We model access on classes with an access matrix:
o The rows of the matrix represents the actors of the system
o The column represent objects whose access we want to
control
 Access Right: An entry in the access matrix. It lists the
operations that can be executed on instances of the class
by the actor.
 Access Matrix Example: Library system
Actors Access Rights objects

Book User Journal Feedbac UserAccou Report Shift

k nt
Book_Borrowe Search() Search() Give()
r Reserve()

Journal_Borro Search() Search() Give()

wer Reserve() Reserve()

Librarian Lend() Add() Lend() Give() Login() Print()

Register() ViewUser( Register() View() View() View()
Return() ) Return() ViewBy() ViewBy()
ViewBook() ViewJournal(
)
Libraray_Ad Lend() Add() Lend() Give() Create() Print() Set()
ministrator Register() ViewUser( Register() View() ChangePass( View() View()
Return() ) Return() ViewBy() ) ViewBy() ViewBy()
ViewBook() ViewJournal Login()
D()
 Global Resource Questions
 Does the system need authentication?
 If yes, what is the authentication scheme?
o User name and password?

o Tickets?

 What is the user interface for authentication?

 Does the system need a network-wide name server?
 How is a service known to the rest of the system?
o At runtime? At compile time?

o By Port?

o By Name?
 Authentication and Encryption
 During system design we model them by examining the object model by
determining which objects are shared among actors.
 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.
♦ Authentication
 Process of verifying the association between the identity of a user (or calling
subsystem) and the system
o User name / password

o Smart Cards

o Biometric Sensors (analyzing patterns of blood vessels in eyes / fingers

♦ Encryption
 Translating a message (plaintext) into an encrypted message (ciphertext).
 A key is used to encrypt (sender) and decrypt (receiver) a message
 System Design Activities: Boundary
Conditions
 Most of the system design effort is concerned with steady-state
behavior.
 However, the system design phase must also address the initiation
and finalization of the system. This is addressed by a set of new uses
cases called administration use cases
 Initialization-
 Describes how the system is brought from a non initialized state to
steady-state ("startup use cases”).
o How does the system start up?

o What data need to be accessed at startup time?

o What services have to registered?

o What does the user interface do at start up time?

o How does it present itself to the user?

Cont..
 Termination
 Describes what resources are cleaned up and which systems are
notified upon termination ("termination use cases").
o Are single subsystems allowed to terminate?

o Are other subsystems notified if a single subsystem terminates?

o How are local updates communicated to the database?

 Failure
 Many possible causes: Bugs, errors, external problems (power
supply).
 Good system design foresees fatal failures (“failure use cases”).
o How does the system behave when a node or communication link

fails? Are there backup communication links?

o How does the system recover from failure? Is this different from

initialization?