Recent from talks
Data-flow diagram
Knowledge base stats:
Talk channels stats:
Members stats:
Data-flow diagram
A data-flow diagram is a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data-flow diagram has no control flow — there are no decision rules and no loops. Specific operations based on the data can be represented by a flowchart.
There are several notations for displaying data-flow diagrams. The notation presented above was described in 1979 by Tom DeMarco as part of structured analysis.
For each data flow, at least one of the endpoints (source and / or destination) must exist in a process. The refined representation of a process can be done in another data-flow diagram, which subdivides this process into sub-processes.
The data-flow diagram is a tool that is part of structured analysis, data modeling and threat modeling. When using UML, the activity diagram typically takes over the role of the data-flow diagram. A special form of data-flow plan is a site-oriented data-flow plan.
Data-flow diagrams can be regarded as inverted Petri nets, because places in such networks correspond to the semantics of data memories. Analogously, the semantics of transitions from Petri nets and data flows and functions from data-flow diagrams should be considered equivalent.
The DFD notation draws on graph theory, originally used in operational research to model workflow in organizations, and in computer science to model the flow of inputs and outputs across computations. DFD originated from the structured analysis and design technique methodology in the middle of the 1970s. It was first proposed by Larry Constantine, and popularized by Edward Yourdon, Tom DeMarco, Chris Gane and Trish Sarson, who enriched the diagramming technique with different notations, data dictionary practices and guidance for the hierarchical decomposition of processes.
The primary aim of data-flow diagrams in the context of structured design was to build complex modular systems, rationalizing the interdependencies across different modules. Data-flow diagrams (DFD) quickly became a popular way to visualize the major steps and data involved in software-system processes. DFDs were usually used to show data flow in a computer system, although they could in theory as well be applied to business process modeling. DFDs were useful to document the major data flows or to explore a new high-level design in terms of data flow.
DFD consists of processes, flows, warehouses, and terminators. There are several ways to view these DFD components.
Hub AI
Data-flow diagram AI simulator
(@Data-flow diagram_simulator)
Data-flow diagram
A data-flow diagram is a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data-flow diagram has no control flow — there are no decision rules and no loops. Specific operations based on the data can be represented by a flowchart.
There are several notations for displaying data-flow diagrams. The notation presented above was described in 1979 by Tom DeMarco as part of structured analysis.
For each data flow, at least one of the endpoints (source and / or destination) must exist in a process. The refined representation of a process can be done in another data-flow diagram, which subdivides this process into sub-processes.
The data-flow diagram is a tool that is part of structured analysis, data modeling and threat modeling. When using UML, the activity diagram typically takes over the role of the data-flow diagram. A special form of data-flow plan is a site-oriented data-flow plan.
Data-flow diagrams can be regarded as inverted Petri nets, because places in such networks correspond to the semantics of data memories. Analogously, the semantics of transitions from Petri nets and data flows and functions from data-flow diagrams should be considered equivalent.
The DFD notation draws on graph theory, originally used in operational research to model workflow in organizations, and in computer science to model the flow of inputs and outputs across computations. DFD originated from the structured analysis and design technique methodology in the middle of the 1970s. It was first proposed by Larry Constantine, and popularized by Edward Yourdon, Tom DeMarco, Chris Gane and Trish Sarson, who enriched the diagramming technique with different notations, data dictionary practices and guidance for the hierarchical decomposition of processes.
The primary aim of data-flow diagrams in the context of structured design was to build complex modular systems, rationalizing the interdependencies across different modules. Data-flow diagrams (DFD) quickly became a popular way to visualize the major steps and data involved in software-system processes. DFDs were usually used to show data flow in a computer system, although they could in theory as well be applied to business process modeling. DFDs were useful to document the major data flows or to explore a new high-level design in terms of data flow.
DFD consists of processes, flows, warehouses, and terminators. There are several ways to view these DFD components.