Architecture Tradeoff Analysis Method

1. Architecture Tradeoff Analysis Method Software Engineering Institute Carnegie Mellon University Presented by: Senthil ayyasamy CS 590l- winter 2003

2. Road Map • Introduction – Software Evaluation • Case Study – Web content Delivery • Secret behind Akamai technologies • ATAM ( Paper Summary) • Terminologies • Steps • Applying ATAM to the case study • Going beyond the paper • what I have done last summer?

3. Software Evaluation • Software Architecture • Analysis and Evaluation • Need for Analysis • AIAM • AIAM Rough Plan

4. - Bridge for Requirements & Code - Choices + tradeoffs - 4+1 View . {Elements, Forms, Rationale} . Logical, Physical, Process and Development View Software Architecture Requirements Architecture Code

5. Analysis and Evaluation • How can we use software architectures to evaluate a Quality Attribute • Quality attributes • Tussle in Software space • Architectural Trade-off and Analysis

6. Why analysis ? • Risk mitigation for a particular systems • What does the quality of attributes imply? • How to you determine these desired QA • Knowing whether the architecture is suitable without even building them • Real time systems

7. AIAM • Assumes • that attribute-specific analyses are interdependent • that each quality attribute has connections with other quality attributes through specific architectural elements • Architectural element: a component, a property of a component, or a property of the relationship between components that affects some quality attributes

8. ATAM Rough Plan Phase IV: Tradeoffs Phase I: Scenario and Requirements Gathering Collect Scenarios Identify Tradeoffs Collect Requirements, Constraints, Environment Identify Sensitivities Describe Architectural Views Attribute Specific Analyses Phase III: Model Building and Analyses Phase II: Architectural Views and Scenario Realization Realize Scenarios

9. II. Case Study – Web content Delivery • Akamai Technologies • Content Delivery • Host Web Service • Possible Architectural Models • Client – Server • Client – Server – Server • Client – Intelligent Cache – Server • Client – Redirection Proxies – Server

10. QA for Content Delivery • Performance • Reliability • Cost

11. III. Summary of [KKC99] • Evaluation • Scenarios: Use/growth/exploratory • QA: stimulus, architectural parameters, responses. • elicitation/screening questions • sensitivity/trade off point • ABAS • problem description, stimuli/response, arch style, analysis • Quality analysis heuristics

12. ATAM Steps • Scenario elicitation • Architecture elicitation • Mapping of Scenarios onto the architecture representations • Analysis

13. Collect Scenarios • Elicit system usage scenarios from stakeholders • Purpose: • to operationalize both functional and quality requirements • facilitate communication • develop a common vision of the important activities the system should support

14. Collect Requirements, Constraints, and Environment • Identify attribute-based requirements, constraints, and environment • Run-time qualities • Non run-time qualities

15. Describe Architectural Views • Generate candidate architectures • Can do this by matching the architectural styles to the quality attributes of the system • Realize the scenarios by verifying the architectures against the scenarios

16. Identify Sensitivities • Involves varying elements of the architecture to identify if values from the attribute analyses change • If a significant change is identified, then the modeled values are considered “sensitivity points”

17. Identify Tradeoffs • Focuses on the interaction of attribute-specific analyses • Finding tradeoff points: • multiple attributes may be sensitive to a single architectural element • the architectural element is considered a tradeoff point

18. IV. Applying ATAM to the case study • In a client-server architecture, each of the following is sensitive to the # of servers • Performance • Availability • Security

19. Iterations • When analyses show that the system’s predicted behavior comes adequately close to its requirements, the designers can proceed to a more detailed level of design • When analyses reveal a problem, we can develop a plan for changing the architecture and repeating the steps • Steps do not have to be linear

20. Tradeoffs Effect of change on attribute Attribute 1 Attribute 2 Attribute-specific architecture analysis Attribute-specific architecture analysis Architecture 1 Architecture 2 Change in software architecture

21. Tradeoffs Effect of change on attributes Attribute Set 1 Attribute Set 2 Attribute-specific architecture analyses Attribute-specific architecture analyses Architecture 1 Architecture 2 Change in software architecture

22. Attribute Analysis • Several analysis techniques already exist for performing: • reliability and risk analysis • safety analysis • performance analysis • security analysis

23. V. Beyond the Paper • Identification of analysis methods • Applicability of methods across several architectural styles • Specification of quality attributes in order to facilitate measurement • Examples!

24. VI So, How is my work related ? • Validation of software systems • FSMs • Markov Analysis • Abstract State Machines • Open source from Microsoft Research • Compatible with all platforms • Will have something exciting soon 