Graphical representation of a process, such as a manufacturing operation or a computer operation, indicating the various steps taken as the product moves along the production line or the problem moves through the computer. Individual operations can be represented by closed boxes, with arrows between boxes indicating the order in which the steps are taken and divergent paths determined by variable results.
Learn more about flowchart with a free trial on Britannica.com.
Data flow diagrams were invented by Larry Constantine, the original developer of structured design, based on Martin and Estrin's "data flow graph" model of computation.
Data flow diagrams (DFDs) are one of the three essential perspectives of 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 dataflow 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 dataflow diagrams to draw comparisons to implement a more efficient system. Dataflow 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 recook. How any system is developed can be determined through a dataflow diagram.
There are different notations to draw data flow diagrams, defining different visual representations for processes, datastores, dataflow, and external entities.
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.
This level 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 0 diagram. A level 0 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 0, e.g. the "enquiry" data flow could be spilt into "enquiry request" and "enquiry results" and still be valid.
This level is a decomposition of a process shown in a level 0 diagram, as such there should be a level 1 diagram for each and every process shown in a level 0 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 1 diagram must be balanced with its parent level 0 diagram.