Architectural Blueprints – The “4+1” View
Model of software Architecture
from IEEE Software (November 1995)
By Philippe Kruchten
Rational Software
General Concept of Software Architecture
• Software Architecture “deals” with
– 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 nonfunctional requirements
From Perry & Wolfe:
Software Architecture = { Elements, Form, Rationale/Constraints }
An Architectural Model
Kruchten Proposes a Model composed of 5
“Views” :
Logical View
Process View
Physical View
Development View
+ 5. Scenario or Use Case
In Describing Each of the 5 Views,
Kruchten uses a Common Methodology
The Notations that will be used for the view is
Elements to express : components, containers, connectors
Form to express : “pattern” that worked
Rationale/Constraints to express : some requirements to be
For each “view” also show:
An example of blueprint, with the view’s notation
The architectural styles that may be utilized for that view
Logical Architecture (View)
• Logical view primarily describes the services provided
to the users. The system is decomposed into key
abstractions (e.g. classes) that describe the functional
– May include the identification of common components across
the system.
– Uses OO Approach &Class Diagrams, which shows
• i) Classes and
• ii) the Relationships (inheritance, composition, usage, etc.) among
– Alternative to OO, may use E-R diagrams for data driven
Logical Architecture (View)
• Notation used for the OO approach of Logical
View is derived from Booch and include:
– A) Components --- Class; Class Utility;
Parameterized Class; Class Category
– B) 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.
Process Architecture (View)
• Process view primarily describes the non-functional
aspects of the requirements and execution control
such as the 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.)
• A task is a thread of control that can be individually scheduled
on one processing node
– Tasks also communicate via some well defined mechanism
– Process i) loads and ii) flow of messages can be estimated
via studying a blueprint of process view.
Process Architecture (View)
• Notation used for Process View is derived from
Booch’s proposal for Ada tasking and includes:
– A) Components --- Process; Simplified Process; Periodic
Process adornment
– B) Connectors ---- Unspecified; Message (unidirectional and
bidirectional); Remote Procedure Call; Event Broadcast
simplified process
• 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.
Development Architecture (View)
• Development view 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.
Development Architecture (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.
Physical Architecture (View)
• Physical view 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.
Physical Architecture (View)
• Notations used are pretty much box and line:
– Components --- processors; devices
– Connectors --- communication lines; high bandwidth bus
comm. line
high bandwidth
• Style:
– There is no specific style except possibly hierarchical
• Physical Blueprint:
– Diagram depicting the process architecture mapped onto
the physical architecture.
My Comments
• 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?
Use Scenarios to Converge and Test the Views
• Come up with scenarios of “most” important or
“most” frequently encountered use cases and run
through the different views.
• Note that Logical views 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
Thus the “major” scenarios form the 5th View or the “4+1” Views!
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.
Iterative Approach to Designing an Architecture
• The phases of (sketching, organizing, specifying,
and Optimizing) architecting 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 ----
The Architecture must be Documented
• Architectural Document should include (my version):
– 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.
My 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
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.

Architectural Blueprints – The “4+1” View Model of