Enhancing AOSD through Software Evolution Techniques for Improved Reusability and Adaptability

1. Cross-fertilisation betweenAOSD and software evolution Tom Mens http://w3.umh.ac.be/genlog Software Engineering Lab University of Mons-Hainaut Belgium

2. Challenges • Can we use formalisms, techniques, tools used in software evolution (and reverse engineering) research to improve the state-of-the-art in AOSD? Examples: graph transformation, description logics, dependency analysis, FCA, clustering, data mining, slicing, … • Can we use AOSD techniques to improve the state-of-the-art in MDE and software evolution? • How can we objectively measure the claimed merits of AOSD? • Is AOSD actually better then other paradigms in terms of reusability, adaptability, evolvability? • Need for empirical research and scientific validation

3. Challenge 1 • Can we use formalisms, techniques, tools used in software evolution research to improve the state-of-the-art in AOSD? • Example: My recent research • use of graph transformation and transformation dependency analysis in the context of • software refactoring • model inconsistency management • with Maja D’Hondt and Raghnild Van Der Streaten

4. Challenge 1 : Example • Suggestion: use transformation dependency analysis to analyse and reason about dependencies and interations between aspects • Determine whether different aspects are “conflicting” • Detect undesired or unexpected interactions between aspects • Determine the optimal ordering of aspect application • Some aspects may sequentially depend on other aspects • The order of applying aspects may be important and give rise to different behaviour • Optimise the aspect weaving process

5. Model inconsistency management Suggested process for UML inconsistency management Suggested approach • Use graph transformation theory and critical pair analysis inconsistencydetection rules inconsistencyresolution rules ? ? UMLmodel detectinconsistencies in UML model selectinconsistencies to be resolved chooseinconsistency resolution strategy applyinconsistency resolutions annotate model with inconsistencies found modify model by selected resolution rules (may give rise to new inconsistencies)

6. Model inconsistency management Step 1: Specify metamodel as type graph

7. Conflict description=“dangling operation reference” Model inconsistency management Step 2: Specify model as a graph Dangling operation reference using UML notation Dangling operation reference using graph notation CardReader readCard() ejectCard() State behaviour Class StateMachine name=“CardPresent” name=“CardReader” isAbstract=false source contains contains Region Transition contains target Operation Operation referredOperation State name=“ejectCard” name=“readCard” name=“RetainingCard” Operation name=“retainCard”

8. Model inconsistency management Step 3: Specify model inconsistencies as graph transformation rules

9. Model inconsistency management Step 4: Specify resolution rules as graph transformations

10. Model inconsistency management Step 5: Use critical pair analysis to detect mutually conflicting resolution rules

11. T1 G H1 T2 T2 H2 X X T1 Model inconsistency management Definition T1and T2 form a critical pair if • they can both be applied to the same initial graph G but • applying T1 prohibits application of T2 and/or vice versa

12. Model inconsistency management Example of a critical pair detecting a mutual conflict between distinct resolution rules

13. Model inconsistency management Step 6: Detect and analyse sequential dependencies between resolution rules

14. X T2 Model inconsistency management Definition T1and T2 form a sequential dependency if • given an initial graph G, T2 can be applied after T1 • but T2 cannot be directly applied to G T1 T2 G H1 H2 G

15. Model inconsistency management Example of a sequential dependency detected between distinct resolution rules

16. Model inconsistency management Step 6: Detect whether a resolution gives rise to new inconsistencies

17. Model inconsistency management Step 7: Detect potential cycles in the incremental inconsistency resolution process

18. Model inconsistency management • Step 8: Develop interactive tool support • Future work • Integrate into graph transformation tool • Integrate into modeling environment

19. QUESTIONS ? QUESTIONS ?

20. Challenge 2 • Can we use formalisms, techniques, tools used in AOSD research to improve the state-of-the-art in model-driven engineering? • Cf. “early aspects”, aspect modeling • Example: UML’s built-in extension mechanism

21. Challenge 2 : Example • Profiles: UML’s built-in extension mechanism UML class diagrams <<extends>> <<extends>> <<profile>> Java <<profile>> EJB <<apply>> <<extends>> <<apply>> <<profile>> AspectJ WebShopping <<apply>>

22. Challenge 2 : Example

23. Challenge 2 : Example • Profiles: UML’s built-in extension mechanism • Need support to • Determine whether two profiles are not mutually conflicting • Decide whether the order of applying multiple profiles is important