Working Page for the Views & Viewpoints Working Group – All Materials are DRAFT. 


The “4+1” viewpoint set is one of the earliest set of software architecture viewpoints to be defined, being the result of the approach that Rational consultants used in the early 1990s when working with customers on Rational Unified Process (RUP) based projects.

The original definition of the set can be found in an IEEE Software article [1] dating from 1995. Arguably this reference has been one of the most important in popularising the idea of architectural viewpoints.

Rational developed the 4+1 model further within their RUP framework (for example later adding a “Data” view), but this is not publically available as it was part of the licensed documentation product sold as the Rational Unified Process. Hence we limit our discussion to the viewpoint set as defined in the original Software article.

The Viewpoints

As its name suggests, there are four viewpoints in this viewpoint set, which are outlined in Table 1.

Viewpoint Definition
Logical The logical representation of the system’s functional structure, normally presumed to be a class model (in an object-oriented systems development context). However for many modern systems, you might expect a component or service model of some sort. The key point is that the view needs to illustrate the names, responsibilities and interactions of the functional processing elements of the system.
Process The concurrency and synchronization aspects of the architecture. This involves identifying process and thread structures along with the inter-process communication mechanisms needed to exchange data and particular coordinate parallel execution between processes and threads.
Development The design-time software structure, identifying modules, subsystems, and layers and the concerns directly related to software development.
Physical The identification of the runtime environment that the system’s software will be executed on and the mapping of other architectural elements to the elements of this environment.


As is obvious from the original article, the original use for the 4+1 viewpoints was the software for systems engineering projects like telephone PABX products and an air traffic control system, because these are the types of projects that many Rational consultants worked on. However, as the original article says, “The 4+1 View Model is rather generic: You can use notations and tools other than those we describe, as Figure 1. The 4+1 View Model is well as other design methods” and it has been applied across a wide range of domains by choosing appropriate modelling approaches within each view (although while the original paper has been widely cited, references of practical use are scarce in the formal literature).

Therefore 4+1 is applicable to most types of software project, provided that the architect is prepared to think carefully about the types of model required in each view and they can use the viewpoints without extensive examples being available.

General Advice

  • When using 4+1, think carefully about the models that you will use in each view as the viewpoint set’s definition is not very prescriptive about this.
  • Start with the Logical view to gain an understanding of what the system needs to do and how it will be partitioned into functional elements. Be sure to clearly define names, responsibilities and interactions between elements.
  • With a Logical view available, then if a complex concurrency model is required, move on to create a Process view, defining how the functional elements are packaged into concurrency containers (such as processes and threads) and how the concurrency containers coordinate their activity with IPC mechanisms.
  • The Development view is intended to capture all of the architectural concerns related to software development so this is where the software module structure (i.e. code structure) can be defined.
  • The Physical view addresses the runtime environment for the system and so can be used to define the runtime platform in terms of compute, network and storage that the system requires, along with its software dependencies and how the system’s elements will be mapped to the runtime environment’s elements.
  • Use Scenarios to analyse and explore your architecture as it emerges, to ensure that it supports its key functional scenarios effectively. While not explicitly mentioned in the original paper, it is also important to use scenarios for system quality properties like performance or scalability.


[1].  Kruchten, Philippe, Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50, November 1995.


Eoin Woods