Attribute-Based Architectural Styles



Rick Kazman

Mark H. Klein

This library item is related to the following area(s) of work:

Software Architecture

This article was originally published in News at SEI on: April 1, 2000

Attribute-based architectural styles (ABASs) are architecture patterns that can be used as primitives for designing and analyzing software architectures. ABASs build on architectural styles by explicitly associating a reasoning framework (qualitative or quantitative) with a style. ABASs allow an architect to reuse the collected wisdom of the architecture design community in much the same way that object-oriented design patterns have given novice designers access to a vast array of experience in the object-oriented design community.

Software architecture is a key artifact in the development of complex software-intensive systems. If you are reading this column, presumably you already agree with this statement. To realize the benefits of architectures, they must be designed so that the resulting systems behave predictably. But there is no real discipline of architectural design today—it is a "black art," left to a select number of gurus. This notion of design as art is anathema to the creation of an engineering discipline for software. To try to address this gaping hole in the practice of architectural design, we have been creating attribute-based architectural styles (ABASs).

ABASs are architecture patterns that can be used as building blocks for designing and analyzing software architectures. ABASs build upon the notion of an architectural style. An architectural style is a description of components, connectors (relations among components), topology (arrangement of components and connectors), and some constraints on their interaction.

The main addition of ABASs to architectural styles is that they add a foundation for precise and efficient reasoning about specific quality-attribute goals. They do this by explicitly associating a reasoning framework with an architectural style. This reasoning framework may be quantitatively grounded (such as Rate Monotonic Analysis or queuing theory or metrics) or it may be qualitative in nature (such as checklists, questionnaires, or scenario-based analysis).

The reasoning framework shows how to reason about the design decisions comprised by the style. These reasoning frameworks are based on models that are quality-attribute specific (such as performance, reliability, and modifiability models), which exist in the various quality-attribute communities. In some cases these models are mathematical in nature and in other cases they simply capture a designer’s experience in the form of standard questions or design heuristics. For example, adding reasoning based on Rate Monotonic Analysis to the pipe-and-filter style allowed us to create the Performance Concurrent Pipelines ABAS, which supports the designer in quantitatively reasoning about worst-case latency. Similarly, adding scenario-based reasoning using the Software Architecture Analysis Method allowed us to create the Modifiability Layering ABAS, which supports the designer in reasoning about the effects of changes on the modifiability and maintainability of the system.

ABASs are similar in spirit to object-oriented design patterns, which document recurring solutions to recurring problems in object-oriented design. ABASs differ from these patterns in two ways: (1) they differ in scope—ABASs are typically broader in scope, and one would expect to find a small number of ABASs describing the complete architecture for a large, complex system; and (2) they add an explicit reasoning framework to the design, so that the implications of using a pattern can be rigorously explored before committing to it.

ABASs are powerful because they provide a designer or analyst with the concentrated wisdom of many preceding designers faced with similar problems. ABASs promote a disciplined way of doing design and analysis of software architecture based on reusing known patterns of software components with predictable properties.

The Parts of an ABAS

We are currently developing a handbook of ABASs. An early version of this handbook can be found at Attribute-Based Architectural Styles.

Part of the process of creating the handbook was to decide upon a consistent way of presenting and reasoning about an ABAS. An ABAS is documented as follows:

1. Problem Description

This is a description of the application of this technique in terms of real-world problems that the ABAS helps to reason about and solve. This section includes a description of the criteria for choosing the ABAS, including when the ABAS is appropriate and the assumptions underlying the reasoning framework. For example, a performance ABAS might only be appropriate for calculating worst-case latency but not average-case latency.

2. Architectural Style

This will describe the architectural style in terms of its components, connectors, topology, and constraints. It will also describe known extensions to the style. For example, we might describe a strictly layered architectural style where a component in a layer can only access a component in a lower layer, and then discuss extensions to the style where a component can access any adjacent layer, whether above or below, or can access non-adjacent layers.

