4+1 architectural view model
· What is 4+1 architectural view model?
4+1 is a view model used for “describing the architecture of software-intensive systems, based on the use of multiple, concurrent views”. The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers, system engineers, and project managers.
The model contains 4+1 views;
- Logical view: The logical view is concerned with the functionality that the system provides to end-users. UML diagrams are used to represent the logical view, and include class diagrams and state diagrams.
2. Process view: The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the run time behavior of the system. The process view addresses concurrency, distribution, integrator, performance, and scalability, etc. UML diagrams to represent process view include the sequence diagram, communication diagram, activity diagram.
3. Development view: The development view illustrates a system from a programmer’s perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram.
4. Physical view: The physical view depicts the system from a system engineer’s point of view. It is concerned with the topology of software components on the physical layer as well as the physical connections between these components. This view is also known as the deployment view. UML diagrams used to represent the physical view include the deployment diagram.
5. Scenarios: The description of an architecture is illustrated using a small set of use cases, or scenarios, which become a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view.
The various views are not fully independent. Elements of one view are connected to elements in other views, following certain design rules and heuristics.
· 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.
· Current usage of 4+1 architectural view model:
Software Intensive Systems and 4+1 Architectural 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.
Example : 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.
*****************************************************************
References:-
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
