Decision Modeling & CASE Tools: Tables, Trees, Tools & Trade-offs

Decision Modeling: Rules into Action

What is Decision Modeling?

Decision modeling transforms business rules into structured formats (tables, trees, or logic diagrams) that systems can execute. It bridges the gap between ambiguous requirements and precise program logic.

stateDiagram-v2
    [*] --> RuleCollection: Start
    RuleCollection --> ConditionCheck: Evaluate IF
    ConditionCheck --> Action1: True?
    ConditionCheck --> Action2: False?
    Action1 --> [*]
    Action2 --> [*]

Why model decisions?

• Reduces ambiguity in requirements
• Automates repetitive “if-then” logic
• Improves maintainability (change rules once, not in 100 code files)

1. Decision Tables: Structured Rule Engines

A decision table lists conditions (rows) and actions (columns) in a grid. Each row = one rule.

How to Read a Decision Table

Worked Example: eSewa Loan Approval

Key Terms:

• Condition stubs: Columns listing possible values (e.g., “Age > 18”).
• Action stubs: Columns listing possible outcomes (e.g., “Approve”).
• Rule: One row combining one condition set with one action.

When to Use:

• Complex rules with many combinations (e.g., insurance claims, tax calculations).
• Not ideal for sequential decisions (use decision trees instead).

2. Decision Trees: Flowchart Logic

Decision trees show sequential choices (like an if-else ladder). Each node = a question; branches = outcomes.

Worked Example: Daraz Order Routing

1. Is order value > ₹5,000?
   • Yes → Express shipping (priority queue).
   • No → Standard shipping (FIFO queue).
2. Is customer premium?
   • Yes → Skip queue (direct dispatch).
   • No → Join standard queue.

Advantages over Tables:

• Easier to follow for sequential logic.
• Handles priority-based decisions well.

Disadvantages:

• Can get messy with many branches.
• Harder to update than tables (redrawing required).

3. Decision Rules: Natural Language to Code

Rules are written in plain English and later converted to code or pseudo-code. Example (Music Competition):

IF (applicant.age > 18 AND applicant.nationality = "Nepali")
   THEN approveEntry()
   ELSE rejectEntry("Age or nationality mismatch")

Tools to Convert Rules:

• CASE tools (e.g., IBM Rational, Visual Paradigm) auto-generate code from tables/trees.
• Business Rule Management Systems (BRMS) like Drools (used in banks for fraud detection).

CASE Tools: The Developer’s Swiss Army Knife

What Are CASE Tools?

Computer-Aided Software Engineering (CASE) tools automate parts of SDLC (design, coding, testing). They come in two flavors:

How CASE Tools Fit into SDLC

Components of CASE Tools

1. Repository: Central storage for all models (e.g., DFDs, code).
2. Diagrammer: Draws UML/DFD/ER diagrams.
3. Code Generator: Converts designs to programming language.
4. Simulator: Tests system behavior before coding.
5. Documentation Generator: Creates user manuals from models.

Advantages of CASE Tools

• Speed: Auto-generates boilerplate code (e.g., CRUD operations).
• Consistency: Enforces standards (e.g., naming conventions).
• Traceability: Links requirements → design → code → tests.
• Collaboration: Teams edit the same model in real-time (e.g., Google Docs for diagrams).

Disadvantages:

• Steep learning curve: Requires training to master.
• Overhead: Small projects may not need CASE tools.
• Vendor lock-in: Proprietary formats can be hard to migrate.

In the Real World

1. eSewa Loan Approval

   • Decision Tables: eSewa uses decision tables to evaluate loan applications based on credit score, income, and loan amount (see the table above). This ensures consistent approval/rejection logic across thousands of daily requests.
   • CASE Tool: Their backend uses IBM Rational to model these rules and auto-generate validation code in Java.

2. Daraz Order Routing

   • Decision Trees: Daraz’s warehouse management system uses decision trees to route orders to the fastest available delivery partner. The tree checks:
     • Order value (express vs. standard).
     • Customer tier (premium vs. regular).
     • Warehouse location (nearest hub).
   • CASE Tool: They use Visual Paradigm to design these trees and simulate bottlenecks before deployment.

3. NTC Traffic Light Control

   • Decision Rules: Kathmandu’s traffic lights use embedded systems with hardcoded rules like:

     IF (sensor[roadA].carCount > 5 AND time > rushHourStart)
        THEN greenLight(roadA) FOR 45_seconds
     

   • CASE Tool: Engineers use LabVIEW (a CASE-like tool) to prototype and test these rules before deploying to hardware.

Worked Example: Pathao Driver Assignment

Scenario: Pathao needs to assign the nearest available driver to a rider’s request. Decision Model:

Steps:

1. Condition 1: Check if rider is within 3km of any driver.
   • If No → Reject (too far).
   • If Yes → Proceed.
2. Condition 2: Check driver availability.
   • If Available → Assign nearest (using GPS distance).
   • If None available → Add rider to waitlist.

CASE Tool Application:

• Tool: Pathao’s team uses Lucidchart to design this tree.
• Output: The tree is converted to a Python function that runs on their backend servers.

Comparing Decision Modeling Techniques

Exam Tip

1. Decision Tables:

   • Always label rows/columns clearly (e.g., “Condition: Age > 18”).
   • Show one “don’t care” entry (e.g., “Income: Any”) to demonstrate completeness.
   • Link to real systems: Mention how banks use tables for loan rules.

2. Decision Trees:

   • Draw sequentially (top-down, left-to-right).
   • Annotate branches with conditions (e.g., “Yes → Express Shipping”).
   • Compare with tables: State when to use each (e.g., “Tables for combinations, trees for sequences”).

3. CASE Tools:

   • Define Upper vs. Lower CASE clearly in your answer.
   • Map to SDLC phases: Give 2–3 examples (e.g., “Upper CASE for DFDs in Analysis phase”).
   • Mention tools: Name at least one tool per category (e.g., “Visual Paradigm for design, Eclipse for coding”).

4. Common Pitfalls:

   • Incomplete tables: Ensure all condition combinations are covered.
   • Circular trees: Avoid loops in decision trees (examiners will penalize this).
   • Ignoring CASE tool phases: Always relate tools to SDLC stages.

Pro Tip: For exam questions on reduced decision tables, start by listing all possible condition combinations, then eliminate redundant rows. For example:

• Original table for “Age AND Nationality” has 4 rows (True/False × True/False).
• Reduced table needs only 2 rows if one condition is mutually exclusive (e.g., “Age > 18” implies “Not Child”).