z The 4+1 View Model of Architecture PHlLlPPE B. KRUCHTEN, Rational Software zyxwv zyxwvut *Th 4+1 ViewMOdel organizes a description of a sojiware architecture usingJive conmwent views, each of which 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 Architeas capture their design decision5 infour views and use t,r,e~fih vim to illustrateand validate them. Do the boxes represent running programs? Chunks of source code? Physical computers? O r merely logical groupings of functionality? D o 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 M a r y Shaw,’ Gregory Abowd and Robert Allen,’ and Paul C1ements.j T h e 4 + 1 View Model was developed to remedy the problem. T h e 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. T h e logical view describes the zyxwvu ” + design’s object model when an objectoriented design method is used. T o 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. T h e process view describes the design’s concurrency and synchronization aspects. T h e physical view describes the mapping of the software o n t o the hardware and reflects its distributed aspect. T h e development view describes the software’s static organization in its 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. T h e architecture is partially evolved from these scenarios. At Rational, we apply Dewayne Perry and Alexander Wolfs formula’ 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. T h e architects can also pick a certain architectural style for each view, thus allowing the coexistence of multiple styles in one system. T h e 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. 1- zyxwvutsrq zyxwvutsrqpo zy zyx zyxw zyxwvut + + + Software architecture = 4t1 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 [Elements, Forms, Rationalelconstraints} independently on each view. For each view we define the set of elements to End users - z ’ - __- Logical iiew Development P ’ zyxw Programmers software management functionality iiew * *I)-=- Scenarios \*---/ Process iiew Physital view w ... System integrators performante ” System engineers system topology delivery scalability installation telecommunication throughput - Figure 1. The 4+1 View Model is used t o organize the description of the architecture of a software-intensive system. 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. T h e logical view primarily supports the functional requirements - the services the system should provide t o its end users. Designers decompose the system into Display and user ioterioce Components Class Connectors - tonversation ~ lontainment, aggregation i) Class utility ---+ Translation services -. Usage --*‘w ~ Terminal Simulation and training - .? Connection formal arquments xw-l_l _- zyxwvutsrqpon II Flight rnanogement ZZ-J Inheritance External interfaces/ gate’woys * U 9 Y Air troific rnanogement L .*, Aeronautical information I --__I I Hethanisms I Class category Basic elements [C] L I - ~~ Ft’pre 2. (A) Notation for the logical blueprint; (B) logical blueprint for the Tdic PBX; (C)bluepiFintfor an aiiT-trafic control system. ___ IEEE SOFTWARE Best Copy Available --~ 43 zyxwvutsrqpo zyxwvu zyxwvutsr zyxwv zyxwvutsrqp events, such as a “start,” “stop,” or “digit.” T h e 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. T h e system, developed by Hughes Aircraft of Canada, contains eight class categories. a set of key abstractions, taken mainly erably to account for only those items from t h e problem domain. T h e s e that are architecturally significant. The abstractions are objects or object classes numerous adornments are not very that exploit the principles of abstrac- useful at this level of design. We use tion, encapsulation, and inheritance. In Rational Rose to support the logicaladdition to aiding functional analysis, view design. decomposition identifies mechanisms Style. For the logical view, we use an and design elements that are common object-oriented style. The main design across the system. W e use the Rational/Booch guideline we follow is to keep a single, approach’ to represent the logical view c o h e r e n t object model across t h e through class diagrams and templates. entire system, avoiding the premature A class diagram shows a set of classes specialization of classes and mechaand their logical relationships: associa- nisms for each site or processor. tion, usage, composition, inheritance, Examples. Figure 2b shows the main and so on. Designers can group sets of related classes into class categories. Class classes involved in a sample PBX architemplates focus on each individual class; tecture we developed at Alcatel. A PBX they emphasize the main class opera- establishes communication among tertions and identify key object character- minals. A terminal might be a teleistics. If an object’s internal behavior phone, a trunk line (a line to the cenmust be defined, we use state-transi- tral ofice), a tie line (a private PBX-totion diagrams or state charts. Class util- PBX line), or a feature phone line. Different lines are supported by difities define common mechanisms or ferent line-interface cards. T h e services. Controller object decodes and injects Ahtion. We derived the logical-view all the signals on the line-interface notation in Figure 2a from the Booch card, translating card-specific signals to notation, which we simplified consid- and from a small, uniform set of Process view. The process view takes into account some nonfunctional .- Terminal process -_I Component - Connectors __ Unspecified P Process ~ - -- Controller process 4 Message . zy zyxwvutsrq zyxwv zyxw (ontroller task (low rote) “ . . _ I (ontroller task [high role) ~ _ _ Figure 3. (A) Notation for the process view; (B) partial process blueprint for the Tdic PBX. 44 - Best Copy Available NOVEMBER 1995 requirements, such as performance and system availability. It addresses concurrency and distribution, system integrity, and fault-tolerance. T h e process view also specifies which thread of control executes each operation of each class identified in the logical view. Designers describe the process view a t several levels of abstraction, each one addressing a different concern. At the highest level, the process view can he seen as a set of independently executing logical networks of communicating programs (“processes”) that are distributed across a set of hardware 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 a t which the process view can he tactically controlled (started, recovered, reconfigured, shut down, and so on). In addition, processes can be replicated to distribute processing load or improve system availability. + I zyxw Exomple. Figure 3 b 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. T h e Controller objects are executed on one of three tasks that comprise the controller process: a low cycle-rate task, which scans all inactive terminals (200 ms) and puts any terminal becoming active in the scan list of the high cvcle-rate task (10 ms), which detects any significant changes of state and Dasses them to the mai; controller task, ’ which interprets the changes and communicates them by message to the corresponding terminal. Message passing within the controller process is done through shared memory. TO DEVELOP THE PROCESS VIEW, THE DESIGNER PARTITIONS THE O W A R E INTO ISSEPARATE TASKS I zy zyxwvuts zyxwvutsrqpon zyxwvutsrq zyxwvutsr fortitioning. T o develop the process view, designers partition the software into a set of independent tasks: separate threads of control that can he individually scheduled on separate processing nodes. W e separate tasks into two groups: Mujor tusks are the architectural elements that can he uniquely addressed (designated from another task). T h e y 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 n o t make assumptions about their collocation in + the same process or processing node. Mznor tasks are additional tasks introduced locally for implementation reasons such as cyclical activities, buffering, and time-outs. They can he implemented as Ada tasks or lightweight threads, for example, and communicate by rendezvous or shared memory. W e -use the process blueprint to estimate message flow and process loads. It is also Dossible to imdement “hollow” process view with dummy Drocess loads and measure its performance on a target system.’ lotofion. Our process-view notation is expanded from Booch’s original notation for Ada tasking and focuses on architecturally significant elements, as Figure 3a shows. W e have used T R W ’ s Universal Network Architecture Services to build and implement the processes and tasks (and their redundancies) into networks of processes. UNAS contains a tool - the Software Architects Lifecycle Environment - that supports our notation. SALE lets us depict the process view graphically, including specifications of the possible intertaskcommunication paths. It can then automatically generate the corresponding Ada or C++ source code. Because it supports automatic code generation, SALE makes it easier to change the process view. Style. Several styles would fit the process view. For example, picking from Garlan and Shaw’s taxonomy,’ you can use pipes and filters or cliendserver, with variants of multiple-cliendsingle-server and multipleclients/multiple-servers. For more complex systems, you can use a style similar to the ISIS system’s process groups, as described by K e n n e t h Birman using another notation and toolset.8 Development view. T h e development view focuses on the organization of the actual software modules in the software-development environment. T h e software is packaged in small chunks - program libraries or subsystems that can he developed by one or more developers. T h e subsystems are organized in a hierarchy of layers, each layer providing a narrow and welldefined interface to the layers above it. T h e development view takes into account internal requirements related to ease of development, software management, reuse or commonality, and constraints imposed by the toolset or the programming language. T h e development view supports the allocation of requirements and work to teams, and supports cost evaluation, planning, monitoring of project progress, and reasoning about software reuse, portability, and security. It is the basis for establishing a line of product. T h e development view is represented by module and subsystem diagrams that show the system’s export and import relationships. You can describe the complete development view only I IEEE S O F T W A R E 45 (ompanents zyxwvutsrqponm zyxwvutsrqponmlk zyxwvutsrqponmlkjih Connector t Referenre (ompilotian deDendencv _r 4 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 ele1 ment. favor of a simpler, layer-by-layer release strategy. 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. T o 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 customerand product-dependent. Spread across the five layers are some 72 subsystems, each containing from 10 to 50 modules. W e represent these subsystems o n additional, more detailed blueprints. zyxwvutsrqp zyxwvutsr zyxwvutsrqponmlkjihgfedcbaZY Subsystem I*"?YL Pa*- . Layer Figure 4. Notation for a development blueprint. Human computer interfate Externol systems Notation. As Figure 4 shows, we again use a variation of the Booch notation, limited to architecturally significant items. Rational's Apex development environment supports the definition and implementation of the developm e n t view, t h e 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. zyxwvutsrqponmlkjihg ATC functional areas flight manage layer 4 ment, sector management, and so on Aeronouticol classes Layer 3 AT( classes Support methonisms tommunitotion time storage, resource monogement and so on layer 2 zyxwvutsrq toyer 1 Common utilities Bindings Low~levelservices Figure 5. The five layers of Hughes A i r Trafic System. Components Style. W e 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 Connectors Communication line ."* --* Processor Communitotion (non permanent) t . - + Unidirectional tommunitation F ~~~- Other device primary * High bondwidth tommunitation, Bus - -1 F zyxwvuts barkup *(A%"" 4k%W K [AI Physical view. T h e physical view takes into account the system's non- K K K (61 7igu.e 6. (A) Notation for a physical blueprint; (B) a PBX physical blueprint. ~ 46 _ _ _ _ ~ - Best Copy Available --- NOVEMBER 1995 F ( (onversotion (entroi process protesr -”* _q F1-W ’ Terminal proteir __ functional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability. T h e software executes on a network of computers (the processing nodes). T h e 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 a t various sites or for different customers. T h e mapping of the software to the nodes must therefore be highly flexible and have a minimal impact o n the source code itself. F Bock-up nodes - zyxwvutsr b F Pseudo tentroi * keudo t e r m / zyxwvu zyxwvutsrqponm zyxwvutsrqp zyxwv t - proters K T Controller process urotess f“-- 1 T v (onversotion (werwtion proteri * ”- prow * 1 - I T T Terininol process v- Terminal ” praters ~-* - 1 More K processors z zyxwvutsrq zyxwvutsrq zyxwvuts Nototion. Because physical blueprints can become very messy in large systems, we organize them in several forms, with or without the mapping from the process view, as Figures 6 and J 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 modifymg the source code. Figure 6b shows a possible hardware configuration for a large PBX; Figures Ja and 7b show mappings of the process view on two different physical views, a small and a large PBX. Scenarios. W e use a small subset of important scenarios - instances of use cases - to show that the elements of the 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.’ T h e scenarios are in some sense an abstraction of the most important requirements. Their design is expressed using object-scenario and object-interaction diagrams.’ T h i s view is redundant with the other ones (hence the “ + l ” ) , but it plays two critical roles: it acts as a driver to help design- + IEEE SOFTWARE K ’ K Controller proters = ** (61 L ‘ (ontroller praters r *uaxl~ I-” K ’ (ontroller i proters & 1 v 1 line tardr tine turds l i n e toids - - - Figure 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 differeat capacities and 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. T h e scenario notation is very similar to that used for the logical view, except that it uses the connectors from the process view t o 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. T h e corresponding script reads: 1. T h e controller of Joe’s phone detects and validates the transition from on-hook to off-hook and sends a message to wake the corresponding terminal object. 2 . T h e terminal allocates some resources and tells the controller to emit a dial tone. 3. T h e controller receives digits and transmits them to the terminal. 4. T h e 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. CORRESPONDENCE AMONG VIEWS T h e various views are n o t 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. W e 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 47 Best Copy Available zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCB ~~ zyx zyxwvutsrqp Joe tonlroller 1 . (1) off-hook (') 'One (3) digit . -. Joe terminol zyxwvutsrqponm zyxwvutsrqp zyxwvutsrqponmlk (4) digi' . Numbering plan (5) open tonversolion 7 tonversotion ~l ' Figure 8. A scenario example fiom a local-call selection phase. the invocation of its own operations. Persistence identifies whether objects are transient or permanent. Do they survive the failure of a process o r processor? Subordination determines if the existence o r persistence of an object depends upon another object. Diswibution 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 n o t 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. M o r e over, if objects are concurrent, there must be some form of arbitration for invoking their operations. O n 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 hav- + + + + + 48 ing additional processes sharing the load); separate concerns between different areas of the software; and achieve a higher system availability (with backup processes). + + Determining concurrency. W e 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 multiplex a single thread of control across multiple active objects of a given class. W e 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. W e use the problem's data integrity and serialization constraints to define the right set of servers and allocate objects to the client and servers agents. W e then identify which objects must be distributed. T h e 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 + + Best Copy Available ~~ ~- 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. T h e 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. T h e flight class is mapped onto a set of f l i g h t agents t h a t must quickly process many flights and spread the load across multiple CPUs while contending with large numbers of external stimuli. T h e persistence and distribution aspects of the flight processing are deferred to a flight serve?', which is duplicated to assure system availability. Flight profile or flight 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 o t h e r 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. zyx 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. N O V E M B E R 1995 zy ~ ~~ flighl iertorizotion zyxwvu zyxwvutsr zyxw zyxwvutsrq zyxwvutsrq zyxwvutsr 0 rleorante . 0 profile 0 ' T o 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. T h e logical and develo p m e n t views are very close, b u t address very different concerns. W e 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. T h e External InterfaceIGateway 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 o r deployment. Birman describes some very elaborate schemes for this mapping in the ISIS project.x In terms of which classes are used, scenarios relate mainly to the logical view, o r to the process view when interactions between objects involve more than one thread of control. ' ilighl .. profile Sotkup v rlearoiite Mulliple flighl ogentr Flight sewer I . jerlorizolion Single rectorization agent lotolion . aorkup * Aeronouiitai info server ~~ ~ Figure 9. hfappingfi-om the (A) logical to the (B) process view. ITERATIVE PROCESS known at the end of the phases to validate the architecture. W e advocate a more iterative development, in which the architecture is actually prototyped, tested, measured, and analyzed, and then refined in subsequent iterations. O u r approach not only mitigates the risks associated with the architecture, i t also helps build teams and improves training, architecture familiarity, tool acquisition, the initial runin period for procedures and tools, and so on. (This holds for evolutionary, rather than throwaway prototypes.) An iterative approach also helps you refine and better understand the requirements. Bernard W i t t and his colleagues describe four phases for architectural design - sketching, organizing, specifylng, and optimizing - and subdivide them into 12 steps.IOAlthough 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 Scenario-driven approach. Scenarios capture the system's critical functionality - functions that are the most important, are used most frequently, or present significant technical risk. T o begin, select a few scenarios on the basis of risk and criticality. You may synthesize a scenario by abstracting several user requirements. T h e n IEEE SOFTWARE qirrpote ioration Best - Copy Available create a strawman architecture and script the scenarios, identifylng major abstractions (such as classes, mechanisms, processes, subsystems)9 and decomposing them into sequences of pairs (object, operation). Next, organize the architectural elements into the four views, implement the architecture, test it, and measure it. T h i s analysis helps you detect flaws o r potential enhancements. Finally, capture lessons learned. Begin the next iteration by reassessing the risks, extending the scenarios to consider, and selecting a few additional scenarios on the basis of risk or extending architecture coverage. Then try to script those scenarios in the preliminary architecture and discover additional architectural elements - or significant architectural changes that must occur to accommodate these scenarios. Update the four views and revise the existing scenarios on the basis of these changes. Next, upgrade the implementation (the architectural 49 prototype) to support the new extended set of scenarios. At this point, you should test the architecture by measuring under load (in the target environment, if possible) and review all five views to detect potential simplifications, commonalities, and opportunities for reuse. Then update the design guidelines and rationale and capture lessons learned. And then loop again. Finally, the initial architectural prototype evolves to become the real system. M e r two or three iterations, the architecture itself should become stable, and you should find no new major abstractions, subsystems, processes, or interfaces. T h e rest is in the realm of software design - where you can continue development using very similar methods and process. development organization. Hence thl iteration may last two to three week for a small project (10,000 lines o code), or from six to nine months for large command-and-control systen (700,000 lines of code or larger). Tailoring the model. Not all softwar’ architectures need every view in thl 4+1 View Model. Views that are use less can be omitted. For example, yo’ could eliminate the physical view i there is only one processor o r t h process view if t h e r e is only o n ’ process or program. For very smal systems, logical and development view are sometimes so similar that they cai be described together. T h e scenario are useful in all circumstances. respected to maintain the architectural integrity of the system. W e have used the 4+1 View Model o n several large projects, customizing it and adjusting the terminology somewhat.5 W e have found that the model actually allows the various stakeholders t o find what they need in the software architecture. System engineers approach i t first f r o m t h e physical view, t h e n t h e process view; end users, customers, and data specialists approach it from the logical view; and project managers and software-configuration staff members approach it from the development view. Other sets of views have been proposed and discussed at our company and elsewhere, but we have found that proposed views can usually be folded into one of the four existing views. A cost and schedule view, for example, folds into the development view, a data view into the logical view, and an execution view into a combination of the process and physical view. zyxwvutsrqp zyxwvutsrq zyxwv Timetable. T h e duration of these iterations varies considerably, depending on the size of the project, the number of people involved, and their expertise in the domain and the development method. It also varies relative to the Documentation. T h e documentatioi produced during the architectura design is captured in two documents: a software architecture documeni organized by the 4+1 views, and a software design guideline, whicl captures (among other things) impor tant design decisions that must b + + ACKNOWLEDGMENTS For their help in shaping or experimenting with the 4+1 View Model I thank my many colleagues at Rational, Hughes Aircraft of Canada, CelsiusTech AB, Alcatel, and elsewhere, and in particular, Chris Thompson, Alex Bell, Mike Devlin, Grady Booch, Walker Royce, Joe Marasco, Rich Reitman, Viktor Ohnjec, Ulf Olson, and Ed Schonberg. Philippe Kruchten is a senior technical consultant at Rational Software, where he is in charge of the Software Architecture Practice area. Kruchten has 20 years experience in software development. He has been associated with several large-scale software-intensive projects around the world, including the Alcatel2505 and Alcatel 2600 private telephone exchanges in Francc, the Ship System 2000 command-and-control system in Sweden, and several other projects in avioiiics, defense, transportation, and compilation. Since August 1902, he has been the lead software architect for the Canadian Automated Air Traffic System, developed by Hughes Aircraft of Canada in Vancouver. Kruchten received an M.Sc. in mechanical engineering from Ecole Centrale de Lyon, France, and a P h D in information technology from the French hlational Institute of Telecommunications, Paris. I I e is a member of the IEEE Computer Society and the ACM. Address questions about this article to Kruchten at Rational Software Corp., 240-1071 1 Camhie Rd., Richmond BC V6X 3GS; pkruchten9rational.com zyxwvutsrqponmlk zyxwvutsrqpo zyxwvut zyxwvutsrqponm zyxwvutsrqp REFERENCES 1. D. Garlan and M. Shaw, ‘‘An Introduction to Software Architecrure,”Adz’ance.r in Software Engineering and fiiowledge Engineering, Vol. 1, World Scientific Publishing Co., Singapore, 1993. 2 . G. Ahnwd, R. Allen, and D. Garlan, “Using Style to Understand Descriptions of Software Architecture,” A C M Softwaw Eizg. Notes, Dec. 1993, pp. 9-20. 3 . Paul Clements, “From Domain Model to Architectures,” A. Abd-Allah et al., eds., Forused Workshop o n Softwai-eArchitectwe, 1994, pp. 404-420. 4. D.E. Perry and A.L. Wolf, “Foundations for the Study of Software Architecture,” ACM Sofinre Eng. ,Votes, Oct. 1992, pp. 40.52. 5 . G. Booch, Ob@-Oriented Analysis and Design with ,4pplications, 2nd. ed., Benjamin-Cummings, Redwood City, Calif., 1993. 6. P. Kruchten and C. Thompson, “An Object-Oriented, Distributed Architecture for Large Scale Ada Systems,” Pnx. TRLAdu ’74, ACM Press, New York, 1994, pp. 262-27 1. 7 . A. Filarey et al., “Software First: Applying Ada Megaprogramming Technology to Target Platform Selection Trades,” h c . TRI-Ada ’71, ACM Press, New York, 1993. 8. K.P. Birman and R. Van Renesse, Reliable Distiibnted Computrng with the Isn Toolkit, IEEE CS Press, Los Alamitos, Calif. 1994. 9. K. Rubin and A. Goldberg, “Object Behavior Analysis,” Comnz.ACAI, Sept. 1902, pp. 48-62. 10. B. I. Witt, F. T. Baker, and E.W. Merritt, Sojiware Arrhitectiire and Design Pmiciples. .2i[odel.r, mid Methods, Van Nostrand Reinholt, New York, 1994. ~ 50 N O V E M B E R 1995