Views and viewpoints: ISO/IEC/IEEE 42010, 4+1 and Rozanski and Woods

One system, many views

No single diagram can describe a real system. A drawing that shows how the food-delivery platform's code is divided into modules says nothing about which servers they run on; a drawing of servers and networks says nothing about what happens, step by step, when a courier accepts a job. If you try to put all of this on one page you get the familiar architecture poster: dozens of boxes, lines meaning six different things, and nobody able to answer a precise question from it.

The idea that resolves this is old and simple. Describe the system through several views, each showing one set of structures for one set of concerns, just as a building is described by a floor plan, an elevation, a wiring plan and a plumbing plan. Each is a partial description; together they describe the whole. This idea underpins the international standard, Kruchten's 4+1 model, Rozanski and Woods's viewpoint catalogue, the SEI's Views and Beyond approach and, in a lightweight form, the C4 model in the next section. This section explains the vocabulary they share and how to choose the views a particular system needs.

Recall from Section 1.5 that a stakeholder is anyone with an interest in the system and a concern is any matter of importance to a stakeholder. Views exist to answer concerns. A view that answers nobody's concern is decoration.

The ISO/IEC/IEEE 42010:2022 conceptual model

ISO/IEC/IEEE 42010 is the international standard for architecture description. Its current edition was published in 2022 and replaced the 2011 edition. It does not tell you how to design, which notation to use or which views to draw; it defines the concepts an architecture description should contain and how they relate, so that descriptions produced by different methods can be compared and checked. Its conceptual model is the common skeleton of almost every documentation approach in this chapter.

The model starts with the entity of interest: the thing whose architecture is described, which can be a software system, a system of systems, a product line or an enterprise (the 2011 edition called it the system of interest). The entity has an architecture, and an architecture description expresses it. Inside the description, stakeholders have concerns. A viewpoint is a reusable specification of conventions for constructing and using one kind of view: it names the concerns it frames, the typical stakeholders, and the model kinds (notations and modelling conventions) to use. A view applies a viewpoint to a particular entity: it addresses those concerns for this system, and is made of view components, such as diagrams, tables and models, each governed by a model kind (the 2011 edition called view components architecture models).

Two further elements matter in practice. Correspondences record relations between elements of the description, most usefully between views: this container in the container view runs on that cluster in the deployment view; this requirement is addressed by that decision. And architecture decisions and their rationale are part of the description, linked to the concerns they address. The 2022 edition also defines more fully two concepts the 2011 edition already mentioned, stakeholder perspectives (ways of grouping concerns) and architecture aspects (characteristics of the entity that cut across views), renames "architecture framework" as architecture description framework, and defines what conforming architecture description frameworks, such as a company's own documentation template, must contain.

Kruchten's 4+1 view model

Philippe Kruchten, then at Rational Software, published Architectural Blueprints: The "4+1" View Model of Software Architecture in IEEE Software in November 1995. The 4+1 view model was the first widely adopted multi-view approach and became part of the Rational Unified Process. Kruchten's argument was that the single diagrams of the day tried to capture too much at once, and that different stakeholders (end users, developers, system engineers, project managers) need different views.

The four views are these. The logical view describes the functionality the system provides to end users, typically as the key abstractions and their relationships (in UML, class and state diagrams). The process view addresses runtime concerns: processes and threads, concurrency, distribution, performance, scalability and fault tolerance. The development view (also called the implementation view) describes the organisation of the software in its development environment: modules, subsystems, layers and their dependencies, which matter to programmers and to managers planning the work. The physical view (or deployment view) maps the software onto hardware and networks. The "+1" is the scenarios: a small set of important use cases, each traced through all four views, which both illustrate the architecture and validate that the views fit together.

The scenarios are the part most often forgotten and arguably the most valuable. A view in isolation can look tidy while hiding a gap; walking one real scenario such as "customer places an order" through the logical, process, development and physical views exposes missing elements and inconsistent assumptions. The same idea reappears in the runtime view of arc42, in C4 dynamic diagrams and, in Section 4.8, in the advice to explain a system by following one request.

Rozanski and Woods: viewpoints and perspectives

Nick Rozanski and Eóin Woods's Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (2nd edition, Addison-Wesley, 2012) offers a catalogue of seven viewpoints aimed at large information systems, together with a second, complementary idea: perspectives.

Their seven viewpoints are: context (the system's relationships with people, systems and external entities around it), functional (the runtime functional elements, their responsibilities, interfaces and primary interactions), information (how data is stored, managed, owned and distributed), concurrency (which parts run concurrently and how they are coordinated), development (what developers, testers and builders need: module structure, common processing, standards and codeline organisation), deployment (the runtime environment and how software maps onto it) and operational (how the system is installed, migrated, administered, monitored and supported in production).

A perspective is their name for a quality concern that cuts across all views, such as security, performance and scalability, availability and resilience, or evolution (their catalogue also includes accessibility, development resource, internationalisation, location, regulation and usability). A perspective is not another view to draw. It is a set of questions, tactics and checks applied to every view: for security, you examine the context view for external actors and trust boundaries, the information view for sensitive data, the deployment view for network zones, and so on. This captures something single views cannot: qualities emerge from the whole system, so they have to be checked everywhere (compare Chapter 2's quality models).

The operational viewpoint deserves particular attention because many approaches underplay it. Who installs the system, how data is migrated from the old one, how configuration is managed, what operators monitor and how they are alerted: these are architectural questions whose answers shape the system, and leaving them until just before go-live is a classic cause of failed launches.

The SEI's three categories: module, component-and-connector, allocation

Chapter 1 introduced the SEI's grouping of structures into three kinds (see Section 1.1). Documenting Software Architectures: Views and Beyond uses the same grouping to organise views, and it is the most useful way to check that a set of views is complete.

Module views show units of implementation (packages, libraries, namespaces) and relations such as is part of, depends on and is a. Typical styles are decomposition, uses, generalisation, layered and data model views. Component-and-connector (C&C) views show the elements present at runtime (services, clients, databases, queues) and the connectors through which they interact (HTTP calls, messages, shared data); typical styles include client-server, publish-subscribe, pipe-and-filter, shared-data and multi-tier. Allocation views map software elements onto non-software things: onto hardware and cloud infrastructure (deployment), onto the file system and build artefacts (implementation and install) and onto teams (work assignment).

The three categories map naturally onto the other approaches. Kruchten's development view is a module view, his process view a C&C view and his physical view an allocation view. Rozanski and Woods's functional and concurrency viewpoints are mostly C&C, their development viewpoint is module, and their deployment and operational viewpoints are allocation. The C4 container and component diagrams of the next section are C&C views with some module flavour, and C4 deployment diagrams are allocation views. When you assemble a documentation set, check that it contains at least one view from each category, because each answers questions the others cannot.

Mapping stakeholders and concerns to views

The most practical tool from the standard is a simple table: list the stakeholders and their main concerns, then name the view or views that address each concern. Gaps (a concern no view addresses) show where the description is incomplete; views no one needs are candidates for deletion. The table below is a first pass for the food-delivery platform.

Choosing the minimum set of views

The temptation, once you know that many viewpoints exist, is to produce all of them. Resist it. Every view has to be kept consistent with the system and with the other views, so each one adds a maintenance cost. The aim is the smallest set of views that answers the important concerns of the important stakeholders, following the rule from Section 4.1 to write for the reader. Views and Beyond describes a similar procedure: build a stakeholder-and-view table, combine views where one diagram can serve several needs, then prioritise.