Software Architecture And

Testing
CT059-3-2

The Architecture
Tradeoff Analysis
Method (ATAM) - A
method for architecture
evaluation
 Topic & Structure of the lesson

• Why use Architecture Tradeoff Analysis?

• The phases of the ATAM
• Implications of the ATAM

Module Code & Module Title Slide Title SLIDE 2

Slide 2Slide
(out of225)
 Learning Outcomes

• By the end of this lecture, YOU should be able to :

– Why ATAM is suitable for architecture evaluation?
– Explain the phases of ATAM
– What are the implications of ATAM?

Module Code & Module Title Slide Title SLIDE 3

Slide 3Slide
(out of325)
 Key Terms you must be able to use

• If you have mastered this topic, you should be able to use

the following terms correctly in your assignments and
exams:
– ATAM
– Utility tree
– Use Case Scenario
– Sensitivity Point
– Tradeoff

Module Code & Module Title Slide Title SLIDE 4

Slide 4Slide
(out of425)
 What is ATAM?

• Architecture Tradeoff Analysis Methods

• Reveals how well an architecture satisfies particular quality
goal
• Provides insight into how those quality goals interact each
other
• Is a structured method for evaluation

Extra Notes
This Method is a method used to evaluate the quality
attributes (such as performance, availability, and security) of
software architectures. ATAM is used to mitigate risks in software
architectures in the early stages of the software development life
cycle (SDLC).Method evaluations expose architectural risks
that potentially inhibit the achievement of an organization’s
business goals.
Why architectural analysis
The earlier you find a problem in a software project, the better off
Module Code & Module Title Slide Title SLIDE 5
Slide 5Slide
(out of525)
 Why use ATAM?
• For ensuring the right questions is asked as early as
possible – requirement and design stage
• It guide the stakeholders to look for conflict
• Find a resolution for those conflicts
• Use for analyse legacy systems (improvement on old
architecture) – Reverse Engineering.
*A legacy system is outdated computing software and/or hardware that is
still in use. The system still meets the needs it was originally designed for, but
doesn’t allow for growth.

Participants in ATAM:
• . •The evaluation team: •Architecture stakeholders:
• team leader • developers
• evolution leader • testers
• scenario and processing • users
scribe • builders of systems
• timekeeper
• process observe
• Project decision makers
Module Code & Module Title Slide Title SLIDE 6
Slide 6Slide
(out of625)
 Benefit of ATAM

• The most important results are improved architectures. The ATAM

aids in eliciting sets of quality requirements along multiple
dimensions, analyzing the effects of each requirement in
isolation, and then understanding the interactions of these
requirements.
1. identified risks early in the life cycle
2. increased communication among stakeholders
3. clarified quality attribute requirements
4. improved architecture documentation
5. documented basis for architectural decisions

Module Code & Module Title Slide Title SLIDE 7

Slide 7Slide
(out of725)
 Who Would Benefit

• Many people have a stake in a system's architecture, and all of

them exert whatever influence they can on the architect(s) to
make sure that their goals are addressed. For example,
• The users want a system that is easy to use and has rich
functionality.
• The maintenance organization wants a system that is easy
to modify.
• The developing organization (as represented by
management) wants a system that is easy to build and that will
employ the existing work force to good advantage.
• The customer (who pays the bill) wants the system to be built
on time and within budget. All of these stakeholders will benefit
from applying the ATAM. And needless to say, the architect is
also a primary beneficiary.

Module Code & Module Title Slide Title SLIDE 8

Slide 8
 ATAM Qualification

• Result depends on the quality of the architecture

• Specification of the architecture
– garbage in, garbage out
• Not an attempt to predict quality attributes
• Quality properties that are not easily expressed
• Quantitatively, such as usability, interoperability

Module Code & Module Title Slide Title SLIDE 9

Slide 9Slide
(out of925)
 ATAM Side-effect

• Improve the architecture documentation.

– Elicit/make precise a statement of the architecture’s driving
quality attribute requirements

• Process benefit:
– Foster stakeholder communication & consensus

Module Code & Module Title Slide Title SLIDE 10

Slide 10Slide
(out of10
25)
 ATAM Preconditions

The ATAM relies critically on:

• Appropriate preparation by the customer
• Clearly-articulated quality attribute requirements
• Active stakeholder participation
• Active participation by the architect
• Evaluator familiarity with architectural
• Styles and analytic models

