The 4+1 View Model

No single diagram can capture every aspect of a complex system. So architects split the description into a collection of views, each giving a partial, purpose-built picture to a specific stakeholder (users, analysts, developers...).

The most popular model for organizing these views is Philippe Kruchten's 4+1 View Model (1995).

Four views describe the system from four independent angles. The +1 (User/Scenario) view isn't a fifth equal view — it's a set of use cases that keeps the other four consistent with each other and validates the whole design against real usage.

Specifies the system's decomposition into conceptual entities (objects/classes) and how they connect — essentially an abstraction of the system's functional requirements.

ATM example — Class Diagram

Shows the classes, their inter-relationships, and each class's operations & attributes. A few notation rules worth memorizing:

• Directional arrows — point from the class that initiates an action to the one it affects (e.g. ATM Transaction → Account).
• Inheritance — a line with a hollow triangular arrowhead, pointing from subclass up to superclass (e.g. Current Account & Saving Account → Account).
• Names above arrows — describe the relationship (e.g. "Maintains" from Bank to ATM Info = each Bank maintains one or more ATMs).
• Multiplicities — numbers near the lines, e.g. 1..* = one-to-many, 1 = exactly one.
• Bidirectional associations — shown with either two arrows or no arrows at all.

ATM example — Collaboration (Communication) Diagram

Focuses on who talks to whom: Bank Client ↔ ATM Machine ↔ Account/Checking Account. The numbered messages trace one full transaction — insert card → request/enter PIN → request/enter amount → process against the account → dispense cash → print receipt.

ATM example — Sequence Diagram

Models interactions over time: same actors, but now ordered top-to-bottom by exact message sequence.

Focuses on the system's execution-time behavior — an abstraction of processes/threads, showing synchronization and concurrency, and how all execution units are organized at runtime.

Feeds directly into non-functional requirements like scalability and performance. Modeled with UML activity diagrams and interaction overview diagrams.

ATM example: the activity diagram traces card validation → PIN entry → balance check → cash dispensing / account debit, running in parallel swim-lanes for Customer, ATM Machine, and Bank.

Describes the software's static organization into modules — class libraries, sub-systems, packages — from an implementation point of view: how source code is organized into modules, packages, and libraries.

Modeled with UML package diagrams and component diagrams. Useful for mapping logical components down to physical files and directories.

Represents deployment aspects — configuration and installation — modeled with UML deployment diagrams.

This is the view to reach for when evaluating:

ATM example: physical nodes — Customer Console, Card Reader, ATM Machine, Bank Database, Web Page, Client Desktop, Employee Console — connected as deployed hardware, mirroring the development view's components but now showing where they physically run.

Describes the system's functionality — how the user uses it, and how the system serves the user. It's the foundation that lets the other four views work together seamlessly and logically.

• Helps designers discover architectural elements during design.
• Helps validate the architecture afterward.
• Keeps the whole architecture consistent against both functional and non-functional requirements.

Modeled with use-case diagrams and textual scenarios.

ATM example: a Bank Client actor triggers "Bank ATM Transaction," which extends into Checking Transaction, Saving Transaction History, Deposit Amount, and Withdrawal Amount — each of which uses an Approval Process, which itself extends to handle an Invalid PIN case.