Introduction

1. Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman http://salmosa.kaist.ac.kr/~cbse/pptfiles/survey_on_SAAM.ppthttp://www.iese.fhg.de/lectures/knauber/WS2000/Slides2411_ATAM.PDF

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