Software Design

 Deriving a solution which

satisfies software requirements

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 1

Objectives
 To introduce the process of software design
 To describe the different stages in this design
process
 To show how object-oriented and functional
design strategies are complementary
 To discuss some design quality attributes

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 2

Programmer’s Approach to
Software Engineering

Skip requirements engineering and design phases;

start writing code

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 3

Why this programmer’s approach?
 Design is a waste of time

 We need to show something to the customer real

quick

 We are judged by the amount of LOC/month

 We expect or know that the schedule is too tight

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 4

Design of small and large systems

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 5

 theStorag e
What is the Problem?
aWarehouse
This is a simple
UM L-A Generated Association Class:aNavPoint Association (0.5)
(1.0)
software system!
aRoute

UM L-A Generated Dependency Class:aRouteCollection Association (0.5)

UML -A Genera ted De pend ency C lass :aRou teCol lectio n Ass ociatio n (0. 25)
theVehicleCollection
UM L-A Generated Association Class:aW arehouse Association (1.0)

aVehicle

UM L-A Generated Dependency Class:theRouter Dependency (1.0)

UM L-A Generated Dependency Class:theRouter Dependency (0.5)
UM L-A Generated Dependency Class:theRouter Association
UM L-A UM (0.25)
Generated
L-AUM
Generated
L-AAssociation
UM
Generated
L-A
Association
UMGenerated
L-A
Class:aNavPoint
Association
Generated
UM
Class:aNavPoint
Association
L-A L-A
UM Class:aNavPoint
Gene
Association
UMAssociation
rated
L-A
Class:aNavPoint
Genera
Association
Association
GeneratedClass:aNavPoint
Association
ted
(1.0)
Depend
Clas
(1.0)
Association
Association s:theW
ency
Association
(1.0)Class
areh
(1.0)
Class:theRouter ouseCollec
:aRouteCollectio
(1.0) tion Depen
Association n Assden
(0.25)oc
UM L-A UM L-A Generated Dependency Class:theRouter Dependency (1.0)
UM L-AUMGenerated
L-AUM
Genera
L-AAssociation
UM
Generated
ted
L-AUM
AsGenerated
socia
L-A
Class:theVehicleCollection
Association
UMGenerated
tion
L-A
CAssociation
UML-
lass:
Generated
Class:theVehicleCollection
A
Association
theVe
UMGen
L-A
hicleC
L-A
dollec onGenerated
Class:theVehicleCollection
erate
Association
UMGenerated
Class:theVehicleCollection
UM
Ass
Generated
Generalization
L-A
ociati
tion nDependency
Class:theVehicleCollection
Association
Generated
Genera
Cl
Association
Generalization
ass:th
lizatio
(1.0) Class:theRouter
Class:theVehicleCollection
Association
eVehi
Generalization
(1.
Class:theVehicleCollection
cleCo
0)
Generalization
(1.0) Dependency
Class:theVehicleCollection
llectio
Generalization
(1.0)
n Ge (1.0)
nerali
Generalization
zation
(1.0)
Generalization(0.5)
(1.0Generalization
) (1.0) (1.0) (1.0)
aTruck aShip aAirplane theW areho useCo llecti on UML- A Ge nerate d Gen eraliz ation Class :avail ableV ehicle Colle ction Depe ndenc y (1.0 )
UMUML-AL-A
Generated
GeneratedAssociation
AssociationClass:theVehicleCollection
Class:availableVehicleCollection
Dependency
Dependency
(0.5) (0.5)
UM L-A Generated Dependency Class:theRouter Association (0.5)
UM L-A Generated Dependency Class:theRouter Association (0.25)

UM L-A Generated Dependency Class:theRouter Dependency (1.0)

