UW Presentation - Architecture Trade-off Analysis Method


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

UW Presentation - Architecture Trade-off Analysis Method

  1. 1. Evaluating ArchitecturesAnalyzing, Selecting, Making Choices… The ATAM Shrikant Palkar
  2. 2. Goals for Todayw  High level building /pre-requisite blocksw  Why Evaluate ? Why Trade-offs ?w  High level ATAM componentsw  Many slides and images from the book Evaluating Software Architectures: Methods and Case Studies – Paul Clements, Rick Kazman, Mark Klein
  3. 3. Looks Familiar ?w  Should we use AIX or Linux for SAP ?w  What should be the system of record for customer information?w  Will Tlogs volume be supported in the new POS?
  4. 4. Architecturew  The (software) architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.’ Bass, Clements, and Kazmanw  “Not just the What but the Why”
  5. 5. Why is Architecture Important?w  It is a vehicle for communication among stakeholdersw  It is the manifestation of earliest design decisionsw  It is a reusable, transferable abstraction of a system
  6. 6. Architecture Definesw  Computation w  Interaction among Components Components n  Clients n  Subprogram calls n  Servers n  Shared data n  Databases n  Client-server n  Filters n  Piped streams n  Layers
  7. 7. Why Evaluate Architectures?w  Because so much is riding on it !w  Architecture evaluation is a cheap way to avoid disasterw  Architectures allow or preclude nearly all of a system’s quality attributes
  8. 8. Architectural Decisions & Quality Attributesw  The degree to which a system meets it’s quality attribute requirements is dependent on architectural decisionsw  A change in structure improving one quality often affects other qualitiesw  These product qualities should be designed into the architecturew  Architecture can only permit, not guarantee, any quality attribute
  9. 9. Architectural Decisionssolution
  10. 10. Architecture Descriptions
  11. 11. Descriptionw  Architectures are typically drawn as box and arrow diagramsw  Understood mostly by intuition, context, explanationw  Many different aspects need to be captured in the diagrams – structure, control, location of parts, relationships …
  12. 12. Is one picture enough?w  Building Architects – multiple viewsw  Address needs of multiple stakeholdersw  Consistency needs to be maintained
  13. 13. Viewsw  A view is a representation of a set of system elements and the relations associated with themw  Not all system elements, some of themw  A view binds an element type and relation type of interest, and illustrates them
  14. 14. Common Viewsw Structural , Conceptualw Runtime, Processw Code, Development,w Physical, Hardware, Deploymentw Use case, Design
  15. 15. The 4+1 View Logical Implementation View ViewAnalysts/ End-user ProgrammersDesignersStructure Functionality Software management Use-Case View Process Deployment View ViewSystem Integrators System EngineeringPerformance System topologyScalability Delivery, installationThroughput communication
  16. 16. Views and Documentsw  Views give us our basic principle of architecture documentation:w  Documenting a software architecture is a matter of documenting the relevant views, and then adding information that applies to more than one view
  17. 17. Which views are relevant?w Depends on: l  who the stakeholders are l  how they will use the documentationw Three primary uses for architecturedocumentation:n  Education -- introducing people to the projectn  Communication -- among stakeholdersn  Analysis -- assuring quality attributes
  18. 18. What views are available?w An architect must consider the system in threeways:n  How is it structured as a set of code units?n  How is it structured as a set of elements that have run-time behavior and interactions?n  How does it relate to non-software structures in its environment?
  19. 19. Identifying Quality Attributes Tactics for architectural design
  20. 20. Architecture & Quality Attributesw  Architecture is critical to the realization of many qualities of interest in a systemw  These qualities should be designed in and can be evaluated at the architectural levelw  Architecture, by itself is unable to achieve qualities. It provides foundation for achieving quality
  21. 21. System Quality Attributew  Performancew  Availabilityw  Usability End User’s view w  Time To Marketw  Security w  Cost and Benefits w  Projected life timew  Maintainability w  Targeted Market Businessw  Portability w  Integration with Community Legacy System vieww  Reusability Developer’s view w  Roll back Schedulew  Testability
  22. 22. Quality Attribute Scenariosw  Bass & others propose a mechanism to capture quality attributesw  A scenario has six parts n  Source of stimulus n  Stimulus n  Environment n  Artifact n  Response n  Response measure
  23. 23. Tactics bridge quality attribute models and architectural designw  Tactics identify key quality attribute concepts and bridge quality attribute model and architectural design n  Modifiability model has concepts such as “dependency” n  A tactic for controlling dependency is “use an intermediary”
  24. 24. Tactics bridge quality attribute models and architectural designw  Quality attribute models (analytic, empirical or qualitative) drive the identification of tactics n  Derived from well-known analytic models n  Also derived from attribute experts
  25. 25. Example: Security Scenario
  26. 26. Architectural driversw  An architectural driver is a quality attribute requirement (concrete scenario) that has major impact on the designw  Usually small number of architectural drivers (~ 5 to 8)w  Located through examination of high business priority quality attribute requirements
  27. 27. Architecture Tradeoff Analysis Method ATAM
  28. 28. Architectural Trade Offsw  All design, in any discipline, involves trade offsw  How well does an architecture satisfy particular goals?w  Provides insight into how quality goals interact, how they trade amongst themselves.w  Has its origins in SAAM (Software Architecture Analysis Method) from the early 1990sw  It is a qualitative methodology
  29. 29. Approaches to Architecture Revieww  Inspection and Walkthrough n  Check documentations n  Walk through the designs (easier if UML-like model is available, difficult if no consistent model)w  Review n  Check documentations n  Peer-reviewed group meetingw  Methodological Approach n  Scenario-based Techniques: e.g. ATAM n  Simulation (e.g. weather simulation) n  Architectural-based Testing or Model-Checking
  30. 30. What is ATAM?w  “The ATAM is a spiral model of refinement : one of postulating candidate architectures, followed by analysis and risk mitigation, leading to refined architectures. “
  31. 31. What is ATAM?w  “ATAM is a method for evaluating architecture level designs that considers multiple quality attributes such as modifiability, performance, reliability and security in gaining insight as to whether the fully fleshed out incarnation of the architecture will meet it’s requirements”
  32. 32. ATAM in a Picture
  33. 33. ATAMw  Identifies tradeoff points between attributesw  Facilitates communication between stakeholders from the perspective of each attributew  Clarifies and refines requirementsw  Provides a framework for the concurrent process of system design and analysis
  34. 34. Attribute specific analyses are interdependentw  Each attribute is connected to other attributes with specific architectural elementsw  Architectural Element: n  It is a l  Component l  Property of a component l  Property of the relationships between components, that affects some quality attribute n  These dependencies are Tradeoff points n  Tradeoff points are architectural elements that are affected by multiple attributes
  35. 35. ATAM Outputsw  Prioritized collection of Quality Attribute Requirementsw  Catalog of Architectural Approaches Usedw  Approach and Quality-Attribute-Specific Analysis Questionsw  Mapping of Architectural Approaches to Quality Attributesw  Risks and Non-Risksw  Sensitivity and Trade-off Points
  36. 36. ATAM Outputsw  Not for precise analysisw  Discovering risks for further analysis, design, prototyping so that the risks can be reduced.w  Document the tradeoffs explicitly by means of documentation
  37. 37. ATAM – Detailed Stepsw  Step 1 : Present the ATAMw  Step 2 : Present business driversw  Step 3 : Present architecturew  Step 4 : Identify architectural approachesw  Step 5 : Generate quality attribute utility treew  Step 6 : Analyze architectural approaches
  38. 38. Step 1 – Present ATAMw  The evaluation team presents an overview of the ATAM includingw  The ATAM stepsw  Techniques n  Utility tree generation n  Architecture elicitation and analysis n  Scenario brainstorming and mapping
  39. 39. Step 2 – Business Goalsw  Business Representatives describe:w  The system’s most important (high-level) functionsw  Any relevant technical, managerial, economic, or political constraintsw  The business goals and context as they relate to the project n  Architectural driver: quality attributes that shape the architecture n  Critical requirements: most important quality attributes for the success of the softwarew  The major stakeholders
  40. 40. Step 3 -Present Architecturew  Software Architect presents: n  An overview of the architectures n  Technical constraints such as OS, hardware and languages n  Other interfacing systems of the current system n  Architectural approaches used to address quality attributes requirements.w  Important architectural information n  Context diagram n  Views: E.g. l  Module or layer view l  Component and connector view l  Deployment view
  41. 41. Step 3 - Present Architecturew  Architectural approaches, patterns, tactics employed, what quality attributes they address and how they address those attributesw  Use of COTS (Component-off-the-shelves) and their integrationw  Evaluation Team begins probing and capturing risksw  Most important use case scenariosw  Most important change scenariosw  Issues/risk w.r.t. meeting the driving requirements
  42. 42. Step 4 – Architectural Approachesw  Catalog the evident patterns and approachesw  Based on step 3w  Start to identify places in the architecture that are keys for realizing quality attributes requirementsw  Identify any useful architectural patterns for the current problemsw  E.g. Client-server, publish-subscribe, redundant hardware
  43. 43. Step 5 - Generate Utility Treew  Utility tree is a top-down tool to refine and structure quality attributes requirementsw  Select the general, important quality attributes to be the high-level node n  E.g. performance, modifiability, security and availability.w  Refine them to more specific categoriesw  All leaves of the utility tree are “scenarios”.w  Prioritize scenarios
  44. 44. Step 5 - Generate Utility Treew  Important first, difficult to achieve first, and so on.w  Importance with respect to system success n  High, Medium, Loww  Difficulty in achieving n  High, Medium, Loww  (H,H), (H,M), (M,H) most interestingw  Present the quality attribute goals in detail
  45. 45. Utility Tree Example(Priority, Difficulty)
  46. 46. Step 6 – Analyze Architectural Approachesw  Examine the highest ranked scenariosw  The goal is for the evaluation team to be convinced that the approach is appropriate for meeting the attribute-specific requirementsw  Scenario walkthroughsw  Identify and record a set of sensitivity points and tradeoff points, risks and non-risksw  Sensitivity and tradeoff points are candidate risks
  47. 47. Sensitivity Point, Tradeoff Points, Risks and non-Risks in Step 6w  Sensitivity points n  Property of components that are critical in achieving particular quality attribute response n  E.g., security: level of confidentiality vs. number of bits in encryption keyw  Tradeoff points n  Property that is sensitivity point for more than one attribute n  E.g., encryption level vs. security and performance, in particular
  48. 48. Sensitivity Point, Tradeoff Points, Risks and non-Risks in Step 6w  Risks n  Potentially problematic architectural decisions. (e.g. test by unacceptable values of responses)w  Non-Risk n  Good architectural decision
  49. 49. Example Scenario
  50. 50. Example Risks
  51. 51. Example Risks
  52. 52. Example Sensitivity Points
  53. 53. Evaluation Phase 2w  Step 7 : Brainstorm and prioritize scenariosw  Step 8 : Analyze architectural approachesw  Step 9 : Present results
  54. 54. Step 7 – Brainstorm & Prioritizew  In Steps 5 and 6 we have captured and analyzed scenarios which covered the required quality attributes.w  In Step 7 stakeholders bring in their scenarios in a brainstorm process.w  Stakeholder scenarios are used to n  represent stakeholders. interests n  understand quality attribute requirementsw  Prioritization: n  Each stakeholder is allocated a number of votes. n  Each stakeholder allocates the votes to the scenarios most important to him/her.
  55. 55. Step 8 – Analyze Architectural Approachesw  Highest ranked scenarios from step 7 are presented to the architectw  Evaluation Team probes architectural approaches from the point of view of quality attributes and business drivers to identify risks. n  Identify the approaches that pertain to the highest priority scenarios. n  Ask quality-attribute specific questions for highest priority scenarios. n  Identify and record risks, non-risks, sensitivity points, and tradeoffs.
  56. 56. Step 9 – Present Resultsw  Outputs:w  The architectural approaches documentedw  The set of scenarios and their prioritization from the brainstormingw  The utility treew  The risks discoveredw  The non-risks documentedw  The sensitivity points and tradeoff points found
  57. 57. ATAM SummaryThe ATAM relies critically onw  Appropriate preparation by the customerw  Clearly-articulated quality attribute requirementsw  Active stakeholder participationw  Active participation by the architectw  Familiarity with architectural approaches, styles and analytic models