4+1 View Model

Philippe Kruchten’s multi-perspective model for software architecture

1. Overview: A model that separates architectural concerns per stakeholder across 5 views

    flowchart LR
    A["Single diagram tries<br/>to express everything<br/>(complex, ambiguous)"] --"Separate concerns<br/>into 5 views"--> B["Logical, Process, Physical,<br/>Development, Scenario views"] --"Tailored communication<br/>per stakeholder"--> C["Architectural clarity<br/>and consensus achieved"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: A software architecture representation framework proposed by Philippe Kruchten that separates a complex system into four views — Logical, Process, Physical, and Development — plus a Scenarios view (the “+1”) that validates them, systematically communicating stakeholder-specific concerns.

Characteristics: (Multi-perspective separation) Splits a single architecture into multiple views, so each stakeholder can focus on just the perspective they need. (Use case view as glue) The Scenario (Use Case) view acts as the glue that connects and validates the other four views. (UML alignment) Naturally maps to UML diagrams, making it a practical standard for software design documentation.

2. Core structure of the 4+1 View Model

A. The five views

    flowchart TD
    SC(["Scenario View<br/>(Scenarios / Use Case)<br/>Validates and connects<br/>the other 4 views via use cases"])

    subgraph R1["　"]
        direction LR
        LV["Logical View<br/>Functional decomposition,<br/>class and object design"]
        PV["Process View<br/>Runtime processes,<br/>threads, concurrency"]
    end
    subgraph R2["　"]
        direction LR
        PHV["Physical View<br/>Servers, network,<br/>deployment infrastructure"]
        DV["Development View<br/>Modules, components,<br/>package structure"]
    end

    SC --> LV
    SC --> PV
    SC --> PHV
    SC --> DV

    style SC  fill:#1E3A5F,stroke:#1E3A5F,color:#fff
    style LV  fill:#E3F2FD,stroke:#1976D2,color:#000
    style PV  fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style PHV fill:#FFF3E0,stroke:#F57C00,color:#000
    style DV  fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none

View	Concern	Key representation elements	Target stakeholders
Logical View	How functional requirements are met, object-oriented decomposition	Class diagrams, sequence diagrams	End users, designers
Process View	Runtime behavior, concurrency, performance, availability	Activity diagrams, state diagrams	System integrators, performance engineers
Physical View	Mapping of software to hardware, deployment configuration	Deployment diagrams, infrastructure diagrams	System engineers, DevOps
Development View	Software module organization, build and management ease	Component diagrams, package structure	Developers, project managers
Scenario View	Validates consistency across the 4 views via use cases	Use case diagrams, scenario descriptions	All stakeholders

B. Stakeholders per view and architecture documentation

    flowchart LR
    subgraph STAKE["Views of interest per stakeholder"]
        direction TB
        S1["End users<br/>→ Logical + Scenario views"]
        S2["Developers<br/>→ Development + Logical views"]
        S3["System engineers<br/>→ Physical + Process views"]
        S4["PM / Architects<br/>→ All 5 views integrated"]
    end

    subgraph DOC["Mapping to UML diagrams"]
        direction TB
        D1["Class / sequence diagrams<br/>(Logical View)"]
        D2["Activity / state diagrams<br/>(Process View)"]
        D3["Deployment diagrams<br/>(Physical View)"]
        D4["Component / package diagrams<br/>(Development View)"]
    end

    STAKE --- DOC

    style STAKE fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style DOC   fill:#E8F5E9,stroke:#388E3C,color:#1B5E20

Applying architecture documentation in practice

Stage	Activity	Deliverable
Requirements analysis	Identify stakeholders and list their concerns	Stakeholder list, use case list
Scenario derivation	Select key use cases (10–20% of the total)	Use case diagrams, scenario descriptions
Per-view design	Design the 4 views sequentially, driven by scenarios	Set of UML diagrams per view
Consistency validation	Use scenarios to check for conflicts or gaps across the 4 views	Architecture review report
Documentation & delivery	Provide stakeholder-tailored architecture documentation	SAD (Software Architecture Document)

3. Expected benefits and practical application of the 4+1 View Model

Category	Key expected benefit	Practical application
Clearer communication	Minimizes misunderstanding by providing a tailored perspective per stakeholder	Link with TOGAF ADM when building EA to structure deliverables
Complexity management	Separates and manages large-system architecture by concern	Apply per-service 4+1 views in MSA design to visualize dependencies
Quality validation	Scenario-based validation detects design gaps and conflicts early	Reflect 5-view completeness criteria in architecture review checklists
Documentation standardization	Natural alignment with UML produces consistent architecture documents	Provide a 4+1 view structure via the SAD template at project kickoff

ArchiMate Layered Architecture