Lecturer: Sebastian Coope
Ashton Building, Room G.18
E-mail: coopes@liverpool.ac.uk
COMP 201 web-page:
http://www.csc.liv.ac.uk/~coopes/comp201
http://www.csc.liv.ac.uk/~pbell/comp201.html
Lecture 13 – Design Methodology
•COMP201 - Software Engineering
•1
Software Design
Deriving a solution which satisfies
software requirements
•COMP201 - Software Engineering
•2
Software Design
 Why
 Software is produced by many people
 Software needs to be





Simple
Understandable
Flexible
Portable
Re-usable
 How
 Complex to simple
 Abstraction
•COMP201 - Software Engineering
•3
Software Design in Reality
 Design mixed with implementation
 Design step 1
 Implement and add more design
 Design step 2
 Implement and add more design
 In effect much of software is designed while coded and the
design document doesn’t reflect the final product
•COMP201 - Software Engineering
•4
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.
•COMP201 - Software Engineering
•5
The Design Process
 Any design may be modeled as a directed graph made up
of entities with attributes which participate in
relationships.
 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.
•COMP201 - Software Engineering
•6
Phases in the Design Process
Re quire me nts
spec ifica
tion
De sign acvities
ti
Arc hite ctur
al
design
Abstra ct
spec ifica
tio
n
Interfa ce
design
Component
design
Data
structur
e
design
Algorithm
design
Syste m
a rc hite ctur
e
Softwa re
spec ifica
tion
Interfa ce
spec ifica
tion
Component
spec ifica
tion
Data
structur
e
spec ifica
tion
Algorithm
spec ifica
tion
De sign pr
oducts
•COMP201 - Software Engineering
•7
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.
•COMP201 - Software Engineering
•8
Design
 Computer systems are not monolithic: they are usually
composed of multiple, interacting modules.
 Modularity has long been seen as a key to cheap, high
quality software.
 The goal of system design is to decode:
 What the modules are;
 What the modules should do;
 How the modules interact with one-another
•COMP201 - Software Engineering
•9
Modular Programming
 In the early days, modular programming was taken to
mean constructing programs out of small pieces:
“subroutines”
 But modularity cannot bring benefits unless the modules
are
 autonomous,
 coherent and
 robust
•COMP201 - Software Engineering
•10
Procedural Abstraction
 The most obvious design methods involve functional
decomposition.
 This leads to programs in which procedures represent
distinct logical functions in a program.
 Examples of such functions:
 “Display menu”
 “Get user option”
 This is called procedural abstraction
•COMP201 - Software Engineering
•11
Programs as Functions
 Another view is programs as functions:
input
output
x  f  f (x)
the program is viewed as a function from a set I of legal
inputs to a set O of outputs.
 There are programming languages (ML, Miranda, LISP)
that directly support this view of programming
Well-suited to certain
application domains
- e.g., compilers
Less well-suited to distributed, nonterminating systems
- e.g., process control systems, operating
systems like WinNT, ATM machines
•COMP201 - Software Engineering
•12
Object-Oriented Design
• The system is viewed as a collection of interacting objects.
• The system state is decentralized and each object manages
its own state.
•Note , use of internal state against functional programming
• Objects may be instances of an object class and
communicate by exchanging messages.
•COMP201 - Software Engineering
•13
Five Criteria for Design Methods
 We can identify five criteria to help evaluate modular design
methods:
 Modular decomposability;
 Modular composability;
 Modular understandability;
 Modular continuity;
 Modular protection.
•COMP201 - Software Engineering
•14
Modular Decomposability
 Modular decomposability - this criterion is met by a
design method if the method supports the decomposition
of a problem into smaller sub-problems, which can be
solved independently.
 In general, this method will be repetitive: sub-problems
will be divided still further
 Top-down design methods fulfil this criterion; stepwise
refinement is an example of such a method
•COMP201 - Software Engineering
•15
Hierarchical Design Structure
System level
Sub-system
level
•COMP201 - Software Engineering
•16
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.
•COMP201 - Software Engineering
•17
An Example of Top-Down Design
• Imagine designing a word processor program from
scratch. What subsystems could be initially found at the top
level?
• File I/O, printing, graphical user interface, text processing
etc.
• For each of these components we can then decompose
further, i.e., File I/O comprises of saving documents and
opening documents..
•COMP201 - Software Engineering
•18
Modular Composability
 Modular composability - a method satisfies this criterion if
it leads to the production of modules that may be freely
combined to produce new systems.
 Composability is directly related to the issue of reusability
 Note that composability is often at odds with
