Data Flow Diagrams
Data Flow Digrams / DFD, Tom De Marco, Visual Paradigm
Data Flow Diagrams / Notation, Method, Architecture
Recently, especially in the context of GDPR (General Data Protection Regulation), data flow diagrams have become popular again. Often such notations are used without knowledge of origins and rules. That gives away a great deal of knowledge, leads to bad and poorly maintainable models. Therefore, here are some basics described and some hints to literature.
Data flow diagrams are supported, for example, by the Visual Paradigm tool.
2 Data Flow Diagrams / Elements of the Notation
Data flow diagrams represent simple elements. The DFD palette is clear:
According to the book (De Marco 1979) DFD know the following elements and links
- Data flows
- Data sources and data sinks (Data Sources, Data Sinks)
Figure 1 shows the DFD palette of Visual Paradigm.
The palette in Visual Paradigm is not identical to the notation of Tom De Marco. DFD is not a standard notation. The representation in Visual Paradigm does not differ essentially from (De Marco 1979). A detailed description of the elements and attributes in Visual Paradigm can be found in the Visual Paradigm User Guide (Visual Paradigm, Inc. 2019).
It is advisable to inform yourself about the elements and possible links before using DFDs.
An (external) entity is a human being, a system or subsystem. It represents a source or a sink of data (data source, data sink). An entity is always external to the process or system of interest.
A process describes a business activity or function that manipulates data.
A data store represents the storage of persistent data that is consumed or produced in processes.
The data flow shows the transfer of information. It is directed or bi-directional.
A DFD is a network of a system or object of interest that generates or consums information. The goal of DFDs was (is) a meaningful partitioning of the area of interest (process, system) to us.
3 Data Flow Diagrams / Method
The definition of DFD in (De Marco 1979) includes not only the description of the elements used, but also the application of a notation. Our goal is the uniform application of the notation by all project participants. Often we describe this in a style guide and a modeling guideline that provides guidance and assistance with the application.
When defining the notation elements, we already some hints. For example: "An entity is always external."
Thie book by Tom De Marco provides a number more hints fort he moment. Important and interesting for me are the following points:
- DFDs have different levels of abstraction. In (De Marco 1979) Tom De Marco describes in Chapter 7: "Leveled Data Flow Diagrams".
- Tom De Marco describes the application of the DFDs for the system specification or the implementation of "Data Dictionaries".
- De Marco describes the connection to structured English. See my white paper on "Textual Analysis."
(De Marco 1979) also gives suggestions and examples for naming notation elements.
4 Data Flow Diagrams, other notations, Architecture
A common use of DFDs is the representation of the interrelationship of information with processes and systems in the context of the GDPR (General Data Protection Regulation). How is the information used, where does it come from, where is it stored and transfered to other systems or processes described. We extend the description of the notation element with information as to whether data is relevant for data protection. In the case of persistent storage, we collect information such as the duration of storage.
As an alternative to DFDs, notations such as Archimate® are used.
Interesting is the description of Decision Tables and Decision Trees in De Marco. For the description of decision tables and decision trees, the OMG standard notation DMN (Decision Model and Notation) (DMN 1.2 2019) is usually used today. Since the OMG standard notations usually contain no statements and recommendations for the use, it pays off to look into books such as (De Marco 1979).
Depending on the project order, we use further notations and describe the relations between the types of representations used (which models and model elements are linked, what type of relationships do exist?). For example, we use DFD to further detail business processes using BPMN and CMMN.
Marco, Tom. Structured Analysis and System Specification. New York, N.Y.: Prentice-Hall, 1979.
DMN 1.2. Decision Model and NotationTM. OMG, 2019.
Visual Paradigm, Inc. Visual Paradigm User Guides. 03 2019. https://www.visual-paradigm.com/support/documents (Zugriff am 30. 03 2019).
This material may be used freely on an in-house, non-commercial basis. Commercial re-use or re-transmission of any portion of this material is prohibited without written permission of Dr. Juergen Pitschke, BCS - Dr. Juergen Pitschke. Contact BCS - Dr. Juergen Pitschke for licensing and re-use arrangements. Please include this notice in all reproduction.