SEng 5861 Introduction to Software Architecture

1
SEng 5861Introduction to Software Architecture

• Week 7
• October 17, 2008

2
Agenda

• ATAM Analysis Method
• ATAM Exercise
• CBAM Analysis Method

3
The ATAM

• Architecture Tradeoff Analysis Method
• A thorough and comprehensive way to evaluate a
  software architecture
• This is hard
• Large systems are very complicated
• Evaluation needs to compare business goals and
  technical decisions
• Careful management of an evaluation process is
  needed to consider multiple stakeholders in a
  review format

4
Participants in the ATAM

• Three basic groups
• The evaluation team 4-5 people
• Project decision makers PM, customer, architect
• Architecture stakeholders recommend 12-15

5
Outputs

• A concise presentation of the architecture
• Defined business goals
• Quality requirements via a collection of
  scenarios
• Mapping of architectural decisions to quality
  requirements
• A set of risks and nonrisks
• A set of risk themes

6
Sensitivity and Trade-offs

• Sensitivity point
• Identifies one or more components critical for
  achieving a particular quality attribute
• Trade-off point
• Property that affects more than one attribute and
  is a sensitivity point for more than one attribute

7
Risks and Non-Risks

• Risks
• Potentially problematic architectural decision
• Documenting Identify decision quality attr
• Non-risks
• Good decisions that rely on assumptions in the
  architecture
• Should be recorded so assumptions dont change

8
Phases

• Phase 0 partnership and preparation
• Phase 1 and 2 evaluation
• Phase 1 has 6 steps with smaller group
• Phase 2 has 3 steps with all stakeholders
• Phase 3 follow-up via written report

9
Phase 1

• Present the ATAM process
• Present the business drivers
• Present the architecture
• Identify architecture approaches
• Generate quality attribute tree
• Table 11.5
• Analyze the architectural approaches

10
QA Utility Tree
11
Group Exercise

• Write out high-level architecture and
  architectural approaches
• Generate a Quality Attribute Utility Tree for
  your Architecture

12
Phase 2

• Hiatus
• Brainstorm and prioritize scenarios
• Table 11.6
• Analyze the architectural approaches
• Present results

13
Brainstormed Scenarios
14
Prioritization

• Each group member gets a number of votes equal to
  30 of the number of remaining scenarios
• Can vote anyway that you want
• Vote publicly

15
Types of Scenarios

• Use Cases
• Expected operation
• Growth
• Anticipated changes
• Exploratory
• Stress the system

16
Group Exercise

• Cross-group Scenario Generation

17
Group Exercise Details

• Present your architecture (briefly) to your
  paired team
• Present your quality attribute utility tree, too
• Everyone (combined groups) brainstorms quality
  attribute scenarios
• Combine and prioritize scenarios
• Role reverse and do 2nd system

18
Benefits of the ATAM

• Gets stakeholders together
• Forces specific quality goals
• Prioritization of conflicting goals
• Forces clear architecture presentation
• Improved quality of architectural docs
• Uncovers reuse opportunities
• Improved practices

19
ATAM Summary

• Not an evaluation of requirements
• Not a code evaluation
• Does not include actual system testing
• Not precise, but identifies possible risk areas
  within the architecture
• Actual practice amazement that so many risks
  can be found in such a short time.

20
CBAM
21
The CBAM

• The biggest tradeoffs in large, complex systems
  usually have to do with economics.
• How should an organization invest its resources
  to maximize gain and minimize risk?
• Economics includes cost to build, but also the
  benefits that an architecture delivers.

22
Decision-Making Context

• Begins with the ATAM results
• Adds in costs and benefits associated with the
  architecture decisions
• The stakeholders decide if they should
• Use redundant hardware failover load balance
• Save cost on this project, invest in another
• Provides a framework for making decisions
• Helps clarify ROI the ratio of benefit to cost

23
Utility

• Definition the benefit gained by system
  stakeholders
• Variation set of ATAM scenarios by varying the
  value of the responses, which gives a
  utility-response curve
• Examples in Figure 12.2

24
Practical Curves

• Use only 5 data points
• 4 values independent of architectural strategy
• Best-case (0.1 sec RT is instantaneous to a
  person, so .03 doesnt matter) 100
• Worst-case (minimum requirement) 0
• Current (relative to Best Worst) x
• Desired (relative to Best Worst) y
• Generate the curves for all scenarios

25
Architectural Strategies

• How do you move from the current quality
  attribute response level to the desired or
  best-case level?
• What would be a strategy for
• increasing system response time?
• Increasing capacity?
• Fifth data point derive expected value of the
  new response utility is interpolation of
  original 4 values
• Watch out for side effects

26
CBAM Example
27
Monte Carlo Simulation

• Example Crystal Ball (Oracle)
• Use with network diagram where each node has a
  certain probability of some outcome
• Example application
• Performance analysis
• Expected utility
• Scheduling

28
Discussion on Analysis Methods and Wrap-up