1. Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman

2. 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.

3. 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

4. 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.

5. 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

6. 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.

7. 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.

8. 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

9. Overview of ATAM
ATAM Phases

10. Overview of ATAM
Evaluate trade-off among multiple S/W quality attributes
Scenario based

11. Overview of ATAM

12. Overview of ATAM

13. ATAM
Motivated 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

14. ATAM
Quality 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?

15. ATAM Example A 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 the
system would perform and adapt to changes.

16. ATAM Example

17. ATAM Example
Scenarios identify need for Backup nodes

18. ATAM Example For 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.

19. ATAM Summary The 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.

20. 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

21. 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 , 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