 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 Approach  Event 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  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 ConceptDraw  Dia - Free source diagramming tool with flowchart support Dia  Kivio - Free source diagramming tool for KDE Kivio  Microsoft Visio - Windows diagramming tool which includes very basic DFD support (Images only, does not record data flows) Microsoft Visio  SILVERRUN ModelSphere - cross-platform tool for business process modelling and data flow diagramming SILVERRUN  SmartDraw - Windows diagraming tool with "Yourdon and Coad Process Notations" and "Gane and Sarson Process Notation" SmartDraw

 Data Flow Diagrams  iagram iagram  Agile Modeling  /dataFlowDiagram.htm /dataFlowDiagram.htm  EDrawSoft – Data Flow Diagrams  Diagrams.php Diagrams.php

 Data flows: Note on Data-Driven Process Modeling  20/readings/dfddiag.htm