Content deleted Content added
Line 1:
{{Short description|Graphical representation of the "flow" of data through an information system}}
[[File:Data-flow-diagram-example.svg|alt=Data flow diagram with data storage, data flows, function and interface|thumb|478x478px|Data flow diagram with data storage, data flows, function and interface]]
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 {{nowrap|flow{{tsp}}{{mdash}}{{tsp}}there}} are no decision rules and no loops. Specific operations based on the data can be represented by a [[flowchart]].<ref name=":0">{{Cite journal|last1=Bruza|first1=P. D.|last2=van der Weide|first2=Th. P.|date=1990-11-01|title=Assessing the quality of hypertext views|journal=ACM SIGIR Forum|volume=24|issue=3|pages=6–25|doi=10.1145/101306.101307|s2cid=8507530|issn=0163-5840}}</ref>
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 [[Unified Modeling Language|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.<ref>{{Cite journal |last1=Martin |first1=David |last2=Estrin |first2=Gerald |date=1967-04-01 |title=Models of Computations and Systems—Evaluation of Vertex Probabilities in Graph Models of Computations |url=https://dl.acm.org/doi/10.1145/321386.321391 |journal=Journal of the ACM |volume=14 |issue=2 |pages=281–299 |doi=10.1145/321386.321391 |issn=0004-5411}}</ref><ref name=":2" /> DFD originated from the [[structured analysis and design technique]] methodology in the middle of the 1970s.<ref name=":2">{{Cite book |last1=Yourdon |first1=Edward |title=Structured Design |last2=Constantine |first2=Larry L. |date=1975 |publisher=Yourdon Inc. |___location=New York |pages=54–55 |oclc=1036882595}}</ref> It was first proposed by Larry Constantine,<ref>{{Cite book |last=Bergland |first=G. D. |chapter=Structured Design Methodologies |date=1978-06-19 |title=15th Design Automation Conference |chapter-url=https://dl.acm.org/doi/10.5555/800095.803131 |___location=Las Vegas, Nevada, USA |publisher=IEEE Press |pages=475–493 |doi=10.1109/DAC.1978.1585214 }}</ref> and popularized by [[Edward Yourdon]], Tom DeMarco,
<ref name=":3">{{Cite book |last=DeMarco |first=Tom |title=Structured analysis and system specification |date=1979 |publisher=Prentice-Hall |isbn=978-0-13-854380-8 |series=Prentice-Hall software series |___location=Englewood Cliffs, N.J}}</ref> Chris Gane and Trish Sarson,<ref name=":4">{{Cite book |last1=Gane |first1=Chris |title=Structured systems analysis: tools and techniques |last2=Sarson |first2=Trish |date=1979 |publisher=Prentice-Hall |isbn=978-0-13-854547-5 |series=Prentice-Hall software series |___location=Englewood Cliffs, N.J}}</ref><ref name=":1">{{Cite book|last=Yourdon|first=Edward|title=Proceedings of the May 19-22, 1975, national computer conference and exposition on - AFIPS '75 |chapter=Structured programming and structured design as art forms |date=1975|pages=277|doi=10.1145/1499949.1499997|s2cid=36802486|doi-access=free}}</ref> who enriched the diagramming technique with different notations, data dictionary practices<ref name=":3" /> and guidance for the hierarchical decomposition of processes.<ref name=":4" />
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.<ref name=":2" /> 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]].<ref>{{Cite journal |last1=Tangkawarow |first1=I R H T |last2=Waworuntu |first2=J |date=April 2016 |title=A Comparative of business process modelling techniques |journal=IOP Conference Series: Materials Science and Engineering |volume=128 |issue=1 |pages=012010 |doi=10.1088/1757-899X/128/1/012010 |issn=1757-8981|doi-access=free |bibcode=2016MS&E..128a2010T }}</ref> DFDs were useful to document the major data flows or to explore a new high-level design in terms of data flow.<ref>{{Cite book|title=Applying UML and patterns : an introduction to object-oriented analysis and design and iterative development|first=Craig|last=Larman|date=2012|publisher=Pearson|isbn=978-8177589795|edition= 3rd|___location=New Delhi|oclc=816555477}}</ref>
[[File:Data-flow-diagram-notation.svg|alt=Data flow diagram - Yourdon/DeMarco notation|thumb|''Data flow diagram - [[Edward Yourdon|Yourdon]]/[[Tom DeMarco|DeMarco]] notation'']]
DFD consists of processes, flows, warehouses, and terminators. There are several ways to view these DFD components.<ref>{{Cite book|title=Analýza a návrh informačních systémů|last=Řepa|first=Václav|date=1999|publisher=Ekopress|isbn=978-8086119137|edition= Vyd. 1|___location=Praha|oclc=43612982}}</ref>
'''Process'''
The process (function, transformation) is part of a system that transforms inputs to outputs. The symbol of a process is a circle, an oval, a rectangle or a rectangle with rounded corners (according to the type of notation). The process is named in one word, a short sentence, or a phrase that is clearly to express its essence.<ref name=":1" />
'''Data flow'''
Data flow (flow, dataflow) shows the transfer of information (sometimes also material) from one part of the system to another. The symbol of the flow is the arrow. The flow should have a name that determines what information (or what material) is being moved. Exceptions are flows where it is clear what information is transferred through the entities that are linked to these flows. Material shifts are modeled in systems that are not merely informative. Flow should only transmit one type of information (material). The arrow shows the flow direction (it can also be bi-directional if the information to/from the entity is logically dependent—e.g. question and answer). Flows link processes, warehouses and terminators.<ref name=":1" />
'''Warehouse'''
The warehouse (datastore, data store, file, database) is used to store data for later use. The symbol of the store is two horizontal lines, the other way of view is shown in the DFD Notation. The name of the warehouse is a plural noun (e.g. orders)—it derives from the input and output streams of the warehouse. The warehouse does not have to be just a data file but can also be, for example, a folder with documents, a filing cabinet, or a set of optical discs. Therefore, viewing the warehouse in a DFD is independent of implementation. The flow from the warehouse usually represents reading of the data stored in the warehouse, and the flow to the warehouse usually expresses data entry or updating (sometimes also deleting data). The warehouse is represented by two parallel lines between which the memory name is located (it can be modeled as a UML buffer node).<ref name=":1" />
'''Terminator'''
The terminator is an external entity that communicates with the system and stands outside of the system. It can be, for example, various organizations (e.g. a bank), groups of people (e.g. customers), authorities (e.g. a tax office) or a department (e.g. a human-resources department) of the same organization, which does not belong to the model system. The terminator may be another system with which the modeled system communicates.<ref name=":1" />
== Rules for creating DFD ==
Entity names should be comprehensible without further comments. DFD is a system created by analysts based on interviews with system users. It is determined for system developers, on one hand, project contractor on the other, so the entity names should be adapted for model ___domain or amateur users or professionals. Entity names should be general (independent, e.g. specific individuals carrying out the activity), but should clearly specify the entity. Processes should be numbered for easier mapping and referral to specific processes. The numbering is random, however, it is necessary to maintain consistency across all DFD levels (see DFD Hierarchy). DFD should be clear, as the maximum number of processes in one DFD is recommended to be from 6 to 9, minimum is 3 processes in one DFD.<ref name=":0" /><ref name=":1" /> The exception is the so-called contextual diagram where the only process symbolizes the model system and all terminators with which the system communicates.
== DFD consistency ==
DFD must be consistent with other models of the system—[[entity–relationship model|entity relationship diagram]], [[State diagram|state-transition diagram]], [[data dictionary]], and [[process specification]] models. Each process must have its name, inputs and outputs. Each flow should have its name (exception see Flow). Each Data store must have input and output flow. Input and output flows do not have to be displayed in one DFD—but they must exist in another DFD describing the same system. An exception is warehouse standing outside the system (external storage) with which the system communicates.<ref name=":1" />
== DFD hierarchy ==
To make the DFD more transparent (i.e. not too many processes), multi-level DFDs can be created. DFDs that are at a higher level are less detailed (aggregate more detailed DFD at lower levels). The contextual DFD is the highest in the hierarchy (see DFD Creation Rules). The so-called zero level is followed by DFD 0, starting with process numbering (e.g. process 1, process 2). In the next, the so-called first level—DFD 1—the numbering continues For example, process 1 is divided into the first three levels of the DFD, which are numbered 1.1, 1.2, and 1.3. Similarly, processes in the second level (DFD 2) are numbered 2.1.1, 2.1.2, 2.1.3, and 2.1.4. The number of levels depends on the size of the model system. DFD 0 processes may not have the same number of decomposition levels. DFD 0 contains the most important (aggregated) system functions. The lowest level should include processes that make it possible to create a process specification for roughly one A4 page. If the mini-specification should be longer, it is appropriate to create an additional level for the process where it will be decomposed into multiple processes. For a clear overview of the entire DFD hierarchy, a vertical (cross-sectional) diagram can be created. The warehouse is displayed at the highest level where it is first used and at every lower level as well.<ref name=":1" />
==
* [[Activity diagram]]
* [[Business Process Model and Notation]]
* [[Control-flow diagram]]
* [[Data island]]
* [[Dataflow]]
* [[Data and information visualization]]
* [[Directed acyclic graph]]
* [[DRAKON|Drakon-chart]]
* [[Functional flow block diagram]]
* [[Function model]]
* [[IDEF0]]
* [[Pipeline (software)|Pipeline]]
* [[Structured analysis and design technique]]
* [[Structure chart]]
* [[System context diagram]]
* [[Value-stream mapping]]
* [[Workflow]]
* [[List of graphical methods]]
==References==
{{Reflist}}
==Bibliography==
*[[Scott W. Ambler]]. [http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm The Object Primer 3rd Edition Agile Model Driven Development with UML 2]
*Schmidt, G., ''Methode und Techniken der Organisation.'' 13. Aufl., Gießen 2003
*[[Stahlknecht, P.]], Hasenkamp, U.: ''Einführung in die Wirtschaftsinformatik.'' 12. Aufl., Berlin 2012
*[[Christopher P. Gane|Gane, Chris]]; Sarson, Trish. ''Structured Systems Analysis: Tools and Techniques''. New York: Improved Systems Technologies, 1977. {{ISBN|978-0930196004}}. P. 373
*[[Tom DeMarco|Demarco, Tom]]. ''Structured Analysis and System Specification''. New York: Yourdon Press, 1979. {{ISBN|978-0138543808}}. P. 352.
*[[Edward Yourdon|Yourdon, Edward]]. ''Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design''. New York: Yourdon Press, 1979. {{ISBN|978-0138544713}}. P. 473.
*[[Page-Jones, Meilir]]. ''Practical Guide to Structured Systems Design''. New York: Yourdon Press, 1988. {{ISBN|978-8120314825}}. P. 384.
*[[Edward Yourdon|Yourdon, Edward]]. ''Modern Structured Analysis''. New York: Yourdon Press, 1988. {{ISBN|978-0135986240}}. P. 688.
==External links==
*{{Commons-inline}}
{{Data model}}
{{Authority control}}
{{DEFAULTSORT:Data Flow Diagram1}}
[[Category:Information systems]]
[[Category:Diagrams]]
[[Category:
[[Category:
[[Category:Modeling languages]]
[[Category:Data engineering]]
| |||