Architecture

Let us slow down and back up for a while to define a bit more what we mean by "software architecture" and to define a few other key concepts. Architecture (with a capital "A") is a discipline, an art, but architecture (with a small "a") also designates a "thing," a property of all systems, and the focus of the work of the architect.

Architecture Defined

Software architecture encompasses the set of significant decisions about the organization of a software system:

• Selection of the structural elements and their interfaces, by which a system is composed

• Behavior as specified in collaborations among those elements

• Composition of these structural and behavioral elements into larger subsystems

• Architectural style that guides this organization

Software architecture is also concerned with

• Usage

• Functionality

• Performance

• Resilience

• Reuse

• Comprehensibility

• Economic and technology constraints and tradeoffs

• Aesthetic concerns

This is more than a one-line definition; it is a whole menu! Yes, architecture, both as an artifact and as a discipline, is quite challenging, and if you are new to the role of architect, be ready for a wild ride. Architecture is quite a complex thing. Note, however, that the architect focuses only on the architecturally significant requirements and the corresponding architecturally significant design decisions (see Figure 16.1). By "architecturally significant," we mean the ones that will have a long and lasting effect on the system performance, quality, and scalability, as opposed to the myriad other design decisions that will be made during the construction of the system. The architect does not bear the responsibility of making all design decisions.

Figure 16.1. Architecting: The Art of Compromise. Architects need to consider and balance the impact along a number of different dimensions when making architectural decisions. This forces the architects to constantly make difficult tradeoffs.

Models and Views

As the architecture of a system may be quite challenging to describe, and as it is the focus of attention of multiple parties, or stakeholders, one approach to organizing its description is to use multiple viewpoints. The description of architecture is organized in views, each focusing on one aspect of architecture, leaving the other perspectives aside. In turn , each view may be described by a UML model or simply descriptive text.

Depending on the specific nature of your project, your architecture will have one of the following views:

• A logical view (existing for any system), showing the various elements of the software and their structure: classes, packages, and so on.

• A process view , in the case of a distributed and concurrent system, showing the parallelism between various entities, and how communication and synchronization are achieved.

• An implementation view, showing how the implementation elements (source code files, executable, and so on) are organized in the development environment.

• A deployment view, showing how physically at runtime the various runtime components are replicated and deployed, and how they communicate.

• A use-case view, capturing the most significant requirements: use cases or parts of use cases that have some great impact on the architecture, as well as significant nonfunctional requirements (see Figure 16.2). This may include use-case realizations to illustrate how the system works.

  Figure 16.2. The 4+1 Views of Architecture. The use-case view contains the architecturally significant use cases and represents the problem space. It ties together the other four views in the solution space. (From Kruchten 1995).

  

The four first views are in the solution space, and the last one ties them with the problem space.

Software Architecture Document

The main responsibility of the architect is to describe the architecture of the system in a major artifact of the RUP product, called the Software Architecture Document ( SAD ). For many projects, this may be the only part of the design that is described in an actual document, as most design aspects can be documented in UML models and in the code itself. The more stakeholders that are interested in understanding or influencing the architecture, the more important this document will be. The SAD is organized along a set of views, chosen among the ones we listed earlier, or any other suitable for the project. The SAD template in the RUP is very general, so the first task of an architect will be to tailor it to suit the specific context and needs of the project. In particular, the architect will chose which views are relevant and how to document them.

Executable Architectural Prototype

The SAD is only an intent, a document. The architectural decisions are validated using an architectural prototype, and the architect is responsible for driving the implementation of this prototype that will subsequently evolve to become the complete system. The prototype is used to validate the architecture, to demonstrate that all major technical risks have been retired , to serve as a baseline for the rest of the development. Its development is also a good way to bring the development organization up to speed with tools, languages, technologies, processes, and performance calibration.

Architectural Mechanisms

Architectural mechanisms represent common, concrete solutions to frequently encountered problems. They may be patterns of structure, patterns of behavior, or both. They provide standard solutions to problems such as garbage collection, persistent storage, list management, "shopping cart" implementation, communication with external systems through a certain protocol, and so on. They play an important role in the description of an architecture.

Additional Architecture?

Architects may develop other RUP artifacts, for example, to analyze tradeoffs between possible solutions or guidelines to convey principles and guidelines to the rest of the development organization. Architects will contribute to RUP artifacts such as risk lists, project plan and iteration plans, vision, requirements, use cases, and so on.

Outside the bounds of an individual project, architects may want to establish an enterprise architecture, including technology choices and development paradigms . Are you organizing around reuse? How should you achieve it? Should you develop all applications on the J2EE platform, where communication between building blocks is done through message queues? What are these major reusable building blocks, and how will they roughly evolve over a series of projects? Do you instead embrace the emerging Web services capability to allow different applications to reuse components across platforms?