Data Flow Diagrams (DFD) are powerful tools for visualising and understanding the flow of data within a system. They provide a clear and concise representation of how information moves through a system, helping analysts and stakeholders comprehend the system's functionalities.
In this comprehensive guide, we will explore the fundamental concepts of Data Flow Diagrams, their components, and their practical application. Additionally, we will delve into an example to illustrate the creation and interpretation of DFDs.
How to Draw Data Flow Diagrams
What is Data Flow Diagram
A data flow diagram (DFD) is a graphical representation of a system that shows the flow of information through a system i.e where data comes from, where it goes and how it gets stored. In other words, it shows how data is processed by a system in terms of inputs and outputs. DFD is built using standardized symbols.Data Flow Diagrams Symbols/Notations/Components
Different people use different notations to represent processes, data stores, data flow and external entities of the DFD. The most commonly used two different types of notations are by Yourdon & Coad or Gane & Sarson.
DFD uses 4 basic symbols to represent the flow of the diagram. They are
- Process
- Data Store
- External Entity
- Arrows (Data Flow)
Process - A process transforms incoming data flow into the outgoing data flow. It works on the input and produces output. Provide the label for the process.
Datastore – Datastores are storage house of data in the system. It represents the place where the data is stored and retrieved from when needed. Provide the label for datastore.
Dataflow - Dataflows shows the direction of flow of information. Label the arrows with the name of the data that moves through it.
External Entity - External entities are objects outside the system, with which the system interacts. External entities are sources and destinations of the system's inputs and outputs.
Data Flow Diagram Levels
Data flow diagrams are categorized by levels. The first level that is drawn is called the Context level or Level 0, and then it is further expanded to explain in detail.
Context Diagram (Level 0 DFD) - A context diagram is a top level (also known as "Level 0") data flow diagram.
It provides a broad view of the system. It only contains one process node which is connected with external entities. In short, it generalizes the function of the entire
DFD Layers - Data flow diagrams can be made in several nested layers. A single process node on a high-level diagram can be expanded to show a more detailed data flow diagram. Draw the context diagram first, followed by various layers of data flow diagrams.
DFD Levels - The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until you reach pseudo code.
Level 1 DFD – This is the level drawn after expanding the context diagram. It is still a general overview but explained in more details than a context diagram. Here, the single process node is expanded further down into sub-processes. As these processes are added, the diagram will need additional data flows and data stores to link them together.
Level 2+ DFD – all the level starting from level 2 are simply drawn by breaking down processes at a higher level into more detailed sub-processes. i.e level 1 is broken down into sub-processes to form Level 2 DFD, and Level 2 DFD is broken down in sub-processes to form Level 3 and so on. Each level explains the DFD in more detail than the higher level.
It is believed that Level 3 DFD are detailed enough to explain the system, though you can go beyond Level 3.
Advantages and Disadvantages of DFDs
Advantages- The DFD method is an element of object-oriented analysis and is widely used.
- Use of DFD's promotes quick and relatively easy project code development.
- DFD's are easy to learn with their few-and simple- to-understand symbols (once you decide on a particular DFD model).
- The syntax used for designing DFD's is simple, employing English nouns or noun adjective-verb constructs.
Disadvantages
- DFDs for large systems can become cumbersome, difficult to translate and read, and be time-consuming in their construction.
- The data flow can become confusing to programmers, but DFD's are useless without the prerequisite detail.
- Different DFD models employ different symbols (circles and rectangles, for example, for entities).
Commonly made errors while constructing a DFD model
Although DFD's are simple to understand and draw, students and practitioners alike encounter similar types of problems while modeling software problems using DFD's.- Many beginners commit the mistake of drawing more than one bubble in the context diagram. A context diagram should depict the system as a single bubble.
- Many beginners have external entities appearing at all levels of DFDs. All external entities interacting with the system should be represented only in the context diagram. The external entities should not appear at other levels of the DFD.
- It is a common oversight to have either too less or too many bubbles in a DFD. Only 3 to 7 bubbles per diagram should be allowed, i.e. each bubble should be decomposed to between 3 and 7 bubbles.
- Many beginners leave different levels of DFD unbalanced.
- A common mistake committed by many beginners while developing a DFD model is attempting to represent control information in a DFD. It is important to realize that a DFD is the data flow representation of a system, and it does not represent control information.
- A data store should be connected only to bubbles through data arrows. A data store cannot be connected to another data store or to an external entity.
- All the functionalities of the system must be captured by the DFD model. No function of the system specified in its SRS document should be overlooked.
- Only those functions of the system specified in the SRS document should be represented, i.e. the designer should not assume functionality of the system not specified by the SRS document and then try to represent them in the DFD.
- Improper or unsatisfactory data dictionary.
- The data and function names must be intuitive. Some students and even practicing engineers use symbolic data names such a, b, c, etc. Such names hinder understanding the DFD model.
Steps for Creating a Data Flow Diagram
1. Identify the System Boundaries
Start by defining the scope of the system. Identify what is included in the system and what is considered external. This step helps in establishing the boundaries of the DFD.
2. Identify Processes
Identify the processes within the system where data is manipulated. Processes should represent distinct functions or activities that contribute to the system's overall functionality.
3. Identify Data Stores
Determine where data is stored within the system. This includes databases, files, or any other repositories where information is retained for future use.
4. Identify Data Flows
Establish the paths through which data moves between processes, data stores, and external entities. Clearly define the inputs and outputs for each process.
5. Connect Components
Use arrows to connect processes, data stores, and external entities, illustrating the flow of data. Ensure that each data flow is properly labeled to indicate the type of data being transferred.
6. Refine the DFD
Review the initial DFD and refine it as needed. Ensure that it accurately represents the system's functionality and data flow. You may need to iterate through this process to achieve the desired level of detail and clarity.
How to draw Data Flow Diagram
Now you have basic knowledge about DFD like symbols used, their pros and cons. You can build your own DFD.Let's review the basic steps you need to know about drawing DFD
- Identify the inputs and outputs in a system.
- Build a context level diagram.
- Expand the context level diagram into Level 1 diagram.
- If required, expand to next levels according to the requirement.
- Finally, verify your diagrams i.e. check all flow of information, all data stores are included, whether there is consistency in inputs and outputs in all diagrams and so on.
- Present your final diagram
Conclusion
Data Flow Diagrams are invaluable tools in system analysis and design, providing a clear and concise representation of how data moves through a system. By understanding the components of DFDs and following a systematic approach to their creation, analysts can effectively model and communicate complex systems.
Embracing the use of DFDs can lead to improved communication, better system understanding, and the identification of potential issues early in the development process.
