This essay describes the concepts and value of the “4+1” View Model of Software Architecture described by Philippe Kruchten in 1995. The purpose of the 4+1 view model is to provide a means to capture the specification of software architecture in a model of diagrams, organized into views. Each view represents a different concern and diagrams within each view use a diagramming notation suitable for that diagram’s purpose. The answers provided in each view answer questions related to the structure, packaging, concurrency, distribution, and behavior of the software system. The “+1” is a view of the scenarios and behavior of the software being described. This view drives development of the other views. The value the 4+1 view model approach brings to software architecture is that it is not specific to any class of software system. The principles behind the 4+1 view model can be applied to any scale of software system, from embedded software to web applications distributed across many collaborating servers. The software architecture of business IT systems can be represented using the 4+1 view model.What is a model? “A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper.” (OMG, 2005) Software can be specified using just textual requirements or it can be shown as a model of collections of diagrams with textual notes describing specific details. Models provide a filter for humans to deal with a lot of information at one time. Models give us a big picture, just like a blueprint does. Diagrams within a model can be organized by subject, purpose, or locality within a system. For building construction, a single page in a roll of blueprints might describe the routing plan for plumbing or electrical conduits. A different page might detail the foundation. Likewise, a diagram within a model might show us the structure of the database. A different diagram will show where each piece of the software runs on a network. The content of diagrams in models can be at any level of “zoom” to describe parts of the software. Simple data structures can be described in a diagram, as can complex scenarios carried out by several servers in synchronization. Kruchten’s purpose in the 4+1 view model is to capture and document the software’s architecture using diagrams organized in several views.What is software architecture? “Software architecture is the principled study of the overall structure of software systems, especially the relationship among subsystems and components.” (Shaw, 2001) I interpret the word “relationship” in this context to mean many possible kinds of relationships. One kind of relationship between subsystems is where one subsystem relies on the services of another subsystem. There can be a behavioral relationship among subsystems, where the protocol of messages between them must be documented. Another type of relationship among subsystems is collocation - how do they communicate? Can they communicate? What is the mechanism used to store transaction data and are the interfaces and support code packaged within each subsystem to allow data storage to happen? These are all questions answered by information at the level of software architecture. “Software architecture is concerned with the high-level structures of a software system, the relationships among them, and their properties of interest. These high-level structures represent the loci of computation, communication, and implementation.” (Garlan, 2006)A driving force behind the 4+1 view model is that a single diagram cannot communicate information about all the different kinds of relationships within a software system. A diagram that showed all the different concerns of a software’s architecture simultaneously would be overwhelming. Each view in the 4+1 view model has a different concern or subject. Multiple diagrams can exist within each view, like files exist within a folder by subject. Modeling and diagramming tools are used to create diagrams and organize them when applying the 4+1 view model. Many tools exist to build diagrams, including Microsoft Visio (VISIO, 2008), Enterprise Architect (EA, 2008) and Rational Software Architect (RSA, 2008). Kruchten uses a notation called the Booch notation in his paper to capture information in his diagrams for each view. Since Kruchten wrote his paper over ten years ago, the Booch notation has been refined and was contributed into the Unified Model Language specification from the Object Management Group.The 4+1 views are the logical view, process view, development view and physical view. The “+1” view contains the scenarios that represent the system’s interaction with the outside world. The scenarios are requirements. They drive the development of the other views of the architecture. The logical view contains the decomposition of the system into functions, structures, classes, data, components and layers. Kruchten points out that several different types of diagrams might be necessary within the logical view, to represent code, data, or other types of decomposition of the requirements. Mainly the scenarios, or “+1” view influences development of this view. The logical view is needed by the development and process views. The process view is concerned with the actual running processes in the deployed system. Processes are connected to each other through communication channels, like remote procedure calls or socket connections. Elements within the logical view run on processes, so there is traceability from the process view back to the logical view. Some projects, like the development of a code editor, will not require a process view since there is only one process involved.The third view is the development view. The scenarios and the elements in the logical view drive the contents of the process view. The development view documents the relationships and packaging of the elements from the logical view into components, subsystems and libraries. Diagrams within a development view might show which classes or functions are packaged into a single archive for installation. The diagrams within the development view should allow someone to trace back from a package of code to elements in the logical view. Dependencies among packages of code are documented in this view also. The fourth view is the physical view and it is created from the scenarios, process view and development view. The fourth view shows the allocation of packages of code and data, and processes to processing nodes, e.g. computers. The relationship between nodes is also shown in this view, usually in the form of physical networks or other physical data channels that allow processes on different nodes to communicate. The final “+1” view is the scenarios, which represent requirements for the behavior of the system. Kruchten’s paper shows examples using object scenario and object interaction diagrams. One could also use classic flow charts, use cases or UML activity diagrams to capture the scenarios of the software system. At a minimum, the scenarios should document how the system behaves and interacts with the outside world, either with people or with other systems.The information captured within a “4+1” View Model of Software Architecture is common to all software systems and can be applied as a general approach to document and communicate about information systems. Business information systems are very often database-centric, and use fat-client or web-based interfaces to enter, search, update and remove data. A business system can enforce a workflow of approvals before it allows a transaction to complete. Data warehousing solutions exist to archive, profile and find patterns in data for new. Many businesses are deploying self-service web sites for customers to interact with their business without constraining the customer to specific times a transaction can take place. Each of these qualities of business systems can be captured with one or more views of the “4+1” model. A logical view can be used to document the database schema, code modules, and even individual pages of content within a web solution. The development view for a J2EE solution would document how HTML files, JSP files, and Java code is packaged into archive files before deployment to the application server. The process view for a client-server database system would show code modules assigned to the user’s application process. The database schema and stored procedures would be assigned to the relational database server processes. Finally, a physical view of a web-based database application would show separate servers for the web and database. The web server process from the process view would be assigned to the web server node, as would the packages of HTML, CGI and other code in the development view. The physical view would also show a similar traceability for the database server node.The value of “4+1” View Model of Software Architecture is that it serves as general guiding principles to answer the question of what needs to be documented at a minimum when describing software architecture. Each view within the model has a well-defined subject or concern for the diagrams that are organized within the view. All software can be described in terms of behavior, structure, packaging and where it executes. These are the basic qualities the 4+1 view intent to document for easier human consumption. There are no official constraints to the notation styles that can be used by diagrams in each view. When applied to larger systems the logical view will contain many types of diagrams. The notation independence makes it a very flexible approach to use for many styles of software. When it is taught to a team along with diagramming skills, it can be used as significant form of communication and provide clarity among software project team members when creating new or documenting legacy IT projects.ReferencesGarlan, D., Schmerl, B. (2006). Architecture-driven Modeling and Analysis. 11th Australian Workshop on Safety Related Programmable Systems (SCS ’06).Kruchten, P. (1995). Architectural Blueprints - The “4+1” View Model of Software Architecture. IEEE Software 12 (6), 42-50.Object Management Group. (2005). Introduction to OMG UML. Retrieved May 10, 2008 from Software Architect product page. (2008). Retrieve May 10, 2008 from, M. (2001). The Coming-of-Age of Software Architecture Research. IEEE. 0-7695-1050-7/01.Sparx Systems home page. (2008). Retrieved May 10, 2008 from