Architectural Bleuprints - the 4+1 View Model of Software Architecture

Only available on StudyMode
  • Download(s) : 112
  • Published : May 28, 2009
Open Document
Text Preview
Paper published in IEEE Software 12 (6) November 1995, pp. 42-50

Architectural Blueprints—The “4+1” View Model of Software Architecture Philippe Kruchten Rational Software Corp.

Abstract This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various ‘stakeholders’ of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenariodriven, iterative development process. Keywords: software architecture, view, object-oriented design, software development process

We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of functionality? Are the arrows representing compilation dependencies? Or control flows? Or data flows? Usually it is a bit of everything. Does an architecture need a single architectural style? Sometimes the architecture of the software suffers scars from a system design that went too far into prematurely partitioning the software, or from an over-emphasis on one aspect of software development: data engineering, or run-time efficiency, or development strategy and team organization. Often also the architecture does not address the concerns of all its “customers” (or “stakeholders” as they are called at USC). This problem has been noted by several authors: Garlan & Shaw1, Abowd & Allen at CMU, Clements at the SEI. As a remedy, we propose to organize the description of a software architecture using several concurrent views, each one addressing one specific set of concerns.

An Architectural Model
Software architecture deals with the design and implementation of the high-level structure of the software. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements of the system, as well as some other, non-functional requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely in this formula2, modified by Boehm: Software architecture = {Elements, Forms, Rationale/Constraints} Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To describe a software architecture, we use a model composed of multiple views or perspectives. In order to eventually address large and challenging architectures, the model we propose is made up of five main views (cf. fig. 1): • The logical view, which is the object model of the design (when an object-oriented design method is used), • the process view, which captures the concurrency and synchronization aspects of the design, • the physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect,

the development view, which describes the static organization of the software in its development environment.

The description of an architecture—the decisions made—can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view. The architecture is in fact partially evolved from these scenarios as we will see later. End-user Functionality Programmers Software management

Logical View

Development View

Scenarios Process View
Integrators Performance Scalability...
tracking img