Jump to content

Data-flow diagram

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Antonielly (talk | contribs) at 12:32, 24 April 2009 (Undid vandalism by 122.168.24.182 (talk)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Data Flow Diagram example.[1]

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 the timing or ordering 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).

Overview

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 invented 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, defining different visual representations for processes, data stores, data flow, and external entities.[3]

Developing a data-flow diagram

data-flow diagram example
data-flow diagram - Yourdon/DeMarco notation

Top-Down Approach

  1. The system designer makes "a context level DFD" or Level 0, which shows the "interaction" (data flows) between "the system" (represented by one process) and "the system environment" (represented by terminators).
  2. The system is "decomposed in lower-level DFD (Level 1)" into a set of "processes, data stores, and the data flows between these processes and data stores".
  3. Each process is then decomposed into an "even-lower-level diagram containing its subprocesses".
  4. This approach "then continues on the subsequent subprocesses", until a necessary and sufficient level of detail is reached which is called the primitive process (aka chewable in one bite).

DFD is also a virtually designable diagram that technically or diagrammatically describes the inflow and outflow of data or information that is provided by the external entity.

Event Partitioning Approach

Event partitioning was described by Edward Yourdon in Just Enough Structured Analysis.[4]

  1. Construct detailed data-flow diagram.
    1. The list of all events is made.
    2. For each event a process is constructed.
    3. 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.
    4. The reaction of each process to a given event is modeled by an outgoing data flow.

Data flow diagram levels

Context Level Diagram

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.[5]

Level 1 (High Level Diagram)

A Level 1 Data flow diagram for the same system.

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 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, e.g. the "enquiry" data flow could be spilt into "enquiry request" and "enquiry results" and still be valid.[5]

Level 2 (Low Level Diagram)

A Level 2 Data flow diagram showing the "Process Enquiry" process for the same system.

This level is a decomposition of a process shown in a level-1 diagram, as such there should be a level-2 diagram for each and every process shown in a level-1 diagram. In this example processes 1.1, 1.2 & 1.3 are all children of process 1, together they wholly and completely describe process 1, and combined must perform the full capacity of this parent process. As before, a level-2 diagram must be balanced with its parent level-1 diagram. [5]

See also

References

  1. ^ John Azzolini (2000). Introduction to Systems Engineering Practices. July 2000.
  2. ^ W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
  3. ^ How to draw Data Flow Diagrams
  4. ^ Yourdon, Edward. Just Enough Structured Analysis., Chapter 19
  5. ^ a b c Denis Wixom Roth (2005). Systems Analysis & Design. 3rd Edition. Wiley Higher Education.

Further reading

Wikimedia Commons has media related to Data flow diagrams.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Data-flow_diagram&oldid=285842865"