The document discusses the Architecture Tradeoff Analysis Method (ATAM) for evaluating software architectures. ATAM is a qualitative methodology that identifies tradeoffs between quality attributes like performance, security, and modifiability. It facilitates communication between stakeholders to clarify requirements and provide a framework for concurrent system design and analysis. The key outputs of ATAM include prioritized quality requirements, architectural approaches used, analysis questions, mapping of approaches to attributes, and risks, sensitivities, and tradeoffs identified.

1. Evaluating Architectures
Analyzing, Selecting, Making Choices…
The ATAM
Shrikant Palkar

2. Goals for Today
w High level building /pre-requisite blocks
w Why Evaluate ? Why Trade-offs ?
w High level ATAM components
w Many slides and images from the book
Evaluating Software Architectures: Methods and Case
Studies – Paul Clements, Rick Kazman, Mark Klein

3. Looks Familiar ?
w Should we use AIX or Linux for SAP ?
w What should be the system of record for
customer information?
w Will Tlogs volume be supported in the new
POS?

4. Architecture
w 'The (software) architecture of a program or
computing system is the structure or
structures of the system, which comprise
software components, the externally visible
properties of those components, and the
relationships among them.’ Bass, Clements, and Kazman
w “Not just the What but the Why”

5. Why is Architecture Important?
w It is a vehicle for communication among
stakeholders
w It is the manifestation of earliest design
decisions
w It is a reusable, transferable abstraction of a
system

6. Architecture Defines
w Computation w Interaction among
Components Components
n Clients n Subprogram calls
n Servers n Shared data
n Databases n Client-server
n Filters n Piped streams
n Layers

7. Why Evaluate Architectures?
w Because so much is riding on it !
w Architecture evaluation is a cheap way to
avoid disaster
w Architectures allow or preclude nearly all of
a system’s quality attributes

8. Architectural Decisions
& Quality Attributes
w The degree to which a system meets it’s quality
attribute requirements is dependent on architectural
decisions
w A change in structure improving one quality often
affects other qualities
w These product qualities should be designed into the
architecture
w Architecture can only permit, not guarantee, any
quality attribute

9. Architectural Decisions
solution

10. Architecture Descriptions

11. Description
w Architectures are typically drawn as box and
arrow diagrams
w Understood mostly by intuition, context,
explanation
w Many different aspects need to be captured in
the diagrams – structure, control, location of
parts, relationships …

12. Is one picture enough?
w Building Architects – multiple views
w Address needs of multiple stakeholders
w Consistency needs to be maintained

13. Views
w A view is a representation of a set of system
elements and the relations associated with
them
w Not all system elements, some of them
w A view binds an element type and relation
type of interest, and illustrates them

14. Common Views
w Structural , Conceptual
w Runtime, Process
w Code, Development,
w Physical, Hardware, Deployment
w Use case, Design

15. The 4+1 View
Logical Implementation
View View
Analysts/
End-user Programmers
Designers
Structure Functionality Software management
Use-Case
View
Process Deployment
View View
System Integrators System Engineering
Performance System topology
Scalability Delivery, installation
Throughput communication

16. Views and Documents
w Views give us our basic principle of
architecture documentation:
w Documenting a software architecture is a
matter of documenting the relevant views,
and then adding information that applies
to more than one view

17. Which views are relevant?
w Depends on:
l who the stakeholders are
l how they will use the documentation
w Three primary uses for architecture
documentation:
n Education -- introducing people to the project
n Communication -- among stakeholders
n Analysis -- assuring quality attributes

18. What views are available?
w An architect must consider the system in three
ways:
n How is it structured as a set of code units?
n How is it structured as a set of elements that have
run-time behavior and interactions?
n How does it relate to non-software structures in its
environment?

19. Identifying Quality Attributes
Tactics for architectural design

20. Architecture & Quality Attributes
w Architecture is critical to the realization of
many qualities of interest in a system
w These qualities should be designed in and
can be evaluated at the architectural level
w Architecture, by itself is unable to achieve
qualities. It provides foundation for
achieving quality

21. System Quality Attribute
w Performance
w Availability
w Usability End User’s view w Time To Market
w Security w Cost and Benefits
w Projected life time
w Maintainability w Targeted Market Business
w Portability w Integration with Community
Legacy System view
w Reusability Developer’s view
w Roll back Schedule
w Testability