Module Code & Module Title Slide Title SLIDE 11

Slide 11Slide
(out of11
25)
 ATAM STEPS

Module Code & Module Title Slide Title SLIDE 12

Slide 12Slide
(out of12
25)
 Step Explanation

1. Presenting ATAM During this activity, describing the evaluation method to the
system stakeholders is required which typically includes customer
representatives, system architectural team, user representatives,
administrators, developers, testers, integrators, etc.
Presentation

2. Presenting In this activity, the project manager needs to explain the business
Business Drivers goal which motivates the development effort that will become
A.

the main architectural drivers for e.g. high availability, released time,
system performance, security, etc.
3. Presenting In this activity, the system architect needs to elaborate the
Architecture. proposed architecture which focuses on a solution to address
the business drivers.
4. Identifying During this activity, the system architect develops or identifies the
Architectural available
Approaches. architectural approaches. Why did we choose 3 tier ?
Investigation
Analysis

5. Generating the Utility Tree. In this activity, the system quality attributes are
Quality Attributes identified into level of scenarios (Redesign quality attributes/re-draw
B.

utility tree)
6. Analyzing the In this activity, the approaches aimed at meeting non-functional
Architectural requirement are further analyzed and points such as risks,
Approaches. sensitivity, and tradeoff are identified.
7. Brainstorm and In this activity, a broader set of scenarios are elicited from the
Prioritizing whole group of stakeholders, voted and selected
Testing

Scenarios.
C.

8. Analyzing the In this activity, step 6 is reiterated but including the broader set of
Architectural scenarios generated at step 7 to point out additional approaches,
Approaches risks, sensitivity, and tradeoff points which are then documented.
9. Present Results In this activity, the team report the findings along with any
Report

proposed mitigation strategies to the stakeholders

D

Module Code & Module Title Slide Title SLIDE 13

Slide 13Slide
(out of13
25)
 1. Explain the ATAM

Evaluation Team presents an overview of ATAM

• ATAM steps in brief
• Techniques
– Utility tree generation
– Architecture elicitation and analysis
– Scenario brainstorming (for example: ATM machine)
*John with draw money at ATM machine
• Outputs
– Architectural approaches
– Utility tree (LIST OF ATTRIBUTES& CHOSEN ATTRIBUTES)
– Scenarios
– Risks and “non-risks”
– Sensitivity points and tradeoffs

Module Code & Module Title Slide Title SLIDE 14

Slide 14Slide
(out of14
25)
 2. Present business drivers

• ATAM customer representative describes the system’s

business drivers including:
– Business context for the system
• Time to market
• Most important functional requirements
• Most important quality attribute requirements
– Architectural drivers:
• Quality attributes that “shape” the architecture
– Critical requirements:
• Quality attributes most central to the system’s success
– High availability, high security,

Module Code & Module Title Slide Title SLIDE 15

Slide 15
 3. Present architecture

• Architect presents an architecture overview include:

– Technical context of the system
• systems with which the system must interact
• Technical constraints such as an OS, hardware, or
middleware prescribed for use (e.g. database,
cloud, iot, sensor)
– Architectural approaches/styles used to address
quality attribute requirements
– Evaluation team begins probing for and capturing
risks

Module Code & Module Title Slide Title SLIDE 16

Slide 16Slide
(out of16
25)
 4. Identify architectural
approaches

• Start to identify parts of the architecture that are key for

realizing quality attribute goals
• Identify any predominant architectural styles, tactics,
guidelines & principles
– Examples:
• 3-tier Client-server
• Watchdog (monitoring reboot software), Redundant
hardware

Module Code & Module Title Slide Title SLIDE 17

Slide 17Slide
(out of17
25)
 5. Generate quality attribute utility
tree

• Identify, prioritize, and refine the most important quality

attribute goals by building a utility tree
– A utility tree is a top-down vehicle for characterizing the
“driving” attribute-specific requirements
– Select the most important quality goals to be the high-level
nodes (e.g. performance, modifiability, security, availability)
– Scenarios are the leaves of the utility tree
• Output: A characterization and a prioritization of specific
quality attribute requirements

Module Code & Module Title Slide Title SLIDE 18

Slide 18Slide
(out of18
25)
 SAMPLE UTILITY TREE

H – High, M – Medium, L – Low

Module Code & Module Title Slide Title SLIDE 19
Slide 19Slide
(out of19
25)
 Scenario

• Scenarios are used to:

