Skip to end of metadata
Go to start of metadata

Introduction

The 4+1 View Model of Software Architecture is probably the most commonly used methodology for documenting software architecture. It was introduced by Philippe Kruchten in 1995 in the article Architectural Blueprints — The "4+1" View Model of Software Architecture and became part of the (Rational) Unified Process. It organizes the architecture documentation in the Scenario View, Process View, Logical View, Implementation View and Physical View.

  • The logical view, which is the object model of the design (when an object-oriented design method is
    used),
  • the process view, which captures the concurrency and synchronization aspects of the design,
  • the physical view, which describes the mapping(s) of the software onto the hardware and reflects its
    distributed aspect,
  • the development view, which describes the static organization of the software in its development
    environment.

4+1 Views with appropriate diagrams

Process View
Physical View
Logical View

Describes the structure of the logical elements of the solution. Examples are the domain model

Diagram types:

Implementation View
Scenario View

Selected use cases/user stories or scenarios that represent typical and/or important functionality for the final solution. The selection of user stories or scenarios is made with respect to their impact on the architecture, or whether they are special in some way or another. The user stories will be addressed in the other views, and will in that way bind the views together.
Format:

Enterprise 4+1 View

In an enterprise architecture context one can combine the Zachman framework and the 4+1 View Model in the following conceptual way:

The IT-part of the enterprise architecture may then be organized as follows:


TODO

Are any of the following appropriate in the 4+1 view model?
Especially interested in where the state machine diagram belongs.

Interaction Overview Diagram
State Machine Diagram
Timing Diagram

Granularity

Let's say a system is decomposed into subsystems, and each subsystem consists of one or more applications (which can be clustered) and external dependencies like databases, file shares or JMS.

In the spirit of agility it seems prudent to make intelligent choices with regards to

  • what views to use?
  • what views are relevant at system, subsystem and application level.
Mapping to SOA

Can the 4+1 view model be used to document a Service Oriented Architecture?
The literature is vague at best at this point; can someone write some advice/pin-pointers?

Resources

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.