



A data flow diagram (DFD) is a graphical
representation of the "flow" of data through an
information system.
A data flow diagram can also be used for the
visualization of data processing (structured
design).
It is common practice for a designer to draw a
context-level DFD first which shows the
interaction between the system and outside
entities.
This context-level DFD is then "exploded" to
show more detail of the system being modeled

There are only four symbols:
› Squares representing external entities, which are
sources or destinations of data.
› Rounded rectangles representing processes,
which take data as input, do something to it,
and output it.
› Arrows representing the data flows, which can
either be electronic data or physical items.
› Open-ended rectangles representing data
stores, including electronic stores such as
databases or XML files and physical stores such
as or filing cabinets or stacks of paper.



Data flow diagrams can be used to provide a
clear representation of any business function.
The technique starts with an overall picture of the
business and continues by analyzing each of the
functional areas of interest.
This analysis can be carried out to precisely the
level of detail required.





All processes must have at least one data
flow in and one data flow out.
All processes should modify the incoming
data, producing new forms of outgoing
data.
Each data store must be involved with at
least one data flow.
Each external entity must be involved with
at least one data flow.
A data flow must be attached to at least
one process.
Top-Down
Event
Approach
Partitioning
Approach

The system designer makes a context level DFD, which
shows the interaction (data flows) between the system
(represented by one process) and the system
environment (represented by terminators).

The system is decomposed in lower level DFD (Zero)
into a set of processes, data stores, and the data flows
between these processes and data stores.

Each process is then decomposed into an even lower
level diagram containing its sub processes.

This approach then continues on the subsequent sub
processes, until a necessary and sufficient level of
detail is reached which is called the primitive process
(aka chewable in one bite).
This approach was described by Edward
Yourdon in Just Enough Structured Analysis
 Construct detailed DFD.

› The list of all events is made.
› For each event a process is constructed.
› Each process is linked (with incoming data flows)
directly with other processes or via data stores,
so that it has enough information to respond to a
given event.
› The reaction of each process to a given event is
modeled by an outgoing data flow

As an aid in developing DFDs, consider
the following description of processing
steps.

Data flows and process consequences.
› Wherever we start in the process, we can
understand the processing steps that the
needed to take to complete the relevant
transaction(s) and to inform its constituents
of the results.

Data inputs and outputs.
› The DFD also makes it possible to understand
what data are needed to provide
appropriate inputs to any processing step.

Simplifying complexity by isolating
process components.
› The DFD would make it easier to capture the
detail of such data flows.
› At the time that DFDs were developed, this
shift towards modularizing data flows and
processing elements represented a major
step forward in enabling systems analysts to
add useful structure to process
representations rapidly and easily.
Illegal
data flows
Illegal data flows
DFDs are not flow charts




One of the patterns of data flow analysis is that all
flows must begin with or end at a processing step.
This makes sense, since presumably data cannot
simply metastasize on its own without being
processed (in spite of the circumstantial evidence
we might have gathered in our own business
experience...).
This simple rule means that the following mistakes
can be fairly easily identified and corrected in a
DFD.
The symbols shown on the next slide are
purposefully left blank (e.g., without captions) so
that it is easier for you to recognize patterns such
as these in your own DFDs.
A processing step may have input flows but
no output flows. This situation is sometimes
called a black hole .
 A processing step may have output flows
but now input flows. This situation is
sometimes called a miracle.
 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. This situation is sometimes referred to
as a grey hole.







Many of us have had prior experience developing flow
charts. Flow chart diagrams can be useful for describing
programming logic or understanding a single sequence of
process activities.
It is important to recognize, however, that DFDs are not
flow charts.
Flow charts often show both processing steps and data
"transfer" steps (e.g., steps that do not "process" data);
DFDs only show "essential" processing steps.
Flow charts might (indeed, often do) include arrows
without labels: DFDs never show an unnamed data flow.
Flow charts show conditional logic; DFDs don't (the
conditional decisions appear at lower levels, always within
processing steps).
Flow charts show different steps for handling each item of
data; DFDs might include several data items on a single
flow arrow.






ConceptDraw - Windows and MacOS X data flow
diagramming tool
Dia - Free source diagramming tool with flowchart
support
Kivio - Free source diagramming tool for KDE
Microsoft Visio - Windows diagramming tool which
includes very basic DFD support (Images only, does
not record data flows)
SILVERRUN ModelSphere - cross-platform tool for
business process modelling and data flow
diagramming
SmartDraw - Windows diagraming tool with "Yourdon
and Coad Process Notations" and "Gane and Sarson
Process Notation"
Data Flow Diagrams
 http://en.wikipedia.org/wiki/Data_flow_d
iagram
 Agile Modeling
 http://www.agilemodeling.com/artifacts
/dataFlowDiagram.htm
 EDrawSoft – Data Flow Diagrams
 http://www.edrawsoft.com/Data-FlowDiagrams.php

Data flows: Note on Data-Driven Process
Modeling
 http://faculty.babson.edu/osborn/mis75
20/readings/dfddiag.htm
