ITU07203: Systems Analysis and

Design II

Chapter 10. Program Design

Dr. Tinabo
 Key Definitions
Program design - creating
instructions for the programmers
The top-down, modular approach -
begin with the “big picture” and
gradually add detail
Program design document – all
structure charts and specifications
needed by programmers to
implement the system
 MOVING FROM LOGICAL TO
PHYSICAL PROCESS MODELS
Analysis phase – focus on logical
processes and data flows
Design phase – create physical
process models showing “how” the
final system will work
Physical process models convey the
“system view” of the new system
 The Physical Data Flow Diagram
The physical DFD contains the same
components as the logical DFD, and
the same rules apply (e.g. balancing,
decomposition, etc.)
There are five steps to perform to
make the transition to the physical
DFD
Steps to Create the Physical Data Flow Diagram
The Physical Data Flow Diagram (The How)
 Designing Programs
Resist temptation to write code too
quickly
System quality is enhanced with top-
down modular design
Advantage of modular design
– code that is easier to understand, is reusable, has
less redundancy, and is easier to maintain
Using a Top-Down Modular Approach
 Designing Programs
 Start with defined overall program at a high level
by using the Structure Chart diagram.
- Illustrates the organization and interactions of
the different pieces of code within the program.
 Then Program specifications are written to
describe exactly what needs to be included in
each program module
- include basic module information(e.g., a name)
– special instructions for the programmer,
– and Pseudocode: similar to structured English
 Designing Programs
Program design document is the final
deliverable for this task
- which includes all of the structure charts and
program specifications that will be used to
implement the system
– Used by programmers to write code
 The Structure Chart
 Starts from the physical process models
 Shows all components of code in a hierarchical
format
– Sequence (in what order components are invoked)
– Selection (under what condition a module is
invoked)
– Iteration (how often a component is repeated)
Structure Chart Example
Structure Chart Elements
 Building the Structure Chart
 Processes in the DFD tend to represent one
module on the structure chart
– Afferent processes – provide inputs to system
– Central processes – perform critical system operations
– Efferent processes – handle system outputs
 The DFD leveling can correspond to the structure
chart hierarchy (e.g., the process on the context-level DFD
would correspond to the top module on the structure chart)
 Types of Structure Charts
Transaction structure – control
module calls subordinate modules,
each of which handles a particular
transaction
– Few afferent processes
– Many efferent processes
– Higher up levels of structure chart
– Coordinating the production of outputs
Transaction Structure
 Transform Structure
This structure has a control module
that calls several subordinate
modules in sequence after which
something “happens.”
These modules are related because
together they form a process that
transforms some input into an
output.
Transform Structure
Transform versus Transaction Structures
 Steps in Building the Structure
Chart
1. Identify top level modules and decompose
them into lower levels
2. Add control connections (loops, conditional lines,
etc.)
3. Add couples (identify the information that has to
pass among the modules i.e. data couple and control
couple)
4. Review and revise again and again until
complete
 Design Guidelines
High quality structure charts result in
programs that are modular, reusable
and easy to implement.
Measures include:
– Cohesion
– Coupling
– Appropriate levels of fan-in and fan-out
 Cohesion
 Cohesion refers to how well the lines of code
within each structure chart module relate to
each other
 Ideally, a module should perform only one
task, making it highly cohesive
 Cohesive modules are easy to understand and
build because their code performs one
function
Types of Cohesion (GPA = grade point average)
 Cohesion Decision Tree
(Adopted From Page-Jones, 1980)
 Factoring
Process of dealing with “low”
cohesion
Separates tasks into different
modules
Reduces use of control flags
 For example, a more cohesive design for the print
grade listing and dean’s list example would be to
factor out print dean’s list and print grade listing
into two separate modules.
 Coupling
 Coupling involves how closely modules are
interrelated.
 The second guideline for good structure chart
design states that modules should be loosely
coupled
– In this way, modules are independent from each
other, which keeps code changes from rippling
throughout the program
Types of Coupling
 Your Turn
What, if anything, happens to
coupling when you create modules
that are more cohesive?
What, if anything happens to the
cohesiveness of modules when you
lower the coupling among them?
 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 very good situation because high fan-in indicates that a
module is reused in many places on the structure chart, which
suggests that the module contains well-written generic code
 Avoid High Fan-out
Although we desire a subordinate to have
multiple control modules, we want to
avoid a large number of subordinates
associated with a single control
There is a limit to the number of employees
that a boss can effectively manage
The general rule of thumb is to limit a
control module’s subordinates to
approximately seven
Examples of Fan-in and Fan-out
 Quality Checklist
1. Library modules have been created where ever possible
2. The diagram has a high fan-in structure
3. Control modules have no more than 7 subordinates
4. Each module performs only one function (high cohesion)
5. Modules sparingly share information (loose coupling)
6. Data couples that are passed are actually used by the accepting
module
7. Control couples are passed from “low to high”
8. Each module has a reasonable amount of code associated with it
 Program Specifications Content
 Written documents that describe exactly what
needs to be included in each program module
 No standard approach
 Include program information
 Note events that trigger actions
 List inputs and outputs (identified by the data
couples and control couples)
 Include Pseudocode
 Present additional notes and comments
Program Specification Form
Pseudocode Example
Process Description – Analysis and
Design
 Summary
 The structure chart shows all of the functional
components needed in the program at a high
level. Components of the structure chart
show sequence, selection, and iteration
 Follow design guidelines regarding cohesion,
coupling, and fan-in/fan-out.
 Prepare detailed specifications to
programmers including pseudocode to show
important programming structures.