History of the DFD
Data flow diagrams were popularized in the late 1970s by computing pioneers Ed Yourdon and Larry Constantine in their book, Structured Design. They based it on the "data flow graph" computation models by David Martin and Gerald Estrin. Both the structured design concept and the DFD method gained widespread adoption in the software engineering and business fields.
Three other experts contributing to this rise in DFD methodology were Tom DeMarco, Chris Gane, and Trish Sarson. They teamed up in various combinations to serve as the primary definers of the symbols and notations used for a data flow diagram.
Symbols and notations used in DFDs
You’ll want to orient yourself with the different data flow diagram symbols before you start. Because there are some symbol variations between systems, the important thing is to be clear and consistent in the shapes and notations you use when communicating and collaborating with others.
Using any convention's DFD rules or guidelines, the symbols depict the four components of data flow diagrams:
1. External entity
An external entity is a system that sends or receives data and communicates with the system being diagrammed. They are the sources and destinations of information entering or leaving the system. They might be an outside organization or person, a computer system, or a business system. They are also known as terminators, sources and sinks, or actors. They are typically drawn on the edges of the diagram.
2. Process
Processes change data and produce an output. They might perform computations, sort data based on logic, or direct data flow according to business rules. A short label is used to describe a process (e.g., "Submit payment").
3. Data store
Data stores are files or repositories that hold information for later use (e.g., a database table or a membership form). Each data store receives a simple label (e.g., "Orders").
4. Data flow
Data flow describes the route that data takes between external entities, processes, and data stores. It portrays the interface between the other components and is shown with arrows, typically labeled with a short data name (e.g., "Billing details").
DFD rules and tips
All data flow diagrams have certain rules to keep in mind:
-
Each process should have at least one input and one output.
-
Each data store should have at least one data flow in and one data flow out.
-
Data stored in a system must go through a process.
-
All processes in a DFD go to another process or a data store.
DFD levels and layers: From context diagrams to pseudocode
A data flow diagram can dive into progressively more detail by using levels and layers, zeroing in on a particular piece. DFD levels are numbered 0, 1, or 2, and occasionally go to even Level 3 or beyond. The necessary level of detail depends on the scope of what you are trying to accomplish.
DFD Level 0
A DFD Level 0 is also called a context diagram. It's a basic overview of the whole system or process being analyzed or modeled. It's designed to be an at-a-glance view, showing the system as a single high-level process and its relationships with external entities. It should be easily understood by a wide audience, including stakeholders, business analysts, data analysts, and developers.
