Model-based Aspect Weaver Construction

1. Model-based Aspect Weaver Construction Suman Roychoudhury Frédéric Jouault Jeff Gray {roychous, jouault, gray} @ cis.uab.edu This project is supported by NSF CAREER award (CCF-0643725) and the OpenEmbeDD project

2. Background - PT based Aspect Weaver • Modified Source Program = fweave (Source Program, Aspect Program) • Using a Program Transformation Engine, one can write an Aspect Program in terms of rewrite rules Example RSL rule: rule insert_trace_probe(stmts:statement_seq): function_body -> function_body = " { \stmts } " -> " { printf("Entering Method…");\stmts }".

3. Motivation Case Study: A Delphi Weaver * Progress Meter Updating • Inc(TotalInserts); • As several evolution tasks (e.g., deleting database triggers, compiling new stored procedures) were executed in the DB Schema manager utility, the processing dialog meter was required to be updated accordingly (appeared in 62 different places in Schema manager utility) * Gray J, and Roychoudhury S, “A Technique for Constructing Aspect Weavers using a Program Transformation Engine,” AOSD ’04, International Conference on Aspect-Oriented Software Development, Lancaster, UK, March 2004, pp. 36-45.

4. RSL Implementation of the Case Study(Rule based aspect weaving) The above rule is written in RSL which is the rewrite language in the DMS program transformation engine

5. Challenges using PT Engines • The rewrite rules used to modify base programs are difficult to compose, which makes it accessible to only language researchers (accidental complexities) • The transformation rules are generally hard to comprehend by average software developers (need to know about the grammar) • The entire weaver is rendered unusable if the base transformation engine is replaced with another one (interoperability problem) • The PT engine may be proprietary, i.e., may not be available for use by all desired parties (e.g., DMS)

6. An Aspect Specification Front-enddecoupled from PT engine Source Aspect Specification for Progress Meter Dialog

7. Model-based Front-end Construction RSL Metamodel Aspect Metamodel • Aspect Specification conforming to an Aspect Metamodel • Rules Specification conforming to a Rules Metamodel • Translation between aspect specification to rules specification is realized using ATL transformations (model transformation language)

8. Source Aspect Metamodel KM3 specification (in AMMA) Ecore metamodel as rendered in Eclipse Modeling Editor

9. Target RSL Metamodel KM3 specification (in AMMA) Ecore metamodel as rendered in Eclipse Modeling Editor

10. ATL Transformations rule AfterAdvice2Pattern { from s : Aspect!AfterAdvice to t : Rsl!Pattern ( ptoken <-'statement_list', ptext <- s.advStmt.stmt ... ), ... } rule Aspect2Rsl { from s: Aspect!Aspect to t: Rsl!Rsl ( domain <- s.domain, pattern <- s.advice, rule <- s.pointcut, ruleset <- rs ), rs: Rsl!RuleSet ( rsname <- s.aname, rname <- s.pointcut-> collect(e|e).pctname), … } Core transformation library : call, exec, set, get, cflow, etc. (i.e., one transformation for each type of pointcut) • The transformations generate the corresponding RSL rule • for the given aspect

11. Transformation Overview Model-Driven Engineering (MDE) Technical Space (TS) Grammarware TS Grammarware TS M3 EBNF EBNF KM3 Aspect.gGrammar Aspect Metamodel RSL Metamodel RSL.g Grammar M2 Myaspect.ap AspectPascal Myaspect Model MyRsl Model MyRsl.rsl RSL program M1 Extraction Aspect2RSL Transformation Injection • The megamodel showing the complete scenario how source aspect specification gets translated to target RSL specification using ATL transformation M1 = terminal model level; M2 = metamodel level; M3 = meta-metamodel level (demo: http://localhost:6885/gaspect )

12. Primary Benefits • Since the rewrite rules are automatically generated (instead of manual coding) from the aspect specification, one need not be aware of the accidental complexities associated with them • Also by decoupling the source aspect model from the target RSL model : • The source aspect model need not be altered even if the target is replaced with a different PT engine (e.g., the rewrite engine used by ASF+SDF) • Conversely, for every new language, one needs to add the appropriate metamodel extensions to the base aspect metamodel, but no change to the target metamodel is needed • Another advantage is that both the aspect language (source) and rules language (target) can evolve independent of each other which leads to new features being added to the weaver

13. Future directions: Core Aspect Metamodel for OOL Aspect Metamodel for Fortran Delphi Java Fortran 2003 Fortran 77 Fortran 90 Java 1.4 Java 1.5 • Towards Generic Aspect Weaver Construction: • Extending the Aspect Metamodel (via Metamodel Extension) to support multiple languages • Extending ATL Transformations (e.g., using rule inheritance, module superimposition) • By adapting this technique we may also construct aspect weavers for domain-specific languages

14. Concluding Remarks - Summary • The majority of research in this area mainly focuses on how aspects can be applied to MDE. This research illustrates how MDE can also assist in building aspect weavers • The main advantage of this approach is the ability to modularize the weaver construction process by decoupling the source aspect language metamodel from the target PTE metamodel • The source aspect metamodel need not be altered even if the target is replaced with a different PT engine • Conversely, for every new language, we need to add the appropriate metamodel extensions to the base aspect metamodel, but no change to the target metamodel is needed (as part of future work) • Nevertheless, one can still leverage the power of program transformation engines (avoid the associated accidental complexities ) to build weavers that are easy to modularize, evolve and maintain

15. Questions ? http://www.cis.uab.edu/softcom/GenAWeave/