UM L-A Generated Dependency Class:theRouter Dependency (1.0)
UM L-AUM
Generated
L-A Generated
Association
Association
Class:aDifficiency
Class:aDifficiency
Association
Association
(1.0) (1.0)
t heRou ter UM L-A
UMGenerated
L-A
UMGenerated
L-A Association
Association
Generated
U ML-AU ML-A
Gen UM Class:aDifficiency
Class:aDifficiency
Association
erated
Gen
L-Aerated
Asso Association
Class:aDifficiency
Generated Association
(1.0) (1.0)
Association (1.
UM L-Aciatio
Asso
UM nciatio
Association
Cla
Generated
L-A ss:aD
n Cla
Generated ss:aD
ifficie
Class:aDifficiency
Association ncy
ifficie
A ncy
Association ssoci
A atio
sso
Class:aDiff
Clas
UM L-A Generated Association Class:aNavPoint Association (0.25) UM L-AUM L-A Genera
Generated ted AssociClass:aSu
Association ation C la
UM L-A Generated Association Class:aNavPoint Association (0.25)
UM L-A Generated Association Class:aW arehouse Association (0.5)
UMAssociation
L-A Generated UM L-A Generated
Association Association
Class:aNavPoint Class:aNavPoint
Association (0.25) Association (0.25)
UM L-A Generated Association Class:aW arehouse (1.0)
UM L-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)
availableVehicleCollection aRouteCollection
UM L-A Generated Dependency Class:theRouter Association (1.0)
UM L-A Generated Dependency Class:theRouter Association (0.5)
UM L-A Generated Association Class:theW arehouseCollection Dependency (0.5)
UM L-A Generated
UM L-ADependency
Generated Dependency
Class:theRouter
Class:theRouter
Association Association
(1.0) (1.0)

theCarg oRouter

UML -A Genera ted As socia tion C lass: theWa rehou seCo llectio n De pende ncy ( 0.25)
UM L-A Generated Association Class:aRoute Association (0.5)

theAWT aLocation
UM L-A Generated Association Class:theRouter Association (0.25)

UM Association
L-A Generated Association Class:aRoute Association (0.25)
UMUML-AL-A
UM L-A Generated
UM L-A Generated
Generated
Generated Association
Class:aNavPoint
Association
Association
Class:aRoute
Association
Class:aRoute
Class:aNavPoint
UM
Association
(0.5)
Association
L-A Generated
Association
(0.25)
(0.5) (0.25)
Association Class:aRoute Association (0.25)

aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog aNavPoint

UM L-A GeneratedUM L-A Generated
Association AssociationAssociation
Class:aNavPoint Class:aW arehouse
(0.5) Association (0.5)
UM L-A Generated Association Class:aW arehouse Association (0.5)

availableGoods aPortC ollec tion theTimeNeeded

UM L-A Generated
UM L-A Generated Association
Association Class:aWClass:aW
arehousearehouse Association
Association (0.5) (0.5)

UM L-A Generated Association Class:aW arehouse Association (0.5)

aPort aSurp lus aDifficiency

UM L-A Generated Association Class:aW arehouse Association (0.5)

UM L-A Generated
UMAssociation
L-A Generated
Class:availableGoods
Association Class:aW
Association
arehouse(0.5)
Association (0.5)

Sommerville, Mejia-Alvarez, 2009 theGoods

Software Engineering, Slide 6
 The Usual Tool: Design Abstraction

aTruck aAirplane aShip

aLocation

aVehicle

aNavPoint aRoute theVehicleCollection

theRouter
RegularStorage

aRouteCollection

theStorage availableVehicleCollection

aWarehous e
theWarehous eCollection

RefrigeratedStorage

aSurplus aDeficiency theCargoRouter

We have to do better!
theGoods theTim eNeeded
aRouterDialog
aPort theAWT

availableGoods

aPortDialog

aVehiceDialog
aWarehous eDialog
aPortCollection

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 7

 Architectural Abstraction
Cl o ck :
Cl o ck

8 : re q u e st

Cl o ckCo n n

9 : n oti fi ca ti o n 1 0 : no ti fi ca ti o n

Wa reh o u se De l i ve ryPo rt Ve h i cl e

7 : re q u e st

1 : re q u e st
4 : re q u e st 3 : re q u e st
Ro u te rCo n n

2 : n oti fi ca ti o n

Ca rgo Rou te r

5 : re q u e st

G ra p h i csCo n n

6 : n oti fi ca ti o n

G ra p h i csB i n d i n g :
G ra p h i csB i n d i n g

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 8

What is not Design
 Design is not programming.
 Design is not modeling. Modeling is part of the architectural
