[4]
![Forwards to [5]](../all_the_pictures/arrow_right.jpg)
M. R. Barbacci
L.J. Bass
J. Carriere
P. Clements
R. Kazman
M. Klein
R. C. Linger
H. F. Lipson
Software Engineering Institute
Carnegie Mellon University
Architectural styles have enjoyed widespread popularity in the past few years because they represent the distilled wisdom of experienced architects, and can inform and guide less experienced architects. An architectural style (as defined by Shaw and Garlan [SG 96] and elaborated on by others [BMR 96]) includes a description of component types and their topology, a description of the pattern of data and control interaction among the components, and an informal description of the benefits and drawbacks of using that style. Architectural styles differentiate classes of designs by offering experiential evidence of how each class has been used, together with qualitative reasoning to explain why each class has certain properties. The purpose of our research is to move the notion of architectural styles toward reasoning (whether qualitative or quantitative) based on quality-attribute-specific models. Attribute-Based Architecture Styles are the next step in the development of architectural styles, and we believe that they are particularly well suited to the analysis and design of survivable systems. The goal of an ABAS is to describe an architectural style and to show how to reason about it from the point of view of a particular quality attribute. ABASs add to the Garlan and Shaw notion of an architectural style by including explicit and rigorous (but not necessarily quantitative) reasoning about attribute-specific behavior.
Thus, for example, a pipe-and-filter performance ABAS would be one that has a description of what it means for a component to be a pipe or a filter and how components would legally be connected, a queuing model of the pipe-and-filter topology together with rules to instantiate the model, and the results of solving the resulting queuing model under varying sets of assumptions. Such an ABAS could be analyzed for survivability characteristics as well.
As indicated in the ISW'98 Call for Participation, "[Information survivability] is more than security, more than safety, and more than fault tolerance. It is a combination of quality attributes that assures that even if significant portions of a system are damaged by an attack, accident, or failure, the mission of the network, software, or service will continue."
One of the objectives of an ABAS is to link an architectural style with specific models of such quality attributes. An ABAS definition includes 1) a section that describes the stimulus-response behavior of the architectural style, 2) a section that explicitly highlights the important Quality Attribute (QA) measures of the responses, 3) a section that describes the structures and properties of the architectural style, 4) a section that explicitly highlights QA properties and stimuli that affect the QA measures of the responses, and 5) a section that defines methods for reasoning (either using mathematical formulas or empirical evidence combined with experience) about how the QA properties and stimuli affect the QA measures. In essence, the QA attribute measures are a function of QA properties and stimuli. The behavior of the architectural style is determined by this function, which the ABAS makes explicit. The reasoning methods and models are drawn from various quality attribute areas, such as the survivability, security, performance, and reliability disciplines.
There are two important points to be made about ABAS concepts. The first is that architectural styles are very useful in analysis. When analyzing a system, recognition of a pipe and filter ABAS, for example, leads to questions about how performance or survivability is handled, and about assumptions that the filters make that might impact their reuse. The second point is that when considering architectural styles as analysis tools, focussing on particular quality attributes [McC 94] leads to the ability to attach known analytic models for these attributes to the architecture being analyzed. This in turn, leads to the ability to predict the effect of particular architectural decisions and changes to the architecture. Thus, instead of a designer relying on vague guidance about how a particular style affects survivability, the designer is given a model, its analysis, and its explicit connection to aspects of the architectural style. The designer can then answer questions such as "What is the effect on survivability of moving a particular function from one component to another within a pipe and filter architectural design?" In essence, ABASs provide a designer with a pre-analyzed structural framework, an analysis, and a mapping between the structure and the analysis.
Associated with the mapping from architectural style to analytic model are two related processes:
- From a design perspective, there are a set of decisions that accompany turning a style into an implementable design. For example, when decomposing a system's functionality into a set of processes, there is an allocation of functionality to each process, and an allocation of processes to processors. For a performance style we might also make decisions such as choosing the priorities of the processes.
- From an analysis perspective, there are a set of questions that accompany an architectural style that aid in understanding the style. For a survivability ABAS, these questions would include investigation of capabilities for intrusion resistance, recognition, and recovery.
If these questions relate to designs that are repeated over and over again within an organization, then they are often organized into checklists [Mar 93] that are employed during architectural reviews. The answers to the questions form the input to the attribute models. This is the key linkage that comprises the reasoning behind an ABAS: architectural parameters—the things that you can change when you do architectural design—are explicitly related to parameters in an analytic model. In solving the model, we are then modeling the expected behavior of the architecture. The results of this model solving can then be compared to the expected behavior.
We envision, and are actively working on, a handbook with many ABASs that encapsulate pre-packaged design and analysis wisdom. Survivability ABASs in the handbook will deal with several architectural styles including those for security (such as authentication and encrypted channels) and those for recoverability (such as replication and logging). This work is an attempt to make architectural design for survivability and other properties more of an engineering discipline; one where design decisions are made on the basis of known characteristics and well-understood analyses.
References
[4]
![Forwards to [5]](../all_the_pictures/arrow_right.jpg)





