Software Architecture Session10
Post on 25-May-2015
118 Views
Preview:
DESCRIPTION
Transcript
PATTERN ORIENTED SOFTWARE
ARCHITECTURE - VOLUME1Chapter 1 - Patterns
Pattern Categories
• To refine our classification, we group patterns into three categories:o Architectural patternso Design patternso Idioms
• Each category consists of patterns having a similar range of scale or abstraction.
1/18/2011
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
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
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
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
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
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
SOFTWARE ARCHITECTURE IN
PRACTICE Part 3 -
Analyzing Architecture
1/18/2011
Overview
• What, why, when• Architecture analysis (ATAM –
Architecture Tradeoff Analysis Merhod)• Software Architecture Analysis
Method (SAAM)
1/18/2011
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
Two kinds of questions
• Is this architecture suitable?• Which of two or more architectures is the
most suitable?
1/18/2011
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
Software Architecture Analysis
1/18/2011
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
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
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
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
Benefits
• Financial gains• Forced preparation• Captured rationale• Early detection of problems• Validation of requirements• Improved architecture
1/18/2011
Participants in ATAM
• Evaluation team• Decision makers• Architecture stakeholders
1/18/2011
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
Example Utility tree
1/18/2011
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
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
Software Architecture AnalysisMethod (SAAM)• Develop scenarios for
o kinds of activities the system must supporto kinds of changes anticipated
• Describe architecture(s)• Classify scenarios
o direct -- use requires no changeo indirect -- use requires change
• Evaluate indirect scenarios: changes and cost• Reveal scenario interaction• Overall evaluation
1/18/2011
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 designo Architecture might not be at right level of detail
1/18/2011
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
5:24 AM SEPS ZG651 Software Architectures
top related