ASAAM: Aspectual Software Architecture Analysis Method

1. ASAAM: Aspectual Software Architecture Analysis Method Bedir TekinerdoganUniversity of Twente Department of Computer Science Enschede, The Netherlands e:mail – bedir@cs.utwente.nl http://www.cs.utwente.nl/~bedir/

2. Contents • Evaluating Architectures using Scenarios • SAAM • Example: Window Management System • ASAAM • Conclusion & Discussions

3. Implementing Architecture • Architecture is the earliest artifact • with the largest impact • where trade-offs are visible. • Implementing it requires lots of resources • time • money • manpower

4. Therefore evaluate architecture early … • Analyzing for system qualities early in the life cycle allows for a comparison of architectural options. • Predict quality of system before it has been built • Identify potential risks • Evaluation later in the project: damage control • Evaluation/Analysis provides a mechanism for understanding how the system will evolve.

5. Architecture (Re)definition Review Guidelines Quality Criteria no Architecture Ok? yes Go! Implement Architecture Software Architecture Evaluation

6. Scenario-based evaluation • Scenario is a brief description of an interaction of a stakeholder with a system What if… What if… System What if… What if… What if…

7. Scenario-based evaluation techniques • SAAM • Scenario-Based Architecture Analysis Method • SAAMCS • SAAM Founded on Complex Scenario • ESAAMI • Extending SAAM by Integration In The Domain • SAAMER • Software Architecture Analysis Method Evolution and Reusability • ATAM • Architecture Trade-off Analysis Method • SBAR • Scenario-Based Architecture Re-engineering • ALPSM • Architecture Level Prediction of Software Maintenance • SAEM • A Software Architecture Evaluation Model L.Dobrica & E.Niemela, A Survey on Software Architecture Analysis Methods,IEEE Transactions on Software Engineering, Vol 28, No. 7, pp. 638-654, July 2002.

8. Example: SAAM • Describe candidate architectures • Develop scenarios • Perform scenario evaluation • Reveal scenario interactions • Generate overall evaluations

9. A window management system includes different important components such as EventManager for I/O controlling, e.g. keyboard and mouse events; Process-Manager for scheduling and managing application processes; ScreenManager for maintaining the integrity of the screen; WindowManager for managing the windows that are related to the application processes. <<arch>> EventManager communicates <<arch>> ScreenManager <<arch>> WindowManager update screen notifies <<arch>> ProcessManager Example: Window Management System

10. Scenario Evaluation • S1. Start multiple processes at the same time. • S2. Change color of widgets in the window. • S3. Close all open windows • S4. Change screen resolution • S5. Enter a command to start application process • S6. Move the main window • S7. Screen saver is activated • S8. Resize a window • S9. Terminate a process • S10. Interrupt a process Direct Scenarios Indirect Scenarios • S11. Change look-and-feel style on run-time. • S12. Add voice control • S13. A failure occurs and the system shuts down. • S14. Provide dual display screen. • S15. Use multiple desktops. • S16. Monitor activities of the user • S17. Provide touch screen and light pen as input • S18. A memory overflow due to many opened windows • S19. Port system to command-based operation system • S20. Minimize windows after idle time for each

11. The good and the bad Scenario interactions can mean: • Scenarios are semantically related • good scenario interactions • shows the cohesiveness of components • Scenarios are semantically distinct • bad scenario interactions • architecture must be refactored

12. Different indirect scenarios... Indirect Scenarios • S11. Change look-and-feel style on run-time. • S12. Add voice control • S13. A failure occurs and the system shuts down. • S14. Provide dual display screen. • S15. Use multiple desktops. • S16. Monitor activities of the user • S17. Provide touch screen and light pen as input • S18. A memory overflow due to many opened windows • S19. Port system to command-based operation system • S20. Minimize windows after idle time for each

13. I cannot get the architecture right? What’s wrong...?! Refactor yes Go! Implement Architecture refactor, refactor, refactor,.... Indirect Scenario no  Architecture Ok?

14. The good, the bad and the ugly... • Current architecture evaluation methods do not explicitly consider potential aspects (the ugly ) • Therefore it is not possible to detect these at the software architecture design level. • Undetected aspects will still pop up later in the software development life cycle. • This is too late, • and will lead to aspectual problems • which is as such contrary to purpose of architecture evaluation approaches

