2. CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method Bedir Tekinerdogan Billkent University, Department of Computer Engineering Bilkent, Turkey, Ankara e:mail - bedir@cs.bilkent.edu.trbedir@cs.bilkent.edu.tr http://www.cs.bilkent.edu.tr/~bedir/

3. 2 © Bedir Tekinerdogan Problem Statement Scenario-based Analysis of Software Architecture ASpectual SAAM (ASAAM) Modeling Aspects using Domain Analysis Table of Contents

4. 3 © Bedir Tekinerdogan Aspect-Oriented Programming Crosscutting and tangling at code level Modeling aspects at code level Aspect-Oriented Design Modeling aspects at design level (Model) Identifying aspects (Method)

5. 4 © Bedir Tekinerdogan Current aspect identification approaches In general ad-hoc “aspects are for the picking...” Usually based on code-analysis: “Assume the given example.... Concerns crosscuts code and is tangled in classes...” class Point { void setX(int x) { _x = x; } Tracer.traceEntry(“Point.set”); Tracer.traceExit(“Point.set”); DisplayTracker.updatePoint(this);

6. 5 © Bedir Tekinerdogan Characteristics of an aspect... Systemic, tends to affect multiple components Cross-cuts, spread over different components Affects performance/quality

7. 6 © Bedir Tekinerdogan Aspect identification... Analysis Design Implementation Testing Requirements Analysis Domain Analysis Problem Solution Aspects?! Where?

8. 7 © Bedir Tekinerdogan software development Analysis Design Implementation Testing Requirements Analysis Domain Analysis Systemic, cross-cuts and relates to quality… Hmmm… There is an aspect, and there, and there too, ooh and over there... Where are the aspects?

9. 8 © Bedir Tekinerdogan Late Aspect Identification Too late! Analysis Design Implementation Testing Requirements Analysis Domain Analysis Missing early aspects. Difficult to model aspects.

10. 9 © Bedir Tekinerdogan Modeling Aspects class Point { void setX(int x) { _x = x; } Tracer.traceEntry(“Point.set”); Tracer.traceExit(“Point.set”); DisplayTracker.updatePoint(this); Alright, tracing is an aspect But what is tracing/ how to model this?

11. 10 © Bedir Tekinerdogan Early Aspect Identification Analysis Design Implementation Testing Requirements Analysis Domain Analysis All relevant aspects can be identified. Modeling aspects from domain knowledge.

12. 11 © Bedir Tekinerdogan What is a method? Webster's dictionaryWebster's dictionary: Method: 1: a procedure or process for attaining an object: as a (1): a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2): a systematic plan followed in presenting material for instruction b (1): a way, technique, or process of or for doing something (2): a body of skills or techniques. Methodology: A branch of philosophy dealing with the science of method; a system of methods and rules applied in a science.

13. 12 © Bedir Tekinerdogan Guidelines for production Guidelines for verification Provides logical consistency among the different processes and phases in design. Helps to reduce possible errors Helps to identify important progress milestones. Rationale for method

14. 13 © Bedir Tekinerdogan Aspect-Oriented Method Identifying Specifying Evaluating aspects in a systematic way

15. 14 © Bedir Tekinerdogan Guidelines for identification/production of aspects Guidelines for verification of aspects Provides logical consistency among the different processes and phases in design; consistency for/with aspects. Helps to reduce possible errors in aspect-oriented programs/designs Helps to identify important progress milestones. Rationale for aspect-oriented method

16. 15 © Bedir Tekinerdogan Software engineering method m application n model o tools 1 application layer method layer model layer support layer Driver Monitoring system objects, classes inheritance Method CASE, OO compiler

17. 16 © Bedir Tekinerdogan What is a method? Use cases entities classes associations STD attributes inheritance If then.. If then.. If then.. If then.. If then.. If then.. If then.. Rules (heuristics) Process Artifacts

18. 17 © Bedir Tekinerdogan Example: Requirements Analysis Models use case actor Rules Identify Actors Identify Use Case Draw the use case diagram Process Application Use case Actor Monitor Driver Actions Track Steering Movement Track Brake Maneuvers Monitor Track Transmission Maneuvers

19. 18 © Bedir Tekinerdogan Architecture Design Methods Ok, but is there a method to identify aspects?

20. ASAAM: Aspectual Software Architecture Analysis Method Bedir Tekinerdogan Billkent University, Department of Computer Engineering Bilkent, Turkey, Ankara e:mail - bedir@cs.bilkent.edu.trbedir@cs.bilkent.edu.tr http://www.cs.bilkent.edu.tr/~bedir/

21. 20 © Bedir Tekinerdogan Contents Software Architecture Evaluating Architectures using Scenarios SAAM Example: Window Management System Architectural Aspects ASAAM Conclusion & Discussions

22. 21 © Bedir Tekinerdogan Architecture Describes (is) Structure Consisting of components which forms the foundation of the whole....

23. 22 © Bedir Tekinerdogan Intuitive notion of software architecture Software Architecture represents the gross level structure of a software system. Design : Implementation = Software Architecture : Design

24. 23 © Bedir Tekinerdogan Design, Realize and Test Architecture Software Architecture Design Requirements Analysis Implementation.............. public class Student {private String name; private int id; public String getName () return name} public void setName (String str){ name = str;} public int getId() {return id; } public void setId(int i) {id = i; } } Analysis & Design theRegistraraSectiontheTranscriptaStudent state of prereq have prereq enroll ed enrollInSecti on: return sections getSectionsFor: addStudent: enrolled takenCourse: prerequisite

