ATAM

1
ATAM Contd

• SEG 3202
• N. Elkadri

2
Architecture Tradeoff AnalysisMethod

• 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 architectures 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 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
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 wont 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
S1 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 7Brainstorm 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)