1 / 23

Architectural Analysis

Architectural Analysis. CSE-861 Software System Design & Architecture. Reasons for Architecture Evaluation. Why? Architectural decisions have downstream effects on the system being developed These effects are known and predictable.

pomona
Download Presentation

Architectural Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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]

More Related