Architectural Viewpoints

Once the quality attributes of the system have been characterized, how do you document how they will be fulfilled? Creating the software architecture of a system can be a large endeavor, depending on the size and complexity of the system. The software architecture should be partitioned into multiple views so that it is more understandable. When we describe any entity be it an architecture, a process, or an object there are many different perspectives or viewpoints to describe. For example, if you were to describe an orange to someone, would you talk about its color, weight, sweetness, skin thickness, or some other attribute of the orange? The attributes that you would choose to describe would depend on the role, the needs and the perspective of the person to whom you are describing the orange. If the person is a purchaser at a grocery store, the purchaser would be more interested in the color of the orange so that customers would buy the orange. A consumer of oranges would be more interested in the taste of the orange than the color. A chemist that is considering using oranges in a cleaning solution product would be interested in the chemical properties of oranges that could be applied to cleaning solutions. The point is that every stakeholder in oranges has a different need and a different perspective, and thus the orange must be described to them in different ways.

The same goes for architecture. All stakeholders in the architecture hold viewpoints that speak to their different perspectives on the project and within the organization. It is also important to separate the architecture description into different viewpoints so that a single stakeholder can understand different aspects of the architecture.

4+1 View Model of Software Architecture

No single standard set of viewpoints must be described for software architecture. In fact, we discuss two popular models to illustrate the point that multiple views are necessary. Philippe Krutchen from Rational software divides architecture into the 4+1 view model (Kruchten 1995) discussed in the following sections.

Logical View

The logical view, or logical architecture, is the object model for the design. It describes the structures of the software that solve the functional requirements for the system. It is a subset of all the classes of the system. The logical view is strictly a structural view of the software, including the important classes and class relationships in the architecture.

Process View

The process view, or process architecture, describes the view of the architecture that includes running processes and instantiated objects that exist in the system. It describes important concurrency and synchronization issues.

Development View

The development architecture view focuses on the module organization of the software. It shows how classes are organized into packages, and it outlines the dependencies between packages of software. This is the view of the design that shows the layered structures of the software and what the responsibilities of each layer in the system are.

Physical View

The physical view describes the machines that run the software and how components, objects, and processes are deployed onto those machines and their configurations at run-time, see Figure 2-2.

Figure 2-2. 4+1 view.

Krutchen, P. The 4 + 1 View Model of Architecture. IEEE Software, pp. 42 50, November 1995.

+1

The +1 in the 4+1 view model describes the scenarios that the architecture is meant to satisfy. The scenarios represent the important requirements that the system must satisfy. The scenarios that are chosen are those that are the most important to solve because they are either the most frequently executed or they pose some technical risk or unknown that must be proven out by the architecture baseline. The other four views are centered on the set of scenarios that are chosen for the creation of the architecture.

Applied Software Architecture Viewpoints

The 4+1 view model is only one of several suggestions for the viewpoints that should be included in software architecture. Hofmeister, Nord, and Soni (1999) propose a different set of viewpoints.

Conceptual Architecture View

The conceptual architecture view is similar to the logical view in the 4+1 view model. However, the conceptual architecture view is more conceptual and broader in scope. It takes into account existing software and hardware integration issues. This view is closely tied to the application domain. The functionality of the system is mapped to architectural elements called conceptual components. These conceptual components are not mapped directly to hardware, but they are mapped to a function that the system performs. This view provides an overview of the software architecture. It is the first place that people will go to find out how the system does what it is supposed to do. The concerns addressed in the conceptual view include the following:

1. How does the system fulfill the requirements?

2. How are the commercial off-the-shelf (COTS) components to be integrated, and how do they interact (at a functional level) with the rest of the system?

3. How are domain-specific hardware and/or software incorporated into the system?

4. How is functionality partitioned into product releases?

5. How does the system incorporate portions of prior generations of the product, and how will it support future generations?

6. How are product lines supported?

7. How can the impact of changes in the requirements domain be minimized?

Module View

The module view of software architecture shows how the elements of the software are mapped into modules and subsystems. The module architecture view shows how the system will be partitioned into separate run-time components. Some of the questions that are answered by this view are as follows:

1. How is the product mapped to the software platform?

2. What system support/services does it use and where?

3. How can testing be supported?

4. How can dependencies between modules be minimized?

5. How can reuse of modules and subsystems be maximized?

6. What techniques can be used to insulate the product from changes in third-party software, changes in the software platform, or changes to standards?

Execution View

The execution view of software architecture shows how modules are mapped onto the hardware of the system. This view shows the run-time entities and their attributes and how these entities are assigned to machines and networks. It shows the memory usage, processor usage, and network usage expectations. This view shows the flow of control between hardware systems that execute the software of the system. Some questions that this view answers are the following:

1. How does the system meet its performance, recovery, and reconfiguration requirements?

2. How is resource usage balanced?

3. How are concurrency, replication, and distribution handled in the system?

4. How can the impact of changes in the run-time platform be minimized?

Code View

The code view shows how the source code and configuration are organized into packages, including package dependencies. It also shows how the executable portions of the system are built from the source code and configuration. This view answers the following questions:

1. How are the builds done? How long do they take?

2. How are versions and releases managed?

3. What tools are needed to support the development and configuration management environments?

4. How are integration and testing supported?

How important is it to define your architecture using one of these standard sets of views? The answer is: not at all. These views are presented here to give you an idea of the kinds of questions that need to be answered when you define your software architecture. When you are on a big project and you don't have a lot of experience with software architecture, it might be a good idea to download the 4+1 view model or purchase Applied Software Architecture (Hofmeister, Nord, and Soni 1999) book to get started. Both provide appropriate guidelines for the kinds of things to keep in mind, but every project and every organization are different. The best way to develop sound software architectures is to have the best software architects and developers. People who understand the intricacies of the technology, processes, and politics of your organization and who can apply some of the fundamental concepts outlined in this chapter will succeed in creating the best possible software architectures. If the method for capturing the architecture is completely ad-hoc or loosely based on the above methods, that is fine. Again, the most important issue is that the important questions get answered and that everyone knows what the answers are. What is not important is the particular format or style of the answers.