UML Modeling: Diagrams, Patterns & Real-World Systems

What is UML and Why Model Software?

Software modeling uses Unified Modeling Language (UML) to visualize systems before coding. UML is a standardized language (not a programming language) with 14 diagram types grouped into structural (showing static relationships) and behavioral (showing dynamic interactions).

Why Model?

• Clarity: Avoids ambiguity in requirements (e.g., eSewa’s payment flow).
• Reusability: Standard diagrams (like class diagrams) work across projects.
• Validation: Catches design flaws early (e.g., Ncell’s billing system errors).
• Communication: Non-technical stakeholders (e.g., Daraz managers) understand visuals.

Structural Diagrams: The "Blueprints" of Software

These show static relationships between components. Key diagrams:

1. Class Diagram

Definition: Shows classes (objects), their attributes, methods, and relationships (association, inheritance, aggregation, composition). Example: A bank account system with Customer, Account, and Transaction classes.

classDiagram
    class Customer {
        -id: int
        -name: string
        +openAccount()
    }
    class Account {
        -accountNumber: string
        -balance: float
        +deposit(amount)
        +withdraw(amount)
    }
    class Transaction {
        -transactionId: int
        -amount: float
        +record()
    }
    Customer "1" -- "0..*" Account : opens
    Account "1" -- "1..*" Transaction : contains

Real-World Tie:

• eSewa’s class diagram would include User, PaymentGateway, and ServiceProvider classes, with User aggregating PaymentHistory.
• Worked Example: Model a Daraz order system with classes Customer, Order, Product, and Delivery. Use composition for Order containing OrderItem.

Key Relationships:

2. Component Diagram

Definition: Shows high-level modules (e.g., libraries, services) and their dependencies. Example: A WhatsApp message system with components:

• UserInterface (UI)
• MessageService (handles sending/receiving)
• Database (stores chats)

Real-World Tie:

• Khalti’s payment system uses components like UserAuth, PaymentGateway, and NotificationService.
• Worked Example: Model NTC’s billing system with components CustomerPortal, BillingEngine, and PaymentProcessor.

3. Deployment Diagram

Definition: Shows hardware nodes (servers, devices) and software deployment. Example: Ncell’s network with:

• Nodes: Base stations, central server, user phones.
• Artifacts: BillingSoftware, CustomerApp.

Behavioral Diagrams: How Software "Moves"

These show dynamic interactions (e.g., user actions, system responses).

1. Use Case Diagram

Definition: Shows actors (users/other systems) and use cases (actions). Example: Pathao ride system:

• Actors: Customer, Driver, Admin.
• Use Cases: Book Ride, Track Ride, Cancel Ride.

Real-World Tie:

• eSewa’s use case diagram includes actors User, Government, Bank and use cases like Pay Bill, Check Balance.
• Worked Example: Model NEPSE’s trading system with actors Broker, Investor, Admin and use cases Place Order, View Portfolio.

2. Sequence Diagram

Definition: Shows object interactions in time order (messages passed between objects). Example: WhatsApp message flow:

1. User sends Message.
2. MessageService processes it.
3. Database stores it.
4. NotificationService alerts recipient.

sequenceDiagram
    participant User
    participant MessageService
    participant Database
    participant NotificationService
    User->>MessageService: sendMessage("Hi!")
    MessageService->>Database: store(message)
    MessageService->>NotificationService: alertRecipient()
    NotificationService->>User2: showNotification()

Real-World Tie:

• Khalti’s payment sequence:
  1. User selects Pay.
  2. PaymentGateway requests Bank.
  3. Bank processes and confirms.
  4. Khalti updates User balance.
• Worked Example: Trace a Daraz order from Customer → OrderService → Inventory → Delivery.

3. State Diagram

Definition: Shows object state transitions (e.g., traffic light, order status). Example: Kathmandu traffic route system for a vehicle:

• States: Waiting, Moving, Stopped.
• Transitions: greenLight → Moving, redLight → Stopped.

