Software Architecture Session10


Published on

Software Architecture

Published in: Software
  • Be the first to comment

Software Architecture Session10

  2. 2. Pattern Categories • To refine our classification, we group patterns into three categories: o Architectural patterns o Design patterns o Idioms • Each category consists of patterns having a similar range of scale or abstraction. 1/18/2011
  3. 3. Architectural Patterns • An architectural pattern expresses a fundamental structural organization schema for software systems. • It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. 1/18/2011
  4. 4. Design Patterns • A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. • It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context 1/18/2011
  5. 5. Design Patterns • Design patterns are medium-scale patterns. • They are smaller in scale than architectural patterns, but tend to be independent of a particular programming language or programming paradigm 1/18/2011
  6. 6. Idioms • An idiom is a low-level pattern specific to a programming language. • An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. • Idioms represent the lowest-level patterns. They address aspects of both design and implementation. 1/18/2011
  7. 7. Integration with S/w Development • Architectural patterns can be used at the beginning of coarse-grained design • Design patterns during the whole design phase • Idioms during the implementation phase. 1/18/2011
  8. 8. Relationships between Patterns • A close look at many patterns reveals that, despite initial impressions, their components and relationships are not always as 'atomic' as they first appear to be. • A pattern solves a particular problem, but its application may raise new problems. • Single components or relationships inside a particular pattern may therefore be described by smaller patterns, all of them integrated by the larger pattern in which they are contained. 1/18/2011
  9. 9. SOFTWARE ARCHITECTURE IN PRACTICE Part 3 - Analyzing Architecture 1/18/2011
  10. 10. Overview • What, why, when • Architecture analysis (ATAM – Architecture Tradeoff Analysis Merhod) • Software Architecture Analysis Method (SAAM) 1/18/2011
  11. 11. Architecture evaluation / analysis • Assess whether architecture meets certain quality goals, such as those w.r.t. maintainability, modifiability, reliability, performance • Mind: the architecture is assessed, while we hope the results will hold for a system yet to be built 1/18/2011
  12. 12. Two kinds of questions • Is this architecture suitable? • Which of two or more architectures is the most suitable? 1/18/2011
  13. 13. Alice in Wonderland analogy • Alice meets the Cheshire Cat and asks for directions. • The cat responds: it depends on where you want to go. • Alice says she doesn’t know. • The cat tells her it doesn’t matter which way she walks. • If the stakeholders cannot articulate their quality goals, any architecture will do 1/18/2011
  14. 14. Software Architecture Analysis 1/18/2011
  15. 15. Analysis techniques • Questioning techniques: how does the system react to various situations; often make use of scenarios • Measuring techniques: rely on quantitative measures; architecture metrics, simulation, etc 1/18/2011
  16. 16. Scenarios in Architecture Analysis • Different types of scenarios, e.g. use-cases, likely changes, stress situations, risks, far into the future scenarios • Which stakeholders to ask for scenarios? • When do you have enough scenarios? 1/18/2011
  17. 17. Preconditions for successful assessment • Clear goals and requirements for the Architecture • Controlled scope • Cost-effectiveness • Key personnel availability • Competent evaluation team • Managed expectations 1/18/2011
  18. 18. Architecture Tradeoff Analysis Method (ATAM) • Reveals how well architecture satisfies quality goals, how well quality attributes interact, i.e. how they trade off • Elicits business goals for system and its Architecture • Uses those goals and stakeholder participation to focus attention to key portions of the architecture 1/18/2011
  19. 19. Benefits • Financial gains • Forced preparation • Captured rationale • Early detection of problems • Validation of requirements • Improved architecture 1/18/2011
  20. 20. Participants in ATAM • Evaluation team • Decision makers • Architecture stakeholders 1/18/2011
  21. 21. Phases of ATAM • Present method to stakeholders • Present business drivers (by project manager of system) • Present architecture (by lead architect) • Identify architectural approaches/styles • Generate quality attribute utility tree • Analyze architectural approaches • Brainstorm and prioritize scenarios • Analyze architectural approaches • Present results 1/18/2011
  22. 22. Example Utility tree 1/18/2011
  23. 23. Outputs of ATAM • Concise presentation of the architecture • Articulation of business goals • Quality requirements expressed as set of scenarios • Mapping of architectural decisions to quality requirements • Set of sensitivity points and tradeoff points • Set of risks, nonrisks, risk themes 1/18/2011
  24. 24. Important concepts in ATAM • Sensitivity point: property critical for certain quality attribute • Tradeoff point: property that affects more than one quality attribute • Risk: potential problem • These concepts are overlapping 1/18/2011
  25. 25. Software Architecture Analysis Method (SAAM) • Develop scenarios for o kinds of activities the system must support o kinds of changes anticipated • Describe architecture(s) • Classify scenarios o direct -- use requires no change o indirect -- use requires change • Evaluate indirect scenarios: changes and cost • Reveal scenario interaction • Overall evaluation 1/18/2011
  26. 26. Scenario interaction in SAAM • Two (indirect) scenarios interact if they require changes to the same component • Scenario interaction is important for two reasons: o Exposes allocation of functionality to the design o Architecture might not be at right level of detail 1/18/2011
  27. 27. Summary • At architecture time, 90% of the cost is determined in 10% of the time • Architecture analysis, with a broad range of stakeholders, is extremely valuable 1/18/2011
  28. 28. 5:24 AM SEPS ZG651 Software Architectures