1. 4+1 View Model of Software Architecture
Architectural Blueprints – The “4+1” View Model of Software Architecture Paper Published in IEEE Software 12 (6), pp (November 1995) Author Philippe Kruchten Rational Software Corporation

2. About Kruchten and his paper
Philippe Kruchten
Have more than 16-years experience as the leader of Rational Unified Process (RUP) development team in Rational Corporation (now owned by IBM).
Have valuable experiences in industry (Telecom, Air traffic control system) which he used them for confirmation of his model.
Paper Citations
More than 1822 citations according to ACM portal site

3. Abstract
This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various ‘stakeholders’ of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenario driven, iterative development process.

4. General Concept of Software Architecture
Software Architecture “deals” with the
design and
implementation
of the high level structure of software.
Software Architecture is the “result” of
assembling a number of architectural elements
in some well chosen form
to satisfy major functionality as well as non-functional requirements such as reliability, scalability, portability, and availability
Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To describe a software architecture, we use a model composed of multiple views or perspectives

5. 4+1 View Model of Architecture
Philippe Kruchten Proposed a Model which is Composed of 5-Views
or Architectures
Logical view
Physical View
Process View
Development view
End user
System Engineer
Integrator
Programmers
& software managers
Scenarios
The architecture in fact partially evolved from these scenarios as well as
The model is rather generic, and other notations and tools can be used, other design methods can be used especially for the logical and process decompositions
For each view, the architects can pick a certain architectural style
Similar views in UML
Use case view> - Encompass the use cases that describe the behavior of the system as seen by its end users, analysts, and testers
Design view - Encompass the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution
Process view - Encompass the threads and processes that form the system's concurrency and synchronization mechanisms
Implementation view - Encompass the components and files that are used to assemble and release the physical system
Deployment view - Encompass the nodes that form the system's hardware topology on which the system executes
The description of an architecture can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view. The architecture is in fact partially evolved from these scenarios

6. General Concept of Software Architecture
Perry & Wolfe
Software Architecture = {Elements, Form, Rationale/Constraints}
We apply Perry & Wolf’s equation independently on each view, i.e., for each view we define the set of elements to use (components, containers, and connectors), we capture the forms and patterns that work, and we capture the rationale and constraints, connecting the architecture to some of the requirements.
Each view is described by a blueprint using its own particular notation. For each view also, the architects can pick a certain architectural style, hence allowing the coexistence of multiple styles in one system.

7. In describing each of 5 Views, Kruchten uses a common methodology
Notations that will be used for the view are defined:
Elements to express: components, containers, connectors
Form to express: “pattern” that worked
Rationale/Constraints to express: some requirements to be satisfied
For each “view” also showed:
An example of blueprint, with the view’s notation
The architectural styles that may be utilized for that view

8. Logical View (Viewer = End-user)
Logical view/architecture primarily describes the services provided to the users. The system is decomposed into key abstractions (Classes) that describe the functional requirements.
May include the identification of common components across the system.
Uses OO Approach & Class Diagrams, which shows
Classes and
Relationships (inheritance, composition, usage, etc.) among Classes
Alternative to OO, may use E-R diagrams for data driven systems

9. Logical View
Notation used for the OO approach of logical view is derived from Booch and include:
Components: Class, Class Utility, Parameterized Class, Class Category
Connectors: Association, Containment & Aggregation, Usage, Inheritance, Instantiation
Style:
Object Oriented Style
A Logical Blueprint
Some pictorial representation, using Booch Notation, of the logical view of a design.
class
usage
inheritance

10. Logical View Example

11. Process View (Viewer = Integrator)
Process view/architecture primarily describes the non-functional aspects of the requirements and execution control such as performance or integrity and addresses issues such as concurrency or distribution
Describes the thread of control of an operation of how a process (i.e. set of tasks) is executed.
Process is a set of tasks that form an executable unit which can be started, controlled, terminated, etc.
Task is a thread of control that can be individually scheduled on one processing node
Tasks also communicate via some well defined mechanism
Process loads and flow of messages can be estimated via studying a blueprint of process view.

12. Process View
Notation used for process view is derived from Booch’s proposal for Ada tasking and includes:
Components: Process, Simplified Process, Periodic Process adornment
Connectors: Unspecified, Message (unidirectional and bidirectional), Remote Procedure Call, Event Broadcast
Style: (several may be used)
Pipe and filter, client server
Process Blueprint:
Some diagram, using the defined notation, to depict the flow of messages from process to process.
message
process
RPC
simplified process

