Notes

Outline

Architecture TradeOff Analysis Method (ATAMSM) John D. McGregor Clemson University

Participants Evaluation team Project decision team Architecture stakeholders

Outputs from ATAM Presentation of the architecture Articulation of the business goals Quality requirements Mapping of architectural decisions to quality requirements Set of identified sensitivity and tradeoff points Set of risks and nonrisks Set of risk themes

Phases Partnership and preparation – this is what we are doing now – setup administrative details Evaluation present the ATAM – doing that today present business drivers present the architecture identify architectural approaches generate quality attribute utility tree analyze architectural approaches

Phases Evaluation – take 2 stakeholder centric brainstorm and prioritize scenarios analyze architectural approaches present results Follow-up final report

Scenario Stimuli – A user moves the mouse rapidly across the desktop Environment – while the Puck is moving across the screen Response – the Paddle is not moved as fast as the mouse.

Scenario Analysis

Utility Tree

Utility Tree

Final Report 1. Introduction 2. The Architecture Tradeoff Analysis Method (ATAM) 3. Business Drivers Presentation 4. Architecture Presentation 5. Utility Tree 6. Scenario Generation/Prioritization 7. Analysis of Architectural Approaches 8. Risks, Sensitivities, Tradeoffs Collected Risks Non-Risks Collected Sensitivities Collected Tradeoffs Risk, Sensitivity, Tradeoff Themes 9. Conclusions and Next Steps 10. References

Risks etc Risk – a potentially problematic decision Non-risk – good, but implicit, decision in the architecture Sensitivity point – point at which an attribute makes a large change in value Tradeoff point – a decision point at which some attributes are enhanced and some are degraded

Risk Themes Synthesizes the risks, non-risks, sensitivity points, and trade-off points into a “theme” The Arcade Game Maker Product Line has at least one risk theme: The user’s experience with a game is related to the number of Game elements on the screen.

Adaptive applications Need to avoid lack of flexibility and lack of maintainability due to adding code to adapt to changing business rules and GUI Forces Separate adaptability concerns Adaptability functionality may be turned off Not all developers need to be aspect literate Can be implemented on any platform Kind of contextual information might change

Example system - dictionary Basic functionality – translates English into Portuguese Implemented on the J2ME (micro edition) for consumer electronics and embedded devices Adaptation – the language to translate into changes as the location of the device changes

Adaptability Aspects Base application – core asset functionality such as business and GUI code Adaptability aspects – shows how base application is to be changed Auxiliary classes – classes used by the aspect weaver Context manager – analyzes context changes Adaptation data provider – provides data for context changes

AdaptabilityAspects

AdaptabilityAspects

Adaptability Aspects provides • Reuse. • Extensibility. • Platform Independence.  Modularity. • Dynamic changes.

Adaptability Aspects liabilities • Code size. • Efficiency. • Dynamic loading.