A data flow diagram represents a software system as a labeled, directed graph. Data flow diagram illustrates the flow of data among a set of components. The components may be tasks, software components, or even abstractions of the functionality that will be included in the software system.
Give example of data flow diagram (DFD).
Consider the Approve Sales process where Sales Order is examined for completeness before being processed further. It flows into the process as Sales Order and out of it as Approved Sales Order.
[Source: Accounting Information Systems By Hall]
Second example of DFD
The two actors are unit tester and the team leader. The unit tester, of course, is responsible for the unit testing. The unit tester uses the source code and the test plan to accomplish the unit testing. The result of this activity is an artifact, the test results. The team leader reviews the results and the result of this activity should be the approval of unit testing. This model does not explicitly show what happens when the process is not successful.
[Source:Shaum's outline of theory and problems of software engineering By David A. Gustafson]
What are the different types of data flow diagrams (DFDs).
Data flow diagrams (DFDs) are categorized as either logical or physical. A logical DFD focuses on the business and how the business operates. It describes the business events that take place and the data required and produced by each event. On the other hand, a physical DFD shows how the system will be implemented.
| Design Feature | Logical | Physical |
|---|---|---|
| What the model depicts | How the business operates | How hue system will be implemented (or how the current system operates) |
| What the process represent | Business activities | Programs, program modules and manual procedures |
| What the data stores represent | Collection of data, regardless of how the data is stored | Physical files and databases, manual files |
| Type of data source | Show data stores representing permanent data collections | Master files, transaction files. Any processes that operate at two different times must be connected by a data source |
| System controls | Show business controls | Show controls for validating input data, for obtaining a record (record found status), for ensuring successful completion of a process and for system security (example: Journal records) |
[Source]
Consider the figure below. It is clear from the figure that orders are placed, orders are received, the location of ordered parts is determined and delivery notes are dispatched along with the order.
It does not however tell us how these things are done or who does them. Are they done by computers or manually and if manually who does them ? A logical DFD of any information system is one that models what occurs without showing how it occurs.
A physical DFD shows, how the various functions are performed? Who does them? Consider the following figure:
The above figure is opposite, it shows the actual devices that perform the functions. Thus there is an "order processing clerk", an "entry into computer file" process and a "run locate program" process to locate the parts ordered. DFD(s) that shows how things happen, or the physical components are called physical DFD(s).
[Source]
A context diagram depicts the entire process being modeled as a single task, or box, in a process diagram. The diagram shows important interactions between the system and external agents.
An event-partitioned system model contains one process per event. The model shows important interfaces with external agents. If no subsystem DFD is created, the event-partitioned system model is also called diagram 0.
A subsystem DFD contains one process per major subsystem. The DFD shows important interfaces with external agents. Each process is further represented by another DFD—an event-partitioned DFD (or diagram zero) for that subsystem.
A DFD fragment is a portion of an event-partitioned system model that shows the process, external agents, data stores, and data flows needed to respond to a single event.
A process decomposition is a DFD that shows the internal implementation details of a single process on another DFD. [Source]
Explain symbols used in DFDs.
[Source: Accounting Information Systems By Hall]
Explain Steps in creating DFDs.
Steps (in short) to create DFD:
Build the context diagram.
Create DFD fragments for each scenario.
Organize DFD fragments into level 0.
Decompose level 0 DFDs as needed.
Validate DFDs with user. [Source]
Steps (somewhat elaborated) to create DFD
1. Start from the context diagram. Identify the parent process and the external entities with their net inputs and outputs.
2. Place the external entities on the diagram. Draw the boundary.
3. Identify the data flows needed to generate the net inputs and outputs to the external entities.
4. Identify the business processes to perform the work needed to generate the input and output data flows.
5. Connect the data flows from the external entities to the processes.
6. Identify the data stores.
7. Connect the processes and data stores with data flows.
8. Apply the Process Model Paradigm to verify that the diagram addresses the processing needs of all external entities.
9. Apply the External Control Paradigm to further validate that the flows to the external entities are correct.
10. Continue to decompose to the nth level DFD. Draw all DFDs at one level before moving to the next level of decomposing detail. You should decompose horizontally first to a sufficient nth level to ensure that the processes are partitioned correctly; then you can begin to decompose vertically. [Source]
Why do we create data flow diagram (DFD)?
The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transformed as they move through the system and (2) to depict the functions (and subfunctions) that transform the data flow. The DFD provides additional information that is used during the analysis of the information domain and serves as a basis for the modeling of function. [Pressmen]
What are the advantages of DFDs?
The DFD offers the analyst several distinct advantages. Most fundamentally, it depicts flow and boundary. The essence of knowing boundary is first to understand the extent of the process prior to beginning to define something that may not be complete or accurate. The concept is typically known as top-down, but the effort can also be conceived as step-by-step. The analyst must first understand the boundary and flows prior to doing anything else. The steps following this will procedurally gather more detailed information until the specification is complete. DFD represents a graphical display of the process and is therefore a usable document that can be shown to both users and programmers, serving the former as a process verification and the latter as the schematic(blueprint) of the system from a technical perspective. It can be used in JAD sessions and as part of the business specification documentation. Most important, it can be used for maintaining and enhancing a process. [Source]
Advantages of logical DFD
- Better communication with users
- More stable systems
- Better understanding of the business by analysts
- Flexibility and maintenance
- Elimination of redundancies and easier creation of the physical model
Advantages of physical DFD
- Clarifying which processes are manual and which are automated
- Describing processes in more detail than logical DFDs
- Sequencing processes that have to be done in a particular order
- Identifying temporary data stores
- Specifying actual names of files and printouts
- Adding controls to ensure the processes are done properly
What are the drawbacks / disadvantages of data flow diagrams (DFDs)?
The biggest drawback of the DFD is that it simply takes long time to create: so long that the analyst may not receive support from management to complete it. This can be especially true when there is a lot of leveling to be performed. Therefore many firms shy away from the DFD on the basis that it is not practical.
The other disadvantage of the DFD is that it does not model time dependent behavior well, that is, the DFD is based on very finite processes that typically have a very definable start and finish. This of course is not true of all processes, especially those that are event driven. [Source]
What is the role of DFD as a documentation aid?
It is a good documentation aid which is understood by both programmers and non-programmers (i.e., laypersons). As DFD specifies only what processes are performed and not how they are performed it is easily understood by a nonprogramming user. [Source]
In what way is physical DFD useful?
It is easy to develop during fact gathering stage of systems analysis. Such a physical DFD is easily understood by a lay user who can verify the DFD drawn by an analyst and tell whether such a DFD corresponds to a particular operation taking place in an organization. Physical DFD is the starting point for developing the logical DFD. [Source]
What are the mistakes in the below DFD?
A data flow cannot have two arrows pointing in opposite directions. A separate data flow line should be drawn for "application returned". [Source]
Different documents that will help you draw Data Flow diagrams (DFDs)
Developing DFDs: An Example
DFD - 1
Data Flow Analysis, Physical and Logical DFDs, Data Flow Notation, Developing Data Flow Diagrams, Validating the DFD, General Rules for Drawing Logical Data Flow Diagrams
DFD - 2
Data Flow Diagram (DFD), Explain what a DFD is, Importance of DFDs in a good software design, DFD for Tic-Tac-Toe game described etc.
DFD - 3
The Data Flow Diagram, Why do we use DFDs?, Levelling, The four main elements of DFDs notation, examples of DFDs etc.
DFD - 4
Function Modeling With Data Flow Diagrams, Data Flow Diagram Icons, Example Dataflow Diagram, Example DFD using Repositories, Refining DFDs etc.
DFD - 5
Data Flow Diagrams - Step by step approach, rules for external entities, data stores, data flows, processes, types of diagrams, balancing DFDs, data flow splits and joins etc.
DFD - 6
How does an analyst determine whether a person or organization should be represented on a DFD as an external agent or by one or more processes?
System scope and degree of control are the main issues here. The person or organization should be represented as an external agent (for example, a customer, bank, or governmental agency), if the system has little or no control over the actions of a person, program, or organization. The person or organization can be represented using processes, data flows, data stores, or real-time links, if the system has substantial control over the person, program, or organization. The issue of control can be overlooked to limit the scope of system development in which case things outside the limited scope are represented as external agents regardless of the issue of control.
What features may be present on a physical DFD that should never be present on a logical DFD?
Generally features that are technology-specific may appear on a physical DFD but not a logical DFD. Also, processes, data flows, and data stores that would not be required if the system were implemented with perfect technology are never present on a logical DFD. Direct examples include processes that represent specific existing programs or persons (roles). Indirect examples include duplicate processes, data stores, and data flows and partitioning of processes or data flows that represents specific technology assumptions. [Source]
Few Data Flow Diagram Tools
1. SmartDraw
2. Visual Case
3. Edraw Soft
4. Concept Draw
5. Gliffy
6. Dia
Also See:
DFD Multiple Choice Questions