4 + 1 View Model of Software Architecture

5 OCTOBER 2008 2 COMMENTS

What is the 4+1 view model of software architecture?  It’s a way to show key viewpoints of an architecture.  InA Practical Guide to Enterprise Architecture (Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the 4+1 view model of software architecture.

Key Take Aways
Here’s my key take aways:

• The four views are: logical, process, development, and physical.
• The +1 is the scenarios.  The scenarios are at the center of the model.
• The logical view is a view of the important classes and relationships.
• The process view is the runtime and execution view. 
• The development view shows the layers and how classes are organized, as well as dependencies.
• The physical view shows the deployment scenario and associated hardware.

Logical View
The logical view is a view of the important classes and relationships.  McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:

The logical view, or logical architecture, is the object model for the design.  It describes the structures of the software that solve the functional requirements for the system.  It is a subset of all the classes of the system.  The logical view is strictly a structural view of the software, including the important classes and class relationships in the architecture.

Process ViewThe process view is the runtime and execution view.  McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:

The process view, or process architecture, describes the view of the architecture that includes running processes and instantiated objects that exist in the system.  It describes important concurrency and synchronization issues.

Development View
The development view shows the layers and how classes are organized, as well as dependencies.  McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:

The development architecture view focuses on the module organization of the software.  It shows how classes are organized into packages, and it outlines the dependencies between packages of software.  This is the view of the design that shows the layered structures of the software and what the responsibilities of each layer in the system are.

Physical ViewThe physical view shows the deployment scenario and associated hardware.  McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:

The physical view describes the machines that run the software and how components, objects, and processes are deployed onto those machines and their configurations at run-time.

+1
The +1 is the scenarios.  McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:

The +1 in 4 + 1 view model describes the scenarios that the architecture is meant to satisfy.  The scenarios represent the important requirements that the system must satisfy.  The scenarios that are chosen are those that are the most important to solve because they are either the most frequently executed or they pose some technical risk or unknown that must be proven out by the architecture baseline.  The other four views are centered on the set of scenarios that are chosen for the creation of the architecture.

 This set of views is known as the 4+1 Views of Software Architecture [KRU95].

• Use-case view: Describes functionality of the system, its external interfaces, and its principal users. This view is mandatory when using the 4+1 Views, because all elements of the architecture should be derived from requirements.
• Logical view: Describes how the system is structured in terms of units of implementation. The elements are packages, classes, and interfaces. The relationship between elements shows dependencies, interface realizations, part-whole relationships, and so forth. Note: This view is mandatory when using the 4+1 Views of Software Architecture.
• Implementation view: Describes how development artifacts are organized in the file system. The elements are files and directories (any configuration items). This includes development artifacts and deployment artifacts. This view is optional when using the 4+1 Views.
• Process view: Describes how the run-time system is structured as a set of elements that have run-time behavior and interactions. Run-time structure often bears little resemblance to the code structure. It consists of rapidly changing networks of communication objects. The elements are components that have run-time presence (processes, threads, Enterprise JavaBeans™ (EJB™), servlets, DLLs, and so on), data stores, and complex connectors, such as queues. Interaction between elements varies, based on technology. This view is useful for thinking about run-time system quality attributes, such as performance and reliability. This view is optional when using the 4+1 Views.
• Deployment view: Describe how the system is mapped to the hardware. This view is optional when using the 4+1 Views.

In addition, you may wish to represent the following,

• Data view: A specialization of the logical view. Use this view if persistence is a significant aspect of the system, and the translation from the design model to the data model is not done automatically by the persistence mechanism.

4+1 architectural view model

From Wikipedia, the free encyclopedia

Illustration of the 4+1 Architectural View Model.

4+1 is a view model designed by Philippe Kruchten for "describing the architecture of software-intensive systems, based on the use of multiple, concurrent views".^[1] The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers and project managers. The four views of the model are logical, development, process and physical view. In addition selected use cases or scenarios are utilized to illustrate the architecture serving as the 'plus one' view. Hence the model contains 4+1 views:^[1]

• Logical view : The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagram, Communication diagram, Sequence diagram.^[2]

• 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.^[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 runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagram.^[2]

• 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 physical view include the Deployment diagram.^[2]

• 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 use case view.

See also[edit]