4+1 architectural view model

What is 4+1 architectural view model?

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.

History and evolution

Kruchten was named Director of Process at Rational Software in 1996, where he oversaw the creation of the “Rational Unified Process” (RUP). In the RUP section on Analysis and Design, the 4 + 1 viewpoints are a key notion.

While Kruchten was at Rational, his colleagues took an alternative approach to talk about software, which resulted in the Unified Modeling Language Framework.

The 4 + 1 views are a generic approach that does not prescribe any specific notation or diagramming structure (although Booch notation is used in the paper); UML fills in the blanks with prescriptive definitions of how to notate certain types of diagrams. Although the 4 + 1 views are not specifically referenced in UML, the intention of the RUP was that it would work in concert with UML as the notation for diagrams. It seems no coincidence and there is a neat alignment with the 4 + 1 views, with many UML diagrams being well suited for use in a specific view.

These days the 4 + 1 views are rarely utilized — technology and tech culture have moved on.

The view

The “4 + 1 Architectural Views” were proposed in 1995 to solve increasing challenges communicating about software architectures.

The purpose of separating the architecture into multiple concurrent views was to isolate and illustrate different aspects of the design with information specifically oriented towards different stakeholders.

Each view should:

• define the system in terms of Components, Connectors and Containers
• use appropriate styles, forms and patterns for each view
• consider applicable constraints in each view
• consider the relationship between the views

Logical View

The logical view illustrates how the system is decomposed into specific areas of functionality. You will likely need to diagram the system at various levels of abstraction.

Process view

The process view gets us to closer to an illustration of running software. Components in the process view are real executables that make up the run-time of your system.

For example, each of the following would be considered a ‘process’:

• IIS Web Application Pool
• Single-page app running in a browser
• Linux Daemon
• Database engine running stored procedures or SQL scripts
• etc.

Processes can be thought of as a unit of ‘tactical control’. An individual process can be deployed, started, recovered, reconfigured, scaled out, and shutdown.

Physical View

Even with the advent of Cloud computing and virtualized hardware, the physical architecture view still plays a critical role in understanding system performance and capacity.

Components are either processing nodes (servers, virtual machines, docker containers, serverless configurations, etc.) or networking channels (routers, firewalls, proxies, load balancers, etc.) and the diagram should illustrate which nodes host which processes from the process view.

Scenario/Use Case View

The scenario or ‘use case’ view helps tie the architecture together. Different diagrams help to illustrate the flow of activity in a system and illustrate which logical, process, physical and development components are working together to facilitate the outcome.

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.

References

1. SOFTWARE ENGINEERING — Report on a conference sponsored by the NATO SCIENCE COMMITTEE — Garmisch, Germany, 7th to 11th October 1968 ↩︎
2. D. Perry & A. Wolf Foundations for the study of Software Architecture, 1992 ↩︎
3. https://en.wikipedia.org/
4. https://www.tutorialspoint.com/