Process Modeling with DFDs: Diagrams, Levels, and Worked Examples

TAKEAWAYS:

• DFDs visualize how data moves through a system using 4 symbols: processes (□), data stores (||), data flows (→), and external entities (□).
• Level-0 DFD shows the big picture (1 process per major function), while level-1 breaks it into sub-processes (e.g., "Payment Processing" → "Validate Card" + "Deduct Balance").
• Balancing DFDs means every input/output must match across levels—missing flows are a design error.
• Real-world use: eSewa’s DFD would show Ncell/Khalti as external entities, user account as a data store, and transaction approval as a process.
• Common mistakes: forgetting to label flows, using DFDs for control flow (use activity diagrams instead), or ignoring data stores (e.g., "patient records").
• Exam focus: You’ll be asked to draw DFDs (30% weight) and explain balancing (20%), so practice tracing data flows end-to-end.

What Are Data Flow Diagrams (DFDs)?

DFDs are visual tools in structured analysis that map how data moves through a system. Unlike flowcharts (which show steps/decisions), DFDs focus only on data:

• No control logic (e.g., "if-else" loops).
• No timing (e.g., "after 5 seconds").
• Only data: inputs, processes, outputs, and storage.

Why use DFDs?

• Clarify system boundaries: What data comes in/out? Who are the external entities (e.g., customers, banks)?
• Spot inefficiencies: Are data stores (e.g., databases) being used optimally?
• Communicate with stakeholders: Non-technical users (e.g., hospital admins) can "see" the workflow.

DFD Symbols: The 4 Building Blocks

graph TD
    A["External Entity\n(□)"] -->|"Data Flow<br/>(→)"| B["Process\n(□)"]
    B -->|"Data Flow"| C["Data Store\n(||)"]
    C -->|"Data Flow"| D["External Entity\n(□)"]

Key symbols:

1. External Entity (□): Sources/sinks of data (e.g., Khalti user, NTC billing system).
2. Process (□): Transforms data (e.g., "Calculate Tax", "Validate Login").
3. Data Store (||): Holds data (e.g., patient records database, eSewa transaction log).
4. Data Flow (→): Movement of data between symbols (must be labeled with data name).

Rule: Every flow must have a name (e.g., "Patient Test Request" → not just "data").

Levels of DFDs: Zooming In and Out

DFDs are drawn at multiple levels to avoid clutter. Think of it like a map:

• Context Diagram (Level 0): The biggest picture (1 process + all external entities).
• Level-1 Diagram: Breaks the main process into sub-processes.
• Level-2, Level-3...: Drill deeper into sub-processes.

Example: Online Pathology Lab System (from past exams)

Context Diagram (Level 0):

flowchart TD
  A["Patient"] -->|"Test Request"| B["Pathology System"]
  B -->|"Test Results"| A
  C["Lab Technician"] -->|"Sample Data"| B
  B -->|"Billing Info"| D["Bank"]

Level-1 Diagram (breaking "Pathology System" into 3 sub-processes):

flowchart TD
  A["Patient"] -->|"Test Request"| B["Register Test"]
  B -->|"Test ID"| C["Process Sample"]
  C -->|"Results"| D["Generate Report"]
  D -->|"Report"| A
  C -->|"Sample Data"| E["Lab Technician"]
  D -->|"Billing"| F["Bank"]

Level-2 Example (for "Process Sample"):

flowchart TD
  A["Test ID"] -->|"Input"| B["Validate Sample"]
  B -->|"Reject"| C["Patient"]
  B -->|"Accept"| D["Store Sample"]
  D -->|"Data"| E["Lab Database"]
  E -->|"Results"| F["Analyze"]

In the Real World

1. eSewa/Khalti Payments:

   • DFD Use: Models how user data (e.g., phone number, transaction amount) flows from the app to Ncell’s servers, then to merchant accounts (e.g., Daraz).
   • Key Processes:
     • "Authenticate User" (checks OTP from Ncell).
     • "Deduct Balance" (interacts with Ncell’s data store).
     • "Send Receipt" (external entity: user’s email).
   • Data Store: "Transaction Log" (stored in eSewa’s database).

2. NTC Billing System:

   • DFD Use: Shows how customer usage data (from smart meters) flows to NTC’s billing process, then to bank for payment collection.
   • External Entities: Customers, Banks, Government (for subsidies).
   • Process: "Calculate Bill" → "Generate Invoice" → "Send to Bank".

3. Pathao Driver App:

   • DFD Use: Models ride requests flowing from user → Pathao server → nearest driver (external entity).
   • Data Store: "Driver Locations" (updated in real-time).
   • Process: "Match Rider-Driver" (uses GPS data flows).

Worked Example: Daraz Order Fulfillment

Scenario: A customer places an order on Daraz. Model this as a Level-1 DFD.

Steps:

1. Identify External Entities:
   • Customer, Supplier, Payment Gateway (Khalti), Logistics (Nepal Post).
2. Main Process: "Order Fulfillment" (broken into sub-processes).
3. Data Stores:
   • "Customer Database", "Inventory", "Order History".
4. Data Flows:
   • Customer → "Place Order" → "Order Database".
   • "Order Database" → "Check Inventory" → Supplier.
   • "Payment Gateway" → "Process Payment" → Bank.

Level-1 DFD:

graph TD
    A["Customer"] -->|"Order"| B["Place Order"]
    B -->|"Order ID"| C["Check Inventory"]
    C -->|"Stock Status"| D["Supplier"]
    C -->|"Confirm"| E["Process Payment"]
    E -->|"Payment"| F["Bank"]
    E -->|"Order Confirmed"| G["Notify Customer"]
    G -->|"Order Details"| A
    C -->|"Pack Order"| H["Logistics"]

Real-World Tie-In:

• Balancing Check: If "Place Order" sends "Order ID" to "Check Inventory", then "Check Inventory" must return a flow (e.g., "Stock Status") back to "Place Order" or to another process. Missing flows = bugs in design.

DFD Rules and Best Practices

Common Pitfalls (and How to Avoid Them)

1. Using DFDs for Control Flow:

   • ❌ Wrong: Modeling "if-else" logic (e.g., "If balance > 1000, approve loan").
   • ✅ Correct: Use decision tables or activity diagrams for logic.

2. Ignoring Data Stores:

   • ❌ Wrong: All data flows directly between processes (e.g., "Customer" → "Process Payment" → "Bank" without storing order details).
   • ✅ Correct: Add a "Orders Database" to store data between steps.

3. Overloading Level-0:

   • ❌ Wrong: Level-0 has 10 processes (e.g., "Login", "Checkout", "Search").
   • ✅ Correct: Level-0 should have 1–3 major processes (e.g., "Order Management").

4. Unlabeled Flows:

   • ❌ Wrong: Arrows without names (e.g., "→").
   • ✅ Correct: Label every flow (e.g., "→ Customer Details").

How to Draw a DFD: Step-by-Step

1. Start with the Context Diagram:

   • Draw the system as a single process.
   • Identify all external entities (who sends/receives data?).
   • Connect them with data flows.

2. Decompose into Level-1:

   • Break the main process into sub-processes (3–7 is ideal).
   • Ensure all inputs/outputs of the parent process are preserved.

3. Add Data Stores:

   • Where is data stored or retrieved? (e.g., "Customer Database").

4. Validate:

   • Trace data: Pick a flow (e.g., "Order") and follow it through all processes.
   • Check balance: Level-0 inputs/outputs must match Level-1 combined.

DFDs vs. Other Diagrams

Exam Tip: How to Score Full Marks

1. For Drawing DFDs (30% weight):

   • Show all 4 symbols (external entity, process, data store, flow).
   • Label every arrow (e.g., "→ Patient Details").
   • Balance parent/child DFDs: If Level-0 has "Order → Payment", Level-1 must include both.
   • Use real scenarios: Examiners love eSewa, Daraz, or hospital lab examples.

2. For Explanations (20% weight):

   • Define data flow vs. control flow.
   • Explain why data stores are needed (e.g., "to persist order history").
   • Mention balancing when asked about levels.

3. Common Exam Questions:

   • "Draw a DFD for [scenario]." → Always start with context diagram.
   • "What’s the difference between DFD and flowchart?" → DFD = data only; flowchart = steps/decisions.
   • "How do you validate a DFD?" → Trace data flows and check balance.

Practice Questions (With Hints)

1. Draw a Level-0 DFD for a bank ATM system.

   • Hint: External entities = "Customer", "Bank Server". Main process = "ATM Transaction".

2. Convert this Level-1 DFD to a context diagram:

flowchart TD
  A["Customer"] -->|"Withdrawal Request"| B["ATM Transaction"]
  B -->|"Transaction Details"| C["Bank Server"]

• Hint: Context diagram will have one process ("ATM System") connected to all external entities.

3. Spot the error in this DFD:

flowchart TD
  A["User"] -->|"Login"| B["Authenticate"]
  B -->|"Success"| C["Dashboard"]
  C -->|"Data"| D["Database"]
  D -->|"Feedback"| B

• Hint: Missing flow from D (Database) back to C (Dashboard).

Real Hardware: Where Data Flows Physically

DFDs are abstract, but data flows through real systems. Here’s how eSewa’s transaction data moves:

graph TD
    A["User's Phone\n(Android/iOS)"] -->|"HTTPS"| B["eSewa Server\n(Nepal Data Centers)"]
    B -->|"API Call"| C["Ncell/Khalti\n(Payment Gateway)"]
    C -->|"Bank API"| D["Nabil Bank/Global IME\n(Server Racks)"
    D -->|"Update"| C
    C -->|"Success"| B
    B -->|"Receipt"| A

(Note: In Nepal, eSewa’s servers are hosted in Nepal Data Centers like Nepal Telecom’s facility in Kathmandu.)

Key Takeaways for the Exam

1. DFDs are about data, not steps: Forget "if-else"; focus on where data comes from and goes to.
2. Start simple: Context diagram first, then decompose.
3. Balance is critical: If Level-0 shows "Order → Payment", Level-1 must include both.
4. Real-world examples score extra: Tie your DFDs to eSewa, Daraz, or hospital systems.
5. Practice tracing: Pick a flow (e.g., "Patient Test Request") and follow it through all processes.

Final Note: DFDs are your secret weapon for visualizing systems. Master them, and you’ll ace the exam—especially the drawing questions. For extra practice, model Khalti’s refund process or NTC’s bill generation as DFDs!