design.
 Design is not part of requirements.
 Where requirements finishes and where design starts ?.
 Requirements = What the system is supposed to do.
 Design = How the system is built.

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 9

 What is Design (or Architecture?)
 A high-level model of a software system
• Describes the structure, functionality and characteristics of the software
system.
• Understandable to many stakeholders
• Allows evaluation of the system’s properties before it is built
• Provides well understood tools and techniques for constructing the thing
from its blueprint
 A software system’s blueprint
• Its components
• Their interactions
• Their interconnections
 Which aspects of a software system are architecturally relevant?

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 10

 What is Design (or Architecture?)
 How should they be represented most effectively to enable
stakeholders to understand, reason, and communicate about a
system before it is built?
 What tools and techniques are useful for implementing an
architecture in a manner that preserves its properties?
 We design the software but we must consider the hardware (and the
environment).
 Design must reflect requirements, and we must be able to relate
each requirements with parts of the design.
 How can we include non-functional requirements into the design?

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 11

Stages of design
 Problem understanding
• Look at the problem from different angles to discover the
design requirements
 Identify one or more solutions
• Evaluate possible solutions and choose the most
appropriate depending on the designer's experience and
available resources
 Describe solution abstractions
• Use graphical, formal or other descriptive notations to
describe the components of the design
 Repeat process for each identified abstraction
until the design is expressed in primitive terms

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 12

From informal to formal design

Informal Informal More

design formal Finished
design design
outline design

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 13

The design process

 The system should be described at several

different levels of abstraction
 Design takes place in overlapping stages. It is
artificial to separate it into distinct phases but
some separation is usually necessary

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 14

 Phases in the design process
Requirements
specifica
tion

Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design

Software Data
System Interface Component Algorithm
specifica
tion structure
architectur
e specifica
tion specifica
tion specifica
tion
specification

Design pr
oducts

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 15

Design phases
 Architectural design Identify sub-systems
 Abstract specification Specify sub-systems
 Interface design Describe sub-system interfaces
 Component design Decompose sub-systems
into components
 Data structure design Design data structures to
hold problem data
 Algorithm design Design algorithms for problem
functions

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 16

From Requirements to Architecture
 From problem definition to requirements specification
• Determine exactly what the customer and user want
• Specifies what the software product is to do
 From requirements specification to architecture
• How do we plan to build (design) the system ?
• Decompose software into modules with interfaces
• Specify high-level behavior, interactions, and non-functional properties
• Consider key tradeoffs
» Schedule vs. Budget
» Cost vs. Robustness
» Fault Tolerance vs. Size
» Security vs. Speed
• Maintain a record of design decisions and traceability
• Specifies how the software product is to do its tasks (from design to programming).

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 17

Architectural design
 An early stage of the system design process.
 Represents the link between specification and design
processes.
 Where do we finish requirements and start design ?.
 Often carried out in parallel with some specification
activities.
 It involves identifying major system components and
their communications.

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 18

Advantages of explicit architecture
 From Requirements to Design
 Stakeholder communication
• Architecture may be used as a focus of discussion by system
stakeholders.
 System analysis
• Means that analysis of whether the system can meet its non-
functional requirements is possible.
 Large-scale reuse
• The architecture may be reusable across a range of systems.
 From Design to Programming ,Testing &
Mantenaince.

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 19

Architecture and system characteristics
How the system must be designed to achieve:

 Performance
 Security
 Safety
 Reliability
 Availability
 Maintainability
 Quality

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 20

Architectural design process
 System structuring
• The system is decomposed into several principal sub-systems
and communications between these sub-systems are identified
 Control modelling
• A model of the control relationships between the different parts
of the system is established
 Modular decomposition
• The identified sub-systems are decomposed into modules

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 21

Design quality
 Design quality is an elusive concept. Quality
depends on specific organisational priorities
 A 'good' design may be the most efficient, the
cheapest, the most maintainable, the most
reliable, etc.
 The attributes discussed here are concerned
with the maintainability of the design
 Quality characteristics are equally applicable to
function-oriented and object-oriented designs

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 22

Design principles

 Abstraction
 Modularity, coupling and cohesion
 Information hiding
 Limit complexity
 Hierarchical structure
 Understandability
 Adaptability

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 23

