0% found this document useful (0 votes)
67 views

SALecture7 PDF

This document provides an overview of architectural evaluation methods. It discusses why evaluation is important, when it should occur in the lifecycle, and typical costs and benefits. The document then describes various techniques for evaluation, including questioning approaches like ATAM and CBAM, as well as measuring techniques. It focuses on explaining the ATAM method, including the phases, participants, and steps involved in evaluating an architecture using ATAM. Finally, it briefly introduces other evaluation methods like CBAM and the use of metrics, simulations and formal notations.

Uploaded by

jacosito
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
67 views

SALecture7 PDF

This document provides an overview of architectural evaluation methods. It discusses why evaluation is important, when it should occur in the lifecycle, and typical costs and benefits. The document then describes various techniques for evaluation, including questioning approaches like ATAM and CBAM, as well as measuring techniques. It focuses on explaining the ATAM method, including the phases, participants, and steps involved in evaluating an architecture using ATAM. Finally, it briefly introduces other evaluation methods like CBAM and the use of metrics, simulations and formal notations.

Uploaded by

jacosito
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

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

You might also like