The 4+1 View Model of Architecture PHILIPPE B . KRUCHTEN, Rational Software *The 4+1 V?ewModel 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- cerns of all “customers.” addressesa speczj%set of concerns. the authors are struggling to represent 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 thefiJZh view to illustrate and groupings of functionality? Do the Robert Allen,’ and Paul C1ements.j 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 42 O/407459/94/$04 00 0 1994 WE NOVEMBER 1995 design’s object model when an object- use (components, containers, and con- I ~~ oriented design method is used. To nectors), capture the forms and pat- Endusers Programmers design an application that is very data- terns that work, and capture the ratio- l functionality l softwaremanagement 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 aspect. generic: You can use notations and + The development view describes tools other than those we describe, as Figure 1. The 4+1 View Model is the software’s static organization in its well as other design methods, especial- used to organize the description of the development environment. ly for the logical and process decom- architecture of a software-intensive Software designers can organize the positions. system. description of their architectural deci- sions around these four views, and then illustrate them with a few selected 4tl VIEW MODEL the major functionality and perfor- use cases, or scenarios, which constitute mance requirements of the system as a fifth view. The architecture is partial- Software architecture deals with well as other, nonfunctional require- ly evolved from these scenarios. abstraction, decomposition and com- ments such as reliability, scalability, At Rational, we apply Dewayne position, and style and aesthetics. It portability, and system availability. Perry and Alexander Wolfs formula’ also deals with the design and imple- Software architecture = [Elements, mentation of software’s high-level Logical view. The logical view pri- Forms, Rationale/Constraints} structure. marily supports the functional require- Designers build architectures using ments - the services the system independently on each view. For each several architectural elements in well- should provide to its end users. view we define the set of elements to chosen forms. These elements satisfy Designers decompose the system into Displaynnd user ~olerfote ExternalInterfores/ Simulationand Class ~~~~~ Assotiotion Translation : troining Conversolion ~ services .- xw&A-&1- Containment, -. oggregotion ‘; Classutility Usage Connectioni, Terminal Flight Air troific services r: manogement monogement .-+&J -+ Inheritance *- 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 . tontroller tosk “...S (ontroller task [high rate) (low rote) .&‘ YS.- &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 the same process or processing node. Example.Figure 3b shows a partial system availability. It addresses con- + Minor tasks are additional tasks process view for the PBX introduced currency and distribution, system introduced locally for implementation in Figure 2b. All terminals are handled integrity, and fault-tolerance. The reasons such as cyclical activities, by a single terminal process that is dri- process view also specifies which buffering, and time-outs. They can be ven by messages in its input queues. thread of control executes each opera- implemented as Ada tasks or light- The Controller objects are executed tion of each class identified in the logi- weight threads, for example, and com- on one of three tasks that comprise the cal view. municate bvi rendezvous or shared controller m-ocess: a low cvcle-rate Designers describe the process view memorv. ’ task, which scans all at several levels of abstraction, each We ‘use the process inactive terminals (200 one addressing a different concern. At blueprint to estimate TODEVELOP ms) and puts any termi- the highest level, the process view can message flow