Phase 2 of 5  ·  Design & Modeling
Week 05 / 20   ·   Ch 5

System
Modeling (UML)

"5 UML diagrams every junior developer should know"

📚 Ch 5 — System Modeling📊 5 Key UML Diagrams🏗️ Model-Driven Architecture⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

👤

Use Case Diagrams

Show interactions between actors (users/systems) and the system. WHAT the system does, not HOW.

When to Use

Requirements phase — show system scope and actor relationships.

Real-World Example

E-commerce system: actors = Customer, Admin, Payment System. Use cases = Browse Products, Checkout, Process Refund.

✓ Advantages

  • Non-technical stakeholders understand them
  • Defines system boundary clearly
  • Links to test cases

⚠ Watch Out

  • No detail on behavior or data
  • Easy to make too big or too small
Use case diagram — actors & system interactions
Actors
  • Customer
  • Admin
  • Payment System
Use Cases
  • Browse products
  • Checkout
  • Track order
  • Manage products
Actors sit outside the system boundary; use cases describe what they can do.
🗂️

Class Diagrams

Show classes, attributes, methods, and their relationships (inheritance, association, composition).

When to Use

Design phase — defines the data model and object relationships.

Real-World Example

Every ORM (Django models, Rails ActiveRecord, Hibernate) is derived from a class diagram.

✓ Advantages

  • Direct translation to code
  • Shows data structure clearly
  • Foundation for database design

⚠ Watch Out

  • Static — doesn't show behavior over time
  • Can become outdated quickly
Class diagram — structure & relationships
Customer
  • + id
  • + email
  • + login()
Order
  • + orderId
  • + total
  • + cancel()
One Customer has many Orders  (1 → *) — attributes sit above methods.
🔄

Sequence Diagrams

Show interactions between objects OVER TIME — the order of messages, calls, and responses.

When to Use

Design phase — trace a specific scenario through the system (e.g., login flow, payment processing).

Real-World Example

Documenting API call flows, debugging async issues, designing microservice communication.

✓ Advantages

  • Shows exact call order
  • Great for debugging complex flows
  • Reveals timing issues

⚠ Watch Out

  • Becomes complex for many objects
  • Static snapshot, not dynamic
Sequence diagram — messages over time
Browser
Server
Database
1Browser → Server: GET /login
2Server → DB: SELECT user
3DB → Server: returns the user row
4Server → Browser: 200 + token
📋

Activity Diagrams

Show the flow of activities in a process — like a flowchart with parallel activities and decision points.

When to Use

Modeling business processes, workflows, algorithms.

Real-World Example

E-commerce checkout: 'Add to cart → Choose shipping → Enter payment → Validate → Confirm OR Error'.

✓ Advantages

  • Easy for non-technical stakeholders
  • Shows parallel activities
  • Good for business processes

⚠ Watch Out

  • Can become very complex
  • Overlaps with flowcharts
Activity diagram — workflow with a decision
1Add items to cart
?Stock available?Decision point
Yes

Proceed to checkout

No

Show “out of stock”

🔀

State Diagrams

Show the states an object can be in and the events that trigger transitions between states.

When to Use

Modeling objects with distinct states — order status, user account, device state.

Real-World Example

Order: Created→Confirmed→Shipped→Delivered→Cancelled. Each state has valid transitions.

✓ Advantages

  • Perfect for event-driven systems
  • Reveals impossible state combinations
  • Maps to state machine code

⚠ Watch Out

  • Only useful for stateful objects
  • Can explode in complexity
State diagram — order lifecycle
Created
Confirmed
Shipped
Delivered
Transitions fire on events: confirmed → shipped → delivered. From Confirmed, an order can also be Cancelled.

📋Quick Reference

θ Ch 5 Cheat Sheet — System Modeling (UML)
Use Case Diagram
WHO does WHAT with the system. Actors + use cases + system boundary. Requirement communication.
Class Diagram
Classes, attributes, methods, relationships. Blueprint for code/database. Design phase.
Sequence Diagram
Object interactions OVER TIME. Call order, messages, responses. Trace one scenario.
Activity Diagram
Workflow/process flow with decisions and parallel paths. Like a smart flowchart.
State Diagram
Object states + transition events. For stateful objects (orders, accounts, devices).
Model-Driven Architecture
Use models as primary artifacts. CIM → PIM → PSM → Code. More formal, less common.
When to model
Use diagrams to communicate, not to document everything. Build what helps your team.
θ
Sommerville's Key Points — Ch 5
Author's own summary from the end of the chapter.
  • 1System models are abstract representations — they simplify reality to answer specific questions.
  • 2Context models show the system boundary and what's external to it.
  • 3Use case diagrams: show interactions between actors and system — for requirements communication.
  • 4Class diagrams: show structure — classes, attributes, methods, and relationships.
  • 5Sequence diagrams: show interactions over time — great for tracing specific scenarios.
  • 6Activity diagrams: workflow and process flows with decisions and parallelism.
  • 7State diagrams: object lifecycle — states and events that cause transitions.
  • 8Model-Driven Architecture (MDA): platform-independent models that generate code.

🌍From the Book & Beyond

📖

Case Study — Modeling Involuntary Detention in Mentcare

The chapter's most striking model is Figure 5.2, a UML activity diagram of involuntary detention: mental health patients who are a danger to themselves or others may be detained against their will, under strict legal safeguards with regular review. The diagram branches on [dangerous] vs. [not dangerous] — a secure facility (or police station if none is available) versus a hospital ward — then a coordination bar fans out to informing social care, informing next of kin, and updating the detention register in parallel. One diagram captures law, ethics, and two «system» boxes in a single page.

2026 Perspective — UML Faded, Diagrams-as-Code Won

Honest update: almost nobody draws all 13 UML diagram types anymore, and heavyweight CASE tools are gone from most teams. What survived is exactly what Sommerville emphasizes — a handful of informal sketches for communication. In 2026 those sketches live as diagrams-as-code: Mermaid renders sequence, class, and state diagrams from plain text right inside GitHub and docs, and the C4 model (context → containers → components → code) has become the go-to for architecture — its context diagram is basically Figure 5.1 reborn. The notation changed; the modeling skill this chapter teaches didn't.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
You're designing a food delivery app. Which UML diagram would you use to model: (a) what features customers and restaurants have access to, (b) the order lifecycle from placed to delivered?
(a) Use Case Diagram — shows actors (Customer, Restaurant, Driver) and use cases (Place Order, Accept Order, Update Location). (b) State Diagram — shows Order states: Placed→Accepted→Preparing→Ready→Out for Delivery→Delivered, plus Cancelled state with transitions.
Q2
Apply
What does a sequence diagram show that a class diagram cannot?
A class diagram is static — it shows structure. A sequence diagram shows dynamic behavior over time — the ORDER of messages between objects during a specific scenario. You need sequence diagrams to understand 'who calls who and when.'
Q3
Analyze
Why does Sommerville say you shouldn't try to model everything?
Models are tools for communication and understanding, not bureaucratic artifacts. Building a complete model of every aspect of a system is expensive and the models quickly go out of date. Build only the models that help your team make decisions or communicate with stakeholders.
Up Next → Week 06
Architectural Design
MVC, Layered, Microservices — your app's skeleton matters more than you think
Continue → Week 06