– Represent stakeholders’ interests
– Understand quality attribute requirements
• Scenarios should cover a range of:
– Use case scenarios
• anticipated uses
– Evolution scenarios
• anticipated changes; e.g. growth
– Exploratory scenarios
• unanticipated stresses to the system

Module Code & Module Title Slide Title SLIDE 20

Slide 20Slide
(out of20
25)
 SAMPLE SCENARIO

• Use case scenario

A remote user requests a database report via the Web during
peak period and receives it within 5 seconds
• Evolution scenario
Add a new data server during peak hours within a downtime of
at most 8 hours
• Exploratory scenario
Half of the servers go down during normal operation without
affecting overall system availability

Module Code & Module Title Slide Title SLIDE 21

Slide 21Slide
(out of21
25)
 STIMULI-ENVIRONMENT-RESPONSES

• ‘Formula’ for scenario’s

– Use case scenario
• Remote user requests a database report via the Web during
peak period and receives it within 5 seconds
– Growth scenario
• Add a new data server during peak hours within a downtime
of at most 8 hours.
– Exploratory scenario
• Half of the servers go down during normal operation without
affecting overall system availability
• A good scenario makes clear what the stimulus is and
what the measurable response of interest is

Module Code & Module Title Slide Title SLIDE 22

Slide 22Slide
(out of22
25)
 6. ANALYZE ARCHITECTURAL
APPROACHES

• The evaluation Team probes architectural approaches with

related to specific quality attributes to identify risks
– Identify the approaches that pertain to the highest
priority quality attribute requirements
– Generate quality-attribute specific questions for highest
priority quality attribute requirement
– Ask quality-attribute specific questions
– Identify and record risks and non-risks, sensitivity points
and tradeoffs

Module Code & Module Title Slide Title SLIDE 23

Slide 23Slide
(out of23
25)
 7. BRAINSTORM AND PRIORITIZE
SCENARIOS

• Stakeholders generate scenarios using a facilitated

brainstorming process
– Examples are used to facilitate the step
– The new scenarios are added to the leaves of the utility tree
• Essentially a process step:
– include a larger group of stakeholders
– extend consensus (esp. on priorities)
– extend confidence in completeness of scenario’s

Module Code & Module Title Slide Title SLIDE 24

Slide 24Slide
(out of24
25)
 8. ANALYZE ARCHITECTURAL APPROACHES

• Identify the architectural approaches impacted by the

scenarios generated in the previous step
• This step continues the analysis started in step 6 using the
new scenarios
• Continue identifying risks and non-risks
• Continue annotating architectural information
• Essentially a process step:
– include a larger group of stakeholders
– extend consensus
– extend confidence in completeness of scenario’s

Module Code & Module Title Slide Title SLIDE 25

Slide 25Slide
(out of25
25)
 9. PRESENT RESULTS

• Recapitulate steps of the ATAM

• Present ATAM outputs
– Architectural approaches
– Utility tree
– Scenarios
– Risks and “non-risks”
– Sensitivity points and tradeoffs

Module Code & Module Title Slide Title SLIDE 26

Slide 26Slide
(out of26
25)
 Implications of the ATAM

• ATAM ‘buys’ time to think about an architecture while

development processes are often under time-pressure
• Identification of risks early in the life-cycle
• Focuses on features that are essential for the stakeholders
and not on technical details
• Improved architecture documentation
• Forces stakeholders to:
– think about qualitative requirements
– prioritize qualitative requirements
• Documented basis for architectural decisions
The results are improved architectures

Module Code & Module Title Slide Title SLIDE 27

Slide 27Slide
(out of27
25)
 Reference

Clements, Kazman & Klein – Evaluating Software

Architectures –– Addison-Wesley.

Module Code & Module Title Slide Title SLIDE 28

Slide 28Slide
(out of28
25)
 Summary of Main Teaching Points

• Why use Architecture Tradeoff Analysis?

• The phases of the ATAM
• Implications of the ATAM

Module Code & Module Title Slide Title SLIDE 29

Slide 29Slide
(out of29
25)
 Question and Answer Session

Q&A

Module Code & Module Title Slide Title SLIDE 30

Slide 30Slide
(out of30
25)
 What To Expect Next Week

In Class Preparation for Class

• SAAM- Software Architecture Analysis • Download the slide and study
Method for the next chapter.

Module Code & Module Title Slide Title SLIDE 31

Slide 31