Context Diagram & Leveling

Context Diagram & Leveling

The context diagram is the highest-level DFD. It shows the entire system as a single process and depicts all external entities that interact with it. Leveling is the technique of decomposing processes into finer detail across multiple DFD levels.

Context Diagram

A context diagram (also called Level-0 DFD) provides a bird's-eye view of the system boundary. It answers the question: "What are the major data flows between the system and its environment?"

            +------------+
            |  Customer  |
            +------+-----+
                   |
          Order / Payment
                   |
                   v
+----------+   +--+----------+   +----------+
| Supplier |<->|   ORDER    |<->| Manager  |
+----------+   |   SYSTEM   |   +----------+
               +--+----------+
                   |
          Reports / Updates
                   |
                   v
            +------+-------+
            |  Database    |
            +--------------+

Key elements:
- Single process = the entire system
- External entities = people or systems outside the boundary
- Data flows = data exchanged across the boundary

Rules for Context Diagrams

• The system is represented as a single process (numbered 0)
• External entities are shown outside the system boundary
• Data flows show data crossing the system boundary
• No data stores are shown (they are internal to the system)
• Every external entity should have at least one data flow to/from the system

Leveling (Decomposition)

Leveling breaks down a complex process into smaller, more manageable sub-processes. Each level provides more detail while maintaining consistency with the parent diagram.

Context Diagram (Level 0)
         System as one process
              |
              | (decompose)
              v
Level 1 DFD
         Major sub-processes
         (e.g., 1.0, 2.0, 3.0)
              |
              | (decompose each)
              v
Level 2 DFD
         Detailed sub-processes
         (e.g., 1.1, 1.2, 2.1, 2.2)

Balancing Rule

When decomposing a process, the inputs and outputs of the child diagram must match the inputs and outputs of the parent process. This is called balancing and ensures data flow consistency across levels.

Parent Process 2.0:
  Input:  Order Data
  Output: Confirmation, Invoice

Child Diagram (2.0 decomposed):
  Process 2.1: Validate Order    (input: Order Data)
  Process 2.2: Check Inventory   (input: Order Data)
  Process 2.3: Generate Invoice  (output: Invoice)
  Process 2.4: Send Confirmation (output: Confirmation)

Balanced: same inputs and outputs at both levels.

Numbering Convention

When to Stop Decomposing

Decompose until each process represents a single, well-defined function that can be described with a single process specification (Structured English, decision table, or decision tree). A good rule of thumb is to stop when a process can be completed by one person in one sitting.

Summary

The context diagram and leveling technique allow analysts to model systems at multiple levels of abstraction, from a high-level overview down to detailed process logic. Balancing ensures consistency across all levels.