4+1 Architectural View Model
Hello everyone!
Welcome back again. In this article, I am going to talk about the “4+1 Architectural View Model”. Let’s move to the article.
Architecture Models
Software architecture involves the high-level structure of software system abstraction, by using decomposition and composition, with architectural style and quality attributes. A software architecture design must conform to the major functionality and performance requirements of the system, as well as satisfy the non-functional requirements such as reliability, scalability, portability, and availability.
Software architecture must describe its group of components, their connections, interactions among them, and deployment configuration of all components.
Software architecture can be defined in many ways :
- UML (Unified Modeling Language) − UML is one of object-oriented solutions used in software modeling and design.
- Architecture View Model (4+1 view model) − Architecture view model represents the functional and non-functional requirements of software application.
- ADL (Architecture Description Language) − ADL defines the software architecture formally and semantically.
In this article, I focus on about “4+1 Architectural View Model”.
4+1 Architectural View Model
History and evolution of 4+1 architectural view model
In 1995, Philippe Kruchten was working at Rational Software Corp, at the time the pre-eminent vendor of software development tools. He had observed that software architecture diagrams often failed to provide clarity as to the actual system design. It was frequently confusing as to what the boxes, lines and arrows really represent, and stakeholders struggled to discover the information they needed.
He proposed a solution in a paper published that year — “Architectural Blueprints — The “4+1” View Model of Software Architecture “- to organize the description of a software architecture using a set of concurrent ‘views’, each addressing specific concerns, for specific stakeholders.
Comparisons between software architecture and the architecture of buildings have been made since at least 1968, when the Nato Science Committee sponsored a Working Conference on Software Engineering. Amongst many other topics the attendees discussed how to discover the “right attitude to design”. Peter Naur (the “N” in BNF) suggested:
“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.”
The following decades contained numerous efforts to grapple with the large scale design of software systems with many foundational principles proposed and refined, but applied sporadically.
It was only in the early 1990s that the term “Software Architecture” came to the fore.
So it was in the context of a discipline with decades of development, but only nascent formalization, that Kruchten proposed his 4 + 1 views. It’s no surprise given the historical analogues with building architecture that he would refer to the views as blueprints.
Methodology
The aim of this research is create software pattern (Template), Which will enhance the 4+1 view model and it’s based on “4+1 view model” software architecture to solve one problem or challenge of Software Intensive System (SIS).
It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Step 1: there are many software architectures available to design and implement the systems. After studying the software architectures, it can be seen the most appropriate architecture that will be used is 4+1 view models.
Step 2: there are many challenges that face software intensive systems. After studying the software intensive system, later each challenge will be discussed and figure out the main reasons of each challenge.
Step 3: study the selective software architecture and compare between SIS’s challenges and each view in order to find a relationship between them.
Step 4: Design the new template based on SIS and 4+1 view architecture models.
Model Description
4+1 Architectural View Model provides four essential views.
Logical View
The logical view is concerned with the system’s functionality as it pertains to end-users. Class diagrams and state diagrams are examples of UML diagrams that are used to depict the logical view.
- 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.
Process View
The process view focuses on the system’s run-time behaviour and deals with the system’s dynamic elements. It explains the system processes and how they communicate. Concurrency, distribution, integrator, performance, and scalability are all addressed in the process view. The sequence diagram, communication diagram, and activity diagram are all UML diagrams that can be used to describe a process view.
- 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.
Development View
The development view depicts a system from the standpoint of a programmer and is concerned with software administration. The implementation view is another name for this view. It describes system components using the UML Component diagram. The Package diagram is one of the UML diagrams used to depict the development view.
- 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.
Physical View
The physical view portrays the system from the perspective of a system engineer. On the physical layer, it is concerned with the topology of software components as well as the physical connections between these components. The deployment view is another name for this view. The deployment diagram is one of the UML diagrams used to depict the physical perspective.
- 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.
This view model can be extended by adding one more view called scenario view or use case view for end-users or customers of software systems. It is coherent with other four views and are utilized to illustrate the architecture serving as “plus one” view, (4+1) view model. The following figure describes the software architecture using five concurrent views (4+1) model.
Scenarios
A small number of use cases, or scenarios, that become the fifth view, are used to illustrate the description of architecture. Sequences of interactions between objects and processes are described in the scenarios. They are used to identify architectural aspects as well as to demonstrate and assess the design of the architecture. They can also be used as a starting point for architecture prototype testing. The use case view is another name for this view.
Advantages of Using 4+1 Architectural View Model Usage
● The 4 + 1 strategy isn’t simply about appeasing various interests. It makes modeling easier to accomplish since it is more organized.
● A typical project will have a number of different sorts of diagrams. A project could include a few hundred sequence diagrams and numerous class diagrams, for example. A typical project will have a number of different sorts of diagrams. A project could include a few hundred sequence diagrams and numerous class diagrams, for example.
● When you group diagrams of similar sorts and purposes together, you’re emphasizing the need for separate issues.
● Similarly, separating various components into separate jar files improves organization.
● When projects follow industry-standard templates again in a company, it indicates that things are better organized.
● The 4 + 1 method also allows architects to prioritize modeling problems.
● Furthermore, the 4 + 1 method allows stakeholders to obtain only the elements of the model that are important to them.
Current usage of 4+1 architectural view model
Software-intensive systems have become a major part of an increasingly growing range of applications, services, and products. Software-intensive systems are systems in which software interacts with other systems, software, sensors, and devices with people.
Such systems are like telecommunications, wireless, heterogeneous systems, business applications with web services. People’s activities depends on complex software-intensive systems increasingly, such systems are becoming more heterogeneous, decentralized, and operating more in dynamic and often unpredictable; this development has several consequences; as software systems grew increasingly, the focus has moved from the complexity of developing algorithms to the complexity structuring large systems, and then to creating complex distributed concurrent systems.
Current engineering methods are not powerful enough to design, deploy and maintain software-intensive systems. However there is no realistic alternative to such systems, we can’t afford to stop building software-intensive systems.
Air Traffic Control
The following are the major Obstacle of current ATC (Air Traffic Control) system;
a) Lack of well-defined human/software interface.
b) Need for high maintenance .
c) Outdated design/technology.
d) Mixed communication.
So for this case, we can use 4+1 architectural view model.
Activities should be controlled ATC system will control each main activity for the plane starting from preflight to landing. So the main function for this system is preventing accidents happen in the air traffic. These activities for ACT are explain below;
a) Preflight -This portion of the flight starts on the ground and includes flight checks, push-back from the gate and taxi to the runway.
b) Takeoff — The pilot powers up the airplane and speeds down the runway.
c) Departure — The plane lifts off the ground and climbs to a cruising altitude.
d) En route — The airplane travels through one or more center airspaces and nears the destination airport.
e) Descent — The pilot descends and maneuvers the airplane to the destination airport.
f) Approach — The pilot aligns the airplane with the designated landing runway.
g) Landing — The airplane lands on the designated runway, taxis to the destination gate and parks at the terminal.
The exact method used to construct the mapping is complex. However, a brief example from a hypothetical air-traffic control system can illustrate it. Above figure shows how a small set of classes from the system can be mapped onto processes. The flight class is mapped onto a set of flight agents that must quickly process many flights and spread the load across multiple CPUs while contending with large numbers of external stimuli. The persistence and distribution aspects of the flight processing are deferred to a flight serve?’, which is duplicated to assure system availability. Flight profile or flight clearance is always subordinate to a flight, and although there are complex classes, they share the processes of the flight class. Flights are distributed to several other processes, notably for display and external interfaces. A sectorization class establishes a partitioning of airspace to assign controller jurisdiction over flights. Because of its integrity constraints, this class must be handled by a single agent, but it can share the server process with the flight, as updates are infrequent. Locations, airspace, and other static aeronautical information are protected objects, shared among several classes. These are rarely updated and mapped on their own server and distributed to other processes.
Why is it called 4+1 instead of 5?
The use case view has a special significance as it details the high-level requirement of a system while other views detail how those requirements are realized. When all other four views are completed, it’s effectively redundant. However, all other views would not be possible without it. The following image and table shows the 4+1 view in detail.
As a summary, The 4+1 View Model describes software architecture using five concurrent views, each of which addresses a specific set of concerns: The logical view describes the design’s object model, the process view describes the design’s concurrency and synchronization aspects; the physical view describes the mapping of the software onto the hardware and shows the system’s distributed aspects, and the development view describes the software’s static organization in the development environment. Software designers can organize the description of their architectural decisions around these four views and then illustrate them with a few selected use cases, or scenarios, which constitute a fifth view. The architecture is partially evolved from these scenarios. The 4+1 View Model allows various stakeholders to find what they need in the software architecture. System engineers can approach it first from the physical view, then the process view; end users, customers, and data specialists can approach it from the logical view; and project managers and software-configuration staff members can approach it from the development view.
I think you got an idea about what is 4+1 view model is and why it’s important.
Let’s meet with the next article. Thank you so much for reading!
References :
https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
Wikipedia: 4+1 architectural view model
Orginal Paper of th 4+1 architectural view model by Philippe Kruchten
4+1 View Model of Software Architecture by Mazeiar Salehie
