Program Design 2
Program Design 2
OBJECTIVES
• MO
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.
The Design Process
• Any design may be modelled 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.
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
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.
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 be;
• How the modules interact with one-another
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
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
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
Sub-system
level
Top-down Design