Skip to content
Software Architecture Guide

Architecture View Model

Explanation

Section titled “Explanation”

A complex system cannot be captured in one model. Rozanski and Woods warn against a single, overloaded, all-encompassing model. They split the architecture description into separate but related views. Each view describes one aspect of the architecture.

A viewpoint is a collection of patterns, templates and conventions for building one type of view. (See Architecture Viewpoint and Architecture View.) A view model is a set of viewpoints chosen to work together, so architects can reuse it instead of inventing their own. The IEEE standard does not prescribe a fixed set of views. Rozanski and Woods therefore offer a catalog of core viewpoints. (See ISO/IEC/IEEE 42010 Architecture Description Standard.)

Kruchten’s 4+1 model was introduced in a 1995 IEEE Software article, “Architectural Blueprints”. It describes software-intensive systems through multiple concurrent views:

  • The logical view covers the functionality offered to end users.
  • The development view, also called the implementation view, shows the system from a programmer’s perspective.
  • The physical view, also called the deployment view, shows the system from a system engineer’s perspective.
  • The +1 is a small set of scenarios (use cases). They illustrate the architecture and form a fifth view.

(See 4+1 View Model for the full model.)

RM-ODP defines five complementary viewpoints. The enterprise viewpoint covers purpose, scope and policies. The information viewpoint covers what the information means and how it is processed. The technology viewpoint covers the technology choices made for the system.

The Zachman Framework is a matrix. Its columns are communication interrogatives and its rows are reification transformations. (See Zachman Framework.)

Other approaches are related but differ in kind. C4 is a diagramming approach with hierarchical diagrams: context, containers, components and code. It does not depend on a notation, and it is not a formal view model. arc42 has a building block view that shows the static decomposition. It is mandatory in every architecture documentation. Runtime views and crosscutting concepts complement it.

Example

Section titled “Example”

A team building an online shop adopts a 4+1-style set of views. One view lists the features customers use. Another shows how developers organize the code. A third shows the servers the shop runs on. A few scenarios, such as “customer places an order”, tie the views together. When a reviewer asks “where do we describe hosting?”, the answer is already in the set.

Trade-offs

Section titled “Trade-offs”

A view model gives you proven viewpoints, so you do not start from a blank page. A single overloaded model is the risk it helps you avoid. Several views also mean more documents to keep consistent. Models differ in kind: C4 is a diagramming approach, not a formal view model, and arc42 pairs a mandatory building block view with other views. The facts here do not say which model is best, so pick one that fits your system and stakeholders.

Checks

Section titled “Checks”
  • The documentation states which set of viewpoints (view model) it uses, rather than an ad hoc collection of diagrams.
  • Each view covers one aspect of the architecture and is not an overloaded all-in-one model.
  • If 4+1 is used, a small set of scenarios is included to illustrate the architecture.
  • The building block view is present, since arc42 requires it in every architecture documentation.
Section titled “Related”

Sources

Section titled “Sources”