The Complete information About DFD

Data flow diagram example
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.
Developing a DFD helps in identifying the transaction data in the data model.
There are different notations to draw data flow diagrams, defining different visual representations for processes, datastores, dataflow, and external entities.

Developing a DFD

1.1 Elements of a DFD
1.2 Top-Down Approach
1.3 Event Partitioning Approach
DFD Levels
2.1 Context Level
2.2 Level 0
2.3 Level 1
DFD tools
3.1 DFD Tool


Developing a DFD

Elements of a DFD
There are 4 key elements in a Data Flow diagram, Processes, Data Flows, Data Stores & External entities.
The Process entity identifies a process taking place, it must have at least one input and output. A process with no input is known as a "miracle process"an output is a "black hole process". Each process has the following
A Number
A Name (verb phrase)
A Description
At least one input
At least one output
The Data Flow entity identifies the flow of data between processes, data stores & external entities. A data flow cannot connect an external entity to a data source, at least one connection must be with a process. There are also "physical" flows, i.e. those that use a physical medium, like a membership card. Each data flow has the following
A Name (Noun)
A Description
One or more connections to a process.
The Data Store entity identifies stores of data, both manual and electronic. Electronic or "digital" stores are identified by the letter D, and manual filing systems by the letter M, e.g. D1 could be a MySQL database, and M4 could be a filing cabinet. Each data store has the following
A Number
A Name
A Description
One or more input data flows.
One or more output data flows.
The External Entity identifies external entities which interacts with the system, usually clients but can be within the same organisation. Multiple existences of the same entity, e.g. the same doctor shown twice on the same diagram, can be identified by a horizontal line in the top left corner of the symbol. Each external entity has the following;
A Name (Noun)
A Description

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.
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 Levels

Context Level

A context level DFD created using Select SSADM.
This level shows the overall context of the system and it's 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.

Level 0

A Level 0 DFD for the same system.
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 it's 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.

Level 1

A Level 1 DFD showing the "Process Enquiry" process for the same system.
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 it's parent level 0 diagram.

DFD tools

CA ERwin Data Modeler, a data modeling tool
ConceptDraw, a Windows and Mac OS X data flow diagramming tool
Dia, a free source diagramming tool with flowchart support
Kivio, a free source diagramming tool for KDE
Microsoft Visio, a Windows diagramming tool which includes very basic DFD support (Images only, does not record data flows)
SmartDraw, a Windows diagraming tool with Yourdon and Coad process notations and Gane and Sarson process notation
System Architect, an enterprise architecture tool, supporting Coad/Yourdon, Gane & Sarson, Ward/Mellor, and SSADM notations and techniques
DFDdeveloper, an open source software application that allows Microsoft Office users to create interactive leveled data flow diagrams and data dictionaries

Your Ad Here