Lecture 11: DFD Refinement

CSC212A Software Development Fundamentals

Course Leader(s):
Sahana.P.Shankar
sahana.cs.et@msruas
Ms. Supriya, M. S.
[email protected]

1
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Lecture Objectives

At the end of this lecture, student will be able to

–Identify data flow and sub processes of software using Data Flow Diagrams
(DFDs)
–Identify various elements of DFDs
–Model the data flow in software with the DFDs
–Develop DFDs for the given problem

2
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Lecture Topics

• Analysis vs Design
• Structured Analysis
• Guidelines for DFD refinement
• Notations in DFD
• Possible errors in design
• Criteria for stopping refinement

3
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Analysis and Design
• Analysis
–The act of defining what an application will do
• What objects does the system manipulate?
• What functions must the system perform?
• What behaviors does the system exhibit?
• What interfaces are defined?
• What constraints apply?

• Design
–The act of defining how the requirements defined during
analysis will be implemented in a specific
hardware/software environment
4
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Structured Analysis
• A set of techniques and graphical tools that allow the analyst
to develop a new kind of system that is understandable to the
user

• Use graphical diagrams to develop and portray system

specifications that are easily understood by users
–Describe the steps that need to occur and the data
required to meet the design function of a particular
software

• Mainly focuses on logical systems and functions

5
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 The Data Flow Hierarchy

6
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Guidelines for Creating DFDs
• The level 0 data flow diagram should depict the software or
system as a single bubble
• Primary input and output should be carefully noted
• Refinement should begin by isolating candidate processes,
data objects, and data stores to be represented at the next
level
• Information flow continuity must be maintained from one
level to another level
• One bubble at a time should be refined
• If a bubble does a number of different things, it needs further
refinement
• All arrows and bubbles should be labeled with meaningful
names 7
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Guidelines for Creating DFDs
• The names of data stores, sources, and
destinations are written in capital letters
• Process and data flow names have the first letter
of each word capitalized
• When a process is exploded into lower level
details, they are numbered
• Processes need to have at least one input data flow and one
output data flow
• Each child diagram should have the same input and output data
flow as the parent process
- Vertical balancing - A child diagram cannot produce output or receive
input that the parent process does not also produce or receive
8
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Guidelines for Creating DFDs contd.

• Data flows should not split into two or more different flows
• All data flows must either originate or terminate at a process
• Avoid crossing data flow lines by repeating data stores and
external entities

9
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Numbering of Bubbles

• Necessary to number the different bubbles occurring in the

DFD
• The bubble at the context level is usually assigned the
number 0
• Baubles at level 1 are numbered,1, 2,etc.
• Processes on the child diagram are numbered using the
parent process number, a decimal point, and a unique
number for each child process
• When a bubble numbered x is decomposed, its children
bubbles are numbered x.1, x.2, x.3, etc.

10
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 When to Stop The Decomposition

• Each process is a single decision or calculation or a single

database operation, such as retrieve, update, create, delete or
read
• Each data store represents data about a single entity such as a
customer, employee, product or order
• The system user does not care to see any more detail
• Every data flow does not need to be split further to show that
different data are handled in different ways

11
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Data Flow Diagram - Example
A high-level data-flow diagram for the library problem

12
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Data Flow Diagramming Mistakes
Illegal data flows: all flows must begin with or end at a
processing step.

13
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Data Flow Diagramming Mistakes

• DFD mistakes arise when the outputs from one processing

step do not match its inputs
–Black hole - a processing step may have input flows but no
output flows
–Miracle - a processing step may have output flows but no
input flows
–Grey hole - a processing step may have outputs that are
greater than the sum of its inputs - e.g., Its inputs could not
produce the output shown
• By tracing the inputs and outputs affecting each processing
step, you can avoid them in your own diagrams

14
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Summary
• A Data Flow Diagram (DFD) is a graphical representation of the
"flow" of data through an information system
• Primary input and output from level 0 should be carefully
noted
• Refinement should begin by isolating candidate processes
and all related entities, data objects, data stores and data
flows to be represented at the next level
• One bubble at a time should be refined
• If a bubble does a number of different things, it needs further
refinement

15
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences