Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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