Software Architectures
Lecture 7
Roadmap of the course
What is software architecture?
Designing Software Architecture
Requirements: quality attributes or qualities
How to achieve requirements : tactics
How do tactics lead to architectural styles
Case studies on architectural styles, observe the achieved qualities
The ADD method
Documenting software architecture
Bass and all
Hofmeister and all the four views
Today:Analyzing and evaluating an architecture
24-Feb-10
Architectural evaluation - why
Architecture tells about system properties
Effects of design decisions are predictable => architecture is
analyzable
Architecture drives the software system => economic value
Good evaluation methods => low-cost risk mitigation
Architecture evaluation good to be standard part of every
architecture-based development method
24-Feb-10
Architectural evaluation - when
Cost-effective: early in lifecycle
Easier to correct problems
Quality cannot be appended to a system later in lifecycle
Developing architecture
Evaluate taken/under consideration decisions
Choose among alternatives or competing architectures
Other times in lifecycle
Completed architecture: validate it before development
Legacy system under consideration, inherited system, large
software system to be aquired
Planned or unplanned
24-Feb-10
Architectural evaluation - cost
Cost = staff time required of the participants
Aproximative cost for AT&T: 70 staff-days
300 full scale architecture reviews for projects requiring
minimum 700 staff-days
ATAM reviews: about 36 staff-days
For evaluation team
Other stakeholders time counts too
Time included for training the evaluation team!
24-Feb-10
Architectural evaluation - benefits
Financial
Forced preparation for the review
Captured rationale
Early detection of problems
Validation of requirements
Improved architectures
Overall: increased quality, controlled cost, decreased budget
risk
24-Feb-10
Architectural evaluation - techniques
Questioning techniques
Rely on thought experiments to check architecture suitability
Hypothetical architectures too
Scenario-based
ATAM
CBAM
Checklist- or questionaire-based
Measuring techniques
Rely on quantitative measures over existing artifact
Architectural metrics
Simulations, prototypes
24-Feb-10
Properties of successful evalution
Clear goals and requirements for architecture
Controlled scope
Cost-effectiveness
Key personnel availability
Competent evaluation team
Managed expectations
Final report
24-Feb-10
ATAM
Architecture Tradeoff Analysis Method
How well an architecture satisfies particular goals?
Provides insight into how quality goals interact, how they trade
off
Has its origins in SAAM (Software Architecture Analysis
Method) from the early 1990s
24-Feb-10
Participants in ATAM
The evaluation team
Project decision makers
Architecture stakeholders
10
24-Feb-10
Outputs of the ATAM
A concise presentation of the architecture
Articulation of the business goals
Quality requirements in terms of a collection of
12
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
24-Feb-10
Other outputs
Secondary outputs
Architecture representation survives evaluation
Scenarios too
Analysis can serve as statement of rationale for architectural
decisions
Made or not
Intangible goals
Social, community sense
Better communication
Improved understanding
13
24-Feb-10
Phases of the ATAM
Phase 0
Partnership and preparation
Phase 1
Evaluation
Phase 2
Evaluation continued
Phase 3
Follow-up
14
24-Feb-10
Steps of evaluation phase 1
Step 1
Present the ATAM
Step 2
Present business drivers
Step 3
Present architecture
Step 4
Identify architectural approaches
Step 5
Generate quality attribute utility tree
Step 6
Analyze architectural approaches
15
24-Feb-10
Step 2: Present business goals
Describe
The systems 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 (the major quality attribute goals)
16
24-Feb-10
Step 3: Present architecture
Driving architectural requirements, measurable
quantities associated with these,
standards/models/approaches for meeting these
Important architectural information
Context diagram
Module or layer view
Component and connector view
Deployment view
17
24-Feb-10
Step 3: Present architecture cont
Architectural approaches, patterns, tactics employed,
18
what quality attributes they address and how they
address those attributes
Use of COTS and their integration
Most important use case scenarios
Most important change scenarios
Issues/risks w.r.t. meeting the driving requirements
24-Feb-10
Step 4: identify architectural
approaches
Catalog the evident patterns and approaches
Based on step 3
Serves as the basis for later analysis
19
24-Feb-10
Step 5: Generate quality attribute utility
tree
Utility tree
Present the quality attribute goals in detail
Quality attribute goals are
Identified, prioritized, refined
Expressed as scenarios
Utility is an expression of the overall goodness of the
system
Quality attributes form the second level being components of
utility
20
24-Feb-10
Step 5: Generate quality attribute utility
tree cont
Scenarios are prioritized
Depending on how important they are and
Depending on how difficult it will be for the architecture to
satisfy a scenario
21
24-Feb-10
22
24-Feb-10
Step 6: Analyze architectural
approaches
Examine the highest ranked scenarios
The goal is for the evaluation team to be convinced that
the approach is appropriate for meeting the attributespecific requirements
Scenario walkthroughs
Identify and record a set of sensitivity points and tradeoff
points, risks and non-risks
Sensitivity and tradeoff points are candidate risks
23
24-Feb-10
24
24-Feb-10
Steps of evaluation phase 2
Step 7
Brainstorm and prioritize scenarios
Step 8
Analyze architectural approaches
Step 9
Present results
25
24-Feb-10
Step 7: Brainstorm and prioritise
scenarios
Utility tree shows architects view on the quality attributes
Here the focus is on the other stakeholders view on the
quality attributes and scenarios based on these
Which are the most meaningful and important scenarios w.r.t.
users etc.
26
24-Feb-10
Step 8: Analyse architectural
approaches
Highest ranked scenarios from step 7 are presented to the
architect
Explain how relevant architectural decisions contribute to
realizing each one
27
24-Feb-10
Step 9: Present results
Outputs:
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
28
24-Feb-10
Other methods
CBAM
Cost-Based Analysis Method
Uses ATAM
Measuring technics
Answer specific questions about specific qualities
Need the presence of a design/implementation artifact (the
object to measure)
RMA rate monotonic analysis: quantitative technique for
ensuring that a set of fixed-priority processes can be scheduled
on a CPU
Can be performed as architecture is being evolved
ADL, formal notations and languages
29
24-Feb-10
CBAM
Biggest trade-offs influence economics
Resources
Earlier: costs
Of building system, not long term
Now also: benefits
Economic models needed
Consider costs, benefits, risks, schedule implications
Basic idea of CBAM
Architectural strategies quality attributes benefits for
stakeholders (utilities)
30
24-Feb-10
CBAM Utilities
Architectural strategy
Provides specific level of utility to stakeholders
Has cost
Takes time to implement
Return On Investment (ROI)
Ratio of benefit to cost
Utility-response curves
Depicts how the utility derived from a particular response varies as
the response varies
Best-case, worst-case, current-case, desired-case response
interpolation
Side effects
31
24-Feb-10
Some formulas
Overal utility of architectural strategy across scenarios
32
Strategy i
Scenario j
Benefit Bi
Benefit bi,j
Weight Wj
Utility U
Return over investment ROI, cost C
Bi = j (bi,j Wj)
bi,j = Uexpected-Ucurrent
Ri = Bi/Ci
24-Feb-10
