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.