Rick Kazman

The architecture tradeoff analysis method

This paper presents the Architecture Tradeoff Analysis Method (ATAM), a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. This method was developed to provide a principled way to evaluate a software architectures fitness with respect to multiple competing quality attributes: modifiability, security, performance, availability, and so forth. These attributes interact-improving one often comes at the price of worsening one or more of the others-as is shown in the paper, and the method helps us to reason about architectural decisions that affect quality attribute interactions. The ATAM is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

SAAM: a method for analyzing the properties of software architectures

While software architecture has become an increasingly important research topic in recent years, insufficient attention has been paid to methods for evaluation of these architectures. Evaluating architectures is difficult for two main reasons. First, there is no common language used to describe different architectures. Second, there is no clear way of understanding an architecture with respect to an organizations life cycle concerns -software quality concerns such as maintainability portability, modularity, reusability, and so forth. We address these shortcomings by describing three perspectives by which we can understand the description of a software architecture and then proposing a five-step method for analyzing software architectures called SAAM (Software Architecture Analysis Method). We illustrate the method by analyzing three separate user interface architectures with respect to the quality of modifiability.<<ETX>>

Scenario-based analysis of software architecture

Despite advances in clarifying high level design needs, analyzing a systems ability to meet desired quality criteria is still difficult. The authors propose using scenarios to make analysis more straightforward. In their case study report, they analyze lessons learned with this approach. They developed the Software Architecture Analysis Method, an approach that uses scenarios to gain information about a systems ability to meet desired quality attributes. Scenarios are brief narratives of expected or anticipated system uses from both user and developer views and they provide a look at how the system satisfies quality attributes in various use contexts.

Playing Detective: Reconstructing Software Architecture from Available Evidence

Because a systems software architecture strongly influences its quality attributes such as modifiability, performance, and security, it is important to analyze and reason about that architecture. However, architectural documentation frequently does not exist, and when it does, it is often “out of sync” with the implemented system. In addition, it is rare that software development begins with a clean slate; systems are almost always constrained by existing legacy code. As a consequence, we need to be able to extract information from existing system implementations and utilize this information for architectural reasoning. This paper presents Dali, an open, lightweight workbench that aids an analyst in extracting, manipulating, and interpreting architectural information. By assisting in the reconstruction of architectures from extracted information, Dali helps an analyst redocument architectures, discover the relationship between “as-implemented” and “as-designed” architectures, analyze architectural quality attributes and plan for architectural change.

WebQuery: searching and visualizing the Web through connectivity

Abstract Finding information located somewhere on the World-Wide Web is an error-prone and frustrating task. The WebQuery system offers a powerful new method for searching the Web based on connectivity and content. We do this by examining links among the nodes returned in a keyword-based query. We then rank the nodes, giving the highest rank to the most highly connected nodes. By doing so, we are finding “hot spots” on the Web that contain information germane to a users query. WebQuery not only ranks and filters the results of a Web query, it also extends the result set beyond what the search engine retrieves, by finding “interesting” sites that are highly connected to those sites returned by the original query. Even with WebQuery filtering and ranking query results, the result sets can be enormous. So, we need to visualize the returned information. We explore several techniques for visualizing this information—including cone trees, 2D graphs, 3D graphs, lists, and bullseyes-and discuss the criteria for using each of the techniques.

Quantifying the costs and benefits of architectural decisions

The benefits of a software system are assessable only relative to the business goals the system has been developed to serve. In turn, these benefits result from interactions between the systems functionality and its quality attributes (such as performance, reliability and security). Its quality attributes are, in most cases, dictated by its architectural design decisions. Therefore, we argue that the software architecture is the crucial artifact to study in making design tradeoffs and in performing cost-benefit analyses. A substantial part of such an analysis is in determining the level of uncertainty with which we estimate both costs and benefits. We offer an architecture-centric approach to the economic modeling of software design decision making called CBAM (Cost Benefit Analysis Method), in which costs and benefits are traded off with system quality attributes. We present the CBAM, the early results from applying this method in a large-scale case study, and discuss the application of more sophisticated economic models to software decision making.

Experience with performing architecture tradeoff analysis

Software architectures, like complex designs in any field, embody tradeoffs made by the designers. However, these tradeoffs are not always made explicitly by the designers and they may not understand the impacts of their decisions. This paper describes the use of a scenario-based and model-based analysis technique for software architectures-called ATAM-that not only analyzes a software architecture with respect to multiple quality attributes, but explicitly considers the tradeoffs inherent in the design. This is a method aimed at illuminating risks in the architecture through the identification of attribute trends, rather than at precise characterizations of measurable quality attribute values. In this paper, the operationalization of ATAM is illustrated via a specific example in which we analyzed a U.S. Army system for battlefield management.

Attribute-Based Architecture Styles

Architectural styles have enjoyed widespread popularity in the past few years, and for good reason: they represent the distilled wisdom of many experienced architects and guide less experienced architects in designing their architectures. However, architectural styles employ qualitative reasoning to motivate when and under what conditions they should be used. In this paper we present the concept of an ABAS (Attribute-Based Architectural Style) which includes a set of components and connectors along with their topology, but which adds to this a quality attribute specific model that provides a method of reasoning about the behavior of component types that interact in the defined pattern. We will define ABASs in this paper, show how they are used, and argue for why this extension to the notion of architectural style is an important step toward creating a true engineering discipline of architectural design.

The metropolis model a new logic for development of crowdsourced systems

It takes a city of developers to build a big system that is never done.

Discovering Architectures from Running Systems

One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. In this paper, we describe a technique that uses runtime observations about an executing system to construct an architectural view of the system. In this technique, we develop mappings that exploit regularities in system implementation and architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations and are formally defined using colored Petri nets. In this paper, we describe a system, called DiscoTect, that uses these mappings and we introduce the DiscoSTEP mapping language and its formal definition. Two case studies showing the application of DiscoTect suggest that the tool is practical to apply to legacy systems and can dynamically verify conformance to a preexisting architectural specification