Architecture Tradeoff Analysis Method

Based on presentations by Kim and Kazman

http://salmosa.kaist.ac.kr/~cbse/pptfiles/survey_on_SAAM.ppt

http://www.iese.fhg.de/lectures/knauber/WS2000/Slides2411_ATAM.PDF

Introduction S/W Quality:

• 1972, Parnas: modularization, information hiding as a means of high-level system decomposition to improve flexibility and comprehensibility

• 1974, Stevens et al.: notion of coupling & cohesion to evaluate alternatives for program decomposition

• Recent years: specification, architecture, and design with respect to S/W qualities

Why Early Phases?• Identify potential risks, Verify the quality before building

• All design involves tradeoffs

• A software architecture is the earliest life-cycle artifact that embodies significant design decisions: choices and tradeoffs.

Definitions

Quality • Nonfunctional characteristics• Desired combination of attributes

· Maintainability: corrections, improvements, adaptation· Modifiability: change quickly and cost effectively

(Extensibility, portability, restructuring)· Flexibility: ease of modification for case NOT designed· …

• paper by [Keller 1990] is a very good starting place for quality attributes

Overview of Architecture Trade-off Analysis Method (ATAM)

• Proposed by Kazman as a technique for understanding the tradeoffs points or dependencies among the attributes, inherent to

architecture evaluation.

•The purpose of the ATAM is: to assess the consequences of architectural decision alternatives in light of quality attribute requirements [Kazman].

• Provides a way to evaluate software architecture’s fitness with respect to multiple competing quality attributes.

• Since these attributes interact, the method helps to reason about architectural decisions that affect quality attribute interactions. • Follows a spiral model of design, postulating candidate architectures

followed by analysis and risk mitigation, leading to refined architectures.

Overview of Architecture Trade-off Analysis Method (ATAM)

We need a method in which the right questions are asked early to:

• Discover risks -- alternatives that might create future problems in some quality attribute

• Discover sensitivity points -- alternatives for which a slight change makes a significant difference in some quality attribute

• Discover tradeoffs -- decisions affecting more than one quality attribute

Overview of Architecture Trade-off Analysis Method (ATAM)

• The purpose of an ATAM is NOT to provide precise analyses . . . the purpose IS to discover risks created by architectural

decisions.

• We want to find trends: correlation between architectural decisions and predictions of system properties.

• Discovered risks can then be made the focus of mitigation activities: e.g. further design, further analysis, prototyping.

Overview of Architecture Trade-off Analysis Method (ATAM)

Benefits from performing ATAM analyses

• Clarified quality attribute requirements

• Improved architecture documentation

• Documented basis for architectural decisions

• Identified risks early in the life-cycle

• Increased communication among stakeholders

• The most important benefit is improved architectures.

Overview of ATAM• Identify, prioritize and refine the most important quality

attribute goals by building a utility tree

• a utility tree is a model of the “driving” attribute-specific requirements

• typically performance, modifiability, security, and availability are the high-level nodes

• intermediate nodes have specific quality goals

• scenarios are the leaves of the utility tree

• Output: a prioritization of specific quality attribute requirements

Overview of ATAM

ATAM Phases

Overview of ATAM

Evaluate trade-off among multiple S/W quality attributes• Scenario based

Overview of ATAM

Overview of ATAM

ATAMMotivated by the high priority leaves of the utility tree,

the Evaluation Team probes the architecture

approaches Identify the approaches which pertain to the

highest priority quality attribute requirements Generate quality-attribute specific questions for

highest priority quality attribute requirement Ask quality-attribute specific questions Identify and record risks and non-risks

ATAMQuality attribute questions probe approaches/styles to elicit

architectural decisions which bear on quality attribute requirements.

Performance How are priorities assigned to processes? What are the message arrival rates?

Modifiability Are there any places where layers/facades are circumvented? What components rely on detailed knowledge of message formats?

ATAM ExampleA distributed battlefield management system (BMS) One mobile central commander node A set of mobile fighter nodes under

commander Information from many sources/sensors Messages of different types (maps, orders)

Stakeholders wanted to understand how thesystem would perform and adapt to changes.

ATAM Example

ATAM Example

Scenarios identify need for Backup nodes

ATAM ExampleFor availability, a backup commander scheme was described

– Need a backup for the backup (otherwise two hits or failures – would disable the system)

For performance, an client-server style was described

Through analysis:

Increasing the number of backups increases availability, but also increases average latency (because these backups must be kept up-to-date by the commander).

Hence, the number of active and passive backups is a tradeoff point in the BMS architecture.

The designers had not been aware of the tradeoff inherent in their design.

ATAM SummaryThe ATAM is a method for evaluating an architecture

with respect to multiple quality attributes. effective strategy for discovering the consequences of

architectural decisions.

The ATAM: can be done early; can be done on legacy systems is inexpensive builds stakeholder confidence and buy-in The key to the method is looking for trends, not in

making precise analyses.

ATAM Summary

The ATAM relies critically on Appropriate preparation by the customer Clearly-articulated quality attribute requirements Active stakeholder participation Active participation by the architect Familiarity with architectural approaches, styles

and analytic models

References

Kazman R., Klein M., Barbacci M., Longstaff T., Lipson H.,Carriere J.,The Architecture Tradeoff Analysis Method,CMU/SEI-98-TR-008, ESC-TR-98-008, July 1998.

Keller, S. E., Kahn, L. G. and Panara, R. B. (1990). "Specifying Software Quality Requirements with Metrics", in Thayer, R. H. and Dorfman, M. (eds.), System and Software Requirements Engineering, IEEE Computer Society Press Tutorial, pp. 145-163.