Data Flow Diagrams (DFDs)

Data Flow Diagrams

A Data Flow Diagrams (DFDs) is a graphical representation of the flow of data through a system, depicting how inputs are transformed into outputs and identifying key processes, data stores, and data flows. DFDs are widely used in software engineering, systems analysis, and business process modeling. They provide a clear overview of how data moves through the system, helping to understand the system’s structure and operations.

Components of DFDs

DFDs consist of four main elements:

  1. Processes (Circles or Rounded Rectangles)
  2. Data Flows (Arrows)
  3. Data Stores (Open Rectangles)
  4. External Entities (Rectangles)

1. Processes

A process represents a transformation or activity that takes input data and produces output data. Each process is numbered and usually labeled with a verb to indicate what the process does. For example, “Process Order” or “Calculate Tax”.

  • Symbol: A circle or rounded rectangle.
  • Naming: Each process has a unique number (e.g., P1, P2) and a descriptive name.

2. Data Flows

Data flows represent the movement of data between elements in the system (between processes, data stores, and external entities). Data flow arrows indicate the direction of data movement.

  • Symbol: An arrow.
  • Naming: Data flow should be named based on the type of data being transferred, such as “Order Details” or “Payment Information”.

3. Data Stores

Data stores represent places where data is stored within the system. These could be databases, files, or temporary storage areas.

  • Symbol: An open-ended rectangle (sometimes referred to as a “box” or “file”).
  • Naming: Each data store is usually named according to the data it stores, such as “Customer Database” or “Order Log”.

4. External Entities

External entities represent the outside systems or users that interact with the system being modeled. These can be individuals, organizations, or other systems that provide data or receive data from the system.

  • Symbol: A rectangle.
  • Naming: External entities should be named based on their role or relationship to the system, such as “Customer” or “Payment Gateway”.

Levels of Data Flow Diagrams

DFDs can be broken down into different levels of abstraction to represent the system at various stages of detail:

  1. Level 0 (Context Diagram)High-Level Overview
    The Level 0 DFD, also known as the Context Diagram, provides a high-level overview of the system. It shows the system as a single process, with data flows to and from external entities. This level captures only the most essential interactions.
    • One process symbol is used to represent the entire system.
    • Data flows are shown between the system and external entities.
    • There are no internal processes or data stores at this level.
    Example:
    • External Entity: Customer
    • Data Flow: “Order Details” → System
    • Data Flow: “Confirmation” → Customer
  2. Level 1 (Decomposed Overview)Detailed Process Breakdown
    Level 1 DFD breaks the system into major processes. Each high-level process from the Level 0 diagram is decomposed into sub-processes, and the data flows between them are more detailed. This level typically represents the main functional areas of the system.
    • Includes multiple processes with clear data flows between them.
    • Data stores are added to capture how data is maintained within the system.
    • Interactions with external entities are still shown.
  3. Level 2 (Detailed Breakdown)Detailed Process Flow
    Level 2 DFD further decomposes each process in the Level 1 diagram into more specific sub-processes. It provides a very detailed view of the system’s workings, often breaking down each process into its specific tasks.
    • Each process in the Level 1 DFD is broken into more detailed sub-processes.
    • Data stores become more granular.
    • Data flows between processes are described in greater detail.
    Example:
    • “Process Order” (Level 1) may be broken down into “Validate Order,” “Calculate Total,” and “Create Invoice” (Level 2).

Steps to Create a DFD

  1. Identify System Boundaries
    • Identify the boundaries of the system you’re modeling. This will help you understand what’s inside the system and what’s external to it.
  2. Define External Entities
    • Determine who or what interacts with the system. External entities could be customers, external systems, or other departments.
  3. Identify Data Flows
    • Trace how data moves from one element to another. Identify the types of data that flow between external entities, processes, and data stores.
  4. Identify Processes
    • Break down the system into major activities. Each activity should take in data, process it, and produce output. This step involves decomposing the system into manageable components.
  5. Identify Data Stores
    • Figure out where data is stored within the system. Data stores are usually required for handling persistent data or temporary information.
  6. Draw the DFD
    • Start with the highest-level diagram (Level 0), then decompose it into further levels as needed. Use standard DFD symbols for processes, data flows, data stores, and external entities.

