Program Design
Ref: Whitten et all, Systems Analysis and Design Methods 7e. McGraw-Hill Higher Education
Mostafijur Rahman Akhond
Lecture, CSE
BRAC University
Outline
●Moving from logical to physical process models.
●Designing programs.
●Structure chart.
●Program specification.
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.
3
Steps to Create the Physical Data
Flow Diagram
4
Physical DFD Example
5
Logical to Physical dfd
Logical Model of the Promote Tunes Process
Physical Model for Promote Tunes Process
6
Structure Chart
▪ The structure chart is an Important program
design technique that help the analyst design
the program.
▪ It shows all the 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)
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.
8
Structure chart notions
9
Structure chart notions (2)
10
Revised Structure chart
11
12
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.
13
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.
● 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.
14
15
Cohesion Decision Tree
16
Create High 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.
17
Avoid High Fan-Out
• fan-in is call by other modules.
• fanout is call from that module.
• 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.
18
Examples of Fan-in and Fan-out
19
Check list for structure chart quality
20
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.
21
22
Pseudocode Example
23
Summery
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.
24
