4️⃣+1️⃣ Architectural View Model
Describing the architecture of software-intensive systems, based on the use of multiple, concurrent views…
History of the 4 + 1 Architectural View Model
Origin Story
Philippe Kruchten was a software developer at Rational Software Corp in 1995.
Years of building large-scale complex software systems in telecommunications, aircraft, transportation, and military had taught him that software architecture diagrams typically failed to convey the real system design. Stakeholders struggled to figure out what the boxes, lines, and arrows actually meant.
But what do the boxes, lines, and arrows mean?
In a paper released that year, titled Architectural Blueprints — The “4+1” View Model of Software Architecture, he presented a way to organize the description of a software architecture using a collection of concurrent “views,” each addressing particular issues for distinct stakeholders.
Historical Context
Since at least 1968, when the Nato Science Committee sponsored a Working Conference on Software Engineering, comparisons between software architecture and building design have been drawn. The guests talked on how to find the “correct mindset to design,” among other things. Peter Naur (the “N” in BNF) made the following suggestion:
“software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem.”
Various basic concepts were presented and improved but only implemented irregularly in the decades that followed, with many attempts to cope with the large-scale design of software systems.
The phrase “software architecture” did not become popular until the early 1990s. “Foundations for the study of Software Architecture,” by Dewayne Perry and Alexander Wolf, was published in 1992.
We believe that the 1990s will be remembered as the decade of software architecture. In contrast to “design,” we use the term “architecture” to suggest ideas of codification, abstraction, standards, formal training (for software architects), and style.
Kruchten offered his 4 + 1 views in the context of a field with decades of growth but just embryonic formalization.
Given the historical parallels with building architecture, it’s no wonder that he refers to the views as blueprints.
The Evolution
Where did the 4 + 1 views go?
Maybe the beginnings of Service-Oriented Architecture (SOA) in 1998 signaled the end? Systems were huge, sophisticated creatures in Kruchten’s article, with a lot of specialized hardware and software implementations. The emergence of SOA coincided with the rise of the web as the preferred communication channel, the introduction of commodity hardware, and an increased desire for “re-usable components” (often pre-packaged components from vendors). It’s conceivable that developers began to recognize the benefit of explicitly describing the different perspectives as time went on.
Is it possible that the rise of Extreme Programming (XP) and Agile have something to do with it?
Model Description
The 4+1 perspectives model is an information organization structure that incorporates information from an application’s logical, process, development, physical layout, and end-user perspective.
A view is an aspect (subpart) of information.
A notion is a way of representing information.
In most cases, a single kind of notation is used in numerous perspectives. Views do not compel someone to believe anything.
1. Logical View captures the functional requirements of the application as decomposition of structural elements or abstractions.
For Developers, Engineer Managers
- Object Decomposition is capturing application behavior into classes and packages. It is the base of functional analysis in the case of the Object-Oriented Paradigm.
Classes and packages may be represented using UML Class Diagrams and UML Package Diagrams, respectively.
- Data Modelling is the analysis of data gathering and organizing data into logical entities.
ER diagram is a well-known notation to represent business entities and relationships.
- System and subsystems view is 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, behavior, 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 transitions.
- Information Flow represents information routing from one entity to another entity.
Data Flow Diagram (DFD), Application Prototype (UX), UML Activity, and UML Sequence diagram represent the various flow information levels.
- Process Decomposition represents runtime partitioned application decomposition. It can be called Service Decomposition for network partitioned processes.
- Non-functional aspects like Throughput, 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 Organization — 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 functionalities.
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. In essence, it captures hardware mapping of application components or processes.
For DevOps
- Topology Architecture | Deployment Plan
The cluster of application instances and their places in the geography of physical or virtual machines 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 are used for elaboration; It may be a combination of textual documents with or without UML Sequences, Actor diagrams, Prototypes.
Why is it called 4+1 instead of 5?
The use case view is unique in that it specifies a system’s high-level needs, whereas other views clarify how those requirements are implemented. It’s basically redundant after the other four perspectives are done. All other points of view, on the other hand, would be impossible to achieve without it. The 4+1 perspective is depicted in detail in the image and table below.
Closing Notes
If done correctly, 4+1 Model Views can cover a lot of software. It’s not set in stone; you can omit any view or subview that doesn’t contribute to the expression of your program design.
References
- SOFTWARE ENGINEERING — Report on a conference sponsored by the NATO SCIENCE COMMITTEE — Garmisch, Germany, 7th to 11th October 1968.
- D. Perry & A. Wolf Foundations for the study of Software Architecture, 1992.
- Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture.
- Mikko Kontio (2008, July) Architectural manifesto: Designing software architectures, Part 5.
- Hui, LM; Leung, CW; Fan, CK; Wong, TN (2004). “Modelling agent-based systems with UML”. Proceedings of the Fifth Asia Pacific Industrial Engineering and Management Systems Conference.
- https://en.wikipedia.org/wiki/4%2B1_architectural_view_model.
- https://www.tutorialspoint.com/software_architecture_design/architecture_models.htm
Thank you very much for reading!
Hope to see you again with another article. Till then, STAY SAFE!!! ツ
-Nipuni Perera-
