Architecture TradeOff Analysis Method (ATAMSM)
| John D. McGregor | |
| Clemson University |
| Evaluation team | |
| Project decision team | |
| Architecture stakeholders |
| 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 |
| 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 | |
| Evaluation take 2 | |
| stakeholder centric | |
| brainstorm and prioritize scenarios | |
| analyze architectural approaches | |
| present results | |
| Follow-up | |
| final report |
| 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. |
| 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 | |
| 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 |
| 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 users experience with a game is related to the number of Game elements on the screen. |
| 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 |
| 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 |
| 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 |
| Reuse. | |
| Extensibility. | |
| Platform Independence. | |
| Modularity. | |
| Dynamic changes. | |
Adaptability Aspects liabilities
| Code size. | |
| Efficiency. | |
| Dynamic loading. | |