1 Introduction to

Software Analysis & Design

Contents

• Overview

• Part I: Planning

• Part II: Analysis

• Part III: Design

• Part IV: Implementation & testing

Overview

• Nature of software design

– What is design?

– Objectives of the design activity

– Design as a wicked problem

• Rationale for methodology

– What is a software design methodology?

– Why are design methodologies needed?

– Problem domains and their influence

Part I: Planning

• Software design process

– Organizing the design process

– Constraints on the process
– Recording design decisions
– Designing in a team

• Design in the software development process

– Context for design

– Economic factors
– Software production strategies
– Prototyping roles and forms
Part II: Analysis

• Expressing ideas about design

– Representing abstract ideas

– Design viewpoints
– Forms of notation

• Design representations

– Pseudo code
– Jackson Structure Diagram (JSD)
– Data Flow Diagram (DFD)
– Entity-Relationship Diagram (ERD)
– Structure Chart
– State Transition Diagram (STD)
Part III: Design

• Design strategies

– Top-down strategies for design

– Design by composition (bottom-up)
– Organisational development of design
– Design by template and design re-use

• Jackson structured programming

• Structured analysis and design

• Object-oriented design

• Formal methods
Part IV: Implementation

• Design quality

– The quality concept

– Assessing design quality
– Quality attributes of the design
– Monitoring the design process
– Quality standards (ISO 9000, etc.)

• Testing

– White-box/black-box tests

– Integration and acceptance tests

Recommended text

Dennis et al.: Alan Dennis and Barbara Haley Wixom and

Roberta M. Roth, Systems Analysis and Design, New
York (NY): John Wiley & Sons, 3rd ed., 2005. [ISBN
0-471-72257-X] (£35)*

* price from Amazon, September 2006.

Recommended text

Dennis et al.: Alan Dennis and Barbara Haley Wixom and

Roberta M. Roth, Systems Analysis and Design, New
York (NY): John Wiley & Sons, 3rd ed., 2005. (£35)*

Further reading

Sommerville: Ian Sommerville, Software Engineering, 8th

ed., Harlow (UK): Addison-Wesley (Pearson Education),
2006. (£43)*

Pressman: Roger S Pressman, Software Engineering: a

practitioner’s approach, 6th ed., Maidenhead (UK): McGraw-
Hill, 2004. (£43)*

Budgen: David Budgen, Software Design, Wokingham (UK):

Addison-Wesley, 2nd ed., 2003. (£36)*

* prices from Amazon, September 2006.

Definitions

• A system: is one or more components identified to work

together to accomplish on or more things. Those components
may or may not be hardware, software, people, facilities, etc.
• For example, there can be a system to teach someone a
concept. The system exists whether there is anyone engaged
in it or not

• The software: is computer code that (a) may be part of a

system (or even more than one). It’s useless without computer
hardware
• Software may have systems within them or be systems
themselves
What is the difference between a system and a
software?

• A system is a broader concept that encompasses

multiple interrelated components, which can include
hardware, software, and other elements, working
together to achieve a specific purpose. It is a collection
of interconnected parts that function as a whole.

• In contrast, software refers to the programs,

applications, and instructions that run on a computer
system and provide specific functionalities. Software is a
component of a system, responsible for the logical
operations and data processing tasks
 The key differences between a system and software are:

• Scope: A system has a wider scope and can include both

hardware and software components, as well as other
elements like processes, people, and data. Software is a
specific component within a system, focused on the digital
aspects of the system.

• Functionality: A system is designed to perform a particular

set of tasks or fulfill a specific purpose, which may involve
multiple software components working together. Software,
on the other hand, is focused on providing a specific set of
functions or capabilities.
• Complexity: Systems can be highly complex, with
numerous interconnected parts and layers, while
software is typically more focused and specialized,
although it can also be complex depending on the
application. Interdependence: Systems rely on the
integration and coordination of various
components, including software, to operate
effectively. Software, in turn, depends on the
hardware and other system components to function
properly.

