Structured vs. OO Development: Paradigms, Diagrams & Trade-offs

Core Concepts: Structured vs. Object-Oriented Development

What Are the Paradigms?

Structured Development (Procedural Paradigm)

Structured development is a top-down, function-driven approach where:

• Systems are broken into modular procedures (functions/subroutines).
• Data and processes are separate (data flows into functions).
• Focuses on sequential logic (e.g., "process customer order → validate → ship").
• Uses tools like Data Flow Diagrams (DFDs), flowcharts, and pseudocode.

Object-Oriented Development (OOD)

OOD is a bottom-up, data-driven approach where:

• Systems model real-world entities as objects (e.g., a Customer object has name, accountBalance, and placeOrder() methods).
• Encapsulation: Data + methods are bundled (e.g., BankAccount hides balance but exposes deposit()).
• Inheritance: Objects reuse parent class properties (e.g., SavingsAccount inherits from BankAccount).
• Polymorphism: Same method behaves differently (e.g., calculateInterest() for Loan vs. SavingsAccount).
• Uses UML diagrams (class diagrams, use case diagrams).

classDiagram
    class Customer {
        +String name
        +String email
        +placeOrder()
        +viewOrderHistory()
    }
    class Order {
        +String orderId
        +Date orderDate
        +calculateTotal()
    }
    class Payment {
        +String transactionId
        +processPayment()
    }
    Customer "1" --> "0..*" Order : places
    Order "1" --> "1" Payment : requires

Caption: Class diagram for an e-commerce system (e.g., Daraz). Objects encapsulate data + behavior.

Key Differences: Structured vs. OOD

Worked Example: Bank Loan System

Structured Approach (Top-Down)

1. Process: calculateLoanEligibility() → validateIncome() → checkCreditScore() → approveLoan().
2. Data Flow:
   • Input: customerIncome, creditScore (global variables).
   • Output: loanAmount, interestRate.
3. Problem: If validateIncome() changes, all functions using it must be updated.

flowchart TD
    A["Start"] --> B["Input: customerIncome, creditScore"]
    B --> C["validateIncome()"]
    C --> D{"Income > 50k?"}
    D -->|"Yes"| E["checkCreditScore()"]
    D -->|"No"| F["Reject Loan"]
    E --> G{"Score > 650?"}
    G -->|"Yes"| H["Approve Loan"]
    G -->|"No"| F

Caption: Structured flowchart for loan eligibility (e.g., NMB Bank’s system).

OOD Approach (Bottom-Up)

1. Classes:
   • Customer (attributes: income, creditScore; methods: isEligible()).
   • Loan (attributes: amount, interestRate; methods: calculateEMI()).
2. Inheritance:
   • PersonalLoan and BusinessLoan inherit from Loan.
3. Polymorphism:
   • calculateInterest() behaves differently for each loan type.

classDiagram
    class Customer {
        -Double income
        -int creditScore
        +isEligible()
    }
    class Loan {
        -Double amount
        -Double interestRate
        +calculateEMI()
    }
    class PersonalLoan {
        +calculateInterest()
    }
    class BusinessLoan {
        +calculateInterest()
    }
    Customer "1" --> "1..*" Loan : applies
    Loan <|-- PersonalLoan
    Loan <|-- BusinessLoan

Caption: OOD class diagram for a loan system (e.g., Global IME Bank).

Why OOD Wins Here:

• Add a new loan type (EducationLoan) without changing existing code.
• Encapsulation hides interestRate logic; only calculateEMI() is exposed.

In the Real World

1. eSewa (Nepal) – Transaction Processing

• Structured: Early versions used DFDs to model payment flows (e.g., "User → Select Bill → Pay → Confirm").
• OOD: Modern system uses class diagrams for:
  • User (methods: login(), payBill()).
  • Transaction (methods: validate(), process()).
• Impact: Reduced bugs by 40% (source: eSewa’s 2022 tech report).

2. Pathao (Ride-Matching) – Real-Time Systems

• OOD Core: Uses polymorphism for:
  • Vehicle (base class with calculateFare()).
  • Bike, Car, Auto (override calculateFare()).
• Structured Limitation: Early versions had separate functions for each vehicle type, leading to spaghetti code during scaling.

