Understanding the 4+1 View Model of Software Architecture

Source: Authorized from JAVA Daily (ID: javadaily). Author: 飘渺Jam.

Hello everyone, I am 飘渺. Continuing the series on the architect's path.

Previously we discussed architecture description, emphasizing a human‑centric approach that presents different viewpoints for various stakeholders.

In 1995, Philippe Kruchten published the paper "The 4+1 View Model of Architecture" in IEEE Software, introducing the 4+1 view model to address this challenge.

4+1 View

The "4+1" model describes architecture from five perspectives: four primary views and a supplemental scenario view.

Logical View : Abstract structural description focusing on functionality delivered to end users.

Process View : Dynamic runtime aspects, covering processes, concurrency, synchronization, and communication.

Physical View : Mapping of software onto hardware, reflecting distributed characteristics.

Development View : Static organization of software in the development environment.

The fifth view, the Scenario view, ties the other four together by illustrating use cases.

When designing architecture, each view guides an independent decomposition of the system, producing components specific to that view's concerns.

01 Logical View

Describes functional requirements, component relationships, constraints, and boundaries, showing how the system is built.

Example: a partial logical view of a Spring Cloud microservice architecture.

02 Physical View

Describes deployment environments—servers, PCs, mobile devices, virtual machines, containers, processes, or threads—typically represented by UML deployment diagrams.

03 Process View

Also called runtime view; it describes communication sequences and data flow between components, often shown with UML sequence or activity diagrams.

04 Development View

Focuses on how architecture guides development, breaking the system into modules or packages with defined interfaces, assigning work accordingly.

05 Scenario View

The most important view, illustrating relationships between actors and use cases, reflecting final requirements and interaction design, usually depicted with UML use‑case diagrams.

Conclusion

While the 4+1 model provides a comprehensive framework, many organizations customize their own architecture templates to suit specific project needs.

Reasons for not directly adopting the 4+1 model include increased system complexity in modern distributed environments, reliance on UML diagrams that may not meet current aesthetic standards, and potential confusion among the logical, development, and process views.