25. 24 © Bedir Tekinerdogan Rationale for Software Architecture Improved understanding because of a higher level abstract specification Guides construction since it embodies earliest design decisions Supports stakeholder communication Support for large-grained reuse Enables to evaluate system before it is implemented Controls impact of change Management of software development activities

26. 25 © Bedir Tekinerdogan 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

27. 26 © Bedir Tekinerdogan 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 Evaluation/Analysis provides a mechanism for understanding how the system will evolve. Identify potential risks Evaluation later in the project: damage control

28. 27 © Bedir Tekinerdogan Architecture Ok? Architecture (Re)definition Go! Implement Architecture yes no Review Guidelines Quality Criteria Software Architecture Evaluation

29. 28 © Bedir Tekinerdogan Evaluation Techniques Simulations Mathematical Modeling Question-based Questionnaire-based List of general open questions that apply to all software architectures (see project review guidelines). Checklist-based detailed set of questions after experience of analyzing common set of systems usually domain specific Scenario-based analysis

30. 29 © Bedir Tekinerdogan Scenarios Scenario is a brief description of an interaction of a stakeholder with a system System What if…

31. 30 © Bedir Tekinerdogan Stakeholders Stakeholders: end users managers developers maintainers analysts designer testers customers....

32. 31 © Bedir Tekinerdogan Quality Correctnessdoes software do what its supposed to? Flexibilityhow easy is it to change it? Securityhow secure is it? Interoperabilitydoes it interface easily? Maintainabilityhow easy is it to repair? Portabilityhow easy is it to transport? Usabilityhow easy is it to use? Reliabilityhow often will it fail? Reusabilityis it reusable in other systems? Safetydoes it prevent hazards? Verifiabilitycan it be tested?

33. 32 © Bedir Tekinerdogan Is the system modifiable? Qualities are vague… What if we change the color of the user interface, is that possible…? Sure! We have just to change that parameter in this component What about changing the data format? Hmmm, no this is not that easy, we have to change too many components…

34. 33 © Bedir Tekinerdogan Quality depends on context We cannot completely define the context but we can focus on important parts of the context and describe desired or anticipated use of the system so that quality considerations become more clear. Scenarios help to provide a view of the context

35. 34 © Bedir Tekinerdogan Stakeholders-Quality Different stakeholders see quality in different terms : End user Usability Understandability Functionality Customer Efficiency Developer Reusability Interoperability Portability Maintainer maintainability Tester Testability Every stakeholder will define specific set of scenarios

36. 35 © Bedir Tekinerdogan Example Scenarios Use Scenario User downloads document from the file server Change scenario The relational database is mapped to an object-oriented database Exploratory scenarios Half of the servers go down during operation

37. 36 © Bedir Tekinerdogan Scenarios should be specific S1. System fails what is system? which component fails? why does it fail? when? S1’. Database is destroyed and the data is recovered from the backup files.

38. 37 © Bedir Tekinerdogan How to extract scenarios Brainstorming Session with different stakeholders Collect Scenarios of different stakeholders Workshop Look at domain Possible uses of system Risks Look at other systems Compare systems Experiences Reuse Scenarios Evaluate scenarios Select scenarios

39. 38 © Bedir Tekinerdogan 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 Scenario-based evaluation techniques 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.

40. 39 © Bedir Tekinerdogan Example: SAAM 1.Describe candidate architectures 2.Develop scenarios 3.Perform scenario evaluation 4.Reveal scenario interactions 5.Generate overall evaluations

41. 40 © Bedir Tekinerdogan Example: Window Management System 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.

42. 41 © Bedir Tekinerdogan 1. Describe Candidate Architectures Identify alternative architectures domain model patterns Structures should be selected based on functional and quality requirements > EventManager > WindowManager > ScreenManager > ProcessManager update screen communicates notifies

43. 42 © Bedir Tekinerdogan 2. Develop and Prioritize Scenarios Develop task scenarios that the system must support Develop change scenarios which describe anticipated changes of system Capture all important scenarios

