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

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

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?

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.

ATAM Example

ATAM Example Scenarios identify need for Backup nodes

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.

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.

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.