Architectural Analysis

1. Architectural Analysis CSE-861 Software System Design & Architecture

2. Reasons for Architecture Evaluation • Why? • Architectural decisions have downstream effects on the system being developed • These effects are known and predictable. • So much is on stake, and it is economical to do it before it becomes reality • When? • It is cost-effective to evaluate software quality as early as possible in the life cycle • Evaluation can also be done to choose between two or more competing architectural solutions

3. The ATAM • It is a comprehensive method for architectural evaluation • Architecture Tradeoff Analysis Method (ATAM) • It reveals how well an architecture satisfies particular quality goals • It provides insight into how quality goals interact—that is, how they trade off • Evaluating an architecture for a large system is a complicated undertaking.

4. The ATAM … • computer system tends to support some specific business goals • the evaluation must interrelate these goals with the technical decisions • A large system has different stakeholders with different perspectives • Management of these stakeholders and their perspectives in a limited time is also difficult

5. Participant in the ATAM • The evaluation team • External to the project • 3-5 people • Can be from the same organisation or some outside consultants • For roles of ATAM evaluation team refer to table 11.1 • Project decision makers • People who can make the decisions about the project • Project manager, architect (must), or the customer • Architecture stakeholders • They have their interests in the architecture performing as it is advertised • developers, testers, integrators, maintainers etc.

6. ATAM Evaluation Team Roles Role: Evaluation Leader Responsibilities: Runs evaluation; facilitates elicitation of scenarios; administers scenario selection/prioritization process; Desirable Characteristics: Comfortable in front of audience; excellent facilitation skills; practiced in architecture evaluations; able to tell when prolonged discussion is leading to a valuable discovery or when it is pointless and should be re-directed (Abstracted fromTable 11.1)

7. Outputs of the ATAM • A concise presentation of the architecture • Articulation of the business goals • Quality requirements in terms of a collection of scenarios • Mapping of architectural decisions to quality requirements • A set of identified sensitivity and tradeoff points • A set of risks and non-risks • A set of risk themes

8. ATAM Phases

9. Steps in ATAM • Total 9 steps are involved in the evaluation/analysis phase • Steps 1-6 are performed in the first evaluation phase • In phase 2, with all stakeholders present, those steps are summarized and steps 7 through 9 are carried out.

10. ATAM Steps • Step 1—Present the ATAM • Evaluation leader presents the ATAM process to the reps. • Step 2—Present Business Drivers • A project decision maker (ideally the project manager or the system's customer) presents a system overview from a business perspective • The system's most important functions • Any relevant technical, managerial, economic, or political constraints • The business goals and context as they relate to the project • The major stakeholders • The architectural drivers (that is, the major quality attribute goals that shape the architecture)

11. ATAM Steps • Step 3—Present Architecture • the lead architect (or architecture team) presents the architecture at an appropriate level of detail • The architect should convey the essence of the architecture to make the most of limited time • Show any technical constraints • Present the architectural approaches used (in terms of patterns, styles etc.) [Refer to the Figure 11.1 to see what aspects can be covered in the presentation]

12. Important Architectural Information (4–8 slides) • Context diagram • Module or layer view • Component-and-connector view • Deployment view Architectural approaches, patterns, or tactics employed • (COTS) products and their integration • use case scenarios • change scenarios • Architectural issues/risks

13. ATAM Steps • Step 4—Identify Architectural Approaches • Main focus of the ATAM is to understand the architectural approaches • Architectural patterns are useful for the known ways in which each one affects particular quality attributes. • the architect is asked to explicitly name the patterns and approaches used • The list is noted down and is displayed so that everyone can see it.

14. ATAM Steps • Step 5—Generate Quality Attribute Utility Tree • High level quality attributes with respect to the business goals were listed in step 2 • However, their analysis is difficult with some concrete context • Modifiability; Modifiable in what way? Which aspect? • Quality attributes are articulated as utility trees. • Most important quality attributes are expressed as scenarios.

15. ATAM Steps - Step 5 Utility Tree • A utility tree begins with utility as the root node. • Utility is an expression of the overall "goodness" of the system • Quality attributes form the second level because these are the components of utility • Under each of these quality attributes are specific quality attribute refinements • performance might be decomposed into "data latency" and "transaction throughput.“ • Scenarios are the mechanism by which broad (and ambiguous) statements of desired qualities are made specific and testable.

16. ATAM Steps - Step 5 • the decision makers assign a priority to each scenario to short list or have a focused discussion • The high priority or most difficult scenarios will be analysed in detail ( most of the time will be spent on analysis)

17. Utility Tree

18. ATAM Steps • Step 6—Analyze Architectural Approaches • highest-ranked scenarios evaluated one at a time • Questioners ask for the architectural approaches that the architect used to carry out the scenario • the team documents the relevant architectural decisions and identifies and Catalogue their risks, nonrisks, and tradeoffs

19. ATAM Steps • Break and Start of Phase 2 • First, step 1 is repeated so that the stakeholders understand the method • Evaluation leader recaps the results of steps 2 through 6, and shares the current list of risks, non-risks, sensitivity points, and trade off points.

20. ATAM – Phase 2 • Step 7—Brainstorm and Prioritize Scenarios • Scenario brainstorming works well in larger groups, creating an atmosphere in which the ideas and thoughts of one person stimulate others' ideas. • The prioritized list of brainstormed scenarios is compared with the utility tree exercise • Once the scenarios have been collected, they must be prioritized

21. ATAM Steps • Step 8—Analyze Architectural Approaches • The highest ranked scenarios from step 7 are chosen for analysis • The architect presents the architectural decisions taken to realise particular quality attributes • Activities of step 6 are repeated by the evaluation team

22. ATAM Steps • Step 9—Present Results • 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 [Table 11.3 Steps and ATAM Outputs, Correlated]

23. References and Further Reading • Chapter 11 of Software Architecture in Practice • Go through the case study given in the book to see how this approach can be applied [The Nightingale System]