decomposability; top-down design,
 for example, it tends to produce modules that may not
be composed in the way desired
 This is because top-down design leads to modules which
fulfil a specific function, rather than a general one
•COMP201 - Software Engineering
•19
Examples
 The Numerical Algorithm Group (NAG) libraries contain a
wide range of routines for solving problems in linear
algebra, differential equations, etc.
 The Unix shell provides a facility called a pipe, written “|”,
whereby
 the standard output of one program may be redirected
to the standard input of another; this convention
favours composability.
•COMP201 - Software Engineering
•20
Modular Understandability
 Abstraction
 int A=21
 int age_in_years = 21;
print_out_document(Document d)
 Modular Understandability - a design method satisfies this
criterion if it encourages the development of modules which
are easily understandable.
 COUNTER EXAMPLE 1. Take a thousand lines program,
containing no procedures; it’s just a long list of sequential
statements. Divide it into twenty blocks, each fifty
statements long; make each block a method.
 COUNTER EXAMPLE 2. “Go to” statements.
•COMP201 - Software Engineering
•21
Modular Understandability
• Related to several component characteristics
– Can the component be understood on its own?
– Are meaningful names used?
– Is the design well-documented?
– Are complex algorithms used?
• Informally, high complexity means many relationships
between different parts of the design.
•COMP201 - Software Engineering
•22
Modular Continuity
 Modular continuity - a method satisfies this criterion if it
leads to the production of software such that a small
change in the problem specification leads to a change in
just one (or a small number of ) modules.
 EXAMPLE. Some projects enforce the rule that no
numerical or textual literal should be used in programs:
only symbolic constants should be used
 COUNTER EXAMPLE. Static arrays (as opposed to dynamic
arrays) make this criterion harder to satisfy.
•COMP201 - Software Engineering
•23
Modular Protection
 Modular Protection - a method satisfied this criterion if it
yields architectures in which the effect of an abnormal
condition at run-time only effects one (or very few)
modules
 EXAMPLE. Validating input at source prevents errors from
propagating throughout the program (design by contract)
 COUNTER EXAMPLE. Using int types where subrange or
short types are appropriate.
•COMP201 - Software Engineering
•24
A Real Life Example – Ariane 5 Flight 501
 The failure of an Ariane 5 space launcher is possibly the
most expensive software bug in history at around $370
million.
 Other bugs have been even worse by causing loss of life,
for example Therac-25 radiation machines.
•COMP201 - Software Engineering
•25
The Ariane 5 Space Launcher
 While developing the Ariane 5 space launcher, the designers
reused a component (the inertial reference software) which
was successfully used in the Ariane 4 launcher
 This component failed 37 seconds into the flight and the
ground crew had to instruct the launcher to self-destruct.
 The error was caused by an unhandled numerical conversion
exception causing a numeric overflow.
 Component reuse is usually a good thing but care must be
taken that assumptions made when the component was
developed are still valid!
•COMP201 - Software Engineering
•26
Repository Models
 Sub systems making up a system must exchange and share data
so they can work together effectively.
 There are two main approaches to this:
 The repository model – All shared data is held in a central database
which may be accessed by all sub-systems
 Each sub-system or component maintains its own database. Data is
then exchanged between sub-systems via message passing.
 There are advantages and disadvantages to each approach as we
shall now see.
•COMP201 - Software Engineering
•27
Repository Model
 The advantages include:
 Databases are an efficient way to share large amounts of data and
data does not have to be transformed between different subsystems (they agree on a single data representation).
 Sub-systems producing data need not be concerned with how that
data is used by other sub-systems.
 Many standard operations such as backup, security, access control,
recovery and data integrity are centralised and can be controlled
by a single repository manager.
 The data model is visible through the repository schema.
•COMP201 - Software Engineering
•28
Repository Model
 The disadvantages include:
 Sub-systems must agree on the data model which means
compromises must be made, for example with performance.
 Evolution may be difficult since a large amount of data is generated
and translation may be difficult and expensive.
 Different systems have different requirements for security,
recovery and backup policies which may be difficult to enforce in a
single database.
 It may be difficult to distribute the repository over a number of
different machines.
•COMP201 - Software Engineering
•29
Lecture Key Points
 We have studied five criteria to help evaluate modular design
methods and their advantages:
 Modular decomposability; modular composability; modular
understandability; modular continuity; modular protection.
 We have seen the advantages and the disadvantages of
repository models
•COMP201 - Software Engineering
•30