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