stateDiagram-v2
    [*] --> Waiting
    Waiting --> Moving : greenLight()
    Moving --> Stopped : redLight()
    Stopped --> Waiting : lightTurnsGreen()
    Stopped --> [*]

Real-World Tie:

• Ncell’s call state: Idle → Ringing → Connected → Ended.
• Worked Example: Model eSewa’s payment status: Pending → Processing → Completed/Failed.

Model-Driven Architecture (MDA)

Definition: Separates platform-independent models (PIM) from platform-specific models (PSM) using transformations. Process:

1. Create PIM (e.g., class diagram of a banking system).
2. Apply transformation rules (e.g., "convert to Java").
3. Generate PSM (Java code + database schema).

flowchart TD
    A["PIM: Class Diagram"] -->|"Transformation"| B["PSM: Java + DB"]
    B --> C["Deployed System"]

Real-World Tie:

• Google’s Android apps use MDA: designers create UI mockups (PIM), tools generate code (PSM).
• Worked Example: Transform a WhatsApp chat PIM (classes User, Message) into a Python PSM with SQLAlchemy models.

Exam Tip: How to Score Full Marks

1. Diagrams > Text: Always draw neat mermaid diagrams (use the exact syntax shown above). Label every element.
2. Real-World Links: Tie every example to Nepalese apps (eSewa, Khalti, Daraz). Examiners love this.
   • Example: "Like eSewa’s payment flow, this sequence diagram shows..."
3. Definitions + Examples: For each diagram type, give:
   • Definition (1 line).
   • Example (draw it).
   • Real-World Use (name a Nepalese app).
4. Avoid Common Mistakes:
   • ❌ Drawing inheritance as a solid line (use hollow triangle).
   • ❌ Forgetting to label arrows in sequence diagrams.
   • ❌ Using UML for flowcharts (use activity diagrams instead).
5. Short-Answer Secrets:
   • Waterfall model: "Sequential phases (requirements → design → ... → maintenance). Use when requirements are stable (e.g., NTC’s billing system)."
   • Event-driven modeling: "Systems react to events (e.g., WhatsApp’s onMessageReceived)."

In the Real World

1. eSewa’s Payment Flow

   • UML Used: Sequence diagram for User → PaymentGateway → Bank → eSewa.
   • Why: Ensures every step (authentication, deduction, confirmation) is visualized before coding.

2. Khalti’s Component Diagram

   • UML Used: Component diagram with UserAuth, TransactionService, Notification.
   • Why: Helps developers see dependencies (e.g., TransactionService needs BankAPI).

3. Daraz’s Order State Machine

   • UML Used: State diagram for Order states: Placed → Processing → Shipped → Delivered.
   • Why: Prevents lost orders by modeling transitions (e.g., "Cannot ship if PaymentFailed").

4. Ncell’s Deployment Diagram

   • UML Used: Shows base stations, central server, and BillingSoftware artifact.
   • Why: Ensures scalability (e.g., adding more base stations for Kathmandu traffic).

5. Pathao’s Use Case Diagram

   • UML Used: Actors Customer, Driver, Admin with use cases like Book Ride.
   • Why: Validates requirements (e.g., "Does the driver need to accept rides?").

Common Pitfalls and How to Avoid Them

Practice Questions (Exam-Style)

1. Draw a class diagram for a bank ATM system with classes Customer, Account, ATM, and Transaction. Use inheritance for SavingsAccount and CurrentAccount.
2. Explain how MDA helps in developing WhatsApp’s backend. Include a transformation step.
3. Model the state transitions of a Daraz order from Placed to Cancelled. What event triggers Cancelled?
4. Compare structural and behavioral diagrams using a table. Give one Nepalese app example for each.
5. Why would NTC use a deployment diagram? Draw a simple version with 3 nodes.

Final Note: UML is not just for exams—it’s how real engineers (at Google, Khalti, or Ncell) design systems. Master the diagrams, and you’ll stand out in interviews too!