Data flow diagram
|It has been suggested that Physical Data Flow be merged into this article. (Discuss) Proposed since February 2014.|
|This article provides insufficient context for those unfamiliar with the subject. (July 2014)|
A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an information system, modelling its process aspects. A DFD is often used as a preliminary step to create an overview of the system, which can later be elaborated. DFDs can also be used for the visualization of data processing (structured design).
A DFD shows what kind of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of process or information about whether processes will operate in sequence or in parallel (which is shown on a flowchart).
Data flow diagrams were proposed by Larry Constantine, the original developer of structured design, based on Martin and Estrin's "Data Flow Graph" model of computation. Starting in the 1970s, data flow diagrams (DFD) became a popular way to visualize the major steps and data involved in software system processes. DFDs were usually used to show data flows in a computer system, although they could in theory be applied to business process modeling. DFD were useful to document the major data flows or to explore a new high-level design in terms of data flow.
It is common practice to draw the context-level data flow diagram first, which shows the interaction between the system and external agents which act as data sources and data sinks. This helps to create an accurate drawing in the context diagram. 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 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 model.
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.
Data flow diagrams can be used in both Analysis and Design phase of the SDLC.
There are different notations to draw data flow diagrams (Yourdon & Coad and Gane & Sarson), defining different visual representations for processes, data stores, data flow, and external entities.
Physical DFDA physical DFD shows how the system is actually implemented, either at the moment (Current Physical DFD), or how the designer intends it to be in the future (Required Physical DFD). Thus, a Physical DFD may be used to describe the set of data items that appear on each piece of paper that move around an office, and the fact that a particular set of pieces of paper are stored together in a filing cabinet. It is quite possible that a Physical DFD will include references to data that are duplicated, or redundant, and that the data stores, if implemented as a set of database tables, would constitute an un-normalised (or de-normalised) relational database. In contrast, a Logical DFD attempts to capture the data flow aspects of a system in a form that has neither redundancy nor duplication.
|This article possibly contains original research. (August 2014)|
- Activity diagram
- Business Process Model and Notation
- Control flow diagram
- Data island
- Directed acyclic graph
- Functional flow block diagram
- Function model
- Logical Data Flow
- Structured Analysis and Design Technique
- Structure chart
- System context diagram
- John Azzolini (2000). Introduction to Systems Engineering Practices. July 2001.
- Bruza, P. D., Van der Weide, Th. P., "The Semantics of Data Flow Diagrams", University of Nijmegen, 1993.
- W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
- Craig Larman, "Applying UML and Patterns", Pearson Education, ISBN 978-81-7758-979-5
- Chris Gane and Trish Sarson. Structured Systems Analysis: Tools and Techniques. McDonnell Douglas Systems Integration Company, 1977
- How to draw Data Flow Diagrams
|40x40px||Wikimedia Commons has media related to Data flow diagrams.|
- DFD Template in Visio
- Yourdon/DeMarco and Gane & Sarson DFDs
- Case study "Current physical dataflow diagram for Acme Fashion Supplies" ..and accompanying elementary process descriptions
- "Yourdon's chapter on DFDs"
- Example of using presentation "DataFlow PowerPoint Diagram"