Data-Flow Oriented

Design

“From DFD to Structure Chart”

TCS2411 Software Engineering 1

 Expanding the DFD

Initial analysis produces the Context

Diagram and Level 1 DFD
In the design phase, the DFD is expanded
to lower levels, giving more sub-processes
within the original process
Level 1  Level 2  Level 3  …
Consistency is to be maintained from level
to level
TCS2411 Software Engineering 3
 Example of Level 1 DFD

application form
Member

Process
Application new member record

Members

TCS2411 Software Engineering 4

 Expanded to Level 2

Member Members
formatted
application
new member
form
record
Get Check Assign Prepare Format
Form Form Code Record Record
application checked new new
details application member member
details details record

TCS2411 Software Engineering 5

 Five-Step Process

The type of information flow is

established
Flow boundaries are indicated
The DFD is mapped into program
structure
Control hierarchy is defined by factoring
Resultant structure is refined using design
measures and heuristics
TCS2411 Software Engineering 6
 Types of Information
Flow
Transform Flow
Information enter at a point, transformed,
and exit at another point
Path: incoming flow  central transform 
outgoing flow
Transaction Flow
Single data item, transaction, triggers one of
many paths
Path: incoming flow  transaction centre 
action path
TCS2411 Software Engineering 7
 Transform Mapping

After transform flow is identified, identify

the boundaries of incoming and outgoing
flow
Incoming flow = Afferent flow
Outgoing flow = Efferent flow
In between the boundaries of the two is
the central transform

TCS2411 Software Engineering 8

 Example of Boundaries

Member Members
formatted
application
new member
form
record
Get Check Assign Prepare Format
Form Form Code Record Record
application checked new new
details application member member
details details record

Afferent flow Central Efferent flow

transform
TCS2411 Software Engineering 9
 First Level Factoring

Process
Membership
Application

Get Process Generate

Application Application New Member

TCS2411 Software Engineering 10

 Second Level Factoring

Process
Membership
Application

Get Process Generate

Application Application New Member

Get Generate Format

Check
Application New New
Application
Form Record Record

TCS2411 Software Engineering 11

 Refinement

The hierarchy produced is then refined to

improve the quality of the design
Modules could be exploded or imploded
Apply design concepts of module
independence, good cohesion, minimal
coupling, and ease of maintenance

TCS2411 Software Engineering 12

 Transaction Mapping

If transaction flow is identified, identify

the transaction centre and flow
characteristics of each action path
Similar to transform flow, boundaries are
identified for incoming flow and the
separate action paths
Each action path is a transform flow or
transaction flow as well
TCS2411 Software Engineering 13
 Example of Transaction
Flow

user commands action paths

read
user
command invoke
command
command
type processing

TCS2411 Software Engineering 14

 Transaction Mapping
transaction
control
a
reception
path
b b d dispatcher

d a c1

p p q

TCS2411 Software Engineering 15

 Factoring and Refining

Each action path has to be refined into a

substructure, either by transform or
transaction mapping
Similar to transaction flow, apply design
concepts to improve quality of design

TCS2411 Software Engineering 16

 Completing the
Structure Chart

For each data flow on the DFD add

exactly one data couple. Use the same
data flow name
For each control module, decide how it
will control subordinates
For modules that select one of several
paths, show selection logic with a
diamond attached to the link
TCS2411 Software Engineering 17
 Design Postprocessing

A processing narrative must be developed

for each module
Interface description is provided for each
module
Define local and global data structures
All design restrictions/limitations noted
Conduct design review
Optimisation is considered
TCS2411 Software Engineering 18
Rajib Mall

TCS2411 Software Engineering 19

Flow Chart Vs. Structure
Chart

A structure chart differs from a flow chart

in principal ways:
It is usually difficult to identify the different
modules of the software from its flow chart
representation.
Sequential ordering of tasks inherent in a
flow chart is suppressed in a structure chart.

TCS2411 Software Engineering 20

 Transformation of a DFD
into a Structure Chart

Structured design provides two strategies:

Transform Analysis
Transaction Analysis

TCS2411 Software Engineering 21

 Transform Analysis

Identifies the primary functional

components (modules) and the high level
inputs and outputs for these components.
The first step in transform analysis is to
divide the DFD into 3 types of parts:
Input
Logical processing
Output
TCS2411 Software Engineering 22
 Transform Analysis

Input portion of the DFD includes processes that

transform input data from physical to logical
form.
Each input portion is called an afferent branch.
Output portion of a DFD transforms output data
from logical to physical form.
Each output portion is called efferent branch.
The remaining portion of a DFD is called
central transform.
TCS2411 Software Engineering 23
 Transform Analysis

Next step of transform analysis, the structure

chart is derived by drawing one functional
component for the central transform, and the
afferent and efferent branches.
Identifying the highest level input and output
transforms requires experience and skill. One
possible approach is to trace the inputs until a
bubble is found whose output cannot be
deduced from its inputs alone.

TCS2411 Software Engineering 24
 Transform Analysis

Third step of transform analysis, the structure

chart is refined by adding sub-functions required
by each of the high-level functional components.
Many levels of functional components may be
added.
This process of breaking functional components
into subcomponents is called factoring.

TCS2411 Software Engineering 25

 For example
1-Level DFD for RMS

Four basic functions that the system needs to perform –

1. accept the input numbers from the user,
2. validate the numbers,
3. calculate the root mean square of the input numbers and,
4. then display the result.
TCS2411 Software Engineering 26
By applying the step 2
and step 3 of
transform analysis, we
get the structure chart
shown

TCS2411 Software Engineering 27

 Transaction Analysis

Transaction analysis is useful while

designing transaction processing
programs.
In a transaction-driven system, one of
several possible paths through the DFD is
traversed depending upon the input data
item.

TCS2411 Software Engineering 28

 Transaction Analysis
For each identified transaction, trace the input
data to the output.
All the traversed bubbles belong to the
transaction.
These bubbles should be mapped to the same
module on the structure chart.
In the structure chart, draw a root module and
below this module draw each identified
transaction a module.

TCS2411 Software Engineering 29

 Transaction Analysis

Every transaction carries a tag, which

identifies its type.
Transaction analysis uses this tag to
divide the system into transaction
modules and a transaction-centre module.

TCS2411 Software Engineering 30

 Transaction-centric module

TCS2411 Software Engineering 31

 References
“Software Engineering: A Practitioner’s
Approach” 5th Ed. by Roger S. Pressman,
Mc-Graw-Hill, 2001
“Software Engineering” by Ian Sommerville,
Addison-Wesley, 2001
“The Practical Guide to Structured Systems
Design” by Meilir Page-Jones,
Benjamin/Cummings, 1988

TCS2411 Software Engineering 32