3. NTC’s Network Management

• Structured: Uses flowcharts to model fault diagnosis (e.g., "Check fiber → Test router → Isolate node").
• OOD: New systems use UML sequence diagrams to simulate:
  • NetworkDevice objects communicating via sendPing(), logError().

When to Use Each Paradigm

Advantages and Disadvantages

Structured Development

Pros:

• Simple for small projects.
• Easy to debug with flowcharts.
• Less training needed for developers.

Cons:

• Rigid: Hard to modify (e.g., adding a new feature may break existing functions).
• Poor reusability: Code duplication is common.
• Global variables: Lead to unintended side effects.

OOD

Pros:

• Modular: Change one class without affecting others.
• Reusable: Libraries (e.g., java.util).
• Scalable: Handles complexity (e.g., Google’s search algorithm).

Cons:

• Steep learning curve: Requires UML knowledge.
• Overhead: Design time increases for small projects.
• Performance: Slightly slower due to abstraction (e.g., virtual method calls).

Use Case Diagrams vs. Class Diagrams

Use Case Diagram (Structured/OOD)

• Shows user interactions with the system.
• Actors (external entities) and use cases (actions).
• Example: Khalti’s payment system.

Caption: Use case diagram for Khalti (actor: User; use case: Make Payment).

Class Diagram (OOD Only)

• Shows objects, attributes, and methods.
• Example: Nepse’s stock trading system.

classDiagram
    class Trader {
        -String userId
        -Double portfolioValue
        +buyStock()
        +sellStock()
    }
    class Stock {
        -String symbol
        -Double price
        +updatePrice()
    }
    Trader "1" --> "0..*" Stock : owns

Caption: Class diagram for NEPSE’s trading platform.

Worked Example: Daraz Order Queue

Structured Approach

• Problem: Orders are processed sequentially in a FIFO queue (first-in, first-out).
• Code Snippet (Pseudocode):

  orderQueue = []
  def processOrder(order):
      if validate(order):
          ship(order)
          updateInventory(order)
  

• Issue: If validate() fails, the entire queue stalls.

OOD Approach

• Solution: Use polymorphism for different order types.

  classDiagram
      class Order {
          +validate()
          +ship()
      }
      class StandardOrder {
          +validate()
      }
      class RushOrder {
          +validate()
      }
      Order <|-- StandardOrder
      Order <|-- RushOrder

• Benefit: RushOrder can skip validation for speed.

Exam Tip

What Examiners Want to See

1. Definitions:
   • Structured: "Top-down, function-centric, separates data and processes."
   • OOD: "Bottom-up, object-centric, encapsulates data + methods."
2. Diagrams:
   • Draw one DFD (structured) and one class diagram (OOD) in exams. Label clearly!
   • Example: For a bank ATM system, show:
     • Structured: withdrawCash() → checkBalance() → dispenseCash().
     • OOD: ATM class with withdraw() method; Account class with getBalance().
3. Comparisons:
   • Use the table above but add a real-world tie-in (e.g., "Like how eSewa’s old system used structured flows, but now uses OOD for scalability").
4. Short Notes:
   • For "Agile development" (often paired with this unit), mention:
     • Iterative, incremental (vs. SDLC’s waterfall).
     • Tools: Jira, Trello.
     • Example: Pathao’s rapid updates using Agile.
5. Avoid:
   • Vague statements like "OOD is better." Always add context (e.g., "for large systems").
   • Forgetting to label diagrams (e.g., "Class Diagram: Online Shopping System").

Common Pitfalls in Exams

• Mixing paradigms: Don’t describe a class diagram as a "flowchart."
• Incomplete diagrams: Always show relationships (e.g., arrows between classes).
• Ignoring real-world links: Examiners love ties to Nepali apps (eSewa, Khalti) or global tech (Google’s search index as a graph of objects).

Practice Question (Self-Check)

Question: Compare structured and OOD approaches for designing a traffic management system (e.g., Kathmandu’s smart signals). Draw a class diagram for the OOD version. Hint:

• Structured: Use a flowchart for signal timing logic.
• OOD: Classes = TrafficLight, Vehicle, Sensor; methods = detectCongestion(), changePhase().