44. 43 © Bedir Tekinerdogan Develop Scenarios - Example 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 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

45. 44 © Bedir Tekinerdogan Identify Stakeholders Who are the important stakeholders? What is their interest? Interview stakeholders iterate until sufficient coverage (never sure)

46. 45 © Bedir Tekinerdogan Classify Scenarios Direct Scenarios can be executed by the system without modification Indirect scenarios require modifications to the system addition/removal/update of architectural components or relations Whether a scenario is direct or indirect depends on both architecture and the scenario itself

47. 46 © Bedir Tekinerdogan Classify Scenarios - Example 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 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 Indirect Scenarios Direct Scenarios > EventManager > WindowManager > ScreenManager > ProcessManager update screen communicates notifies

48. 47 © Bedir Tekinerdogan 3. Perform Scenario Evaluation For each indirect scenario identify the components and relations that must be modified (added, removed or updated) provide an estimation of the difficulty of the modification Difficulty of modification is based on the architectural components that need to be modified.

49. 48 © Bedir Tekinerdogan Perform Scenario Evaluation - Example 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 Indirect Scenario Impacts WindowManager EventManager EventManager, ProcessManager WindowManager all components EventManager EventManager, ScreenManager all components ScreenManager

50. 49 © Bedir Tekinerdogan 4. Reveal Scenario Interactions Scenario interaction: Multiple indirect scenarios affect the same components Good scenario interactions Semantically related scenarios affect the same architectural components. Bad scenario interactions Semantically unrelated scenarios affect the same components  shows which components are implementing semantically unrelated functions Poor separation of concerns ComponentDirect Scenarios Indirect Scenarios EventManagerS3, S5S12,S13,S16, S17,S18,S19 ScreenManagerS4, S7S16,18,S19,S20 WindowManagerS2, S3, S6,S8S11, S14, S15, S16,S19 ProcessManagerS1, S3, S9, S10 S13, S16,S19

51. 50 © Bedir Tekinerdogan Cohesion Cohesive component performs only one concern/task Maximize cohesion within an architectural component required changes can be easily localized and will not propagate Synchronization Recovery Authentication Many concerns in one module Low Cohesion SynchronizationRecovery Authentication Each module addresses one concern High Cohesion

52. 51 © Bedir Tekinerdogan Coupling Two components are independent if they do not have interactions Highly coupled components have many dependencies/interactions Minimize coupling between architectural components reduces complexity of interactions reduces ‘ripple’ effect C1C3 C2 C1C3 C2

53. 52 © Bedir Tekinerdogan What to do if scenarios interact? Scenarios are all of the same class (cohesion). Scenarios are of different classes, and component can be subdivided. Scenarios are of different classes and component cannot easily be subdivided.

54. 53 © Bedir Tekinerdogan 5. Generate overall evaluation Reason about quality attributes State list of architectural problems Give hints/guidelines for improvements Refactor...

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

56. 55 © Bedir Tekinerdogan Different 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 Indirect Scenarios difficult to localize... affect multiple components (crosscut)

57. 56 © Bedir Tekinerdogan 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

58. 57 © Bedir Tekinerdogan The good and the bad... ComponentDirect Scenarios Indirect Scenarios EventManagerS3, S5S12,S13,S16, S17,S18,S19 ScreenManagerS4, S7S16,18,S19,S20 WindowManagerS2, S3, S6,S8S11, S14, S15, S16,S19 ProcessManagerS1, S3, S9, S10 S13, S16,S19 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 Indirect Scenarios Good or Bad

59. 58 © Bedir Tekinerdogan 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

60. 59 © Bedir Tekinerdogan ASAAM 1.Describe candidate architecture 2.Develop and prioritize scenarios 3.Individual scenario evaluation and aspect identification Direct Scenarios, Indirect Scenarios, Aspectual scenarios, Architectural aspects 4.Scenario interaction evaluation and component classification Cohesive component, tangled component, composite component, ill-defined component 5.Refactor architecture using conventional techniques (OO, patterns etc.) using aspect-oriented techniques

61. 60 © Bedir Tekinerdogan Heuristic rules for scenario evaluation R0: Develop SCENARIO artifacts based on PROBLEM DESCRIPTION Scenario R0 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 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 Scenarios

62. 61 © Bedir Tekinerdogan Extract Scenarios Brainstorming Session with different stakeholders Collect Scenarios of different stakeholders Workshop Look at domain Possible uses of system Risks Look at other systems Compare systems Experiences Reuse Scenarios Evaluate scenarios Select scenarios

63. 62 © Bedir Tekinerdogan Heuristic rules for scenario evaluation R1: IF SCENARIO does not require any changes to architectural description THEN 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 Scenario Direct Scenario Indirect Scenario R0 R1R2 R3

