Saturday, May 7, 2011

The “4+1” View Model of Software Architecture

In November 1995, while working as Lead software architect at Hughes Aircraft Of Canada Philippe Kruchten published a paper entitled: "Architectural Blueprints—The “4+1” View Model of Software Architecture". The intent was to come up with a mechanism to separate the different aspects of a software system into different views of the system. Why? Because different stakeholders always have different interest in a software system. Some aspects of a system are relevant to the Developers; others are relevant to System administrators. The Developers want to know about things like classes; System administrators want to know about deployment, hardware and network configurations and don't care about classes. Similar points can be made for Testers, Project Managers and Customers. Kruchten thought it made sense to decompose architecture into distinct views so stakeholders could get what they wanted. In total there were 5 views in his approach but he decided to call it 4 + 1. We'll discuss why it's called 4 + 1 later! But first, let's have a look at each of the different views.

  • The logical view
    This contains information about the various parts of the system. In UML the logical view is modelled using Class, Object, State machine and Interaction diagrams (e.g Sequence diagrams). It's relevance is really to developers.
  • The process view
    This describes the concurrent processes within the system. It encompasses some non-functional requirements such as performance and
    availability. In UML, Activity diagrams - which can be used to model concurrent behaviour - are used to model the process view.
  • The development view
    The development view focusses on software modules and subsystems. In UML, Package and Component diagrams are used to model the development view.
  • The physical view
    The physical view describes the physical deployment of the system. For example, how many nodes are used and what is deployed on what node. Thus, the physical view concerns some non-functional requirements such as scalability and availability. In UML,
    Deployment diagrams are used to model the physical view.
  • The use case view
    This view describes the functionality of the system from the perspective from outside world. It contains diagrams describing what the system is supposed to do from a black box perspective. This view typically contains Use Case diagrams. All other views use this view to guide them.

Why is it called the 4 + 1 instead of just 5?
Well this is because of the special significance the use case view has. When all other views are finished, it's effectively redundant. However, all other views would not be possible without it. It details the high levels requirements of the system. The other views detail how those requirements are realised.

4 + 1 came before UML
It's important to remember the 4 + 1 approach was put forward two years before the first the introduction of UML which did not manifest in its first guise until 1997. UML is how most enterprise architectures are modelled and the 4 + 1 approach still plays a relevance to UML today. UML 2.0 has 13 different types of diagrams - each diagram type can be categorised into one of the 4 + 1 views. UML is 4 + 1 friendly!

So is it important?
The 4 + 1 approach isn't just about satisfying different stakeholders. It makes modelling easier to do because it makes it easier to organise. A typical project will contain numerous diagrams of the various types. For example, a project may contain a few hundred sequence diagrams and several class diagrams. Grouping diagrams of similar types and purpose means there is an emphasis in separating concerns. Sure isn't it just the same with Java? Grouping Java classes of similar purpose and related responsibilities into packages means organisation is better. Similarly, grouping different components into different jar files means organisation is better. Modelling tools will usually support the 4 + 1 approach and this means projects will have templates for how to split the various types of diagrams. In a company when projects follow industry standard templates again it means things are better organised.

The 4 + 1 approach also provides a way for architects to be able to prioritise modelling concerns. It is rare that a project will have enough time to model every single diagram possible for an architecture. Architects can prioritise different views. For example, for a business domain intensive project it would make sense to prioritise the logical view. In a project with high concurrency and complex timing it would make sense to ensure the process view gets ample time. Similarly, the 4 + 1 approach makes it possible for stakeholders to get the parts of the model that are relevant to them.


  1. Architectural Blueprints—The “4+1” View
    Model of Software Architecture Paper

  2. Learning UML 2.0 by Russ Miles & Kim Hamilton. O'Reilly


  1. Nice blog! Haven't seen the 4+1 approach to date. Can't help but wonder though given Agile's grip on the industry and it's tendency to avoid UML, is there still life left in 4+1?

  2. @callahj4

    Good point.

    Even forgetting about Agile for a sec, code should be self describing and well javadoc'd and this should negate a lot of need for UML.

    But, I agree with you about Agile's tendency to avoid UML. Martin Fowler put it very well when he said there common ways to use UML:

    1. As a sketch - using UML to convey key points.
    2. As a blueprint
    3. As a programming language

    There is still a lot of room for UML in the 'as a sketch' category in Agile methodology. For example, say you are introducing a new component and new classes into your system to provide a new a feature. You can do the diagrams quickly and communicate complex ideas without ending up in analysis paralysis.

    But, the 4 + 1 approach still has some relevance in Agile. There is still a sense of separation in concerns; for example between say Deployment and Class diagrams. Even though these both are driven by the same Use Case requirements they have different purposes and meant to convey completely different characteristics of your architecture.

  3. I have heard that logic view is for end-users as it captures functional aspects of the system - in terms what system will provide to end user, but you mentioned that its more relevant to developers, please clear my confusion.

  4. Thank you for mentioning which UML diagrams goes with each view. really appreciate it.