Aim

To Familiarize the Participants with

Data Flow Diagrams (DFD)
 Data Flow Diagram (DFD)- Introduction
• DFD is a system modelling tool, the most popular and
important representation in data flow modelling.
• DFD allows us to picture a system as a network of
functional processes, connected to one another by
“pipelines” and “holding tanks "of data.
• In DFD, functions of the system are of paramount
importance. DFD is function-oriented.
• DFD is simple but powerful technique which are easily
understood
• You can also call DFD as: bubble chart, bubble diagram,
process model, work flow diagram
 The Basic Building Blocks of a DFD
• Process (a bubble, a function or a transformation) –
how inputs are transformed or changed into outputs
• Data Flow – used to describe the movement of data or
physical materials from one part of the system to another part. It
represents data or physical
materials in motion.
• Data Store – it is used to model a collection of data packets
at rest. (files, tapes, punched cards, etc.)
• External Entity (Terminator)
– Entities external to the system, with which the system
communicates.
They are outside the control of the system that is being modeled.
It may
also be another system.
 Process
• Presentation:
– A process is represented graphically as a
circle. Other alternative includes a rectangle
with rounded edges.
• Naming:
– The process name will describe what the
process does. A good name will generally
consist of a verb-object phrase such as
VALIDATE INPUT or COMPUTE TAX RATE.
 Data Flow
• Representation: – it is presented graphically by an
arrow into or out of a process.
• Naming:
– the name represents the meaning of the packet that moving
along the flow.
– The flow carries only one type of packet. But it is sometimes
useful to consolidate several elementary data flows into a
consolidated flow. E.g., a single dataflow labeled VEGETABLES
instead of several different data flows labeled POTATOES,
CUCUMBERS,
SPROUTS, and PEAS.
 Data Flow
• Features of a Data Flow:
– it shows direction: an arrowhead at either end of the flow (or
possibly at both ends) indicates whether data (or material) are
moving into or out of a process (or doing both).
– For single direction flow, data moving along the flow will either
travel to another process (as an input) or to a store or a terminator.
PHONE NUMBER VALIDATE
PHONE
NUMBER
An input flow
GENERATE
TRUCKER
DELIVERY
SCHEDULE
An output flow
TRUCKER
 Data Store
• Representation:
• – it is represented by two parallel lines. There are also other alternatives.
• Naming:
• – The name chosen to identify the store is the plural of the name of the
• packets that are carried by flows into and out of the store.
• Purpose:
• – the store exists as a necessary time-delayed storage area between two
• processes that occur at different times.
• – Some stores are implementation store.
• • as intermediate file
• • as backup mechanism
• • as testing and debugging facility
• • as an anticipation of future user needs
 Data Store
• Features:
• – a data store is one of the following:
• a flow from a store : read or access to info in the store
• a flow to a store: write, update or possibly a delete.
• – the store is changed as a result of the flow entering
the store. It is the process (or processes) connected to
the other end of the flow that is responsible for making
the change to the store.
• – flows connected to a store can only carry packets of
information that the store is capable of holding.
 External Entity/Terminator
• Representation:
• – it is graphically represented as a rectangle.
• • Features:
• – Outside the system we are modelling; the flows connecting the
• terminators to various processes (or stores) in our system represent
• the interface between our system and the outside world.
• – As a consequence, system designer are not in a position to change
• the contents of a terminator or the way the terminator works.
• – Any relationship that exists between terminators will not be shown
• in the DFD model.
 Constructing DFD Guidelines
• • Choose meaningful names for processes, flows, stores, and
• terminators.
• – Processes: use specific verb+object, avoid using “elastic” verbs like
• do, handle, etc.
• – avoid using abbreviation.
• – avoid using programming-oriented terminology as “ROUTINE”,
• “PROCEDURE” and “FUNCTION”.
• • Number the processes
• – be consistent in numbering
• – numbering scheme has nothing to do with sequence of execution. It
• should be served as a convenient way of referring to the processes.
• More importantly, the numbers become the basis for a hierarchical
• numbering scheme in leveled DFDs.
 Constructing DFD Guidelines
• Avoid overly complex DFDs
• – DFD should be readily understood, easily absorbed, and pleasing to
• the eye
• – do not create a DFD with too many processes (usually 3-8
• processes in a level), flows, stores, and terminators.
• • Redraw DFDs as many times as necessary
• – redrawn again and again until it is (1) technically correct, (2)
• acceptable to the user, and (3) neatly enough. Develop an accurate,
• consistent, esthetically pleasing model.
• • Make sure DFDs are logically consistent
• – Avoid “black holes”: processes have inputs but no outputs.
• – Avoid “miracles”: processes having outputs but no inputs, are
• suspicious, and generally incorrect. (random-number generator is
• an exception.)
 Constructing DFD Guidelines
• Make sure DFDs are logically consistent
• – Beware of unlabeled flows and unlabeled
processes.
• – Beware of read-only or write-only stores
 Leveled DFD
• Organize the overall DFD in a series of levels so that each
• level provides successively more detail about a portion of
• the level above it.
• – Context Diagram: The top-level DFD is context diagram consisting
• of only one process, representing the entire system; It shows the
• interfaces between the system and the external entities.
• – Level 0: Immediately beneath the context diagram is the highestlevel
• view of the major functions within the system, as well as the
• major interfaces between those functions.
• – The numbers serve as a convenient way of relating a process to the
• next lower level DFD, which should be numbered for convenient
• reference.
 Some principles of levelling DFDs
• Each DFD figure should have no more than 8 or 9 processes and
• related stores. The number of level and partition should be based on
• the above principle.
• • The number of levels is dependent on system complexity.
• • Complexity of each level may not be the same. Some can be more
• complex than other levels.
• – Make sure that the levels of DFDs are consistent with each other: the
• data flow coming into and going out of a process at one level must
• correspond to the data flows coming into and going out of an entire
• figure at the next lower level which describe that process. (see Figure
• 9.22(b): A balanced DFD fragment and Figure 9.22(a): A DFD
• fragment that is out of balance.).
• – Show a store at the highest level where it first serves as an interface
• between two more processes; then show it again in EVERY lowerlevel
• diagram that further describe (or partitions) those interface
• bubbles. (see Figure 9.23: Showing stores at lower levels)
 Some Common Mistakes
• Process Errors
• – Process that have no outputs (a black hole)
• – Processes that have no inputs (a miracle)
• – The label should be a verb phrase
• • Data Store Errors
• – Data stores never be read and written to throughout all level of
figures
• – The label should be a noun phrase
• • External Entity Errors
• – Un-connected external entities
• – Data move directly from a entity to another entity
• – The label should be a noun phrase
 Some Common Mistakes
• Data Flow Errors
• – A data flow cannot be two direction of flow between symbols
• – A fork/join in a data flow should be exactly the same
• – A data flow cannot go directly back to same process it leaves
• – Having no source
• – Having no destination
• – The label should be a noun phrase
• • Connection Errors
• – Data cannot move directly from store to external entity
• – Data cannot move directly from a data store to another data
store