Decision Tables, DFD
1. Decision Tables
Definition
A decision table is a structured representation used to model complex business logic and decision-making processes. It specifies actions to be taken under various combinations of conditions.
Components
A decision table consists of four main parts:
- Conditions (Condition Stubs) – List of possible conditions (Boolean or multi-valued).
- Condition Entries – Possible values (True/False, Y/N, or specific values) for each condition.
- Actions (Action Stubs) – List of actions to be performed.
- Action Entries – Indicate which actions are executed for each combination of conditions (usually marked with “X”).
Structure
| Conditions | Rule 1 | Rule 2 | Rule 3 | ... |
|---|---|---|---|---|
| Condition 1 | Y | N | Y | |
| Condition 2 | Y | Y | N | |
| ... | ||||
| Actions | ||||
| Action A | X | X | ||
| Action B | X | X |
Types
- Limited-entry: Conditions are Boolean (Y/N), actions are marked with X or blank.
- Extended-entry: Conditions may have multiple values, and actions may include parameters.
Advantages
- Clear, concise representation of complex logic.
- Helps avoid missing combinations of conditions.
- Easy to validate and verify with stakeholders.
- Useful for generating test cases.
Disadvantages
- Can become large and unwieldy with many conditions.
- Not suitable for sequential or iterative logic.
Use Cases
- Business rule specification.
- Software requirements documentation.
- Test case design (each column = one test scenario).
2. Data Flow Diagrams (DFD)
Definition
A Data Flow Diagram (DFD) is a graphical representation of the “flow” of data through a system. It shows how data is input, processed, stored, and output.
Purpose
- Model system functionality from a data perspective.
- Identify data sources, destinations, storage, and transformations.
- Aid in system analysis and design (especially in structured analysis).
Key Symbols (Gane & Sarson Notation)
| Symbol | Name | Description |
|---|---|---|
| 🟦 Rectangle | External Entity | Source or destination of data outside the system (e.g., Customer, Bank). |
| 🟨 Circle/Oval | Process | Action that transforms or manipulates data (e.g., “Validate Order”). |
| ➡️ Arrow | Data Flow | Movement of data between entities, processes, and data stores. Labeled with data name. |
| 🟩 Open Rectangle | Data Store | Repository where data is stored (e.g., “Customer Database”). |
Note: Yoursy notation uses rectangles with rounded corners for processes.
Levels of DFD
- Context Diagram (Level 0)
- Single process representing the entire system.
- Shows interactions with external entities.
- Level 1 DFD
- Breaks the main process into major sub-processes.
- Shows key data stores and flows.
- Level 2+ DFDs
- Further decomposition of Level 1 processes for detailed analysis.
Rules & Guidelines
- Processes must have at least one input and one output data flow.
- Data cannot flow directly between two external entities (must go through a process).
- Data stores must be connected to a process (not directly to external entities).
- Balancing: Data flows into/out of a parent process must match the combined flows of its child diagram.
Advantages
- Easy to understand for technical and non-technical stakeholders.
- Focuses on data movement, not control flow or timing.
- Helps identify redundancies and inefficiencies.
Limitations
- Does not show sequence, timing, or loops.
- Not suitable for modeling real-time or object-oriented systems.
- Can become complex at higher levels.
Common Mistakes to Avoid
- Missing data flows (e.g., no output from a process).
- Connecting entities directly to data stores.
- Unbalanced decomposition between levels.
- Using vague process names like “Handle Data” – be specific (e.g., “Calculate Invoice Total”).
Comparison Summary
| Feature | Decision Table | DFD |
|---|---|---|
| Purpose | Model logic/rules | Model data movement |
| Focus | Conditions → Actions | Inputs → Processes → Outputs |
| Best For | Business rules, validation logic | System boundaries, data architecture |
| Notation | Tabular | Graphical (symbols & arrows) |
| Shows Sequence? | No | No |
| Used In | Requirements, testing | System analysis, design |
Exam Tips
- For Decision Tables: Always check for completeness (all condition combinations covered) and redundancy (identical rules).
- For DFDs: Ensure every process has inputs and outputs; label all flows clearly; balance parent and child diagrams.
- Practice drawing a Context Diagram and Level 1 DFD for a simple system (e.g., Library Management, Online Order System).
- Remember: DFDs ≠ Flowcharts – DFDs show data movement, not program logic or control flow.