3. Analysis

This section presents the attribute-specific analysis model (the reasoning framework). A single architectural style may result in several ABASs, because ABASs are quality-attribute specific. So one might have a Security Client-Server ABAS, a Modifiability Client-Server ABAS, a Performance Client-Server ABAS, and so forth. Each will have the same style but a different analysis section. The analysis section will describe the key stimuli to the style, the responses that the analysis allows one to predict, and the architectural properties assumed to be provided as input to the analysis. This section will also include a set of analysis and design heuristics (a set of questions and guidelines that aid the architect in understanding how to achieve the desired response, concentrating particularly on how to manipulate the architectural parameters), and a set of extrapolations (typical ways in which this ABAS is extended relating to the choice of architectural parameters).

4. Examples

In this section we present the ABAS in action, showing how a sample architecture is described, reasoned about, and analyzed. This section may include several iterations of the analysis, showing how the reasoning allows one to discover and deal with design problems in an effective, disciplined way.

5. Related ABASs

This section presents a set of ABASs that either use the same topology, but with a focus on a different quality attribute (e.g., Security Client-Server ABAS vs. Performance Client-Server), or which aid in reasoning about the same response, or a closely related response (e.g., average-case latency vs. worst-case latency).

6. Tradeoffs

In this section we detail the known, frequently seen tradeoff points experienced when dealing with this ABAS. For example, layer bridging is a modifiability/performance tradeoff that frequently occurs in the layering ABAS.

7. Implementation Considerations

This section contains a discussion of the considerations and problems that are known to occur with this style in actual use. For example, layers can be realized in code through such means as coding and naming conventions and restrictions on access to interfaces and the internals that implement them. The engineer using a layering ABAS would have to choose one of these options to realize the ABAS in code.

8. Further Reading

Finally, we complete the ABAS by listing a set of references for the reasoning behind the ABAS, foundations of the analytic model, and so forth. We assume that the information in the ABAS will cover the majority of uses, but if the user has a particular need that goes beyond the presented analysis then he or she can consult the background references.

Designing with ABASs

Architectural design using ABASs is different from ordinary design. Rather than designing first from principles or by limiting reasoning to topology, we envision a process in which a designer considers the problem’s constraints, its inherent topology, and the quality-attribute responses that must be controlled for the system to be successful. From these considerations, the designer can then look up appropriate ABASs from a handbook that is indexed by attribute responses and topology. The bulk of the design and analysis work is ready for the architect to reuse wholesale, and this, we believe, is an enormous benefit. We have already reaped this benefit in practice many times by using ABASs and ABAS-style reasoning in analyzing software architectures.

Architectural analysis and design, as it is currently practiced, is ad hoc in that it always starts from first principles. ABASs hold the promise of changing that, giving software engineers proven starting points and techniques for design and analysis. This holds the promise of making architectural design a true engineering discipline. We expect to publish a handbook of ABASs in 2001, including ABASs on performance, availability, security, usability, testability, and modifiability. We currently have about 15 ABASs in draft or final form and anticipate roughly double that number in the published version of the handbook.

About the Authors

Rick Kazman is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He is also an adjunct professor at the Universities of Waterloo and Toronto. His primary research interests within software engineering are software architecture, design tools, and software visualization. He is the author of more than 50 papers and co-author of several books, including a book recently published by Addison-Wesley titled Software Architecture in Practice. Kazman received a BA and MMath from the University of Waterloo, an MA from York University, and a PhD from Carnegie Mellon University

Mark Klein is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He has more than 20 years of experience in research and technology transition on various facets of software engineering and real-time systems. Klein’s most recent work focuses on the analysis of software architectures. His work in real-time systems involved the development of rate monotonic analysis (RMA), the extension of the theoretical basis for RMA, and its application to realistic systems. He has co-authored many papers and is a co-author of the RMA Handbook, titled A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-time Systems.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.