1. ATAM –Cont’d
SEG 3202
N. Elkadri

2. Architecture Tradeoff Analysis Method
ATAM is an architecture evaluation method that
focuses on multiple quality attributes
illuminates points in the architecture where quality attribute tradeoffs occur
generates a context for ongoing quantitative analysis
utilizes an architecture’s vested stakeholders as authorities on the quality attribute goals

3. The ATAM
The SEI has developed the Architecture Tradeoff Analysis Method.
The purpose of ATAM is:
to assess the consequences of architectural decisions in light of quality attribute requirements and business goals.

4. The ATAM is a method that helps stakeholders ask the right questions to discover potentially problematic architectural decisions
Discovered risks can then be made the focus of mitigation activities: e.g. further design, further analysis, prototyping.
Surfaced tradeoffs can be explicitly identified and documented.

5. The purpose of the ATAM is NOT to provide precise analyses
The purpose of the ATAM is NOT to provide precise analyses the purpose IS to discover risks created by architectural decisions.
We want to find trends: correlation between architectural decisions and predictions of system properties.

6. ATAM Steps 1. Present the ATAM 2. Present business drivers
3. Present architecture
4. Identify architectural approaches
5. Generate quality attribute utility tree
6. Analyze architectural approaches
7. Brainstorm and prioritize scenarios
8. Analyze architectural approaches
9. Present results

7. Architectural Decisions Risk Sensiti-vity Tradeoff Non-risk
Example of Scenario
Architectural Decisions
Risk
Sensiti-vity
Tradeoff
Non-risk
AD1 Backward compatibility of interface R1
AD2 Static linkage of client stubs in servers (static binding of libraries) R2
AD3 Single copy of key operational database R3 S1
T1,T2
AD4 Information about data types distributed throughout systems
R4-R6 S2
AD5 Name independence of subsystems T3
AD6 Distributed objects with stable, simple API
NR1
AD7 Uncontrolled dependencies among source files R7

8. Example of Risks R1
ECS is not using the infrastructure capability to “sign” an interface, thus ensuring only syntactic but not semantic compatibility. Consequence: interface may be syntactically compatible but semantically incompatible and system won’t catch this. Could result in incorrect results or failures. R2
Static linkage of client stubs requires that a new version of the system be deployed when an interface changes. Consequences: unintended changes may be included with the interface changes. R3
Single version of databases means that changes affecting the databases require significant testing. Consequence: changes require lots of testing and downtime.

9. Example of Risks R4
Data type information is distributed throughout the system. Consequence: a change to a data type may “ripple” throughout the system. R5
This decision makes it difficult to change data types. Consequences: increased modification costs and reluctance to make enhancements. R6
All instances of data types may not be changed correctly. Consequence: database inconsistencies may result.

10. Examples of Sensitivity/Tradeoff Points
Increasing the amount of downtime associated with a software upgrade increases the risk of the upgrade because rollback is difficult. T1
Availability may be negatively affected by having a single set of databases, but the single set is easier to maintain. T2
While implementing with a single database might be less expensive, maintainability suffers since there might be a reluctance to upgrade: having database replicas reduces time and risk of software upgrades, hence the system owners are more willing to do them. T3
Going through the name server enhances modifiability but imposes a performance cost.

11. Steps of Evaluation Phase Two
Step 7 : Brainstorm and prioritize scenarios
Step 8 : Analyze architectural approaches
Step 9 : Present results

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

13. Scenario Types
Scenarios are used to exercise the architecture against current and future situations:
Use case scenarios reflect the normal state or operation of the system.
Growth scenarios are anticipated changes to the system (e.g., double the message traffic, change message format shown on operator console).
Exploratory scenarios are extreme changes to the system. These changes are not necessarily anticipated or even desirable situations (e.g., message traffic grows 100 times, replace the operating system).

14. Example - Scenarios Scenarios should be as specific as possible:
Stimulus . Environment . Response.
Use case scenario
System keeps doors locked for protection. When a crash occurs, system unlocks doors.
Growth scenario
Customer B needs a function, which was developed for customer A. Reuse it within 1 week.
Exploratory scenario
Reuse a 10-year-old function in the new software generation within 1 month.

15. Stimulus Environment Response
Example Use Case Scenario:
Remote user requests a database report via the Web during peak period
and receives it within 5 seconds.
Example Growth Scenario:
Add a new data server
to reduce latency in scenario 1 to 2.5 seconds within 1 person-week.
Example Exploratory Scenario:
Half of the servers go down during normal operation without affecting overall system availability.

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

17. 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

18. ATAM Nominal Phases
ATAM evaluations are often conducted in two stages or phases:
During phase 1 the architect describes the quality attribute requirements and how the architecture meets these requirements.
During phase 2 we determine if a larger group of stakeholders agrees with the requirements and their treatment.

19. The essentials
Architectural evaluation is an essential part of system development. Here, we have emphasized the importance of architecture and outlined a formal method for evaluating architecture in ATAM. Architectural evaluation is important for the success of all systems, irrespective of size. But, normally, it becomes more significant to use formal architectural evaluation methods in medium to large-scale projects.

20. References
Evaluating Software Architectures: Methods and Case Studies, by Paul Clements, Rick Kazman, and Mark Klein. (Chapter 11)
CBAM (2001/SEI) – Cost Benefit Analysis Method (Chapter 12)
Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman (Chapter 11)