The fundamental organization of a software system can be represented by: Structural elements and their interfaces that comprise or form a system Behavior represented by collaboration among the structural elements

Composition of Structural and Behavioral elements into larger subsystems

• Such compositions are guided by desired abilities (non-functional requirements) like usability, resilience, performance, re-use, comprehensibility, economic and technology constraints and trade-offs etc.
• Also, there are cross-cutting concerns (like security and transaction management) that apply across all the functional elements
• The 4+1 View Approach is an ‘architecture style’ to organize an application’s architecture representations into views to meet individual stakeholder’s needs.

Figure 1 shows the views in the 4+1 View Architecture.

Logical View (Object Oriented Decomposition)

• This view focuses on realizing an application’s functionality in terms of structural elements, key abstractions and mechanisms, separation of concerns and distribution of responsibilities. Architects use this view for functional analysis.
• The logical architecture is represented at different levels of abstraction and progressively evolves in iterations.

Process View (Process Decomposition)

• This view considers non-functional aspects such as performance, scalability and throughput. It addresses the issues of concurrency, distribution and fault tolerance.
• It shows the main abstractions from the Logical View executing over a thread as an operation. A process is a group of tasks that form an executable unit; a software system is partitioned into sets of tasks. Each task is a thread of control that executes with collaboration among different structural elements (from the Logical View).
• Process View also encompasses re-usable interaction patterns to solve recurring problems and to meet non-functional service levels.
• The process architecture can be represented at various levels of abstraction such as interactions between systems, subsystems and objects etc. based on the need.

Implementation or Development View (Subsystem Decomposition)

• This is a view of a system’s architecture that encompasses the components used to assemble and release a physical system.
• This view focuses on configuration management and actual software module organization in the development environment.
• The software is actually packaged into components that can be developed and tested by the development team.
• While the Logical View is at the conceptual level, the diagrams in this view represent the physical-level artifacts that are built by the team.

Deployment or Physical View (Mapping Software to Hardware)

• This view encompasses the nodes that form the system’s hardware topology on which the system executes; it focuses on distribution, communication and provisioning.
• The software executes on a network of computers, or processing nodes.
• The various elements such as processes, tasks and objects need to be mapped to the nodes on which they execute.
• These physical configurations can differ between production, development and testing environments.
• The software should be built to be flexible to scale across these hardware changes. Hence, this view accommodates the non-functional requirements such as availability, reliability, performance, throughput and scalability.