1 / 23

Cross-fertilisation between AOSD and software evolution

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

tad
Télécharger la présentation

Cross-fertilisation between AOSD and software evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related