Encompassing the Whole World Front Page /// Categories /// Site Index

Data Flow Diagram

A data flow diagram is a partitioning tool used for structured system analysis and design. It is used for making logical models of systems prior to updating them, and for graphically mapping the changes you are going to make.

This sort of diagram follows the data throughout it's lifetime, noting where it is changed, stored and retrieved, but from the data's perspective.

It is a vastly misunderstood diagram, which contrary to what some people believe says absolutely nothing about how the processing is serialised, or if it is realtime at one extreme or batch processing at the other.

In fact when looking at the logical model, such implementational details should have dissappeared into the detail, and be hidden by the various abstractions used.

A Data Flow Diagram consists of four fundamental elements:
1.Data Flows, data structures in motion
2.Data Stores, files or databases for data structures at rest
3.Processes, internal processes within the system which transform data
4.Sources and Sinks, external processes which send or receive data from processes in the system, but whose scope is outside the domain of interest

Data flows along data flows, between processes, sometimes being stored for later retrieval by another process, and only processess can access file stores. The obvious method of looking at these data structures is by means of something called a Data Structure Diagram, often stored in a Data Dictionary so that you can use a computer to help organise and optimise these structures.

As you can probably guess, the difference between a process and a source or sink is highly dependent on where you define the edge of the interesting part of the system to be, and it is not unusual for there to be movement between these statuses.

Process descriptions can have a number of forms.

Two related forms which they can take are as decision trees, or as decision tables, and these could often be implemented as executable specifications using Expert Systems.

Another form they can take are as one page "Structured English" descriptions, which can at low levels be nearly equivalent to Pseudocode, and therefore is relatively simple to turn into a Flowgraph.

The other possible representation is as a lower level, more detailed Data Flow Diagram. This can completely replace the process it describes, and as you can imagine, things get very big and complex very fast.

This naturally resolves into partitioning the diagram into multiple levels, rather than having the massive football pitch sized drawing, and rebalancing the levels if the details require a sufficient repartitioning.

See also Data Flow Diagramming for a more detailed explanation of the methods of dfd's.

link back to site index