العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolDATA FLOW DIAGRAM
A 'data flow diagram' ('DFD')
is a graphical representation of the "flow" of data through an information system. A data flow diagram can also be used for the visualization of data processing (structured design). It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system being modeled.
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 restock how any system is developed can be determined through a dataflow diagram.
A data flow diagram illustrates the processes, data stores, and external entities in a business or other system and the connecting data flows.
The four components of a data flow diagram (DFD) are:
;External Entities/Terminators : are outside of the system being modelled. Terminators (also referred to as sources or sinks, depending on whether data flows from or into them) represent where information comes from or where it goes. In designing a system, we have no idea about what these terminators do or how they do it.
;Processes : modify the inputs in the process of generating the outputs
;Data Stores : represent a place in the process where data comes to rest. A DFD does not say anything about the relative timing of the processes, so a data store might be a place to accumulate data over a year for the annual accounting process.
;Data Flows : are how data moves between terminators, processes, and data stores (those that cross the system boundary are known as IO or Input Output Descriptions).
Every page in a DFD should contain fewer than 10 components. If a process has more than 10 components, then one or more components (typically a process) should be combined into one and another DFD be generated that describes that component in more detail. Each component should be numbered, as should each subcomponent, and so on. So for example, a top level DFD would have components 1 2 3 4 5, the subcomponent DFD of component 3 would have components 3.1, 3.2, 3.3, and 3.4; and the subsubcomponent DFD of component 3.2 would have components 3.2.1, 3.2.2, and 3.2.3. DFD can use to in presenting project.
This is published by M. Talha Umair
A data store ''symbolizes permanent information that is used by the system and must therefore be stored if the system is to function properly (i.e. Information held in a database)''
# The system designer makes a context level DFD, which shows the interaction (data flows) between the system (represented by one process) and the system environment (represented by terminators).
# The system is decomposed in lower level DFD (Zero) into a set of processes, data stores, and the data flows between these processes and data stores.
# Each process is then decomposed into an even lower level diagram containing its subprocesses.
# This approach then continues on the subsequent subprocesses, until a necessary and sufficient level of detail is reached which is called the primitive process (aka chewable in one bite).
This approach was described by Edward Yourdon in ''Just Enough Structured Analysis''[1]
# Construct detailed DFD.
## The list of all events is made.
## For each event a process is constructed.
## Each process is linked (with incoming data flows) directly with other processes or via datastores, so that it has enough information to respond to a given event.
## The reaction of each process to a given event is modeled by an outgoing data flow.
★ ConceptDraw - Windows and MacOS X data flow diagramming tool
★ Dia - Free source diagramming tool with flowchart support
★ Kivio - Free source diagramming tool for KDE
★ Microsoft Visio - Windows diagramming tool which includes very basic DFD support (Images only, does not record data flows)
★ SILVERRUN ModelSphere - cross-platform tool for business process modelling and data flow diagramming
★ SmartDraw - Windows diagraming tool with "Yourdon and Coad Process Notations" and "Gane and Sarson Process Notation"
★ Dataflow
★ Pipeline
★ Flow chart
★ System context diagram
★ Context Diagram Level Zero
★ Data structure diagram
1. Just Enough Structured Analysis, , Edward, Yourdon, , , , Chapter 19
★ "The Semantics of Data Flow Diagrams" by P. D. Bruza and Th. P. van der Weide
★ Case study "Current physical dataflow diagram for Acme Fashion Supplies" ..and accompanying elementary process descriptions
is a graphical representation of the "flow" of data through an information system. A data flow diagram can also be used for the visualization of data processing (structured design). It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system being modeled.
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 restock how any system is developed can be determined through a dataflow diagram.
| Contents |
| Components |
| Data store |
| Developing a DFD |
| Top-Down Approach |
| Event Partitioning Approach |
| DFD tools |
| See also |
| References |
| Further reading |
| External links |
Components
A data flow diagram illustrates the processes, data stores, and external entities in a business or other system and the connecting data flows.
Data flow diagram example
The four components of a data flow diagram (DFD) are:
Data flow diagram notation
;External Entities/Terminators : are outside of the system being modelled. Terminators (also referred to as sources or sinks, depending on whether data flows from or into them) represent where information comes from or where it goes. In designing a system, we have no idea about what these terminators do or how they do it.
;Processes : modify the inputs in the process of generating the outputs
;Data Stores : represent a place in the process where data comes to rest. A DFD does not say anything about the relative timing of the processes, so a data store might be a place to accumulate data over a year for the annual accounting process.
;Data Flows : are how data moves between terminators, processes, and data stores (those that cross the system boundary are known as IO or Input Output Descriptions).
Every page in a DFD should contain fewer than 10 components. If a process has more than 10 components, then one or more components (typically a process) should be combined into one and another DFD be generated that describes that component in more detail. Each component should be numbered, as should each subcomponent, and so on. So for example, a top level DFD would have components 1 2 3 4 5, the subcomponent DFD of component 3 would have components 3.1, 3.2, 3.3, and 3.4; and the subsubcomponent DFD of component 3.2 would have components 3.2.1, 3.2.2, and 3.2.3. DFD can use to in presenting project.
This is published by M. Talha Umair
Data store
A data store ''symbolizes permanent information that is used by the system and must therefore be stored if the system is to function properly (i.e. Information held in a database)''
Developing a DFD
Top-Down Approach
# The system designer makes a context level DFD, which shows the interaction (data flows) between the system (represented by one process) and the system environment (represented by terminators).
# The system is decomposed in lower level DFD (Zero) into a set of processes, data stores, and the data flows between these processes and data stores.
# Each process is then decomposed into an even lower level diagram containing its subprocesses.
# This approach then continues on the subsequent subprocesses, until a necessary and sufficient level of detail is reached which is called the primitive process (aka chewable in one bite).
Event Partitioning Approach
This approach was described by Edward Yourdon in ''Just Enough Structured Analysis''[1]
# Construct detailed DFD.
## The list of all events is made.
## For each event a process is constructed.
## Each process is linked (with incoming data flows) directly with other processes or via datastores, so that it has enough information to respond to a given event.
## The reaction of each process to a given event is modeled by an outgoing data flow.
DFD tools
★ ConceptDraw - Windows and MacOS X data flow diagramming tool
★ Dia - Free source diagramming tool with flowchart support
★ Kivio - Free source diagramming tool for KDE
★ Microsoft Visio - Windows diagramming tool which includes very basic DFD support (Images only, does not record data flows)
★ SILVERRUN ModelSphere - cross-platform tool for business process modelling and data flow diagramming
★ SmartDraw - Windows diagraming tool with "Yourdon and Coad Process Notations" and "Gane and Sarson Process Notation"
See also
★ Dataflow
★ Pipeline
★ Flow chart
★ System context diagram
★ Context Diagram Level Zero
★ Data structure diagram
References
1. Just Enough Structured Analysis, , Edward, Yourdon, , , , Chapter 19
Further reading
★ "The Semantics of Data Flow Diagrams" by P. D. Bruza and Th. P. van der Weide
External links
★ Case study "Current physical dataflow diagram for Acme Fashion Supplies" ..and accompanying elementary process descriptions
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
