4+1 The View Model of Architecture
PHILIPPE
B.
KRUCHTEN,
Rational
Software
*The
4+1 V?ew Model
organizes a description of a sojimare architecture usingjive concurrent views, each of which addressesa speczj%set of concerns. Architects capture their design decisions in four- views and use thefiJZh view to illustrate and validate them.
e all have seen many books and articles in which a single diagram attempts to capture the gist of a system architecture. But when you look carefully at the diagram s boxes and arrows, it becomes clear that the authors are struggling to represent more in one diagram than is practical. Do the boxes revpresent running programs? Chunks of source code? Physical computers? Or merely logical groupings of functionality? Do the arrows represent compilation dependencies? Control flows? Dataflows? Usually the answer is that they represent a bit of everything. Does an architecture need a single architectural style? Sometimes the software architecture suffers from system designers who go too far, prema-
turely partitioning the software or overemphasizing one aspect of development (like data engineering or runtime efficiency), development strategy, or team organization. Other software architectures fail to address the concerns of all customers. Several authors have noted the problem of architectural representation, including David Garlan and Mary Shaw, Gregory Abowd and Robert Allen, and Paul C1ements.j The 4 + I View Model was developed to remedy the problem. The 4 + 1 model describes software architecture using five concurrent views. As Figure 1 shows, each addresses a specific set of concerns of interest to different stakeholders in the system. + The logical view describes the
42
O/407459/94/$04
00 0 1994 WE
NOVEMBER
1995
design object model when an objects oriented design method is used. To design an application that is very datadriven, you can use an alternative approach to develop some other form of logical view, such as an entityrelationship diagram. + The process view describes the design concurrency and synchronizas tion aspects. + The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. + The development view describes the software static organization in its s 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. At Rational, we apply Dewayne Perry and Alexander Wolfs formula
Software architecture = [Elements, Forms, Rationale/Constraints}
use (components, containers, and connectors), capture the forms and patterns that work, and capture the rationale and constraints, connecting the architecture to some of the requirements. Each view is described by what we call a blueprint that uses its own particular notation. The architects can also pick a certain ahitectural style for each view, thus allowing the coexistence of multiple styles in one system. The 4+1 View Model is rather generic: You can use notations and tools other than those we describe, as well as other design methods, especially for the logical and process decompositions.
I ~~ users End
l
functionality Logicalview .
Programmers l softwaremanagement Development,~ew **.I)-=-. .<.?_ Scenarios
hb*.e _/-
Physical view ,_s_l .. - .wi Systemengineers l systemtopology l delivery l installation l telecommunication
Process view . IIexe Systemintegrators l performance l scolobility l throughput
1. The 4+1 View Model is used to organize the description of the architecture of a software-intensive system.
Figure
4tl VIEW MODEL Software architecture deals with abstraction, decomposition and composition, and style and aesthetics. It also deals with the design and implementation of software s high-level structure. Designers build architectures using several architectural elements in wellchosen forms. These elements satisfy
the major functionality and performance requirements of the system as well as other, nonfunctional requirements such as reliability, scalability, portability, and system availability. Logical view. The logical view primarily supports the functional requirements - the services the system should provide to its end users. Designers decompose the system into
independently on each view. For each view we define the set of elements to
Displaynnd user ~olerfote ExternalInterfores/ Simulation and troining .xw&A-&1-
Class
~~~~~
Assotiotion Containment, oggregotion
Conversolion ~
Translation : services -.
Class ; utility
Usage
Terminal
-+ Inheritance formalorguments porometerized -- -~---, kiStontiOtiOn class
Connectioni, services r: .-+&J
Flight manogement *9Y Aeronautical mformotion
Air troific monogement L . .a,
Controller
Class category
Figure 2. (A) Notation jh
control system.
the logical blueprint;
(B) logical blueprint for the Tt!lic PBX; (C) bluepht
for an ail--traj
IEEE SOFTWARE
Best Copy ~~ Available ----
43
a set of key abstractions, taken mainly from the problem domain. These abstractions are objects or object classes that exploit the principles of abstraction, encapsulation, and inheritance. In addition to aiding functional analysis, decomposition identifies mechanisms and design elements that are common across the system. We use the RationaUBooch approach to represent the logical view through class diagrams and templates. A class diagram shows a set of classes and their logical relationships: association, usage, composition, inheritance, and so on. Designers can group sets of related classes into class categories. Class templates focus on each individual class; they emphasize the main class operations and identify key object characteristics. If an object internal behavior s must be defined, we use state-transition diagrams or state charts. Class utilities define common mechanisms or services. NOM~OII. derived the logical-view We notation in Figure 2a from the Booth notation, which we simplified consid-
erably to account for only those items that are architecturally significant. The numerous adornments are not very useful at this level of design. We use Rational Rose to support the logicalview design. Style.For the logical view, we use an object-oriented style. The main design guideline we follow is to keep a single, coherent object model across the entire system, avoiding the premature specialization of classes and mechanisms for each site or processor. Examples. Figure 2b shows the main classes involved in a sample PBX architecture we developed at Alcatel. A PBX establishes communication among terminals. A terminal might be a telephone, a trunk line (a line to the central of&e), a tie line (a private PBX-toPBX line), or a feature phone line. Different lines are supported by different line-interface cards. The Controller object decodes and injects all the signals on the line-interface card, translating card-specific signals to and from a small, uniform set of
events, such as a start, stop, or digit. The controller also bears all the hard real-time constraints. This class has many subclasses that cater to different interfaces. The Terminal object maintains the state of a terminal and negotiates services on behalf of that line. For example, it uses the services of the Numbering Plan object to interpret dialing. The Conversation object represents a set of terminals engaged in a conversation. It uses the Translation Services object (for accessing a directory, mapping a logical address to a physical one, and routing) and the Connection Services object to establish a voice path among the terminals. Larger systems contain dozens of architecturally significant classes, such as the top-level class diagram of an airtraffic control system in Figure 2c. The system, developed by Hughes Aircraft of Canada, contains eight class categories. Processview. The process view takes into account some nonfunctional
Terminalprocess
-Component ~~ Process Connectors Unspecified Controllerprocess
.
-wA.r .
tontroller tosk (low rote)
...S .&YS.-
(ontroller task [high rate)
&we
3. (A) Notation for the process view; (B) partial process blueprint for the Tt!lic PBX.
Best Copy Available
NOVEMBER
1995
requirements, such as performance and system availability. It addresses concurrency and distribution, system integrity, and fault-tolerance. The process view also specifies which thread of control executes each operation of each class identified in the logical view. Designers describe the process view at several levels of abstraction, each one addressing a different concern. At the highest level, the process view can be seen as a set of independently executing logical networks of communicating programs (processes) that are across a set of hardware distributed resources, which in turn are connected by a bus or local area network or wide area network. Multiple logical networks may exist simultaneously, sharing the same physical resources. For example, you can use independent logical networks to separate on- and offline operational systems and to represent the coexistence of simulation or test versions of the software. A process is a group of tasks that form an executable unit. Processes represent the level at which the process view can be tactically controlled (started, recovered, reconfigured, shut down, and so on). In addition, processes can be replicated to distribute processing load or improve system availability. fortifioning. To develop the process view, designers partition the software into a set of independent tasks: separate threads of control that can be individually scheduled on separate processing nodes. We separate tasks into two groups: + Major tasks are the architectural elements that can be uniquely addressed (designated from another task). They communicate through a set of well-defined intertask-communication mechanisms: synchronous and asynchronous message-based communication services, remote procedure calls, event broadcasts, and so on. Major tasks should not make assumptions about their collocation in
the same process or processing node. + Minor tasks are additional tasks introduced locally for implementation reasons such as cyclical activities, buffering, and time-outs. They can be implemented as Ada tasks or lightweight threads, for example, and communicate bv rendezvous or shared i memorv. We use the process blueprint to estimate message flow and process loads. It is also possible to implement a hollow process view with dummy process loads and measure its performance on a target system.
TODEVELOP THE PROCESS , VIEW THE DESIGNER PARTITIONS THE SOFTWARE INTO SEPARATE TASKS.
Ivofufion. Our process-view notation is expanded from Booth original notas tion for Ada tasking and focuses on architecturally significant elements, as Figure 3a shows. Development view. The develonment We have used TRW s Universal view foc&es on the organizationLof the Network Architecture Services to actual software modules in the softbuild and implement the processes and ware-development environment. The tasks (and their redundancies) into networks of m-ocesses. UNAS contains a 1 software is nackaged in small chunks - program librahes or subsystems tool the Software Architects that can be developed by one or more Lifecycle Environment - that supdevelopers. The subsystems are orgaports our notation. SALE lets us depict nized in a hierarchy of layers, each the process view graphically, including layer providing a narrow and wellspecifications of the possible intertaskdefined interface to the layers above it. communication paths. It can then The development view takes into automatically generate the correspondaccount internal requirements related ing Ada or C++ source code. Because it to ease of development, software mansupports automatic code generation, agement, reuse or commonality, and SALE makes it easier to change the constraints imnosed bv the toolset or nrocess view. , the program;ning language. The development view supports the allocaStyle. Several styles would fit the tion of requirements and work to process view. For example, picking from Garlan and Shaw taxonomys 1 teams, and supports cost evaluation, you can use pipes and filters or planning, monitoring of project progress, and reasoning about software client/server, with variants of multireuse, portability, and security. It is the ple-client/single-server and multiplebasis for establishing a line of product. clients/multiple-servers. For more The development view is representcomplex systems, you can use a style ed by module and subsystem diagrams similar to the ISIS system process s that show the system export and s groups, as described by Kenneth import relationships. You can describe Birman using another notation and the complete development view only toolset.*
1
Example.Figure 3b shows a partial process view for the PBX introduced in Figure 2b. All terminals are handled by a single terminal process that is driven by messages in its input queues. The Controller objects are executed on one of three tasks that comprise the controller m-ocess: a low cvcle-rate task, which scans all inactive terminals (200 ms) and puts any terminal becoming active in the scan list of the high cycle-rate task (10 ms), which detects any significant changes of state and passes them to the main controller task, which interprets the changes and communicates them by message to the corresponding terminal. Message passing within the controller nrocess is done through shared memory.
I
I
IEEE
SOFTWARE
45
Components
connector . Reference lomp~lation dependency (include,with)
Module
after you have identified all the software elements. However, you can list the rules that govern the development view - partitioning, grouping, and visibility - before you know every element. Ivotahr. As Figure 4 shows, we again use a variation of the Booth notation, limited to architecturally significant items. Rational Apex development s environment supports the definition and implementation of the development view, the layering strategy described above, and design-rule enforcement. Rational Rose can draw the development blueprints for Ada and C++ at the module and subsystem level, in forward engineering, and by reverse engineering from the development source code. Style. We recommend you define four to six layers of subsystems in the development view. One design rule we follow here is that a subsystem can only depend on subsystems in the same or lower layers. This minimizes the development of very complex networks of dependencies between modules in
favor of a simpler, release strategy.
layer-by-layer
Layer
Figure 4. Notation for a developmen;
blueprint.
Layer Layer4
Human-computer interface Externolrvrtemr ATC fu&onal areas:flight management, sectormonogement, IO on. ond Aeronouticol closles ATt classes Supportmechanisms: communication, time, storoge, resource management, so on and Bindings Common utilities ,ow~,eve, rerviter
Oyer 3 Layer 2
Layer 1
Examples. As Figure 5 shows, the Hughes Air Traffic System has five development layers. Layers 1 and 2 utilities and support mechanisms constitute a domain-independent, distributed infrastructure that is common across the line of products. These layers shield the application from variations in hardware platforms, operating systems, or off-the-shelf products such as database-management systems. To this infrastructure, layer 3 adds an airtraffic control framework to form a domain-specific software architecture. Layer 4 adds a palette of functionality, and layer 5 contains most of the user interface and the interfaces to external systems. This top layer is customerSpread across and product-dependent. the five layers are some 72 subsystems, each containing from 10 to 50 modules. We represent these subsystems on additional, more detailed blueprints. Physical view. The physical view takes into account the system nons
Figure
fi. The five layers of Hughes
System.
Air Trafic
Components
Communicafion line mm*, . *.v Processor Communication (non-permanent)
-A .A F
- * Unidirectional communication ,a-Otherdevice High-bondwidth communication,
BUS
F
primary * *&SW
) backup V, S
..
K (Al (Bl
.C
4.
..
PC
.C
.I
.*
K
K
K , ._
K
K
K
K
igure 6. (A) Notation fey a physical blueprint;
(@ a PBX physical blueprint.
46
Best Copy Available ---
NOVEMBER
1995
F hverralion process w* _q v Termlnol proteir .__ I F
( prorerr * v--w--
functional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes on a network of computers (the processing nodes). The various elements identified in the logical, process, and development views - networks, processes, tasks, and objects - must be mapped onto the various nodes. Several different physical configurations will be used - some for development and testing, others for system deployment at various sites or for different customers. The mapping of the software to the nodes must therefore be highly flexible and have a minimal impact on the source code itself. Notation.Because physical blueprints can become very messy in large systerns, we organize them in several forms, with or without the mapping from the process view, as Figures 6 and 7 show. UNAS provides us with a data-driven means of mapping the process view onto the physical view. This lets us make many changes to the mapping without modifying the source code. Figure 6b shows a possible hardware configuration for a large PBX; Figures 7a and 7b show mappings of the process view on two different physical views, a small and a large PBX. Scenarios. We use a small subset of important scenarios - instances of use cases - to show that the elements the of four views work together seamlessly. For each scenario, we describe the corresponding scripts (sequences of interactions between objects and between processes) as described by Ken Rubin and Adele Goldberg. The scenarios are in some sense an abstraction of the most important requirements. Their design is expressed using object-scenario and object-interaction diagrams. This view is redundant with the other ones (hence the +l), but it plays two critical roles: + it acts as a driver to help design-
* Pseudo-tentrol
prOtW
F
* keudo-cenrrol
pot&S
? * r-=K Controller prorerr b_,i- . (onveriotion prow * A-
A
. hrerrotion prow5
(Al
.
Terminal process ~c p?
I 7
*
Terminal prow . A=
process = L _ ** -
proterr *-x--
prcters ,
. tw
tine * tardr he turds
.
he cords
Fip-e
7. (A) A small PBX physical view with process allocation; (B) a physical blueprint for a larger- PBX; C, F, and K are three types of computers that have
___
___
different capacities azd support three different executables.
ers discover architectural elements during the architecture design, and + it validates and illustrates the architecture design, both on paper and as the starting point for the tests of an architectural prototype. Nototion. The scenario notation is very similar to that used for the logical view, except that it uses the connectors from the process view to indicate object interactions. As for the logical view, we manage object-scenario diagrams using Rational Rose. Figure 8 shows a fragment of a scenario for the small PBX. The corresponding script reads: 1. The controller of Joe phone s detects and validates the transition from on-hook to off-hook and sends a message to wake the corresponding terminal object. 2. The terminal allocates some resources and tells the controller to emit a 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.
AMONG VIEWS CORRESPONDENCE The various views are not fully independent. Elements of one view are connected to elements in other views, following certain design rules and heuristics. From logical view to process view. We identify several important characteristics of the logical view classes: autonomy, persistence, subordination and distribution. Autonomy identifies whether objects are active, passive, or protected. An active object invokes other objects operations or its own operations, and has full control over other objects invoking its operations. Apassive object never spontaneously invokes any operations, and has no control over other objects invoking its operations. A protected object never invokes spontaneously any operations but arbitrates
IEEE
SOFTWARE
Best Copy Available --
47
(1) off-hook loe:tonlroller . ( diol ) One (3) digit c ) 1oe:terminol (4) digit * Numberingplan
(5) open tonverrotion .
tonverrotion
Figure 8. A scenario example from a local-call selectiolz phase.
the invocation of its own operations. Persistence identifies whether objects are transient or permanent. Do they survive the failure of a process or processor? Subordination determines if of an the existence or persistence object depends upon another object. Distribution determines if the object s state or operations are accessible from many nodes in the physical view and from several processes in the process view. In the logical view of the architecture, we could consider each object as active and potentially concurrent; that is, behaving in parallel with other objects and paying no more attention to the exact degree of concurrency than it needs to achieve this effect. Hence the logical view takes into account only the requirements functional aspects. However, when we define the process view, it is not practical to implement each object with its own thread of control (such as its own Unix process or Ada task) because of the huge overhead this imposes. More over, if objects are concurrent, there must be some form of arbitration for invoking their operations. On the other hand, multiple threads of control are needed to + react rapidly to certain classes of external stimuli, including time-related events; + take advantage of multiple CPUs in a node or multiple nodes in a distributed system; + increase CPU utilization by allocating CPUs to other activities when a thread of control is suspended during another activity (such as access to some external device or access to some other active object); + prioritize activities (and thus potentially improve responsiveness); + support system scalability (by having additional processes sharing the load); + separate concerns between different areas of the software; and + achieve a higher system availability (with backup processes). Determining concurrency. We use two strategies simultaneously to determine the right amount of concurrency and define the set of necessary processes. Keeping in mind the set of potential physical target views, we can proceed either from the inside out or the outside in. + Inside out. Starting from the logical view, we define agent tasks that a single thread of control multiplex across multiple active objects of a given class. We execute subordinate objects on the same agent as their parent. Classes that must be executed in mutual exclusion, or that require a minimal amount of processing share a single agent. This clustering proceeds until we have reduced the processes to a small number that still allows distribution and use of the physical resources. + Outside in. Starting with the physical view, we identify external stimuli (requests) to the system, and then define client processes to handle the stimuli and server processes that provide (rather than initiate) services. We use the problem data integrity and s serialization constraints to define the right set of servers and allocate objects to the client and servers agents. We then 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 view. Typically, there is an agent task for an active class, with some variations, such as several agents for a given class to increase throughput or several classes
mapped onto a single agent either to assure sequential execution or because the class operations are infrequently invoked. Finally, this is not a linear, deterministic process leading to an optimal process view; it requires a few iterations to reach an acceptable compromise. There are numerous other ways to proceed. , Exumple.The exact method used to construct the mapping is complex. However, a brief example from a hypothetical air-traffic control system can illustrate it. Figure 9 shows how a small set of classes from the system can be mapped onto processes. The flight class is mapped onto a set of flight agents that must quickly process many flights and spread the load across multiple CPUs while contending with large numbers of external stimuli. The persistence and distribution aspects of the flight processing are deferred to a flight serve? which is , duplicated to assure system availability. Flight profile or jhgbt clearance is 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 display and external interfaces. A sectorization class establishes a partitioning of airspace to assign controller jurisdiction over flights. Because of its integrity constraints, this class must be handled by a single agent, but it can share the server process with the flight, as updates are infrequent. Locations, airspace, and other static aeronautical information are protected objects, shared among several classes. These are rarely updated and mapped on their own server and distributed to other processes. From logical view to development view. A class is usually implemented as a module, and large classes are decomposed into multiple packages. Collections of closely related classes - class categories - are grouped into subsystems.
48
Best Copy Available
NOVEMBER
1995
flight
0 l
ierlorizotion
0
rleoronce
profile
l
To define subsystems, we must consider additional constraints, such as team organization, expected magnitude of code (typically 5,000 to 20,000 lines of code per subsystem), degree of expected reuse and commonality, as well as strict layering principles (visibility issues), release policy, and configuration management. Thus, we usually end up with a view that does not have a one-to-one correspondence with the logical view. General issues. 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. This also holds for the process and physical views. For example, comparing Figure 2c with Figure 5, there is no one-to-one mapping from the class categories to the layers. The External Interface/Gateway category 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 are in layer 5 subsystems. 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 project. In terms of which classes are used, scenarios relate mainly to the logical view, or to the process view when interactions between objects involve more than one thread of control.
(Al
~orotlon
girspote
flight . . v Multiple flight ogents I Sotkup
proflle
clearonte
Flightserver
jettorlzotlon
.
Singlesectorizotion agent lototion
riirrpote Aeronouwi info server
Figure 9. Mappingfi-om
the (A) logical to the (B) process view.
ITERATIVEPROCESS Bernard Witt and his colleagues describe four phases for architectural design - sk e t c h mg, organizing, specifying, and optimizing - and subdivide them into 12 steps. lo Although they do indicate that some backtracking may be needed, we think their approach is too linear for ambitious or unprecedented projects, because too little is
known at the end of the phases to validate the architecture. We advocate a more iterative development, in which the architecture is actually prototyped, tested, measured, and analyzed, and then refined in subsequent iterations. Our approach not only mitigates the risks associated with the architecture, it also helps build teams and improves training, architecture familiarity, tool acquisition, the initial runin period for procedures and tools, and...