Types of Data Flow Diagrams

1. Context Diagram (Level 0 DFD)

  • High-level overview of the system.
  • Contains:
    • A single process symbol representing the whole system.
    • All external entities interacting with the system.
    • Major data flows between the process and entities.

Example: A payment processing system.

  • Process: Handle Payments.
  • Entities: Customer, Bank.
  • Data Flows: Payment Details, Approval Notification.

2. Level 1 DFD

  • Decomposes the main process in the Context Diagram into sub-processes.
  • Shows:
    • Detailed data flows between sub-processes.
    • Data stores for storing and retrieving information.

Example: Decomposition of Handle Payments.

  • Processes: Validate Payment, Process Payment, Send Confirmation.
  • Data Stores: Payment Records.

3. Level 2 (or More Detailed) DFD

  • Breaks down Level 1 processes into more specific tasks.
  • Provides:
    • Comprehensive details about each process.
    • Granular data flows and interactions.

Example: Breaking Validate Payment.

  • Sub-processes: Check Card Details, Check Balance.

4. Logical DFD

  • Represents what the system does (logical flow of data).
  • Abstract and independent of physical implementation.
  • Used during the initial analysis phase.

Example: Logical DFD for a library system.

  • Process: Borrow Book.
  • Data Flows: Book Request, Approval.

5. Physical DFD

  • Represents how the system is implemented physically.
  • Includes details like user interfaces, hardware, and database systems.

Example: Physical DFD for the same library system.

  • Shows User Interface for book search.
  • Highlights Database Server interactions.

Comparison of Logical and Physical DFDs

AspectLogical DFDPhysical DFD
FocusFunctional aspects (what)Implementation details (how)
Abstraction LevelHighDetailed
PurposeAnalysis and designImplementation and testing

DFD Example

Consider a simple online ordering system. Let’s break it down into a DFD.

Level 0 (Context Diagram)

  • External Entities: Customer, Payment Gateway
  • Process: “Online Ordering System”
  • Data Flows:
    • Customer → “Order Details” → Online Ordering System
    • Online Ordering System → “Order Confirmation” → Customer
    • Online Ordering System → “Payment Info” → Payment Gateway
    • Payment Gateway → “Payment Status” → Online Ordering System

Level 1

  • Processes:
    • “Validate Order”
    • “Process Payment”
    • “Create Invoice”
  • Data Stores:
    • “Customer Database”
    • “Order Database”
  • Data Flows:
    • Customer → “Order Details” → Validate Order
    • Validate Order → “Customer Info” → Customer Database
    • Validate Order → “Invoice Info” → Create Invoice
    • Create Invoice → “Order Info” → Order Database
    • Process Payment → “Payment Info” → Payment Gateway
    • Payment Gateway → “Payment Status” → Process Payment

Level 2 (For “Validate Order” Process)

  • Sub-processes:
    • “Check Customer Info”
    • “Check Product Availability”
  • Data Flows:
    • Customer → “Order Details” → Check Customer Info
    • Check Customer Info → “Customer Info” → Customer Database
    • Check Product Availability → “Product Info” → Product Database
    • Product Database → “Availability Status” → Check Product Availability

Characteristics of Data Flow Diagrams (DFDs)

1. Clarity

  • DFDs provide a clear and straightforward visual representation of data flows and processes, making complex systems easier to understand.

2. Hierarchy

  • DFDs use levels (Context, Level 1, Level 2, etc.) to represent varying degrees of detail, from high-level overviews to granular details.

3. Focus on Data Movement

  • Emphasizes how data moves between processes, data stores, and external entities rather than how the processes are executed.

4. Standardized Notation

  • Uses a consistent set of symbols (circles, rectangles, arrows) to represent processes, data flows, stores, and entities.

5. Flexibility

  • Applicable to a wide range of domains, including business processes, software design, and systems analysis.

