The 4+1 View Model of Architecture
The 4+1 View Model of Architecture
The 4+1 View Model of Architecture
Model of
Architecture
PHILIPPE B. KRUCHTEN, Rational Software
*The 4+1 V?ew Model e all have seen turely partitioning the software or
many books and articles in which a overemphasizing one aspect of devel-
organizes a description of a single diagram attempts to capture the opment (like data engineering or run-
sojimare architecture usingjive gist of a system architecture. But when time efficiency), development strategy,
you look carefully at the diagram’s or team organization. Other software
concurrent views, each of which boxes and arrows, it becomes clear that architectures fail to address the con-
the authors are struggling to represent cerns of all “customers.”
addressesa speczj%set of concerns. more in one diagram than is practical. Several authors have noted the
Architects capture their design Do the boxes revpresent running pro- problem of architectural representa-
grams? Chunks of source code? tion, including David Garlan and
decisions in four- views and use Physical computers? Or merely logical Mary Shaw,’ Gregory Abowd and
groupings of functionality? Do the Robert Allen,’ and Paul C1ements.j
thefiJZh view to illustrate and
arrows represent compilation depen- The 4 + I View Model was devel-
validate them. dencies? Control flows? Dataflows? oped to remedy the problem. The 4 +
Usually the answer is that they repre- 1 model describes software architec-
sent a bit of everything. ture using five concurrent views. As
Does an architecture need a single Figure 1 shows, each addresses a spe-
architectural style? Sometimes the cific set of concerns of interest to dif-
software architecture suffers from sys- ferent stakeholders in the system.
tem designers who go too far, prema- + The logical view describes the
driven, you can use an alternative nale and constraints, connecting the Logicalview . Development‘,~ew
approach to develop some other form architecture to some of the require- **.I)-=-. .<.?_
of logical view, such as an entity- ments. Scenarios
relationship diagram. Each view is described by what we ’ hb*.e _/- ’
+ The process view describes the call a “blueprint” that uses its own par- Processview - Physicalview
design’s concurrency and synchroniza- ticular notation. The architects can . IIexe ,_s_l .. - ” .wi ”
tion aspects. also pick a certain ahitectural style for Systemintegrators Systemengineers
l performance l systemtopology
+ The physical view describes the each view, thus allowing the coexis- l scolobility l delivery
mapping of the software onto the tence of multiple styles in one system. l throughput l installation
hardware and reflects its distributed The 4+1 View Model is rather l telecommunication
Displaynnd
user ~olerfote
ExternalInterfores/
Simulationand
Class ~~~~~ Assotiotion Translation : troining
Conversolion ~ services
.- xw&A-&1-
Containment,
-.
oggregotion
‘; Classutility Usage Connectioni, Flight Air troific
Terminal
services r: manogement monogement
-+ Inheritance .-+&J
*- 9 Y L . .a,
formalorguments
porometerized -- -~---, kiStontiOtiOn
Controller Aeronautical
class
mformotion
Classcategory
Figure 2. (A) Notation jh the logical blueprint; (B) logical blueprint for the Tt!lic PBX; (C) bluepht for an ail--traj
control system.
Best
----
Copy ~~Available
IEEE SOFTWARE 43
a set of key abstractions, taken mainly erably to account for only those items events, such as a “start,” “stop,” or
from the problem domain. These that are architecturally significant. The “digit.” The controller also bears all
abstractions are objects or object classes numerous adornments are not very the hard real-time constraints. This
that exploit the principles of abstrac- useful at this level of design. We use class has many subclasses that cater to
tion, encapsulation, and inheritance. In Rational Rose to support the logical- different interfaces.
addition to aiding functional analysis, view design. The Terminal object maintains the
decomposition identifies mechanisms state of a terminal and negotiates ser-
and design elements that are common Style.For the logical view, we use an vices on behalf of that line. For exam-
across the system. object-oriented style. The main design ple, it uses the services of the
We use the RationaUBooch guideline we follow is to keep a single, Numbering Plan object to interpret
approach’ to represent the logical view coherent object model across the dialing.
through class diagrams and templates. entire system, avoiding the premature The Conversation object represents
A class diagram shows a set of classes specialization of classes and mecha- a set of terminals engaged in a conver-
and their logical relationships: associa- nisms for each site or processor. sation. It uses the Translation Services
tion, usage, composition, inheritance, object (for accessing a directory, map-
and so on. Designers can group sets of Examples.Figure 2b shows the main ping a logical address to a physical one,
related classes into class categories. Class classes involved in a sample PBX archi- and routing) and the Connection
templates focus on each individual class; tecture we developed at Alcatel. A PBX Services object to establish a voice path
they emphasize the main class opera- establishes communication among ter- among the terminals.
tions and identify key object character- minals. A terminal might be a tele- Larger systems contain dozens of
istics. If an object’s internal behavior phone, a trunk line (a line to the cen- architecturally significant classes, such
must be defined, we use state-transi- tral of&e), a tie line (a private PBX-to- as the top-level class diagram of an air-
tion diagrams or state charts. Class util- PBX line), or a feature phone line. traffic control system’ in Figure 2c.
ities define common mechanisms or Different lines are supported by dif- The system, developed by Hughes
services. ferent line-interface cards. The Aircraft of Canada, contains eight class
Controller object decodes and injects categories.
NOM~OII.We derived the logical-view all the signals on the line-interface
notation in Figure 2a from the Booth card, translating card-specific signals to Processview. The process view takes
notation, which we simplified consid- and from a small, uniform set of into account some nonfunctional
Terminalprocess
-- .
Controllerprocess
Component Connectors
~~ Unspecified
Process
-wA.r
.
&we 3. (A) Notation for the process view; (B) partial process blueprint for the Tt!lic PBX.
line operational systems and to repre- architecturally significant elements, as through shared memory.
sent the coexistence of simulation or Figure 3a shows.
test versions of the software. We have used TRW’s Universal Development view. The develonment
A process is a group of tasks that Network Architecture Services to view foc&es on the organizationLof the
form an executable unit. Processes rep- build and implement the processes and actual software modules in the soft-
resent the level at which the process tasks (and their redundancies) into net- ware-development environment. The
view can be tactically controlled (start- works of m-ocesses. UNAS contains a 1 software is nackaged in small chunks
I
ed, recovered, reconfigured, shut tool - the Software Architects - program’ librahes or subsystems -
down, and so on). In addition, process- Lifecycle Environment - that sup- that can be developed by one or more
es can be replicated to distribute pro- ports our notation. SALE lets us depict developers. The subsystems are orga-
cessing load or improve system avail- the process view graphically, including nized in a hierarchy of layers, each
ability. specifications of the possible intertask- layer providing a narrow and well-
communication paths. It can then defined interface to the layers above it.
fortifioning. To develop the process automatically generate the correspond- The development view takes into
view, designers partition the software ing Ada or C++ source code. Because it account internal requirements related
into a set of independent tasks: separate supports automatic code generation, to ease of development, software man-
threads of control that can be individu- SALE makes it easier to change the agement, reuse or commonality, and
ally scheduled on separate processing nrocess view.
I
constraints imnosed bv, the toolset or
nodes. the program;ning language. The
We separate tasks into two groups: Style. Several styles would fit the development view supports the alloca-
+ Major tasks are the architectural process view. For example, picking tion of requirements and work to
elements that can be uniquely from Garlan and Shaw’s taxonomy- 1 teams, and supports cost evaluation,
addressed (designated from another you can use pipes and filters or planning, monitoring of project
task). They communicate through a client/server, with variants of multi- progress, and reasoning about software
set of well-defined intertask-commu- ple-client/single-server and multiple- reuse, portability, and security. It is the
nication mechanisms: synchronous clients/multiple-servers. For more basis for establishing a line of product.
and asynchronous message-based complex systems, you can use a style The development view is represent-
communication services, remote pro- similar to the ISIS system’s process ed by module and subsystem diagrams
cedure calls, event broadcasts, and so groups, as described by Kenneth that show the system’s export and
on. Major tasks should not make Birman using another notation and import relationships. You can describe
assumptions about their collocation in toolset.* the complete development view only
IEEE SOFTWARE 45
Components connector
.
Reference
lomp~lation
Module
dependency
(include,“with”)
after you have identified all the soft- favor of a simpler, layer-by-layer
ware elements. However, you can list release strategy.
the rules that govern the development
view - partitioning, grouping, and Examples. As Figure 5 shows, the
visibility - before you know every ele- Hughes Air Traffic System has five
ment. development layers.’ Layers 1 and 2 -
utilities and support mechanisms -
Layer
Ivotahr. As Figure 4 shows, we again constitute a domain-independent, dis-
use a variation of the Booth notation, tributed infrastructure that is common
Figure 4. Notation for a developmen; limited to architecturally significant across the line of products. These lay-
blueprint. items. Rational’s Apex development ers shield the application from varia-
environment supports the definition tions in hardware platforms, operating
and implementation of the develop- systems, or off-the-shelf products such
ment view, the layering strategy as database-management systems. To
Human-computer interface described above, and design-rule this infrastructure, layer 3 adds an air-
Layer ’ Externolrvrtemr enforcement. Rational Rose can draw traffic control framework to form a
ATCfu&onal areas:flight manage- the development blueprints for Ada domain-specific software architecture.
Layer4 ment, sectormonogement,ond IO on. and C++ at the module and subsystem Layer 4 adds a palette of functionality,
level, in forward engineering, and by and layer 5 contains most of the user
Aeronouticolclosles
‘Oyer 3 ATt classes reverse engineering from the develop- interface and the interfaces to external
ment source code. systems. This top layer is customer-
Supportmechanisms:
and product-dependent. Spread across
Layer 2 communication,time, storoge,
resourcemanagement,and so on Style. We recommend you define the five layers are some 72 subsystems,
four to six layers of subsystems in the each containing from 10 to 50 mod-
Layer 1
Bindings
Commonutilities ,ow~,eve,rerviter
development view. One design rule we ules. We represent these subsystems
follow here is that a subsystem can on additional, more detailed blue-
only depend on subsystems in the same prints.
or lower layers. This minimizes the
Figure fi. The five layers of Hughes development of very complex networks Physical view. The physical view
Air Trafic System. of dependencies between modules in takes into account the system’s non-
Components
Communicafion
line
mm*, . *.v
Processor Communication
(non-permanent)
-A .A
- * Unidirectionalcommunication
F F
primary * ) backup
,a-- - High-bondwidthcommunication,
*&SW V,‘S “’
Otherdevice BUS
.. .C 4. . . PC .C .I .*
K K K K K K K K
(Al (Bl , ._
46 Best
---
Copy Available NOVEMBER 1995
F (
hverralion
process prorerr
w* _q * v--w--
v
Termlnol
F * F *
proteir Pseudo-tentrol keudo-cenrrol
functional requirements such as system .__ I - prOtW pot&S
availability, reliability (fault-tolerance), ‘* “?’r-=- A
performance (throughput), and scala- . .
bility. The software executes on a net- K ’
Controller (onveriotion hrerrotion
work of computers (the processing prorerr prow prow5
nodes). The various elements identi- b_,i-” *‘A - I *
(Al
fied in the logical, process, and devel- . 7
opment views - networks, processes, Terminal Terminal
tasks, and objects - must be mapped process prow
onto the various nodes. Several differ- ~‘?c p”- ‘. A=
ent physical configurations will be used
- some for development and testing,
others for system deployment at vari-
ous sites or for different customers. process proterr prcters
The mapping of the software to the ’ =‘** L _‘-” *-“x-- ,
nodes must therefore be highly flexible
and have a minimal impact on the . .
source code itself. tw tine *tardr he turds he cords
IEEE SOFTWARE 47
Best Copy Available
--
-
(1) off-hook )
rleoronce profile
l ’
IEEE SOFTWARE
Best Copy Available
~-~
49
prototype) to support the new extend- development organization. Hence the respected to maintain the architectural
ed set of scenarios. iteration may last two to three weeks integrity of the system.
At this point, you should test the for a small project (10,000 lines of
architecture by measuring under load
(in the target environment, if possible)
and review all five views to detect
code), or from six to nine months for a
large command-and-control
(700,000 lines of code or larger).
system W e have used the 4+1 View Model
on several large projects, cus-
tomizing it and adjusting the termi-
potential simplifications, commonali- nology somewhat.5 We have found
ties, and opportunities for reuse. Then Tailoring the model. Not all software that the model actually allows the vari-
update the design guidelines and ratio- architectures need every view in the ous stakeholders to find what they
nale and capture lessons learned. And 4+1 View Model. Views that are use- need in the software architecture.
then loop again. less can be omitted. For example, you System engineers approach it first
Finally, the initial architectural pro- could eliminate the physical view if from the physical view, then the
totype evolves to become the real sys- there is only one processor or the process view; end users, customers,
tem. After two or three iterations, the process view if there is only one and data specialists approach it from
architecture itself should become sta- process or program. For very small the logical view; and project managers
ble, and you should find no new major systems, logical and development views and software-configuration staff mem-
abstractions, subsystems, processes, or are sometimes so similar that they can bers approach it from the develop-
interfaces. The rest is in the realm of be described together. The scenarios ment view.
software design - where you can con- are useful in all circumstances. Other sets of views have been pro-
tinue development using very similar posed and discussed at our company
methods and process. Documentation. The documentation and elsewhere, but we have found that
produced during the architectural proposed views can usually be folded
Timetable. The duration of these iter- design is captured in two documents: into one of the four existing views. A
ations varies considerably, depending + a software architecture document, cost and schedule view, for example,
on the size of the project, the number organized by the 4+ 1 views, and folds into the development view, a data
of people involved, and their expertise 6 a software design guideline, which view into the logical view, and an exe-
in the domain and the development captures (among other things) impor- cution view into a combination of the
method. It also varies relative to the tant design decisions that must be process and physical view. +
50 NOVEMBER 1995