Scribd
Upload
67 views22 pages

Program Design 2

Uploaded by

Justin William
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
67 views22 pages

Program Design 2

Uploaded by

Justin William
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 22

PROGRAM DESIGN

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

Well-suited to certain application Less well-suited to distributed, non-terminating systems


domains - e.g., compilers - e.g., process control
systems, operating systems like WinNT, ATM machines
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.
– Objects may be instances of an object class
and communicate by exchanging methods.
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.
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 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 method
Hierarchical Design Structure
System level

Sub-system
level
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.
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, 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
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.
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.
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.
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 open
arrays) make this criterion harder to satisfy.
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.
• COUNTER EXAMPLE. Using int types where subrange or short
types are appropriate.

You might also like