Kruchten’s 4 + 1 views of Software Design
Software Design Expression Categorisation Framework
Whenever we design software, we try to describe its design; the description may be in terms of words (document), visual (diagram) or demonstration.
In the internal description, a single representation of an architectural view of an application cannot meet the eyes of all associated various skilled stakeholders (Management, Infrastructure, Product Managers, Developers).
Every Stackholder is only interested in some part of a software design information.
Philippe Kruchten defined an information organisation framework named 4+1 Views Model to capture the description of Software Implementation or Architecture into multiple concurrent views.
A ViewModel is a subpart of the overall software implementation description knowledge and targets a subset of your audience.
4+1 Views Model
4+1 views model is an information organisation framework; it consists of logical, process, development, physical information perspectives of an application and end-user perspective information.
A view is an aspect (subpart) of information.
A notion is a way of representing information.
It is usual to find a single type of notation is used in multiple views. Views do not enforce any notion.
1. Logical View captures the functional requirements of the application as decomposition of structural elements or abstractions.
For Software Engineers
- Object Decomposition is the art of decomposing the application behaviour into classes and package. It is the base of functional analysis in case of Object-Oriented Paradigm.
UML Class Diagrams and UML Package Diagrams can be used to represent classes and packages respectively.
- Data Modelling is the analysis of data gathering and organising data into logical entities.
ER diagram is a well-known notation to represent business entities and relationships
- System and subsystems — the breaking down of application into modules and arrangement of their responsibilities and relationships.
UML Component diagram can be used.
2. Process View captures the process, behaviour, task concurrency and flow of information and non-functional aspects.
- States Transition can be used to understand state and transition in case of a workflow-based system.
UML State Diagram is used to represent state and state transition.
- The Flow of Information can be abstracted or represented in details. The granularity of information depends on the application.
Data Flow Diagram (DFD), Application Prototype (UX), UML Activity and UML Sequence diagram are used to represent the various level of flow information.
- Process Decomposition represents runtime partitioned application decomposition. It can be called Service Decomposition for network partitioned processes.
- Non-functional aspects like Integrity, Fault Tolerance, Availability, and Concurrency. These are easier to put in words than in diagrams.
3. Development View focuses on the management of an application.
For Management & Developers
- Teams Organisation — Roles and Responsibilities of team members
- Development Methodology is a way of development workflow implementation. Agile Methodologies are popular these days.
Tip: It is crucial to have agility than Agile Framework.
Popular Agile Methodologies Framework: Scrum, XP, Kanban …
- Development Standards — Set of guidelines & coding standards, automation tools.
e.g. VCS System and their branching system, CI, Deployment Automation, Code Linting, Code Style
- Test Planning of developed Application.
How do you test? Automation or Manual or hybrid?
What do you test ? — Scope of test ?
How do you record test step sequences?
- Work logs and Tracker system to manage and track tasks.
JIRA, Asana, Harvest are popular commercial tools.
- Road-maps give ideas about deliverables.
4. Physical View represents the deployment layout or infrastructure of an application. It also concerns non-functional aspects like availability and scalability.
- Topology Architecture
The cluster of application instances and their places in the geography of physical or virtual machine available.
UML deployment diagram, Network diagram are standard options.
- System Capacity of the application
- Configuration Management
Tip: It is essential to keep configuration out of the application and build a workflow to change the configuration to have a higher degree of observability and flexibility.
Use Cases captures an End-User Perspective into a systematic, logical information structure. It complements all other views and is used to validate them.
For Every Stakeholder
Stories (Agile) are used for detailed level; the combination of textual documents is used with UML Sequences, Actor diagrams, Prototypes…
4+1 Model Views covers much of the software if done right. It is not strict; You can skip any view or subview which does not make any sense in expressing your software design.
4+1 Views Model is too result-oriented. Views only represent the results of decisions which may not be evident over time or to the people who were not part of the original design discussion. This problem can be solved including an additional view: Architecture Decision View.
Architecture Decision View captures contextual knowledge behind any architectural decision. It focuses on causation and circumstances that lead to decisions.
Architecture Decision Record (ADR) is one of the implementations which can be found at:
The Original Paper
You can also read the original paper of 4+1 Views Model at:
The more you clap, the more this article find its audience, or you want to keep it to yourself.