A Data Flow Diagram (DFD) is a graphical tool used in system analysis and design to represent how data moves through a system.
Thank you for reading this post, don't forget to subscribe!- It shows how inputs are transformed into outputs through various processes, helping stakeholders understand how a system works without going into implementation details.
Main Components of a DFD:
1.) Processes:
- Represent actions or functions that transform incoming data into outgoing data.
- Labeled with a verb phrase (e.g., Process Order, Calculate Total).
2.) Data Stores:
- Represent storage of data that is used and updated by processes.
- Labeled with a noun phrase (e.g., Customer Records, Order Database).
3.) Data Flows:
- Represent the movement of data between processes, data stores, and external entities.
- Labeled with the name of the data moving (e.g., Order Details, Invoice).
4.) External Entities (Terminators):
- Represent people, organizations, or systems that interact with the system.
- Serve as data sources or destinations (e.g., Customer, Supplier).
Rules for Drawing Data Flow Diagrams (DFDs):
- Data cannot flow between two external entities directly.
- A data flow must always pass through a process. If two entities need to exchange data, it should be modeled through a process that handles or transforms the data.
- Data cannot flow directly between two data stores.
- All data movement between data stores must go through at least one process that reads from one and writes to another.
- Data cannot flow directly from an external entity to a data store or from a data store to an entity.
- Any data coming from or going to an external entity must be processed by a process before reaching a data store or vice versa.
- Every process must have at least one input data flow and one output data flow.
- A process cannot exist in isolation; it must receive data and produce a result. A process with only an input or only an output is invalid.
- Every data store must have at least one input and one output data flow.
- A data store must be involved in both storing and retrieving data via associated processes. A data store with only input or only output is considered incomplete.
- Two data flows should not cross each other unnecessarily.
- This is a visual design rule to improve the readability of the diagram. Keeping lines from crossing helps prevent confusion.
- All processes in the system must be connected to at least one data store, another process, or an external entity.
- Every process should be meaningfully connected within the system. Orphan processes (not connected to any other components) are not valid.
Levels of DFDs:
1.) Level 0 DFD:
A Context Diagram, also known as Level 0 DFD, is the highest-level data flow diagram that provides a broad overview of the entire system, showing how it interacts with external entities.
- It represents the system as a single process and illustrates the input and output data flows between the system and its external entities such as users, organizations, or other systems.
- No data stores or internal processes are shown in a context diagram.
- The main goal is to establish the system boundaries and understand the overall interaction with its environment.
2.) Level 1 Data Flow Diagram (DFD):
A Level 1 DFD decomposes the single process in the context diagram into multiple sub-processes, providing more detailed insight into the internal operations of the system.
- Level 1 DFD includes internal processes, data stores, data flows, and external entities.
- It shows how major system functions are divided and how data is stored and retrieved.
- This level bridges the gap between the high-level overview (context diagram) and deeper-level process logic.
3.) Level 2 Data Flow Diagram (DFD):
A Level 2 DFD further breaks down the sub-processes identified in Level 1 into more detailed sub-processes to show more specific data flow and process behavior.
- Level 2 DFD is used when a Level 1 process is too complex and needs further clarification.
- It continues the decomposition process by expanding specific functions into finer details, including additional data flows and interactions with data stores or external entities.
- This level helps analysts and developers understand system components in greater depth.
3.) Level 3 Data Flow Diagrams (DFDs):
A Level 3 DFD continues the decomposition process by breaking down one or more Level 2 processes into even smaller, more detailed sub-processes.
- Level 3 (and higher-level) DFDs are created only when necessary, particularly for highly complex systems.
- They offer the most granular view of system processes, data movement, and storage.
- These diagrams are essential when there is a need to model complex logic or when very detailed analysis is required for implementation or validation.
Guidelines for Drawing DFDs:
1.) Use Meaningful Names:
- All elements (processes, data flows, data stores, external entities) should have descriptive and specific names.
2.) Clearly Indicate Data Flow Direction:
- Use arrows to show the direction of data movement between components.
3.) Ensure Process Validity:
- Every process must have at least one input and one output data flow.
4.) Maintain Consistency Across Levels:
- Inputs and outputs at higher-level DFDs must align with the decomposed elements in lower-level DFDs.
5.) Avoid Black Holes, Miracles, and Gray Holes:
- Black hole: A process with input but no output.
- Miracle: A process with output but no input.
- Gray hole: A process whose outputs are not logically related to its inputs.
Benefits of DFDs:
- Improve communication between developers and stakeholders.
- Help identify system inefficiencies or missing elements.
- Serve as a foundation for further analysis, like logic modeling and data modeling.