6. Logical Representation

  • Focuses on the logical flow of data, independent of physical implementation or technology.

7. Non-linear

  • DFDs can illustrate concurrent processes and interactions between multiple entities.

DFD Guidelines & Best Practices

  1. Consistency in Naming:
    • Always use clear, consistent naming for processes, data flows, data stores, and external entities.
  2. Use Simple Symbols:
    • Keep the diagram simple and use standard symbols so that the diagram is easy to understand by anyone, regardless of their technical knowledge.
  3. Avoid Overcrowding:
    • Avoid overcrowding the diagram with too many processes at one level. If a process becomes too complex, decompose it further into lower levels.
  4. Validate the DFD:
    • Make sure the DFD is logical and that all data flows are valid and make sense. Each process should have inputs and outputs, and data flows should align with system requirements.
  5. Iterative Process:
    • DFDs should evolve as you learn more about the system. Iterate and refine as you analyze system requirements and functionality.

Suggested Questions

1. What is a Data Flow Diagram (DFD)?

Q: Define a Data Flow Diagram.
A: A Data Flow Diagram (DFD) is a graphical representation of a system that illustrates how data moves through processes, data stores, and external entities. It helps visualize the flow of information and the logical operations performed within a system.


2. What are the main components of a DFD?

Q: List and explain the components of a DFD.
A: The main components are:

  1. Processes: Represent actions performed on data (e.g., Calculate Salary).
  2. Data Flows: Show the movement of data (e.g., Customer Details).
  3. Data Stores: Represent where data is stored (e.g., Database).
  4. External Entities: Represent sources or destinations outside the system (e.g., Customer).

3. What are the different levels of a DFD?

Q: Explain the different levels of DFDs with examples.
A:

  1. Context Diagram (Level 0): A high-level overview showing the entire system as a single process and its interactions with external entities.
  2. Level 1 DFD: Breaks the main process into sub-processes and shows data stores.
  3. Level 2 (and beyond): Further decomposes sub-processes for greater detail.

4. What is the difference between Logical and Physical DFDs?

Q: Compare Logical and Physical DFDs.
A:

  • Logical DFD focuses on what the system does and is used for analysis.
  • Physical DFD focuses on how the system is implemented and includes technical details.

5. What are the advantages of using DFDs?

Q: Why are DFDs important in system analysis?
A:

  • Provides a clear understanding of the system.
  • Simplifies complex processes.
  • Facilitates communication between stakeholders.
  • Identifies potential inefficiencies or bottlenecks.

6. How do you create a DFD?

Q: Outline the steps for creating a DFD.
A:

  1. Identify external entities interacting with the system.
  2. Define the main processes and sub-processes.
  3. Determine data flows between entities, processes, and data stores.
  4. Validate the diagram for logical consistency and completeness.

7. What is a Context Diagram?

Q: What is the purpose of a Context Diagram?
A: A Context Diagram is a Level 0 DFD that provides a high-level overview of a system, showing the main process, external entities, and major data flows. It simplifies the system for initial analysis.


8. Can DFDs represent real-time systems?

Q: Are DFDs suitable for modeling real-time systems?
A: Yes, DFDs can model real-time systems by incorporating feedback loops, concurrent processes, and data flows that update in real-time. However, they focus on logical data flows rather than timing details.


9. What are common mistakes in creating DFDs?

Q: What should be avoided when creating a DFD?
A:

  • Missing or unclear labels for components.
  • Overcomplicating the diagram with too many details in one level.
  • Mixing Logical and Physical elements in the same DFD.
  • Ignoring data stores or flows that are essential to the process.

10. What tools can be used to create DFDs?

Q: Name tools commonly used for drawing DFDs.
A: Popular tools include:

  • Lucidchart
  • Microsoft Visio
  • Draw.io
  • EdrawMax
  • Gliffy

1 thought on “Data Flow Diagrams (DFDs)”

  1. Pingback: Function Oriented Design In Software Engineering - Eduforskills.com

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top