13. Process View Example

14. Development View (Viewer = Programmers & Software Managers)
Development view/architecture focuses on the software module organization as they are packaged into small units of subsystems or libraries that can be developed by a small unit of developers.
Subsystems are organized in a hierarchy of layers
The rules that govern the development architecture may include: partitioning, grouping, visibility
Takes into account of the “internal requirements” related to development, project management, re-use, toolset constraints, development platform and language constraints, etc.

15. Development View
Notation used for development view is again derived from Booch:
Components: Module, Subsystem, Layer
Connectors: References, Compilation Dependency
Style:
Layered (4 to 6 layers)
Development Blueprint:
Some diagram depicting the layers of a software system that matches the logical view of the same system.
Contained within each layer are several subsystems, which in turn may contain several modules.
module
subsystem
layer
reference

16. Physical View (Viewer = System Engineer)
Physical view/architecture focuses on the non-functional requirements of the “hardware” system on top of which the software resides.
The various elements identified are parts of the physical configuration needed to run the software
These may include nodes, processors, devices, lines, etc.
The configurations may be for development purpose, for testing purpose, deployment purpose, etc.

17. Physical View Notations used are pretty much box and line: Style:
Components: processors, devices
Connectors: communication lines, high bandwidth bus
Style:
There is no specific style except possibly hierarchical
Physical Blueprint:
Diagram depicting the process architecture mapped onto the physical architecture.
processor
device
high bandwidth
communications
comm. line

18. Physical View Example

19. Physical View Example (cont.)

20. Comments on Views
It is good to realize that architectural design is a result of considering many different perspectives. Clearly, we need to somehow combine these differing views into one cohesive architecture ---- or do we?
Also, do we always need the logical, process, development, and physical views?
Do we need more? ---- how about Data View?
Can we do with less?

21. Use Scenarios to Converge and Test Views
Come up with scenarios of “most important” or “most frequently” encountered use cases and run through the different views.
Note that Logical view describes the “components”, and Process view describes the “execution” control and synchronization. So use the scenarios to converge (map) the Logical and Process Views together so that we can:
Discover if we defined all the needed “components”
Discover if the components can interact in the expected manner
Thus the “major” scenarios form the 5th View or the “4+1” Views!

22. Scenario Example

23. Mapping the Views is Hard
Do all the views have to be carried to the same level of depth before we can map them together?
How do we map the views?
Logical View to Process view
Basically this is looking at the “objects” or “components” and asking how the execution path will look like.
So we need to know the characteristics of these objects or components: Autonomy; Persistence; Subordination; Distribution
We need to know the execution thread of control in the process view: inside-out locus of control; outside in locus of control
Logical View to Development View
Looking at implementing a “class” as a module and packaging modules together. Should the modules be implemented and packaged in a specific pattern such as “layered”?
Process View to Physical View
Looking at the processing or execution control, we may choose to deploy different processes on different hardware nodes.

24. Iterative Approach to Designing an Architecture
The phases of architecting (sketching, organizing, specifying, and Optimizing) should not be a linear, single pass approach --- a more iterative “scenario driven approach” should be taken:
Start with a number of main scenarios and run them through the “strawman” architecture.
The architectural elements discovered through this scenario driven approach is documented via logical, process, development, and physical views.
Use more scenarios to iterate through the views and capture the architecture (including the rationale part) until satisfied ----

25. The Architecture must be Documented
Architectural Document should include:
Architectural goals & constraints
Software Architectural Views:
Logical Views (representing user functionalities)
Process views (representing system execution )
Development Views (representing implementation breakdown )
Physical Views (representing deployment/hardware assignments)
Data view (representing the key files and tables)
Scenarios
Rationale
Software Architecture (combined all the views and rationale) = {elements, forms, rationale}
The author includes more such as: change history, scope, references,
performance & size, quality, etc.

26. Further Comments Addressing multiple views make sense.
Seems that Data View should be included as one of the “required” and Development View may be an “option”.
The hardest part of moving forward with multiple views is “how do you combine” them:
The views must be at the same level of depth
The views must not have any conflicting information
The views must be clearly expressed in languages that allows “combination” into a software architectural representation language.

27. Final Remarks Methodology successfully used in the industry
Air Traffic Control
Telecom
Model is comprehensive as all other views are reducible to one of the 4 views
In this paper there are no tools to integrate views. So there is an inconsistency problem in this model which is more tangible in the maintenance of the architecture.