4+1 Architectural View Model

The 4+1 view model, published by Philippe Kruchten in IEEE Software in 1995, describes a software architecture through four concurrent views plus a set of scenarios that tie them together. Its premise is that one diagram cannot serve every stakeholder, because different readers are asking different questions.

The four views divide as follows. The logical view is organized around the functionality the system provides. The process view addresses execution concurrency and distribution: which processes or threads run independently, how they communicate, and where they synchronize. For example, two workers updating the same order need an ordering or synchronization rule. These design questions affect performance and availability; concurrency and request rate as load measures describe the workload those processes must handle, not their synchronization design. The development view describes how the software is organized into modules in the development environment. The physical view maps software onto processing nodes and is shaped mainly by non-functional requirements — what this site calls quality requirements. Kruchten expects several different physical configurations of the same system, some for development and testing and others for particular sites or customers, so the mapping of software to nodes needs to be flexible and have minimal impact on the source code.

Scenarios supply the additional view. Kruchten uses selected use cases both to drive design and to validate and illustrate it. Following an order submission can reveal the logical responsibilities needed, the workers that communicate, their source modules, and the nodes on which they run. Replaying that scenario against the resulting views then checks whether those choices fit together. Scenarios therefore help discover the architecture as well as test its consistency.

A useful distinction in the model is that what the parts are and what they are responsible for is a different description from where instances of them run. Folding both into one diagram is how a design can be logically sound and still violate a residency rule, or be redeployed without any change to its logical structure.

Later notations draw the same boundary in lighter form. The C4 model separates container diagrams from deployment diagrams because the container diagram says little about deployment, which varies across environments, and the deployment diagram places instances of those containers onto infrastructure, one diagram per environment.

How these views fit alongside a third description — who operates each part — is worked through in Architecture Levels and the Scope of a Decision.

References

• Philippe Kruchten, Architectural Blueprints—The 4+1 View Model of Software Architecture (1995, author copy)
• C4 model, Container diagram
• C4 model, Deployment diagram