Steps in an Architectural Tradeoff Analysis Method: Quality Attribute Models and Analysis

A variety of qualitative and quantitative techniques are used for analyzing specific quality attributes [Barbacci 95]. These techniques have evolved in separate communities, each with its own vernacular and point of view and have typically been performed in isolation. However, the attribute-specific analyses are interdependent, for example, performance affects modifiability, availability affects safety, security affects performance, and everything affects cost. In other words, each quality attribute has interfaces to other attributes. These interfaces represent dependencies between attributes and are defined by parameters that are shared among attribute models. If we can identify these interfaces, the results from one analysis can feed into the others. This is the principal difference between an architecture tradeoff analysis and other software analysis techniques-that it explicitly considers the interfaces between multiple attributes, and permits principled reasoning about the tradeoffs that inevitably result from such connections. Other analysis frameworks, if they consider connections at all, do so only in an informal fashion, or at a high level of abstraction (see [McCall 94, Smith 93]).

In addition to the technical factors represented by the quality attribute's models and analysis, a software architecture is influenced by business and social forces from multiple stakeholders. Thus, design decisions are often made for non-technical reasons: strategic business concerns, meeting the constraints of cost and schedule, using available personnel, and so forth. "[The message] is that the relationships among business goals, product requirements, practitioner's experience, architectures, and fielded systems form a cycle with feedback loops that a business can manage" [Bass 98]. This "architecture business cycle" is illustrated in Figure 1-1.

Figure 1-1: The Architecture Business Cycle [Bass 98]

There are multiple activities involved in the architecture business cycle:

• creating the business case for the system

• understanding the requirements

• creating or selecting the architecture

• representing and communicating the architecture

• analyzing or evaluating the architecture

• implementing the system based on the architecture

• ensuring that the implementation conforms to the architecture

These activities do not take place in a strict sequence and there are many feedback loops as the multiple stakeholders negotiate among themselves, striving for some consensus. To visualize the process, imagine a blackboard, Figure 1-2, in which the participants read and write various types of information (e.g., requirements, constraints, evaluation results) without necessarily following a set order or rank. The implication is that potentially any of the stakeholders (architects, attribute experts, developers, etc.) can make use of information developed by any other stakeholder and can introduce information that could be of interest to anyone else.

Figure 1-2: Information in the Blackboard

The purpose of this report is to illustrate, through a simple problem, the attribute modeling, analysis, and tradeoff activities suggested by the blackboard "boxes." We have chosen a "model system" that has been used in several case studies [ Nielsen 87, Sanden 89, Smith 93 ]. We have generalized the problem description by requiring support for multiple host computers acting as clients - the single host computer in the original problem becomes a special case. This extension provides a richer basis for exploring a variety of quality attribute issues.

In Chapter 2 we present the problem, identify the requirements and constraints, and present a structural view of an architecture to be analyzed. In Chapter 3 we present attribute-specific models for performance, availability, and security. The models to be considered in an architecture tradeoff analysis are determined by the system requirements, the architectural views, and the experience of the attribute specialists and the architect.

In Chapter 4 we apply the attribute models developed in the previous chapter and carry out the analyses. To conduct the analyses we must identify values for the parameters of the models. As we shall see, these parameters can be explicit in the requirements or architectural view, discovered in the models, or assumed in scenarios used to carry out the analyses. In all cases, the values are either known from prior experience or are assumed to be so, but subject to confirmation during development. The discovered and assumed parameters have to be added to the architecture as refinements or annotations. Since any assumptions, constraints, etc. needed for a model could potentially affect other models, the annotation of the architectural views-together with the scenarios-must be exposed or communicated to all stakeholders.

Finally, Chapter 5 discusses the sensitivity of the results to the information used in the analyses and the tradeoff points between attributes.