22. Quality Attribute Scenarios
w Bass & others propose a mechanism to capture
quality attributes
w A scenario has six parts
n Source of stimulus
n Stimulus
n Environment
n Artifact
n Response
n Response measure

23. Tactics bridge quality attribute
models and architectural design
w Tactics identify key quality attribute concepts
and bridge quality attribute model and
architectural design
n Modifiability model has concepts such as
“dependency”
n A tactic for controlling dependency is “use an
intermediary”

24. Tactics bridge quality attribute
models and architectural design
w Quality attribute models (analytic, empirical
or qualitative) drive the identification of
tactics
n Derived from well-known analytic models
n Also derived from attribute experts

25. Example: Security Scenario

26. Architectural drivers
w An architectural driver is a quality attribute
requirement (concrete scenario) that has
major impact on the design
w Usually small number of architectural drivers
(~ 5 to 8)
w Located through examination of high
business priority quality attribute
requirements

27. Architecture Tradeoff Analysis
Method
ATAM

28. Architectural Trade Offs
w All design, in any discipline, involves trade offs
w How well does an architecture satisfy particular
goals?
w Provides insight into how quality goals interact,
how they trade amongst themselves.
w Has its origins in SAAM (Software Architecture
Analysis Method) from the early 1990s
w It is a qualitative methodology

29. Approaches to Architecture
Review
w Inspection and Walkthrough
n Check documentations
n Walk through the designs (easier if UML-like model is available,
difficult if no consistent model)
w Review
n Check documentations
n Peer-reviewed group meeting
w Methodological Approach
n Scenario-based Techniques: e.g. ATAM
n Simulation (e.g. weather simulation)
n Architectural-based Testing or Model-Checking

30. What is ATAM?
w “The ATAM is a spiral model of refinement :
one of postulating candidate architectures,
followed by analysis and risk mitigation,
leading to refined architectures. “

31. What is ATAM?
w “ATAM is a method for evaluating
architecture level designs that considers
multiple quality attributes such as
modifiability, performance, reliability and
security in gaining insight as to whether the
fully fleshed out incarnation of the
architecture will meet it’s requirements”

32. ATAM in a Picture

33. ATAM
w Identifies tradeoff points between attributes
w Facilitates communication between
stakeholders from the perspective of each
attribute
w Clarifies and refines requirements
w Provides a framework for the concurrent
process of system design and analysis

34. Attribute specific analyses are
interdependent
w Each attribute is connected to other attributes with
specific architectural elements
w Architectural Element:
n It is a
l Component
l Property of a component
l Property of the relationships between components, that affects
some quality attribute
n These dependencies are Tradeoff points
n Tradeoff points are architectural elements that are
affected by multiple attributes

35. ATAM Outputs
w Prioritized collection of Quality Attribute
Requirements
w Catalog of Architectural Approaches Used
w Approach and Quality-Attribute-Specific
Analysis Questions
w Mapping of Architectural Approaches to
Quality Attributes
w Risks and Non-Risks
w Sensitivity and Trade-off Points

36. ATAM Outputs
w Not for precise analysis
w Discovering risks for further analysis, design,
prototyping so that the risks can be reduced.
w Document the tradeoffs explicitly by means
of documentation

37. ATAM – Detailed Steps
w Step 1 : Present the ATAM
w Step 2 : Present business drivers
w Step 3 : Present architecture
w Step 4 : Identify architectural approaches
w Step 5 : Generate quality attribute utility tree
w Step 6 : Analyze architectural approaches

38. Step 1 – Present ATAM
w The evaluation team presents an overview of
the ATAM including
w The ATAM steps
w Techniques
n Utility tree generation
n Architecture elicitation and analysis
n Scenario brainstorming and mapping

39. Step 2 – Business Goals
w Business Representatives describe:
w The system’s most important (high-level) functions
w Any relevant technical, managerial, economic, or political
constraints
w The business goals and context as they relate to the project
n Architectural driver: quality attributes that shape the architecture
n Critical requirements: most important quality attributes for the
success of the software
w The major stakeholders

40. Step 3 -Present Architecture
w Software Architect presents:
n An overview of the architectures
n Technical constraints such as OS, hardware and languages
n Other interfacing systems of the current system
n Architectural approaches used to address quality attributes
requirements.
w Important architectural information
n Context diagram
n Views: E.g.
l Module or layer view
l Component and connector view
l Deployment view

41. Step 3 - Present Architecture
w Architectural approaches, patterns, tactics employed, what
quality attributes they address and how they address those
attributes
w Use of COTS (Component-off-the-shelves) and their
integration
w Evaluation Team begins probing and capturing risks
w Most important use case scenarios
w Most important change scenarios
w Issues/risk w.r.t. meeting the driving requirements

42. Step 4 – Architectural Approaches
w Catalog the evident patterns and approaches
w Based on step 3
w Start to identify places in the architecture that are
keys for realizing quality attributes requirements
w Identify any useful architectural patterns for the
current problems
w E.g. Client-server, publish-subscribe, redundant
hardware

43. Step 5 - Generate Utility Tree
w Utility tree is a top-down tool to refine and
structure quality attributes requirements
w Select the general, important quality attributes
to be the high-level node
n E.g. performance, modifiability, security and
availability.
w Refine them to more specific categories
w All leaves of the utility tree are “scenarios”.
w Prioritize scenarios

44. Step 5 - Generate Utility Tree
w Important first, difficult to achieve first, and so on.
w Importance with respect to system success
n High, Medium, Low
w Difficulty in achieving
n High, Medium, Low
w (H,H), (H,M), (M,H) most interesting
w Present the quality attribute goals in detail

45. Utility Tree Example
(Priority, Difficulty)

46. Step 6 – Analyze Architectural
Approaches
w Examine the highest ranked scenarios
w The goal is for the evaluation team to be convinced
that the approach is appropriate for meeting the
attribute-specific requirements
w Scenario walkthroughs
w Identify and record a set of sensitivity points and
tradeoff points, risks and non-risks
w Sensitivity and tradeoff points are candidate risks

47. Sensitivity Point, Tradeoff Points,
Risks and non-Risks in Step 6
w Sensitivity points
n Property of components that are critical in achieving
particular quality attribute response
n E.g., security: level of confidentiality vs. number of bits
in encryption key
w Tradeoff points
n Property that is sensitivity point for more than one
attribute
n E.g., encryption level vs. security and performance, in
particular

48. Sensitivity Point, Tradeoff Points,
Risks and non-Risks in Step 6
w Risks
n Potentially problematic architectural decisions.
(e.g. test by unacceptable values of responses)
w Non-Risk
n Good architectural decision

49. Example Scenario

50. Example Risks

51. Example Risks

52. Example Sensitivity Points

53. Evaluation Phase 2
w Step 7 : Brainstorm and prioritize scenarios
w Step 8 : Analyze architectural approaches
w Step 9 : Present results

54. Step 7 – Brainstorm & Prioritize
w In Steps 5 and 6 we have captured and analyzed scenarios
which covered the required quality attributes.
w In Step 7 stakeholders bring in their scenarios in a
brainstorm process.
w Stakeholder scenarios are used to
n represent stakeholders. interests
n understand quality attribute requirements
w Prioritization:
n Each stakeholder is allocated a number of votes.
n Each stakeholder allocates the votes to the scenarios most important
to him/her.

55. Step 8 – Analyze Architectural
Approaches
w Highest ranked scenarios from step 7 are presented
to the architect
w Evaluation Team probes architectural approaches
from the point of view of quality attributes and
business drivers to identify risks.
n Identify the approaches that pertain to the highest priority
scenarios.
n Ask quality-attribute specific questions for highest
priority scenarios.
n Identify and record risks, non-risks, sensitivity points,
and tradeoffs.

56. Step 9 – Present Results
w Outputs:
w The architectural approaches documented
w The set of scenarios and their prioritization from the
brainstorming
w The utility tree
w The risks discovered
w The non-risks documented
w The sensitivity points and tradeoff points found

57. ATAM Summary
The ATAM relies critically on
w Appropriate preparation by the customer
w Clearly-articulated quality attribute requirements
w Active stakeholder participation
w Active participation by the architect
w Familiarity with architectural approaches, styles and
analytic models