64. 63 © Bedir Tekinerdogan Direct and Indirect Scenarios 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 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 Indirect Scenarios Direct Scenarios > EventManager > WindowManager > ScreenManager > ProcessManager update screen communicates notifies

65. 64 © Bedir Tekinerdogan Heuristic rules for scenario evaluation 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 Scenario Direct Scenario Indirect Scenario Aspectual Scenario R0 R1R2 R3 R4R5

66. 65 © Bedir Tekinerdogan Aspectual Scenarios S11. Change look-and-feel style on run-time. S12. Add voice control S14. Provide dual display screen. S15. Use multiple desktops. S17. Provide touch screen and light pen as input S18. A memory overflow due to many opened windows S20. Minimize windows after idle time for each S13. A failure occurs and the system shuts down. S16. Monitor activities of the user S19. Port system to command-based operation system Indirect Scenarios 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 Aspectual Scenarios

67. 66 © Bedir Tekinerdogan Heuristic rules for scenario evaluation R6: Derive ARCHITECTURAL ASPECT from ASPECTUAL SCENARIO Scenario Direct Scenario Indirect Scenario Aspectual Scenario Architectural Aspect R0 R1R2 R3 R4R5 R6

68. 67 © Bedir Tekinerdogan Architectural Aspects S13. A failure occurs and the system shuts down. S16. Monitor activities of the user S19. Port system to command-based operation system Aspectual Scenarios Failure Management Logging Restarting Checkpointing Monitoring Operating System Aspect Architectural Aspects Domain Analysis

69. 68 © Bedir Tekinerdogan Heuristic Rules for Component Classification Component Direct Component Indirect Component R7 R8R9 R10 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 a SCENARIO THEN component is INDIRECT COMPONENT for SCENARIO R10 IF INDIRECT COMPONENT can be refactored to perform INDIRECT SCENARIO THEN INDIRECT COMPONENT is DIRECT COMPONENT

70. 69 © Bedir Tekinerdogan Direct and Indirect Components ComponentDirect for Scenarios Indirect for Scenarios EventManagerS3, S5, S8S12,S13,S16, S17,S18,S19 ScreenManagerS4, S7S16,18,S19,S20 WindowManagerS2, S3, S6,S8S11, S14, S15, S16,S19 ProcessManagerS1, S3, S9, S10 S13, S16,S19

71. 70 © Bedir Tekinerdogan Cohesive, Tentative Tangled or Composite Component R11 IF DIRECT COMPONENT performs semantically close scenarios THEN DIRECT COMPONENT is COHESIVE COMPONENT R12 IF DIRECT COMPONENT performs semantically distinct scenarios AND cannot be decomposed THEN DIRECT COMPONENT is TENTATIVE TANGLED COMPONENT R13 IF DIRECT COMPONENT performs semantically distinct scenarios AND can be decomposed THEN DIRECT COMPONENT is COMPOSITE COMPONENT Component Direct Component Indirect Component R7 R8R9 R10 Cohesive Component Tentative Tangled Component Composite Component R11 R12 R13

72. 71 © Bedir Tekinerdogan Cohesive, Tentative Tangled or Composite Component R14: IF INDIRECT COMPONENT includes semantically close scenarios THEN 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 Component Direct Component Indirect Component R7 R8R9 R10 Cohesive Component Tentative Tangled Component Composite Component R11R12 R13R14 R15 R16

73. 72 © Bedir Tekinerdogan Cohesive, Tentative Tangled or Composite Component ComponentCohesiveTent. TangledComposite EventManagerS3, S5S13,S16,S19S12,S17 ScreenManagerS14S13,S19S4,S7 WindowManagerS2,S3,S6, S8,S20 S16,S19S11,S18,S15 ProcessManagerS1,S9,S10S13,S16,S19

74. 73 © Bedir Tekinerdogan Tangled Component or Ill-Defined 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 Component Direct Component Indirect Component R7 R8R9 R10 Cohesive Component Tentative Tangled Component Composite Component R11R12 R13R14 R15 R16 Tangled Component Ill-Defined Component R17R18

75. 74 © Bedir Tekinerdogan Identified Aspects and Tangled Components ComponentCohesiveTangled (Aspect) CompositeIll-defined. EventManagerS3, S5S13,S16,S19S12,S17- ScreenManagerS14S13,S19S4,S7- WindowManagerS2,S3,S6, S8,S20 S16,S19S11,S18,S15- ProcessManagerS1,S9,S10S13,S16,S19- Aspects derived from scenarios S13, S16, S19: Failure Management, Monitoring, Operating System Portability

76. 75 © Bedir Tekinerdogan Aspectual Refactoring > EventManager > WindowManager > ScreenManager > ProcessManager update screen communicates notifies > EventManager > log() > checkpoint() > recover()

77. 76 © Bedir Tekinerdogan 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.