• 230 likes • 310 Views
Cross-fertilisation between AOSD and software evolution. Tom Mens. http://w3.umh.ac.be/genlog Software Engineering Lab University of Mons-Hainaut Belgium. Challenges.
E N D
Cross-fertilisation betweenAOSD and software evolution Tom Mens http://w3.umh.ac.be/genlog Software Engineering Lab University of Mons-Hainaut Belgium
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
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
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
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)
Model inconsistency management Step 1: Specify metamodel as type graph
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”
Model inconsistency management Step 3: Specify model inconsistencies as graph transformation rules
Model inconsistency management Step 4: Specify resolution rules as graph transformations
Model inconsistency management Step 5: Use critical pair analysis to detect mutually conflicting resolution rules
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
Model inconsistency management Example of a critical pair detecting a mutual conflict between distinct resolution rules
Model inconsistency management Step 6: Detect and analyse sequential dependencies between resolution rules
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
Model inconsistency management Example of a sequential dependency detected between distinct resolution rules
Model inconsistency management Step 6: Detect whether a resolution gives rise to new inconsistencies
Model inconsistency management Step 7: Detect potential cycles in the incremental inconsistency resolution process
Model inconsistency management • Step 8: Develop interactive tool support • Future work • Integrate into graph transformation tool • Integrate into modeling environment
QUESTIONS ? QUESTIONS ?
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
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>>
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