ATAM –Cont’d

1. ATAM –Cont’d SEG 3202 N. Elkadri

2. Architecture Tradeoff AnalysisMethod • ATAM is an architecture evaluation method that • focuses on multiple quality attributes • illuminates points in the architecture where quality attribute tradeoffs occur • generates a context for ongoing quantitative analysis • utilizes an architecture’s vested stakeholders as authorities on the quality attribute goals

3. The ATAM • The SEI has developed the Architecture Tradeoff Analysis Method. • The purpose of ATAM is: • to assess the consequences of architectural decisions in light of quality attribute requirements and business goals.

4. The ATAM is a method that helps stakeholders ask the right questions to discover potentially problematic architectural decisions • Discovered risks can then be made the focus of mitigation activities: e.g. further design, further analysis, prototyping. • Surfaced tradeoffs can be explicitly identified and documented.

5. The purpose of the 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.

6. ATAM Steps 1. Present the ATAM 2. Present business drivers 3. Present architecture 4. Identify architectural approaches 5. Generate quality attribute utility tree 6. Analyze architectural approaches 7. Brainstorm and prioritize scenarios 8. Analyze architectural approaches 9. Present results

7. Example of Scenario

8. Example of Risks

9. Example of Risks

10. Examples of Sensitivity/Tradeoff Points

11. Steps of Evaluation Phase Two Step 7 : Brainstorm and prioritize scenarios Step 8 : Analyze architectural approaches Step 9 : Present results

12. Step 7:Brainstorm and Prioritize scenarios • In Steps 5 and 6 we have captured and analyzed scenarios which covered the required quality attributes. • In Step 7 stakeholders bring in their scenarios in a brainstorm process. • Stakeholder scenarios are used to • represent stakeholders interests • understand quality attribute requirements • Prioritization: • Each stakeholder is allocated a number of votes. • Each stakeholder allocates the votes to the scenarios most important to him/her.

13. Scenario Types • Scenarios are used to exercise the architecture against current and future situations: • Use case scenarios reflect the normal state or operation of the system. • Growth scenarios are anticipated changes to the system (e.g., double the message traffic, change message format shown on operator console). • Exploratory scenarios are extreme changes to the system. These changes are not necessarily anticipated or even desirable situations (e.g., message traffic grows 100 times, replace the operating system).

14. Example - Scenarios Scenarios should be as specific as possible: • Stimulus . Environment . Response. • Use case scenario • System keeps doors locked for protection.When a crash occurs, system unlocks doors. • Growth scenario • Customer B needs a function, which was developed for customer A. Reuse it within 1 week. • Exploratory scenario • Reuse a 10-year-old functionin the new software generationwithin 1 month.

15. Stimulus Environment Response • Example Use Case Scenario: • Remote user requests a database report via the Webduring peak period and receives it within 5 seconds. • Example Growth Scenario: • Add a new data server to reduce latency in scenario 1 to 2.5 secondswithin 1 person-week. • Example Exploratory Scenario: • Half of the servers go downduring normal operationwithout affecting overall system availability.

16. Step 8: Analyze Architectural Approaches • Highest ranked scenarios from step 7 are presented to the architect • Evaluation Team probes architectural approaches from the point of view of quality attributes and business drivers to identify risks. • Identify the approaches that pertain to the highest priority scenarios. • Ask quality-attribute specific questions for highest priority scenarios. • Identify and record risks, non-risks, sensitivity points, and tradeoffs.

17. Step 9: Present Results • Outputs: • The architectural approaches documented • The set of scenarios and their prioritization from the brainstorming • The utility tree • The risks discovered • The non-risks documented • The sensitivity points and tradeoff points found

18. ATAM Nominal Phases • ATAM evaluations are often conducted in two stages or phases: • During phase 1 the architect describes the quality attribute requirements and how the architecture meets these requirements. • During phase 2 we determine if a larger group of stakeholders agrees with the requirements and their treatment.

19. The essentials • Architectural evaluation is an essential part of system development. Here, we have emphasized the importance of architecture and outlined a formal method for evaluating architecture in ATAM.Architectural evaluation is important for the success of all systems, irrespective of size. But, normally, it becomes more significant to use formal architectural evaluation methods in medium to large-scale projects.

20. References • Evaluating Software Architectures: Methods and Case Studies, by Paul Clements, Rick Kazman, and Mark Klein. (Chapter 11) • CBAM (2001/SEI) – Cost Benefit Analysis Method (Chapter 12) • Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman (Chapter 11)