15. ASAAM • Describe candidate architecture • Develop and prioritize scenarios • Individual scenario evaluation and aspect identification • Direct Scenarios, Indirect Scenarios, Aspectual scenarios, Architectural aspects • Scenario interaction evaluation and component classification • Cohesive component, tangled component, composite component, ill-defined component • Refactor architecture • using conventional techniques (OO, patterns etc.) • using aspect-oriented techniques

16. Heuristic rules for scenario evaluation • R0:Develop SCENARIO artifacts based on PROBLEM DESCRIPTION • R1:IF SCENARIO does not require any changes to architectural descriptionTHEN SCENARIO becomes DIRECT SCENARIO • R2: IF SCENARIO requires changes to one or more ARCHITECTURAL COMPONENTs THEN SCENARIO becomes INDIRECT SCENARIO • R3:IF INDIRECT SCENARIO can be resolved after refactoring THEN INDIRECT SCENARIO is DIRECT SCENARIO • R4:IF DIRECT SCENARIO is scattered and cannot be localized in one component THEN DIRECT SCENARIO is ASPECTUAL SCENARIO • R5:IF INDIRECT SCENARIO is scattered and cannot be localized in one component THEN INDIRECT SCENARIO is ASPECTUAL SCENARIO • R6:Derive ARCHITECTURAL ASPECT from ASPECTUAL SCENARIO R0 Scenario R1 R2 Direct Scenario Indirect Scenario R3 R4 R5 Aspectual Scenario R6 Architectural Aspect

17. Heuristic Rules for Component Classification • R7: Select COMPONENT from ARCHITECTURE • R8:IF COMPONENT is not affected by a SCENARIO THEN component is DIRECT COMPONENT for SCENARIO • R9:IF COMPONENT is affected by one or more SCENARIO THEN component is INDIRECT COMPONENT for SCENARIO • R10IF INDIRECT COMPONENT can be refactored to perform INDIRECT SCENARIO THEN INDIRECT COMPONENT is DIRECT COMPONENT • R11IF DIRECT COMPONENT performs semantically close scenarios THEN DIRECT COMPONENT is COHESIVE COMPONENT • R12IF DIRECT COMPONENT performs semantically distinct scenarios AND cannot be decomposed THEN DIRECT COMPONENT is TENTATIVE TANGLED COMPONENT • R13IF DIRECT COMPONENT performs semantically distinct scenarios AND can be decomposed THEN DIRECT COMPONENT is COMPOSITE COMPONENT • R14:IF INDIRECT COMPONENT includes semantically close scenariosTHEN INDIRECT COMPONENT is COHESIVE COMPONENT • R15:IF INDIRECT COMPONENT includes semantically distinct scenarios AND cannot be decomposed THEN COMPONENT becomes TENTATIVE TANGLED COMPONENT • R16:IF INDIRECT COMPONENT includes semantically distinct scenarios AND can be decomposed THEN INDIRECT COMPONENT is COMPOSITE COMPONENT • R17:IF TENTATIVE TANGLED COMPONENT includes ASPECTUAL SCENARIO THEN TENTATIVE TANGLED COMPONENT is TANGLED COMPONENT for given aspectual scenario • R18:IF TENTATIVE TANGLED COMPONENT does not include ASPECTUAL SCENARIO THEN TENTATIVE TANGLED COMPONENT is Ill-DEFINED COMPONENT

18. Identified Aspects and Tangled Components Aspects derived from scenarios S13, S16, S19: Failure Management, Monitoring, Operating System Portability

19. <<arch-aspect>> EventManager <<pointcut>> recover() Aspectual refactoring <<arch>> EventManager communicates update screen <<arch>> ScreenManager <<arch>> WindowManager notifies <<arch>> ProcessManager

20. Conclusion • Architectural aspects exist • e.g. failure management, monitoring, operating system portability • ASAAM extends existing scenario based software architecture analysis methods • to explicitly identify architectural aspects • and pinpoint aspectual refactoring for corresponding aspects.