Abstraction
 procedural abstraction: natural consequence of
stepwise refinement: name of procedure denotes
sequence of actions

abstraction subproblems

time

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 24

Abstraction
 data abstraction: aimed at finding a hierarchy in
the data
application-oriented
data structures

simpler data
general structure
data structures

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 25

Modularity
 structural criteria which tell us something about
individual modules and their interconnections

 cohesion and coupling

 cohesion: the glue that keeps a module together

 coupling: the strength of the connection between

modules

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 26

Cohesion
 A measure of how well a component 'fits
together'
 A component should implement a single logical
entity or function
 Cohesion is a desirable design component
attribute as when a change has to be made, it
is localised in a single cohesive component
 Various levels of cohesion have been identified

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 27

Cohesion levels
 Coincidental cohesion (weak)
• Parts of a component are simply bundled together
 Logical association (weak)
• Components which perform similar functions are grouped
 Temporal cohesion (weak)
• Components which are activated at the same time are grouped
 Procedural cohesion (weak)
• The elements in a component make up a single control
sequence

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 28

Cohesion levels
 Communicational cohesion (medium)
• All the elements of a component operate on the same input or
produce the same output
 Sequential cohesion (medium)
• The output for one part of a component is the input to another part
 Functional cohesion (strong)
• Each part of a component is necessary for the execution of a single
function
 Object cohesion (strong)
• Each operation provides functionality which allows object attributes
to be modified or inspected

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 29

Cohesion as a design attribute
 Not well-defined. Often difficult to classify
cohesion
 Inheriting attributes from super-classes
weakens cohesion
 To understand a component, the super-classes
as well as the component class must be
examined
 Object class browsers assist with this process

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 30

Coupling
 A measure of the strength of the inter-connections
between system components
 Loose coupling means component changes are
unlikely to affect other components
 Shared variables or control information
exchange lead to tight coupling
 Loose coupling can be achieved by state
decentralisation (as in objects) and component
communication via parameters or message
passing

28
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 31
Tight coupling

Module A Module B

Module C Module D

Shared data
area

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 32

Loose coupling
Module A

A’s data

Module B Module C

B’s data C’s data

Module D

D’s data

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 33

Coupling and inheritance
 Object-oriented systems are loosely
coupled because there is no shared state and
objects communicate using message passing
 However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes. Such changes must be carefully
controlled

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 34

Information hiding
 each module has a secret
 design involves a series of decision: for each such
decision, wonder who needs to know and who can
be kept in the dark
 information hiding is strongly related to
• abstraction: if you hide something, the user may abstract from that
fact
• coupling: the secret decreases coupling between a module and its
environment
• cohesion: the secret is what binds the parts of the module together

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 35

Complexity
 measure certain aspects of the software (lines of
code, # of if-statements, depth of nesting, …)
 use these numbers as a criterion to assess a design,
or to guide the design
 interpretation: higher value  higher complexity
 more effort required (= worse design)
 two kinds:
• intra-modular: inside one module
• inter-modular: between modules

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 36

Top-down design
 In principle, top-down design involves starting
at the uppermost components in the hierarchy
and working down the hierarchy level by level
 In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience (and
sometimes components) during the design
process

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 37

Hierarchical design structure
System level

Sub-system
level

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 38

Understandability
 Related to several component characteristics
• Cohesion. Can the component be understood on its own?
• Naming. Are meaningful names used?
• Documentation. Is the design well-documented?
• Complexity. Are complex algorithms used?
 Informally, high complexity means many
relationships between different parts of the
design. hence it is hard to understand
 Most design quality metrics are oriented
towards complexity measurement. They are
of limited use

32
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 39
Adaptability
 A design is adaptable if:
• Its components are loosely coupled
• It is well-documented and the documentation is up to date
• There is an obvious correspondence between design levels
(design visibility)
• Each component is a self-contained entity (tightly cohesive)
 To adapt a design, it must be possible to trace the
links between design components so that change
consequences can be analysed

33
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 40
Design traceability
C
F
B
D Object interaction
A level

P O R
Object decomposition
level

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 41

Key points
 Design is a creative process
 Design activities include architectural design,
system specification, component design, data
structure design and algorithm design

36
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 42