A 

data flow diagram (DFD) is a graphical representation of the "flow" of data through an information
system. DFDs can also be used for the visualization of data processing (structured design).

On a DFD, data items flow from an external data source or an internal data store to an internal data
store or an external data sink, via an internal process.

A DFD provides no information about the timing of processes, or about whether processes will
operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow
of control through an algorithm, allowing a reader to determine what operations will be performed, in
what order, and under what circumstances, but not what kinds of data will be input to and output from
the system, nor where the data will come from and go to, nor where the data will be stored (all of
which are shown on a DFD).

Contents

1 Overview

2 Developing a data flow diagram

o 2.1 Event partitioning approach

 2.1.1 Level 1 (high level

diagram)

 2.1.2 Level 2 (low level

diagram)

3 See also

4 Notes

5 Further reading

6 External links

[edit]Overview

Data flow diagram example.

Data flow diagram -Yourdon/DeMarco notation.

It is common practice to draw a context-level data flow diagram first, which shows the interaction
between the system and external agents which act as data sources and data sinks. On the context
diagram (also known as the 'Level 0 DFD') the system's interactions with the outside world are
modelled purely in terms of data flows across the system boundary. The context diagram shows the
entire system as a single process, and gives no clues as to its internal organization.

This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some of the detail of
the system being modeled. The Level 1 DFD shows how the system is divided into sub-systems
(processes), each of which deals with one or more of the data flows to or from an external agent, and
which together provide all of the functionality of the system as a whole. It also identifies internal data
stores that must be present in order for the system to do its job, and shows the flow of data between
the various parts of the system.

Data flow diagrams were proposed by Larry Constantine, the original developer of structured design,
[2]
 based on Martin and Estrin's "data flow graph" model of computation.

Data flow diagrams (DFDs) are one of the three essential perspectives of the structured-systems
analysis and design method SSADM. The sponsor of a project and the end users will need to be
briefed and consulted throughout all stages of a system's evolution. With a data flow diagram, users
are able to visualize how the system will operate, what the system will accomplish, and how the
system will be implemented. The old system's dataflow diagrams can be drawn up and compared with
the new system's data flow diagrams to draw comparisons to implement a more efficient system. Data
flow diagrams can be used to provide the end user with a physical idea of where the data they input
ultimately has an effect upon the structure of the whole system from order to dispatch to report. How
any system is developed can be determined through a data flow diagram.

In the course of developing a set of levelled data flow diagrams the analyst/designers is forced to
address how the system may be decomposed into component sub-systems, and to identify
the transaction data in the data model.
There are different notations to draw data flow diagrams (Yourdon & Coad and Gane & Sarson[3]),
defining different visual representations for processes, data stores, data flow, and external entities.[4]

[edit]Developing a data flow diagram

[edit]Event partitioning approach
Event partitioning was described by Edward Yourdon in Just Enough Structured Analysis.[5]

A context level Data flow diagram created using Select SSADM.

This level shows the overall context of the system and its operating environment and shows the whole
system as just one process. It does not usually show data stores, unless they are "owned" by external
systems, e.g. are accessed by but not maintained by this system, however, these are often shown as
external entities.[6]

Number the Processes As a convenient way of referencing the processes in a DFD, most systems
analysts number each bubble. It doesn’t matter very much how you go about doing this — left to right,
top to bottom, or any other convenient pattern will do -- as long as you are consistent in how you
apply the numbers. The only thing that you must keep in mind is that the numbering scheme will
imply, to some casual readers of your DFD, a certain sequence of execution. That is, when you show
the DFD to a user, he may ask, “Oh, does this mean that bubble 1 is performed first, and then bubble
2, and then bubble 3?” Indeed, you may get the same question from other systems analysts and
programmers; anyone who is familiar with a flowchart may make the mistake of assuming that
numbers attached to bubbles imply a sequence. This is not the case at all. The DFD model is a
network of communicating, asynchronous processes, which is, in fact, an accurate representation of
the way most systems actually operate. Some sequence may be implied by the presence or absence
of data (e.g., it may turn out that bubble 2 cannot carry out its function until it receives data from
bubble 1), but the numbering scheme has nothing to do with this. So why do we number the bubbles
at all? Partly, as indicated above, as a convenient way of referring to the processes; it’s much easier
in a lively discussion about a DFD to say “bubble 1” rather than “EDIT TRANSACTION AND REPORT
ERRORS.” But more importantly, the numbers become the basis for a hierarchical numbering scheme
when we introduce leveled dataflow diagrams in Section 9.3.

[edit]Level 1 (high level diagram)

This level (level 1) shows all processes at the first level of numbering, data stores, external entities
and the data flows between them. The purpose of this level is to show the major and high-level
processes of the system and their interrelation. A process model will have one, and only one, level-1
diagram. A level-1 diagram must be balanced with its parent context level diagram, i.e. there must be
the same external entities and the same data flows, these can be broken down to more detail in the
level 1, example the "enquiry" data flow could be split into "enquiry request" and "enquiry results" and
still be valid.[6] This is all about using your creativity. So why do we number the bubbles at all? Partly,
as indicated above, as a convenient way of referring to the processes; it’s much easier in a lively
discussion about a DFD to say “bubble 1” rather than “EDIT TRANSACTION AND REPORT
ERRORS.”
[edit]Level 2 (low level diagram)