ARCHITECTURE REPRESENTATION

In one form or another, many different parties are interested in architecture:

The system analyst, who uses it to organize and articulate the requirements and to understand the technological constraints and risks
End users or customers, who use it to visualize at a high level what they are buying
The software project manager, who uses it to organize the team and plan the development
The designers, who use it to understand the underlying principles and locate the boundaries of their own design
Other development organizations (if the system is open ), which use it to understand how to interface with it
Subcontractors, who use it to understand the boundaries of their chunk of development
Architects, who use it to reason about evolution or reuse

To allow the various stakeholders to communicate, discuss, and reason about architecture, we must have an architectural representation that they understand. The architecture and its representation are not quite the same thing: by choosing a representation, we omit some of the most intangible or soft aspects.

The various stakeholders have different concerns and are interested in different aspects of the architecture. Hence, a complete architecture is a multidimensional thing. Architecture is not flat.

Multiple Views

For a building, different types of blueprints are used to represent different aspects of the architecture:

Floor plans
Elevations
Electrical cabling
Water pipes, central heating, and ventilation
The look of the building in its environment (in sketches )

Over decades, blueprints have evolved into standard forms so that each person involved in the design and construction of the building understands how to read and use them. Each of these blueprints tries to convey one aspect of the architecture for one category of stakeholders, but the blueprints are not independent of each other. On the contrary, they must be carefully coordinated.

Similarly, in the architecture of a software- intensive system, you can envisage various blueprints for various purposes:

To address the logical organization of the system
To organize the functionality of the system
To address the concurrency aspects
To describe the physical distribution of the software on the underlying platform

And there are many more purposes. These are what we call architectural views. ^[4]

^[4] This multiple-view approach is to conform to the future IEEE Recommended Practice for Architectural Description. See Draft 5.2 of IEEE P1471, November 1999.

An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns and omitting entities that are not relevant to this perspective. For each view, we need to clearly identify the following:

The point of view ”the concerns and the stakeholders to be addressed
The elements that will be captured and represented in the view, together with their relationships
The organizational principles used to structure the view
The way elements of this view are related to those of other views
The best process to use in creating this view

The 4+1 View Model of Architecture

As shown in Figure 5-1, the Rational Unified Process suggests a five-view approach. ^[5] The following sections summarize the five views.

^[5] Philippe Kruchten, "The 4+1 view of Architecture," IEEE Software , 12(6) Nov. 1995, pp. 45 “50.

Figure 5-1. The 4+1 view model of architecture

The Logical View

This view of the architecture addresses the functional requirements of the system, in other words, what the system should do for its end users. It is an abstraction of the design model and identifies major design packages, subsystems, and classes.

Examples include a flight, a flight plan, an airway, an airport, and an airspace package.

The Implementation View

This view describes the organization of static software modules (source code, data files, components , executables, and other accompanying artifacts) in the development environment in terms of packaging and layering and in terms of configuration management (ownership, release strategy, and so on). It addresses the issues of ease of development, management of software assets, reuse, subcontracting , and off-the-shelf components.

Examples include the source code for a flight class and the library of code for an airspace database.

The Process View

This view addresses the concurrent aspects of the system at run-time ” tasks , threads, or processes as well as their interactions. It addresses issues such as concurrency and parallelism, system start-up and shutdown, fault tolerance, and object distribution. It deals with issues such as deadlock, response time, throughput, and isolation of functions and faults. It is concerned with scalability.

Examples are a flight management process, flight plan entry processes, and an airspace management process.

The Deployment View

This view shows how the various executables and other runtime components are mapped to the underlying platforms or computing nodes. It is here that software engineering meets system engineering. It addresses issues such as deployment, installation, and performance.

For example, the flight management process runs on the main flight processor, whereas the flight plan entry processes run on any workstations.

The Use-Case View

This view plays a special role with regard to the architecture. It contains a few key scenarios or use cases. Initially, these are used to drive the discovery and design of the architecture in the inception and elaboration phases, but later they will be used to validate the different views. These few scenarios act to illustrate in the software architecture document how the other views work.

Examples are the entry of a flight plan and the handover of responsibility to another air-traffic controller.

Models and Views

The preceding description of the architecture is true also for the models introduced in the first section of this chapter. We create different models to address different needs. But the models are complete representations of the system, whereas an architectural view focuses only on what is architecturally significant. If we do not make this distinction, there is no clear way to distinguish "design" from "architecture." Not all design is architecture.

What is "architecturally significant"? An architecturally significant element has a wide impact on the structure of the system and on its performance, robustness, evolvability, and scalability. It is an element that is important for understanding the system.

Architecturally significant elements include the following:

Major classes, in particular those classes modeling major business entities
Architectural mechanisms that give behavior to these classes, such as persistency mechanisms and communication mechanisms
Patterns and frameworks
Layers and subsystems
Interfaces
Major processes, or threads of control

Table 5-1. The Relationship between Models and Views

Model	Architectural View
Design model	Logical view
Design model ^[*]	Process view
Implementation model	Implementation view
Deployment model	Deployment view
Use-case model	Use-case view

^[*] or a process model for a complex system

Architectural views are like slices cut through the various models, illuminating only the important, significant elements of the models. Table 5-1 summarizes the relationship between models and views. The views useful for a system are captured in an important artifact: the software architecture description.

Architecture Is More Than a Blueprint

Architecture is more than just a blueprint of the system to be developed. To validate the architecture and to assess its qualities in terms of feasibility, performance, flexibility, and robustness, we must build it.

Building the architecture, validating it, and then baselining it are the number one objectives of the elaboration phase. Therefore, in addition to a software architecture description, the most important artifact associated with the architecture is an architectural prototype that implements the most important design decisions sufficiently to validate them ”that is, to test and measure them. This prototype is not a quick-and-dirty throwaway prototype, but it will evolve through the construction phase to become the final system. See the section titled Prototypes in Chapter 11.