• In summary, a system is a broader and more

comprehensive concept that encompasses software
as one of its key components, along with other
hardware, procedures, and elements necessary to
achieve a specific goal or purpose
Nature of design
What is design?

• things are devised and created by man

– cars, houses, fridges, computer games, etc.

• they are typically designed and then made

– shoes that fit well (good design)

– flat roof that leaks (bad design)

• perception of importance of design varies

– well-proven design practices for bridges, planes, cars

– also important for clothes, furniture, etc.

• software design is equally important!

• software design is equally important:

– commercially influential, e.g. for a web browser

– safety critical, e.g. for fly-by-wire navigation

• consequences of unprincipled design:

– no clear idea of nature or purpose of design

– unstructured and piecemeal result

• design is not only factor, implementation matters too:

– good design can be marred by bad implementation;

– whereas, poor design is hard to recover. . . !

• Software design uses general concepts of design:

“The fundamental problem is that designers are

obliged to use current information to predict a fu-
ture state that will not come about unless their
predictions are correct. The final outcome of de-
signing has to be assumed before the means of
achieving it can be explored: the designers have
to work backwards in time from an assumed ef-
fect upon the world to the beginning of a chain of
events that will bring the effect about.” [Jones,
Designing Methods: Seeds of Human Futures.]

• design differs from the scientific method:

– scientific analysis usually leads to one solution

– design can produce many possible solutions

 external requirements
initial observations
1
1 Formalise
Conduct requirements
experiment requirement specification
systematic observations 2
2 Analyse
Construct requirements
theory functional specification
theoretical predictions 3
3 Construct
Devise design
experiments design model mismatches
experimental results new predictions 4
4 Validate
Refine model
theory logical design
formalised model 5
5 Elaborate
Derive design
scientific design blueprints
principles
6
Implement
solution

Nature of scientific progress (left); model of the design process (right).

Prototyping

• Prototyping a design:

– propose a solution

– build a model of the solution

– evaluate the model against the original requirements

– elaborate it into a detailed description of the solution

“If, as is likely, the act of tracing out the interme-

diate steps exposes unforeseen difficulties or sug-
gests better objectives, the pattern of the original
problem may change so drastically that the de-
signers are thrown back to square one.” [Jones.]
Moving house
• Problem:
kitchen living room
Where to put furniture? bedroom 1

– identify optimum dis- cloak

hall
tribution of furniture in room

new house. bedroom 2

bathroom
• Strategies:
– group furniture by
• Constraints:
function, then match
– Functional: fridge in
groups to rooms
kitchen, sofa in lounge.
(top-down)
– Aethetic: colour, pat-
– locate key furniture in
tern, style, etc.
its best place, then
– Utilitarian: power out-
continue piece by piece
lets, natural light —
(bottom-up)
Oops! needs extension
• Solution: to our model. . .
a series of compromises
 1.2 Objectives of the design activity

• A shared blueprint for implementation:

– e.g., room plan of furniture for removal men, circuit

diagram, component plan for PCB, etc.

• Overview of software development process:

Requirements
Analysis

Functional
Specification

Design

Implementation
(coding)

Testing

Software development lifecycle, ‘waterfall’ model.

Software development lifecycle

1. Planning (Requirements analysis) identifies what is

needed from a system.

2. Analysis (Functional specification) states precisely

what the system must do to meet its requirements.

3. Design describes how the system is to perform its

tasks, so as to meet the specification.

4. Implementation and Testing translate the design into

computer code, and validate that it conforms with
the original requirements, specification and design.
 1.3 Software design

“How a system is structured, including specification of the

interfaces between components”

• Software-design strategy: overall plan and direction for

performing a design

• Software-design concept: fundamental idea applied to

designing a system

• Software-design notation: a means of describing a soft-

ware design

• Software-design methodology: systematic approach for

creating a design.
Approach, Representation and Process

• Software-design strategy:
overall plan and direction for performing a design
– e.g., functional decomposition

