Systems Analysis and Design
5th Edition
Program Design
Alan Dennis, Barbara Haley Wixom, and Roberta Roth
© Copyright 2011 John Wiley & Sons, Inc. 10-1
Chapter 10 Outline
Moving from logical to physical
process models.
Designing programs.
Structure chart.
Program specification.
© Copyright 2011 John Wiley & Sons, Inc. 10-2
INTRODUCTION
Program design – Analysts determine what programs will
be written and create instructions for the programmers.
Various implementation decisions are made about the
new system (e.g., what programming language(s) will be
used.)
The DFDs created during analysis are modified to show
these implementation decisions, resulting in a set of
physical data flow diagrams.
The analysts determine how the processes are organized,
using a structure chart to depict the decisions.
Detailed instructions called program specifications are
developed.
© Copyright 2011 John Wiley & Sons, Inc. 10-3
Steps to Create the Physical Data
Flow Diagram
© Copyright 2011 John Wiley & Sons, Inc. 10-4
Example of Physical DFD
© Copyright 2011 John Wiley & Sons, Inc. 10-5
Logical Model of the Promote Tunes Process
Physical Model for Promote Tunes Process
STRUCTURE CHART
The structure chart is an Important program
design technique that help the analyst design the
program.
It shows all components of code in a hierarchical
format that implies
– Sequence (in what order components are invoked),
– Selection (under what condition a module is invoked),
– Iteration (how often a component is repeated)
10-7
An academic system needs a program that will print a listing of students along
with their grade point averages (GPAs), both for the current semester and overall.
First, the program must retrieve the student grade records; then it must calculate
the current and cumulative GPAs; finally, the grade list can be printed.
© Copyright 2011 John Wiley & Sons, Inc. 10-8
a programmer can tell that there are four
main code modules involved in creating a
student grade listing: getting the student
grade records, calculating current GPA,
calculating cumulative GPA, and printing the
listing. Also, there are various pieces of
information that are either required by each
module or created by it (e.g., the grade
record, the cumulative GPA).
© Copyright 2011 John Wiley & Sons, Inc. 10-9
Syntax of Structure Chart
© Copyright 2011 John Wiley & Sons, Inc. 10-10
(cont’d)
© Copyright 2011 John Wiley & Sons, Inc. 10-11
(cont’d)
Revised structure chart example
© Copyright 2011 John Wiley & Sons, Inc. 10-12
© Copyright 2011 John Wiley & Sons, Inc. 10-13
Design Guidelines
High quality structure charts result in
programs that are modular, reusable, and
easy to implement.
Measures of good design include
– cohesion,
– appropriate levels of fan-in and fan-out.
© Copyright 2011 John Wiley & Sons, Inc. 10-14
Build Modules with High Cohesion
Cohesion refers to how well the lines
of code within each module relate to
each other.
Cohesive modules are easy to
understand and build because their
code performs one function
effectively.
© Copyright 2011 John Wiley & Sons, Inc. 10-15
(cont’d)
There are various types of cohesion.
Functional cohesion – all elements of the
modules contribute to performing a single task.
Temporal cohesion – functions are invoked at
the same time.
Coincidental cohesion – there is no apparent
relationship among a module’s functions.
© Copyright 2011 John Wiley & Sons, Inc. 10-16
(cont’d)
© Copyright 2011 John Wiley & Sons, Inc. 10-17
Cohesion Decision Tree
© Copyright 2011 John Wiley & Sons, Inc. 10-18
Fan-In
Fan-in describes the number of control
modules that communicate with a
subordinate.
A module with high fan-in has many
different control modules that call it. This is
a good situation because high fan-in
indicates that a module is reused in many
places on the structure chart.
© Copyright 2011 John Wiley & Sons, Inc. 10-19
Fan-Out
A large number of subordinates associated with a
single control should be avoided.
The general rule of thumb is to limit a control
module’s subordinates to approximately seven
for low fan-out.
fanin is call by other modules.
– Create High Fan-In
fanout is call from that module.
– Avoid High Fan-Out
© Copyright 2011 John Wiley & Sons, Inc. 10-20
Examples of Fan-in and Fan-out
© Copyright 2011 John Wiley & Sons, Inc. 10-21
Assess the Chart for Quality
Check list for structure chart quality
© Copyright 2011 John Wiley & Sons, Inc. 10-22
PROGRAM SPECIFICATION
Program Specifications are documents that include
explicit instructions on how to program pieces of code.
There is no formal syntax for program specification.
Four components are essential for program
specification:
- Program information;
- Events;
- Inputs and outputs; and
- Pseudocode – a detailed outline of lines of code that
need to be written.
Additional notes and comments can also be included.
© Copyright 2011 John Wiley & Sons, Inc. 10-23
Program specification form
© Copyright 2011 John Wiley & Sons, Inc. 10-24
© Copyright 2011 John Wiley & Sons, Inc. 10-25
(cont’d)
Pseudocode Example
© Copyright 2011 John Wiley & Sons, Inc. 10-26
SUMMARY
Moving from logical to physical process models.
- Physical DFDs show implementation details.
Structure chart.
- The structure chart shows all of the functional
components needed in the program at a high level.
Building structure chart.
- Module, control connection, couples, review.
Structure chart design guidelines.
- Cohesion, coupling, and fan-in/fan-out.
Program specifications.
- Program specifications provide more detailed
instructions to the© programmers.
Copyright 2011 John Wiley & Sons, Inc. 10-27
