ArticlePDF Available


The 4 + 1 View Model describes software architecture using five concurrent views, each of which addresses a specific set of concerns: The logical view describes the design's object model, the process view describes the design's concurrency and synchronization aspects; the physical view describes the mapping of the software onto the hardware and shows the system's distributed aspects, and the development view describes the software's static organization in the development environment. Software designers can organize the description of their architectural decisions around these four views and then illustrate them with a few selected use cases, or scenarios, which constitute a fifth view. The architecture is partially evolved from these scenarios.The 4+1 View Model allows various stakeholders to find what they need in the software architecture. System engineers can approach it first from the physical view, then the process view; end users, customers, and data specialists can approach it from the logical view; and project managers and software-configuration staff members can approach it from the development view.
Paper published in IEEE Software 12 (6)
November 1995, pp. 42-50
Architectural Blueprints—The “4+1” View
Model of Software Architecture
Philippe Kruchten
Rational Software Corp.
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.
Keywords: software architecture, view, object-oriented design, software development process
We all have seen many books and articles where one diagram attempts to capture the gist of the architecture
of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear
that their authors have struggled hard to represent more on one blueprint than it can actually express. Are
the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely
logical groupings of functionality? Are the arrows representing compilation dependencies? Or control
flows? Or data flows? Usually it is a bit of everything. Does an architecture need a single architectural
style? Sometimes the architecture of the software suffers scars from a system design that went too far into
prematurely partitioning the software, or from an over-emphasis on one aspect of software development:
data engineering, or run-time efficiency, or development strategy and team organization. Often also the
architecture does not address the concerns of all its “customers” (or “stakeholders” as they are called at
USC). This problem has been noted by several authors: Garlan & Shaw1, Abowd & Allen at CMU,
Clements at the SEI. As a remedy, we propose to organize the description of a software architecture using
several concurrent views, each one addressing one specific set of concerns.
An Architectural Model
Software architecture deals with the design and implementation of the high-level structure of the software. It
is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy
the major functionality and performance requirements of the system, as well as some other, non-functional
requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely
in this formula2, modified by Boehm:
Software architecture = {Elements, Forms, Rationale/Constraints}
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. In order to
eventually address large and challenging architectures, the model we propose is made up of five main views
(cf. fig. 1):
The logical view, which is the object model of the design (when an object-oriented design method is
•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
The description of an architecture—the decisions made—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 as we will see later.
Logical View Development
Process View Physical View
Software management
System engineers
Figure 1 — The “4+1” view model
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.
We will now look in turn at each of the five views, giving for each its purpose: which concerns is addresses,
a notation for the corresponding architectural blueprint, the tools we have used to describe and manage it.
Small examples are drawn from the design of a PABX, derived from our work at Alcatel Business System
and an Air Traffic Control system3, but in very simplified form—the intent here is just to give a flavor of
the views and their notation and not to define the architecture of those systems.
The “4+1” view model is rather “generic”: other notations and tools can be used, other design methods can
be used, especially for the and the logical and process decompositions, but we have indicated the ones we
have used with success.
The Logical Architecture
The Object-Oriented Decomposition
The logical architecture primarily supports the functional requirements—what the system should provide in
terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from
the problem domain, in the form of objects or object classes. They exploit the principles of abstraction,
encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also
serves to identify common mechanisms and design elements across the various parts of the system. We use
the Rational/Booch approach for representing the logical architecture, by means of class diagrams and class
templates.4 A class diagram shows a set of classes and their logical relationships: association, usage,
composition, inheritance, and so forth. Sets of related classes can be grouped into class categories. Class
templates focus on each individual class; they emphasize the main class operations, and identify key object
characteristics. If it is important to define the internal behavior of an object, this is done with state transition
diagrams, or state charts. Common mechanisms or services are defined in class utilities.
Alternatively to an OO approach, an application that is very data-driven may use some other form of logical
view, such as E-R diagrams.
Notation for the logical view
The notation for the logical view is derived from the Booch notation4. It is considerably simplified to take
into account only the items that are architecturally significant. In particular, the numerous adornments are
not very useful at this level of design. We use Rational Rose® to support the logical architecture design.
Class Utility
Class category
Figure 2 — Notation for the logical blueprint
Style for the logical view
The style we use for the logical view is an object-oriented style. The main guideline for the design of the
logical view is to try to keep a single, coherent object model across the whole system, to avoid premature
specialization of classes and mechanisms per site or per processor.
Examples of Logical blueprints
Figure 3a shows the main classes involved in the Télic PABX architecture.
Controller Numbering
and Training
management Air Traffic
Display &
Figure 3— a. Logical blueprint for the Télic PABX . b. Blueprint for an Air Traffic Control System
A PABX establishes commmunications between terminals. A terminal may be a telephone set, a trunk line
(i.e., line to central-office), a tie line (i.e., private PABX to PABX line), a feature phone line, a data line, an
ISDN line, etc. Different lines are supported by different line interface cards. The responsibility of a line
controller object is to decode and inject all the signals on the line interface card, translating card-specific
signals to and from a small, uniform set of events: start, stop, digit, etc. The controller also bears all the
hard real-time constraints. This class has many subclasses to cater for different kinds of interfaces. The
responsibility of the terminal object is to maintain the state of a terminal, and negotiate services on behalf of
that line. For example, it uses the services of the numbering plan to interpret the dialing in the selection
phase. The conversation represents a set of terminals engaged in a conversation. The conversation uses
translation services (directory, logical to physical address mapping, routes), and connection services to
establish a voice path between the terminals.
For a much bigger system, which contains a few dozen classes of architectural significance, figure 3b show
the top level class diagram of an air traffic control system, containing 8 class categories (i.e., groups of
The Process Architecture
The Process Decomposition
The process architecture takes into account some non-functional requirements, such as performance and
availability. It addresses issues of concurrency and distribution, of system’s integrity, of fault-tolerance, and
how the main abstractions from the logical view fit within the process architecture—on which thread of
control is an operation for an object actually executed.
The process architecture can be described at several levels of abstraction, each level addressing different
concerns. At the highest level, the process architecture can be viewed as a set of independently executing
logical networks of communicating programs (called “processes”), distributed across a set of hardware
resources connected by a LAN or a WAN. Multiple logical networks may exist simultaneously, sharing the
same physical resources. For example, independent logical networks may be used to support separation of
the on-line operational system from the off-line system, as well as supporting the coexistence of simulation
or test versions of the software.
A process is a grouping of tasks that form an executable unit. Processes represent the level at which the
process architecture can be tactically controlled (i.e., started, recovered, reconfigured, and shut down). In
addition, processes can be replicated for increased distribution of the processing load, or for improved
The software is partitioned into a set of independent tasks. A task is a separate thread of control, that can be
scheduled individually on one processing node.
We can distinguish then: major tasks, that are the architectural elements that can be uniquely addressed and
minor tasks, that are additional tasks introduced locally for implementation reasons (cyclical activities,
buffering, time-outs, etc.). They can be implemented as Ada tasks for example, or light-weight threads.
Major tasks communicate via a set of well-defined inter-task communication mechanisms: synchronous and
asynchronous message-based communication services, remote procedure calls, event broadcast, etc. Minor
tasks may communicate by rendezvous or shared memory. Major tasks shall not make assumptions about
their collocation in the same process or processing node.
Flow of messages, process loads can be estimated based on the process blueprint. It is also possible to
implement a “hollow” process architecture with dummy loads for the processes, and measure its
performance on the target system, as described by Filarey et al. in their Eurocontrol experiment.
Notation for the Process view
The notation we use for the process view is expanded from the notation originally proposed by Booch for
Ada tasking. Again the notation used focuses on the elements that are architecturally significant. (Fig. 4)
Remote Procedure Call
Message, bidirectional
Event broadcast
Periodic process
(Indicates a cyclical process
Figure 4 — Notation for the Process blueprint
We have used the Universal Network Architecture Services (UNAS) product from TRW to architect and
implement the set of processes and tasks (and their redundancies) into networks of processes. UNAS
contains a tool—the Software Architects Lifecycle Environment (SALE)—which supports such a notation.
SALE allows for the graphical depiction of the process architecture, including specifications of the possible
inter-task communication paths, from which the corresponding Ada or C++ source code is automatically
generated. The benefit of this approach to specifying and implementing the process architecture is that
changes can be incorporated easily without much impact on the application software.
Style for the process view
Several styles would fit the process view. For example, picking from Garlan and Shaw’s taxonomy1 we can
have: pipes and filters, or client/server, with variants of multiple client/single server and multiple
clients/multiple servers. For more complex systems, one could use a style similar to the process groups
approach of the ISIS system as described by K. Birman with another notation and toolset.
Example of a Process blueprint
Controller task
Low rate
Controller task
High rate
Figure 5 — Process blueprint for the Télic PABX (partial)
All terminals are handled by a single terminal process, which is driven by messages in its input queues. The
controller objects are executed on one of three tasks that composes the controller process: a low cycle rate
task scans all inactive terminals (200 ms), puts any terminal becoming active in the scan list of the high
cycle rate task (10ms), which detects any significant change of state, and passes them to the main controller
task which interprets the changes and communicates them by message to the corresponding terminal. Here
message passing within the controller process is done via shared memory.
The Development Architecture
Subsystem decomposition
The development architecture focuses on the actual software module organization on the software
development environment. The software is packaged in small chunks—program libraries, or subsystems
that can be developed by one or a small number of developers. The subsystems are organized in a hierarchy
of layers, each layer providing a narrow and well-defined interface to the layers above it.
The development architecture of the system is represented by module and subsystem diagrams, showing the
‘export’ and ‘import’ relationships. The complete development architecture can only be described when all
the elements of the software have been identified. It is, however, possible to list the rules that govern the
development architecture: partitioning, grouping, visibility.
For the most part, the development architecture takes into account internal requirements related to the ease
of development, software management, reuse or commonality, and to the constraints imposed by the toolset,
or the programming language. The development view serves as the basis for requirement allocation, for
allocation of work to teams (or even for team organization), for cost evaluation and planning, for
monitoring the progress of the project, for reasoning about software reuse, portability and security. It is the
basis for establishing a line-of-product.
Notation for the Development Blueprint
Again, a variation of the Booch notation, limiting it to the items that are architecturally significant.
Compilation dependency
(include, "with")
Figure 5 — Notation for the Development blueprint
The Apex Development Environment from Rational supports the definition and the implementation of the
development architecture, the layering strategy described above, and the enforcement of the design rules.
Rational Rose can draw the development blueprints at the module and subsystem level, in forward
engineering and by reverse engineering from the development source code, for Ada and C++.
Style for the Development View
We recommend adopting a layered style for the development view, defining some 4 to 6 layers of
subsystems. Each layer has a well-defined responsibility. The design rule is that a subsystem in a certain can
only depend on subsystem that are in the same layer or in layers below, in order to minimize the
development of very complex networks of dependencies between modules and allow simple release
strategies layer by layer.
Common utilities Bindings
Low-level services
Support Mechanisms:
Communication, Time, Storage,
Resource management, etc.
Aeronautical classes
ATC classes
ATC Functional areas: Flight manag-
ement, Sector Management, etc.
Man-Machine Interface
External systems Off-line tools
Test harnesses
HardWare, OS, COTS
Basic elements
Distributed Virtual Machine
ATC Framework
HATS Components
CAATS, MAATS, etc... 5
Figure 6 — The 5 layers of Hughes Air Traffic Systems (HATS)
Example of Development architecture
Figure 6 represents the development organization in five layers of a line-of-product of Air Traffic Control
systems developed by Hughes Aircraft of Canada3. This is the development architecture corresponding to
the logical architecture shown in fig. 3b.
Layers 1 and 2 constitute a domain-independent distributed infrastructure that is common across the line of
products and shields it from variations in hardware platform, operating system, or off-the-shelf products
such as database management system. To this infrastructure, layer 3 adds an ATC framework to form a
domain-specific software architecture. Using this framework a palette of functionality is build in layer 4.
Layer 5 is very customer- and product-dependent, and contains most of the user-interface and interfaces
with the external systems. Some 72 subsystems are spread across of the 5 layers, containing each from 10 to
50 modules, and can be represented on additional blueprints.
The Physical Architecture
Mapping the software to the hardware
The physical architecture takes into account primarily the non-functional requirements of the system such as
availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes
on a network of computers, or processing nodes (or just nodes for short). The various elements identified—
networks, processes, tasks, and objects—need to be mapped onto the various nodes. We expect that several
different physical configurations will be used: some for development and testing, others for the deployment
of the system for various sites or for different customers. The mapping of the software to the nodes
therefore needs to be highly flexible and have a minimal impact on the source code itself.
Notation for the Physical Blueprint
Physical blueprints can become very messy in large systems, so they take several forms, with or without the
mapping from the process view.
Communication line
Uni-directional communication
High bandwidth communication,
Other device
Figure 7 — Notation for the Physical blueprint
UNAS from TRW provide us here with data-driven means of mapping the process architecture onto the
physical architecture allowing a large class of changes in the mapping without source code modifications.
Example of Physical blueprint
Primary F
Primary F
primary C
Figure 8 — Physical blueprint for the PABX
Figure 8 shows one possible hardware configuration for a large PABX, whereas figures 9 and 10 show
mappings of the process architecture on two different physical architectures, corresponding to a small and a
large PABX. C, F and K are three types of computers of different capacity, supporting three different
Figure 9 — A small PABX physical architecture with process allocation
Pseudo Central
Pseudo Central
line cards line cards
line cards
Back-up nodes
more K
Figure 10 — Physical blueprint for a larger PABX showing process allocation
Putting it all together
The elements in the four views are shown to work together seamlessly by the use of a small set of important
scenarios —instances of more general use cases—for which we describe the corresponding scripts
(sequences of interactions between objects, and between processes) as described by Rubin and Goldberg6.
The scenarios are in some sense an abstraction of the most important requirements. Their design is
expressed using object scenario diagrams and object interaction diagrams4.
This view is redundant with the other ones (hence the “+1”), but it serves two main purposes:
as a driver to discover the architectural elements during the architecture design as we will describe later
as a validation and illustration role after this architecture design is complete, both on paper and as the
starting point for the tests of an architectural prototype.
Notation for the Scenarios
The notation is very similar to the Logical view for the components (cf. fig. 2), but uses the connectors of
the Process view for interactions between objects (cf. fig. 4). Note that object instances are denoted with
solid lines. As for the logical blueprint, we capture and manage object scenario diagrams using Rational
Example of a Scenario
Fig. 11 shows a fragment of a scenario for the small PABX. The corresponding script reads:
1. The controller of Joe’s phone detects and validate the transition from on-hook to off-hook and sends a
message to wake up the corresponding terminal object.
2. The terminal allocates some resources, and tells the controller to emit some dial-tone.
3. The controller receives digits and transmits them to the terminal.
4. The terminal uses the numbering plan to analyze the digit flow.
5. When a valid sequence of digits has been entered, the terminal opens a conversation.
Joe:Controller Joe:Terminal Numbering plan
(1) Off-Hook
(2) dial tone
(3) digit
(4) digit
(5) open
Figure 11 — Embryo of a scenario for a local call—selection phase
Correspondence Between the Views
The various views are not fully orthogonal or independent. Elements of one view are connected to elements
in other views, following certain design rules and heuristics.
From the logical to the process view
We identify several important characteristics of the classes of the logical architecture:
Autonomy: are the objects active, passive, protected?
-an active object takes the initiative of invoking other objects’ operations or its own operations, and has
full control over the invocation of its own operations by other objects
-a passive object never invokes spontaneously any operations and has no control over the invocation of
its own operations by other objects
- a protected object never invokes spontaneously any operations but performs some arbitration on the
invocation of its operations.
Persistence: are the objects transient , permanent? Do they the failure of a process or processor?
Subordination: are the existence or persistence of an object depending on another object?
Distribution: are the state or the operations of an object accessible from many nodes in the physical
architecture, from several processes in the process architecture?
In the logical view of the architecture we consider each object as active, and potentially “concurrent,” i.e.,
behaving “in parallel” with other objects, and we pay no more attention to the exact degree of concurrency
we need to achieve this effect. Hence the logical architecture takes into account only the functional aspect
of the requirements.
However when we come to defining the process architecture, implementing each object with its own thread
of control (e.g., its own Unix process or Ada task) is not quite practical in the current state of technology,
because of the huge overhead this imposes. Moreover, if objects are concurrent, there must be some form of
arbitration for invoking their operations.
On another hand, multiple threads of control are needed for several reasons:
To react rapidly to certain classes of external stimuli, including time-related events
To take advantage of multiple CPUs in a node, or multiple nodes in a distributed system
To increase the CPU utilization, by allocating the CPU to other activities while some thread of control
is suspended waiting for some other activity to complete (e.g., access to some external device, or access
to some other active object)
To prioritize activities (and potentially improve responsiveness)
To support system scalability (with additional processes sharing the load)
To separate concerns between different areas of the software
To achieve a higher system availability (with backup processes)
We use concurrently two strategies to determine the ‘right’ amount of concurrency and define the set of
processes that are needed. Keeping in mind the set of potential physical target architectures, we can proceed
Starting from the logical architecture: define agent tasks which multiplex a single thread of control
across multiple active objects of a class; objects whose persistency or life is subordinate to an active
object are also executed on that same agent; several classes that need to be executed in mutual
exclusion, or that require only small amount of processing share a single agent. This clustering
proceeds until we have reduced the processes to a reasonably small number that still allows distribution
and use of the physical resources.
Starting with the physical architecture: identify external stimuli (requests) to the system, define client
processes to handle the stimuli and servers processes that only provide services and do not initiate
them; use the data integrity and serialization constraints of the problem to define the right set of
servers, and allocate objects to the client and servers agents; identify which objects must be distributed.
The result is a mapping of classes (and their objects) onto a set of tasks and processes of the process
architecture. Typically, there is an agent task for an active class, with some variations: several agents for a
given class to increase throughput, or several classes mapped onto a single agent because their operations
are infrequently invoked or to guarantee sequential execution.
Note that this is not a linear, deterministic process leading to an optimal process architecture; its requires a
few iterations to get an acceptable compromise. There are numerous other ways to proceed, as shown by
Birman et al.5 or Witt et al.7 for example. The precise method used to construct the mapping is outside of
the scope of this article, but we can illustrate it on a small example.
Fig. 12 shows how a small set of classes from some hypothetical air-traffic control system maybe mapped
onto processes.
The flight class is mapped onto a set of flight agents: there are many flights to process, a high rate of
external stimuli, response time is critical, the load must be spread across multiple CPUs. Moreover the
persistency and distribution aspects of the flight processing are deferred to a flight server, which is
duplicated for availability reasons.
A flight profile or a clearance are always subordinate to a flight, and although there are complex classes,
they share the processes of the flight class. Flights are distributed to several other processes, notably for to
display and external interfaces.
A sectorization class, which established a partitioning of airspace for the assignment of jurisdiction of
controllers over flights, because of its integrity constraints, can be handled only by a single agent, but can
share the server process with the flight: updates are infrequent.
Locations and airspace and other static aeronautical information are protected objects, shared among
several classes, rarely updated; they are mapped on their own server, and distributed to other processes.
clearance profile
location airspace
multiple flight agents flight serve
Single sectorization agent
aeronautical info
Figure 12: Mapping from Logical to Process view
From logical to development
A class is usually implemented as a module, for example a type in the visible part of an Ada package. Large
classes are decomposed into multiple packages. Collections of closely related classes—class categories—
are grouped into subsystems. Additional constraints must be considered for the definition of subsystems,
such as team organization, expected magnitude of code (typically 5K to 20K SLOC per subsystem), degree
of expected reuse and commonality, and strict layering principles (visibility issues), release policy and
configuration management. Therefore we usually end up with a view that does not have a one to one
correspondence with the logical view.
The logical and development views are very close, but address very different concerns. We have found that
the larger the project, the greater the distance between these views. Similarly for the process and physical
views: the larger the project, the greater the distance between the views. For example, if we compare fig. 3b
and fig. 6, there is no one to one mapping of the class categories to the layers. If we take the ‘External
interfaces—Gateway’ category, its implementation is spread across several layers: communications
protocols are in subsystems in or below layer 1, general gateway mechanisms are in subsystems in layer 2,
and the actual specific gateways in layer 5 subsystems.
From process to physical
Processes and process groups are mapped onto the available physical hardware, in various configurations
for testing or deployment. Birman describes some very elaborate schemes for this mapping in the Isis
The scenarios relate mostly to the logical view, in terms of which classes are used, and to the process view
when the interactions between objects involve more than one thread of control.
Tailoring the Model
Not all software architecture need the full “4+1” views. Views that are useless can be omitted from the
architecture description, such as the physical view, if there is only one processor, and the process view if
there is only process or program. For very small system, it is even possible that the logical view and the
development view are so similar that they do not require separate descriptions. The scenarios are useful in
all circumstances.
Iterative process
Witt et al. indicate 4 phases for the design or an architecture: sketching, organizing, specifying and
optimizing, subdivided into some 12 steps7. They indicate that some backtracking may be needed. We think
that this approach is too “linear” for an ambitious and rather unprecedented project. Too little is known at
the end of the 4 phases to validate the architecture. We advocate a more iterative development, were the
architecture is actually prototyped, tested, measured, analyzed, and then refined in subsequent iterations.
Besides allowing to mitigate the risks associated with the architecture, such an approach has other side
benefits for the project: team building, training, acquaintance with the architecture, acquisition of tools, run-
in of procedures and tools, etc. (We are speaking here of an evolutionary prototype, that slowly grows into
becoming the system, and not of throw-away, exploratory prototypes.) This iterative approach also allows
the requirements to be refined, matured, better understood.
A scenario-driven approach
The most critical functionality of the system is captured in the form of scenarios (or use cases). By critical
we mean: functions that are the most important, the raison d’être of the system, or that have the highest
frequency of use, or that present some significant technical risk that must be mitigated.
A small number of the scenarios are chosen for an iteration based on risk and criticality. Scenarios
may be synthesized to abstract a number of user requirements.
A strawman architecture is put in place. The scenarios are then “scripted” in order to identify major
abstractions (classes, mechanisms, processes, subsystems) as indicated by Rubin and Goldberg6
decomposed in sequences of pairs (object, operation).
The architectural elements discovered are laid out on the 4 blueprints: logical, process, development,
and physical.
This architecture is then implemented, tested, measured, and this analysis may detect some flaws or
potential enhancement.
Lessons learned are captured.
Loop: The next iteration can then start by:
reassessing the risks,
extending the palette of scenarios to consider
selecting a few additional scenarios that will allow risk mitigation or greater architecture
Try to script those scenarios in the preliminary architecture
discover additional architectural elements, or sometimes significant architectural changes that
need to occur to accommodate these scenarios
update the 4 main blueprints: logical, process, development, physical
revise the existing scenarios based on the changes
upgrade the implementation (the architectural prototype) to support the new extended set of
Test. Measure under load, in real target environment if possible.
All five blueprints are then reviewed to detect potential for simplification, reuse, commonality.
Design guidelines and rationale are updated.
Capture the lessons learned.
End loop
The initial architectural prototype evolves to become the real system. Hopefully after 2 or 3 iterations, the
architecture itself become stable: no new major abstractions are found, no new subsystems or processes, no
new interfaces. The rest of the story is in the realm of software design, where, by the way, development may
continue using very similar methods and process.
The duration of these iterations varies considerably: with the size of the project to put in place, with the
number of people involved and their familiarity with the domain and with the method, and with the degree
of “unprecedentedness” of the system w.r.t. this development organization. Hence the duration of an
iteration may be 2-3 weeks for a small project (e.g., 10 KSLOC), or up to 6-9 months for a large command
and control system (e.g., 700 KSLOC).
Documenting the architecture
The documentation produced during the architectural design is captured in two documents:
•A Software Architecture Document, whose organization follows closely the “4+1” views (cf. fig. 13 for
a typical outline)
•A Software Design Guidelines, which captures (among other things) the most important design
decisions that must be respected to maintain the architectural integrity of the system.
Title Page
Change History
Table of Contents
List of Figures
1. Scope
2. References
3. Software Architecture
4. Architectural Goals & Constraints
5. Logical Architecture
6. Process Architecture
7. Development Architecture
8. Physical Architecture
9. Scenarios
10. Size and Performance
11. Quality
A. Acronyms and Abbreviations
B. Definitions
C. Design Principles
Figure 13 — Outline of a Software Architecture Document
This “4+1” view model has been used with success on several large projects with or without some local
customization and adjustment in terminology4. It actually allowed the various stakeholders to find what they
want to know about the software architecture. Systems engineers approach it from the Physical view, then
the Process view. End-users, customers, data specialists from the Logical view. Project managers, software
configuration staff see it from the Development view.
Other sets of views have been proposed and discussed, within Rational and elsewhere, for instance by
Meszaros (BNR), Hofmeister, Nord and Soni (Siemens), Emery and Hilliard (Mitre)8, but we have found
that often these other views proposed could usually be folded into one of the 4 we described. For example a
Cost & Schedule view folds into the Development view, a Data view into the Logical view, an Execution
view into a combination of the Process and Physical view.
View Logical Process Development Physical Scenarios
Components Class Task Module,
Subsystem Node Step,
Connectors association,
RPC, etc.
“with” clause,
tion medium,
bus, etc.
Containers Class category Process Subsystem
(library) Physical
subsystem Web
Stakeholders End-user System
manager System
designer End-user,
Concerns Functionality Performance,
S/W fault-
portability, line-
Tool support Rose UNAS/SALE
Table 1 — Summary of the “4+1” view model
The “4+1” view model owes its existence to many colleagues at Rational, at Hughes Aircraft of Canada, at
Alcatel, and elsewhere. In particular I would like to thank for their contributions Ch. Thompson, A. Bell, M.
Devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec, and E. Schonberg.
1. D. Garlan & M. Shaw, “An Introduction to Software Architecture,” Advances in Software
Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co. (1993).
2. D. E. Perry & A. L. Wolf, “Foundations for the Study of Software Architecture,” ACM Software
Engineering Notes, 17, 4, October 1992, 40-52.
3. Ph. Kruchten & Ch. Thompson, “An Object-Oriented, Distributed Architecture for Large Scale Ada
Systems,” Proceedings of the TRI-Ada ’94 Conference, Baltimore, November 6-11, 1994, ACM,
4. G. Booch: Object-Oriented Analysis and Design with Applications, 2nd. edition, Benjamin-Cummings
Pub. Co., Redwood City, California, 1993, 589p.
5. K. P. Birman, and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE
Computer Society Press, Los Alamitos CA, 1994.
6. K. Rubin & A. Goldberg, “Object Behavior Analysis,” CACM, 35, 9 (Sept. 1992) 48-62
7. B. I. Witt, F. T. Baker and E. W. Merritt, Software Architecture and Design—Principles, Models, and
Methods, Van Nostrand Reinhold, New-York (1994) 324p.
8. D. Garlan (ed.), Proceedings of the First Internal Workshop on Architectures for Software Systems,
CMU-CS-TR-95-151, CMU, Pittsburgh, 1995.
... En general, esos frameworks pretenden abarcar una "Enterprise Architecture", donde por "Enterprise" se entiende que la arquitectura incluye otras dimensiones pertenecientes al dominio de la organización y que trascienden el software, como los datos o los procesos de negocio. En ocasiones, sin embargo, se puede pretender describir y analizaŕ unicamente el software, y en ese caso puede ser suficiente un modelo como el de 4+1 vistas presentado en 1995 [34]. ...
... En la Sección 3.1 se presenta la metodología seguida para el análisis. Las secciones 3.2, 3.3, 3.4, 3.5 y 3.7 presentan respectivamente las vistas lógica, física, de procesos, de desarrollo y de casos de uso de APEX siguiendo el modelo de 4+1 vistas[34]. La sección 3.6 presenta algunas consideraciones especiales sobre una vista de desarrollo para el caso del IDE.3.1. ...
Full-text available
Multi-tier architectures have been the de facto standard for web applications, leaving little room for alternative architectures. In the industry there is a product to develop and run web applications that follows a different architecture, centered on the RDBMS to the extreme of not needing any other component to function. There are not many papers in academia that addresses RDBMS-centric architectures in general, and this extreme architecture in particular has not been considered. In this work, the state of the art of database-centric architectures is analyzed, and an example of extreme database-centric architecture is analyzed. The general case of the architecture that I have called RDBMS-only is described, and the guidelines of this architecture are followed in the development of a functional prototype. Based on the implementation of that prototype, the feasibility of the architecture for a class of applications is shown, and a critical analysis of the architecture is carried out.
... For instance, they are elaborated by the 4+1 architectural view model [29] involving a logical view, process view, development view, physical view, and scenarios, which do not have a visual format. Furthermore, the 4+1 model can be generalized to the N+1 model [30]. ...
... Thus, in the result, we might again refer back to the N+1 model [30]. These views have been detailed in [35], such as logical view, process view, deployment/physical view, data view, security view, implementation view, development view, and use case view. ...
Full-text available
Microservice system solutions are driving digital transformation; however, fundamental tools and system perspectives are missing to better observe, understand, and manage these systems, their properties, and their dependencies. Microservices architecture leads towards decentralization, which implies many advantages to system operation; it, however, brings challenges to their development. Microservice systems often lack a system-centric perspective that would help engineers better cope with system evolution and quality assessment. In this work, we explored microservice-specific architecture reconstruction based on static analysis. Such reconstruction typically results in system models to visualize selected system-centric perspectives. Conventional models involve 2D methods; however, these methods are limited in utility when services proliferate. We considered various architectural perspectives relevant to microservices and assessed the relevancy of the traditional method, comparing it to alternative data visualization using 3D space. As a representative of the 3D method, we considered a 3D graph model presented in augmented reality. To begin testing the feasibility of deriving such perspectives from microservice systems, we developed and implemented prototype tools for software architecture reconstruction and visualization of compared perspectives. Using these prototypes, we performed a small user study with software practitioners to highlight the potentials and limitations of these innovative visualizations used for common practitioner reasoning and tasks.
... We build on the results of this paper and present the following figure (Figure 3) with a visual mapping of the Pharaon (technology-agnostic) logical or functional layers to horizontal functional layers of the CREATE-IoT 3D RAM [17], with the most relevant Cross-Cutting Functions (CCF) and Properties (PROP) for Pharaon. In Pharaon, we opted to describe the architecture using the 4 + 1 View Model [18] of architecture, which organizes a description of the architecture using five views (each focusing on a specific set of concerns), which are: logical/functional view, process view, development view, physical view and scenarios (or use cases). ...
... The Application layer encompasses information delivery to Pharaon end-users following appropriate and common practices in Human-Computer Interaction (HCI) and Human-Environment Interaction (HEI). In Pharaon, we opted to describe the architecture using the 4 + 1 View Model [18] of architecture, which organizes a description of the architecture using five views (each focusing on a specific set of concerns), which are: logical/functional view, process view, development view, physical view and scenarios (or use cases). ...
Full-text available
The EU project Pharaon aims to support older European adults by integrating digital services, tools, interoperable open platforms, and devices. One of the objectives is to validate the integrated solutions in large-scale pilots. The integration of mature solutions and existing systems is one of the preconditions for the successful realization of the different aims of the pilots. One such solution is an intelligent, privacy-aware home-care assistance system, SmartHabits. After briefly introducing the Pharaon and SmartHabits, the authors propose different Pharaon models in the Ambient/Active Assisted Living (AAL) domain, namely the Pharaon conceptual model, Pharaon reference logical architecture view, AAL ecosystem model, meta AAL ecosystem model, and Pharaon ecosystem and governance models. Building on the proposed models, the authors provide details of the holistic integration and deployment process of the SmartHabits system into the Pharaon ecosystem. Both technical and supporting integration challenges and activities are discussed. Technical activities, including syntactic and semantic integration and securing the transfer of the Pharaon sensitive data, are among the priorities. Supporting activities include achieving legal and regulatory compliance, device procurement, and use-case co-designing in COVID-19 conditions.
... All these frameworks are similar in their argument about the individual model and how it is made, not what the role of the model is. This shortcoming is addressed in Kruchten's 4+1 View Model of Architecture [27]. To assist a selection of the model type and constrain the content this model ought to have, given the vastness of the subject matter, Kruchten structures his framework according to software development processes they support. ...
Conceptual models are an effective and unparalleled means to communicate complicated information with a broad variety of stakeholders in a short period of time. However, in practice, conceptual models often vary in clarity, employed features, communicated content, and overall quality. This potentially impacts model comprehension to a point where models are factually useless. To counter this, guidelines to create “good” conceptual models have been suggested. However, these guidelines are often abstract, hard to operationalize in different modeling languages, partly overlap, or even contradict one another. In addition, no comparative study of proposed guidelines exists so far. This issue is exacerbated as no established metrics to measure or estimate model comprehension for a given conceptual model exist. In this article, we present the results of a literature survey investigating 109 publications in the field and discuss metrics to measure model comprehension, their quantification, and their empirical substantiation. Results show that albeit several concrete quantifiable metrics and guidelines have been proposed, concrete evaluative recommendations are largely missing. Moreover, some suggested guidelines are contradictory, and few metrics exist that allow instantiating common frameworks for model quality in a specific way.
... Note that adding security to an RA is not adding security after a system is built; the RA is a conceptual model, not a specific software implementation; as such we can consider possible attacks for each included service or function. Also, an SRA is not a view of an architecture [71] (which only applies to a specific architecture), but a different model used for different purposes, although built from an RA. ...
Full-text available
Secure systems must be built in a systematic and holistic way, where security is an integral part of the development lifecycle and cuts across all architectural layers. This need is more evident in Cyber Physical Systems (CPSs), where attacks may target not only the information model of the system but also its physical entities. CPS systems are heterogeneous and often highly complex. Their possibly numerous components and cross-domain complexity make attacks easy to propagate and security difficult to implement. Moreover, this complexity results in a considerable variety of vulnerabilities and a large attack surface. To design secure CPS systems a good approach is to abstract their complexity and develop a common framework, namely a Reference Architecture (RA), to which we add security mechanisms in appropriate places to stop its threats to define a Security Reference Architecture (SRA). An SRA is an abstract architecture describing a conceptual model of security that provides a way to specify security requirements for a wide range of derived concrete architectures. An important type of CPS is a maritime container terminal, a facility where cargo containers are transported between ships and land vehicles for onward transportation, and vice versa. We present here an SRA for cargo ports built out of patterns, which goes beyond existing models in providing a global view and a more precise description than just block diagrams. Starting from an RA, we analyze security issues in each activity of the processes of the system and enumerate its threats. We describe threats using misuse patterns, and from them we select security patterns that realize defensive solutions.
... A possible task to show this level of understanding is then to describe the architecture. This can be expressed, for example, as defined by the 4+1 views suggested by Kruchten (1995). For example, in an experiment we can ask participants to draw a conceptual diagram showing relations between entities. ...
Full-text available
Understanding program code is a complicated endeavor. As a result, studying code comprehension is also hard. The prevailing approach for such studies is to use controlled experiments, where the difference between treatments sheds light on factors which affect comprehension. But it is hard to conduct controlled experiments with human developers, and we also need to find a way to operationalize what “comprehension” actually means. In addition, myriad different factors can influence the outcome, and seemingly small nuances may be detrimental to the study’s validity. In order to promote the development and use of sound experimental methodology, we discuss both considerations which need to be applied and potential problems that might occur, with regard to the experimental subjects, the code they work on, the tasks they are asked to perform, and the metrics for their performance. A common thread is that decisions that were taken in an effort to avoid one threat to validity may pose a larger threat than the one they removed.
Full-text available
This thesis explored software architecture design of microservices systems in the context of DevOps and make the following novel aspects: (1) This thesis proposes a set of taxonomies of the research themes, problems, solutions, description methods, design patterns, quality attributes as well as the challenges of microservices architecture in DevOps that contributes to the software engineering body of knowledge by conducting state of the art (i.e., systematic mapping) and practice (i.e., mixed-method) studies on architecture design of microservices systems. These studies mainly identify, analyze, and classify the challenges and the solutions for microservices architecture in DevOps, design of microservices systems, as well as monitoring and testing of microservices systems. The findings of these studies can help practitioners to improve the design of microservices systems. (2) This thesis proposes a taxonomy of issues occurring in microservices systems by analyzing 1,345 issue discussions extracted from five open source microservices systems. The proposed taxonomy of issues consisting of 17 categories, 46 subcategories, and 138 types. This thesis also identified a comprehensive list of causes and mapped them to the identified issues. The identified causes consist of 7 categories, 26 subcategories, and 109 types. The proposed taxonomy and identified causes can help practitioners to avoid and address various types of issues in the architecture design of microservices systems. (3) This thesis proposes a set of decision models for selecting patterns and strategies in four MSA design areas: application decomposition into microservices, microservices security, microservices communication, and service discovery. The proposed decision models are based on the knowledge gained from the systematic mapping study, mixed-method study, exploratory study, and grey literature. The correctness and usefulness of the proposed decision models have been evaluated through semi-structured interviews with microservices practitioners. The proposed decision models can assist practitioners in selecting appropriate patterns and strategies for addressing the challenges related to the architecture design of microservices systems.
Full-text available
Enterprise modeling is a set of tools, methods and practices for an aligned development of business, functional, organizational and technical aspects of an enterprise. Therefore, an enterprise model is always a set of sub-models of different semantics. In order to form a consistent enterprise model, its sub-models should be aligned to each other. The practice of modeling shows the difficulties in design of an aligned set of sub-models of an enterprise model. In this paper we present a review of enterprise modeling approaches aiming to find the reasons of difficulties. Our review shows that enterprise modeling approaches not sufficiently use the semantic relations of sub-models for building an enterprise model. This paper identifies and formalizes the semantic relations of sub-models and suggests to use them as constraints directing the design of aligned sub-models. The constraints imposed by sub-models of the enterprise model to each other are illustrated with a case study in ArchiMate.
Conference Derivative Article. Every day, people need to be trained, either to complement their professional skills or because of personal interests that lead to their well-being. Online education, especially MOOC and SPOC are good alternatives for carrying out continuing educational processes, but are not enough when it comes to learning motor skills. This paper shows a research approach on how MOOC can expand its functionalities so that it can be applied to learning motor skills. It also proposes the development of a project to integrate three components: the integration component, the wearable component and the open edX component for the future development of a "salsa" course. Finally, it proposes an architecture based on the 4+1 view model, where the functionality in different areas of the design is shown.
A blockchain network is a distributed system established by mutually distrusting participants to operate a blockchain, enabling them to manage critical information such as account balances or asset ownership without a centralised third party. Blockchain network deployment and evaluation have become prevalent due to the emerging blockchain use cases by enterprises, governments, and Internet of Things (IoT) applications, which demand private blockchains rather than participating in public ones. A blockchain network architecture drives deployment and evaluation activities. Nevertheless, practitioners must learn and perform error-prone activities to transform architecture into a blockchain network and evaluate it. Therefore, it is beneficial to automate these activities so that practitioners can focus on the architecture design, a valuable and hard-to-automate activity. The key challenges of such an automation framework are keeping up with the advances in blockchain technologies and the increasing complexity of blockchain network architecture. This paper proposes NVAL, a software framework that implements a novel architecture-driven, community-supported approach to automate blockchain network deployment and evaluation. NVAL accepts blockchain network architecture as input. It supports complex multi-channel blockchain networks, an increasingly prevalent architecture for private blockchain. The framework keeps up with blockchain technologies by leveraging platform-specific automation programs developed by a practitioner community via runtime composition to handle new networks. We evaluated NVAL with a case study and showed that the framework requires only seven automation programs to deploy 65 blockchain networks with 12 diverse architectures and generate 295 evaluation datasets. Furthermore, it consumes only 95.5 ms to plan and orchestrate the deployment and evaluation, which is minuscule compared to the total time required for deploying and benchmarking a blockchain network.
As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system – the software architecture – presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper, we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions.
Conference Paper
This paper presents an architectural model ideally suited for the description of large, distributed command and control systems. This model is organized around multiple dimensions (or views) of software architecture and is used to describe the software architecture of a family of automated air traffic control systems currently under development by Hughes Aircraft of Canada. Some of the features of this family of systems are described, and in particular the mechanism used for transparent access to objects. This distributed object management mechanism illustrates the implementation of the most salient architectural principles used in the design.
Conference Paper
The 14-state European Organization for the Safety of Air Navigation (EUROCONTROL) has recently completed its target platform selection analyses for the Central Flow Management Unit’s (CFMU) Tactical subsystem (TACT). TACT will provide support to CFMU and other users of the airspace in their tactical and pm-tactical Air Traffic Plow Management (A- activities for Europe. Its estimated size is about 160,000+ Ada source lines. To assure ample computing margins on its target platform, EUROCONTROL undertook rigorous selection analyses which evaluated platforms proposed by several vendors. These analyses employed a true s@var@rst approach, whereby several independent software benchmarks were hosted and executed on all proposed platforms, ateach vendor’s site. The benchmarks consist of (1) a large, distributed prototype TACT subsystem constructal using TRW’s Universal Network Architecture Services (UNAS) product(2) UNAS’S internally-developed Performance Te.sL used to compare interpmcess communications performance and (3) a database intensive tesb used to obtain ORACLE performance characteristics (not covered in this paper). The focus of this paper is on UNAS’S open technology and how it was explohed to build and fully instrument benchmarks (1) and (2) on four completely independent hardware configurations+qmesenting a truly sofiwaref~ approach to target platform selection. CFMU’S TACT SYSTEM OVERVIEW To cope with Europe’s accelerated growth in air traffic and at the request of the Ministers of Transport of the 23 states belonging to @eEuropean Civil Aviation Conference (ECAC), EUROCONTROL prepared the CFMU plan in July, 1989. The plan proposes a phased implementation of CPMU. The TACT system is being implemented forCFMU111for May, 1994.
The software architecture of most systems is described informally and diagrammatically. In order for these descriptions to be meaningful at all, figures are understood by interpreting the boxes and lines in specific, conventionalized ways[5]. The imprecision of these interpretations has a number of limitations. In this paper we consider these conventionalized interpretations as architectural styles and provide a formal framework for their uniform definition. In addition to providing a template for precisely defining new architectural styles, this framework allows for the proof that the notational constraints on a style are sufficient to guarantee the meanings of all described systems and provides a unified semantic base through which different stylistic interpretations can be compared. 1 Introduction Software architecture is an important level of description for software systems. At the software architectural level of abstraction, a system is typically described as a collection of int...
From Domain Model to Architectures <i>Focused Workshop on Software Architecture,</i&gt
  • Paul Clements