A Case for Data Flow Diagrams
Time to Read 4 min
Do you need a quick overview of a complex system? Do you frequently have to explain the functionality of a system? Do you face the task of developing a system from scratch and are not sure about which architecture is the best? Do you need to replace an old system without documentation? In all these cases, data flow diagrams can assist you and help you to simplify communication with other people involved.
Data flow diagrams have sunk into oblivion
Data flow diagrams were defined over 40 years ago as part of the then popular structured analysis (e.g. by Tom DeMarco). Structured analysis uses data flow diagrams to analyze business requirements and map them into software (SW).
With the appearance of object oriented analysis (OOA) and the therein used unified modeling language (UML), data flow diagrams got less important. A big part of this disappearance is because UML does not use pure data flow diagrams. You usually get the advice to simply draw a UML activity diagram, but this diagram type primarily shows the control flow of a software. Additionally, it allows to indicate data flows. However, this mixture of control flow and data flow can make it hard to focus on the essentials when analyzing and designing a new system.
Advantages of data flow diagrams
Using pure data flow diagrams during the early stages of system design has many advantages:
- Simple notation allows discussion with all relevant people
- Quick identification of functionality
- Simplified partitioning of hardware and software
- SW partitioning into different (interrupt) execution contexts
- Better identification of interfaces
- Optimization of redundant processing steps
- Independence from implementation
Data flow diagrams have hardly evolved in the last 40 years. Particularly, no standard notation has been established. However, the basic structures of data flow diagrams are so simple that they are usually understood without further explanation. Hint: Make sure to add a legend and / or a data dictionary to your diagram in order to leave no room for interpretation.
Data flow diagrams consist of the following elements:
- Processing functions (Process)
- Storage / databases (Data Store)
- Start / end points (External Entity)
- Data flow arrows (Flow)
Some common notations can be found in the following table: