ATAM –Cont’d SEG 3202 N. Elkadri

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

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.

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.

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.

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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.

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)