• Software-design concept:
fundamental idea applied to designing a system
– e.g., information hiding

• Software-design notation:
a means of describing a software design:
– graphical, symbolic, textual

• Software-design methodology:
systematic approach for creating a design.
– describes sequence of steps to follow.
 1.4 Software development lifecycle

1. Planning

2. Analysis

3. Design

4. Implementation & testing

 1.4 Software development lifecycle

1. Planning (requirements analysis and specification): de-

scribing completely the system’s external behaviour

2. Analysis (architectural or logical design): structuring

problem into its components, according to design method-
ology, e.g.

• decomposition into tasks and modules

• synthesis of coherent functional units

• sequencing of behavioural elements

3. Design (detailed or physical design)

4. Implementation & testing

 1.4 Software development lifecycle

1. Planning (requirements analysis and specification)

2. Analysis (architectural or logical design)

3. Design (detailed or physical design): designing of al-

gorithmic detail of each component, using a program
design language (e.g., pseudo code, structured English)

4. Implementation & testing: conversion into program-

ming language, and validation,

• unit testing

• integration (or system) testing

• acceptance testing
How Design differs from Analysis and Implementation

• Design phase should produce the plans for software pro-

duction to proceed – the system blueprints

• Extent of these plans is governed by the size of project

(larger projects require greater detail)

• Blueprints determine the form of design output:

– static system structure, with hierarchy of modules

– algorithms to be used

– data objects to be used

– interfaces and relationships between components

– packaging of the system (how components are grouped)

System blueprints

• They also include details of the implementation process:

– order of development for modules and subprograms

– strategy for their integration into complete system

A software engineer designs a system: its structure, be-

haviour and function, modelled by design representations
State Transition
Diagram (STD)

Entity Relationship Data Flow

Diagram (ERD) Diagram (DFD)

Design model

Design models: ERD, STD and DFD.

1.5 Design as a problem-solving process

• Purpose of design is simply to produce a solution to a

problem, summarised by the requirements specification

• It is the designer’s task to provide a description of how

the requirements will be met

• So, the design process is a problem-solving task, but

not an analytical (formulaic) one:

– series of trade-offs (speed, size, ease of adaptation)

– evaluation of different options and selection accord-

ing to rational criteria
• Design methods help guide the decisions:

– abstraction removes detail, while retaining essential

structure

– abstraction enables designer to concentrate on high-

level features of problem without worrying about im-
plementation detail

• Abstraction is key to modular design, e.g. functionality

of home-entertainment system:

– to play CD/DVD/MP3/TV
– to decode any RF signal or stored media
– to filter and amplify the signals
– to play through the screen & loudspeakers

By treating components abstractly, we can separate the

functionality wherever possible and simplify the design.
 1.6 Design as a wicked problem

• A wicked problem is one whose form is such that a

solution for one aspect reveals an even more complex
problem beneath.

• First arose in the analysis of social planning problems

(1984) – urban renewal and demolition of communities,
replaced by high rise flats.

• Four characteristics of wicked problems:

1. There is no definitive formulation. Often under-

standing of a problem is bound up with ideas on how
to solve it – not enough separation of specification
and design.
 2. No stopping rule. No way to tell when a solution has
been reached. Lack of a measure to determine that
the best solution has been achieved.

3. Solutions are not ‘true’ or ‘false’; only ‘good’ or

‘bad’. This is unlike many scientific or classic en-
gineering problems, which have analytical solutions.

4. Resolving one discrepancy in a design may pose a

new one. For instance, a data structure that helps
resolve one problem may present problems elsewhere.

• Software system maintenance: adding an innocuous

feature may require major re-design of internal data
structures and functions
e.g., HTML browsing with flash or voice XML
 1 Summary of the Introduction

• Nature of design

• Overview of software design

• Software lifecycle:

– planning

– analysis

– design

– implementation

• Design as a problem-solving process

• Design as a wicked problem