A Parameterized Interpreter for Modeling Different AOP Mechanisms

1. ASE 200520th IEEE/ACM International Conference on Automated Software Engineering Long Beach, California, USA, November 7-11, 2005 A Parameterized Interpreter for Modeling Different AOP Mechanisms Naoyasu Ubayashi (Kyushu Institute of Technology, Japan) Genki Moriyama (Kyushu Institute of Technology, Japan) Hidehiko Masuhara (University of Tokyo, Japan) Tetsuo Tamai (University of Tokyo, Japan) November 10, 2005

2. Outline • Motivation • X-ASB: A parameterized interpreter • Modeling different AOP mechanisms • Discussion towards reflection for AOP • Related work • Conclusion

3. 1. Motivation

4. AOP Aspect-oriented programming (AOP) is a programming paradigm in which crosscutting concerns are modularized as aspects. • Logging • Error handling • Synchronization • Performance optimization

5. What is the essence of AOP ? Join Point Model ! A mechanism for modularizing crosscutting concerns • Join points • Means of identifying the join points • Means of raising effects at the join points pointcut (AspectJ) advice (AspectJ)

6. Example -- AspectJ-like JPM class FigureElement { Display display; } class Point extends FigureElement { int x, y; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; } void setY(int y) { this.y = y; } } class Line extends FigureElement { Point p1, p2; int getP1() { return p1; } int getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; } void setP2(Point p2) { this.p2 = p2; } } Display updating Pointcut after (FigureElement fe): (call(void set*(..)) && target(fe) { fe.display.update(fe); } advice

7. But, Current AOP languages … • Each of current AOP languages is based on a few fixed set of JPMs. • Many different JPMs have been proposed, and they are still evolving so that they better modularize various crosscutting concerns. need to explore common mechanisms in major JPMs !!

8. Three-part modeling framework A common structure in major four JPMs [Masuhara & Kiczales ECOOP2003]. • PA - pointcuts and advice (as in AspectJ) • TRAV - traversal specifications (as in Demeter, Northeastern Univ.) • COMPOSITOR - class merges (as in Hyper/J or CME, IBM) • OC - open classes (as in AspectJ inter-type declarations) visitor [TRAV] [COMPOSITOR] [OC] class A class B class A new fields new methods merge classes that crosscut each other insert crosscut concerns (fields/methods) to classes traverse an object tree (e.g. crosscutting concerns over AST)

9. Three-part modeling framework The framework models the process of weaving as a tuple of nine parameters. A B X XJP A AID AEFF B BID BEFF META BEFF AEFF BID AID Weave XJP X

10. Problem to be tackled • Although the three-part modeling framework identified a common structure among different AOP mechanisms, the commonality is given in an informal manner. • There has been no single model that captures all the different AOP mechanisms.

11. Our approach & contribution • We present a single model that captures different AOP mechanisms, in the form of a parameterized interpreter that takes several parameters to cover different JPMs including PA, TRAV, COMPOSITOR, and OC. • The interpreter will be helpful in rapid-prototyping a new AOP mechanism or a reflective AOP system that supports different mechanisms.

12. 2. X-ASB:A parameterized interpreter

13. X-ASB -- extensible ASB • Based on the three-part modeling framework. • Built on ASB (Aspect SandBox), a suite of interpreters written in Scheme. [C. Dutchyn et al.] • The interpreter consists of the core part and various sets of parameters. interpreter for PA TRAV COMPOSITOR OC param provide parameters param core part X-ASB

14. effect-b effect-a lookup-b lookup-a computation-at-jp XJP (define weave (lambda (pgm-a pgm-b) (register-jp) (eval-program pgm-a pgm-b))) (define eval-program (lambda (pgm-a pgm-b) ( <iterate the following steps - get the next program element - generate a join point - call computation-at-jp> ))) (define computation-at-jp (lambda (jp) <mediate the following> (effect-a (lookup-a jp)) (effect-b (lookup-b jp)))) ... other definitions Architecture weave (= interpreter) register-jp eval-program base (core part) parser common library

15. Parameters Coordination using a join point type Three-part model X-ASB parameters eval-program computation-at-jp X XJP A AID AEFF B BID BEFF META register-jp lookup-a effect-a lookup-b effect-b (included in register-jp) Registration of a join point type

16. 3. Modeling different AOP mechanisms

17. Interpreter construction steps • Step1: Design a join point type using the register-jpparameter. • Step2: Coordinate the computation at a join point using the computation-at-jp parameter. • Step3: Design a weaving process using the eval-program parameter in which the computation-at-jp is called.

18. Step1: Design a join point type Example: PA (define-struct (call-jp jp) mname target args) (define-struct jtype (jname generator)) (define register-jp (lambda () (register-one-jp 'call-jp (lambda (mname target args) (make-call-jp 'b-control-a lookup-methodexecute-method lookup-adviceexecute-advice mname target args))))) • lookup-a • effect-a • lookup-b • effect-b join point name META (computation-strategy) join point generator

19. effect-b effect-a lookup-b lookup-a computation-at-jp XJP Step2: Coordinate the computation at a join point Example: PA (define computation-at-jp (lambda (jp) (let* ((lookup-a (jp-lookup-a jp)) (effect-a (jp-effect-a jp)) (lookup-b (jp-lookup-b jp)) (effect-b (jp-effect-b jp))) (effect-b (lookup-b jp) jp (lambda () (effect-a (lookup-a jp) jp)))))) extract from a join point type • lookup-method • execute-method • lookup-advice • execute-advice coordinate the computation

20. Step3: Design a weaving process weaving process Example: PA (define eval-program ( <evaluate exps by calling eval-exp> ) (define eval-exp (lambda (exp env) (cond ((method-call-exp? exp) (call-method …) <other expressions> ))) (define call-method (lambda (mname obj args) (computation-at-jp (jtype-generator (lookup-jp 'call-jp)) mname obj args))) effect-b effect-a lookup-b lookup-a base (parser) call computation-at-jp XJP effect-b effect-a override parser lookup-b lookup-a call computation-at-jp XJP

21. Design of the four JPMs PA TRAV OC COMPOSITOR

22. What is the essence of modeling AOP mechanisms ? It is important for JPM developers to make the following design decisions: • What kinds of join points are needed? • What kinds of coordination should be defined at the join points?

23. LOC for developing each JPM Part PA TRAV COM. OC 1. register-jp 81 36 16 32 2. computation-at-jp 9 16 5 11 3. eval-program 64 131 238 28 4. base 537 537 537 537 A: sum of 1 – 3 154 183 259 71 B: sum of 1 – 4 691 720 796 608 A / B (%) 22.3 25.4 32.5 11.7 • We have only to add 10 - 30 % new code to develop a new JPM. • However, it is not necessarily easy to design the eval-program parameter.

24. LOC for extending PA field-set join point field-get join point Part original PA add fset-jp add fget-jp 1. register-jp 81 44 38 2. computation-at-jp 9 (reused) (reused) 3. eval-program 64 4 4 sum of 1 – 3 A:154 B:48 B:42 B / (A+B) (%) 23.8 20.8 • We have only to add about 20 % new code to add a new kind of join point. • It is easy to extend an existing JPM.

25. 4. Discussion Towards reflection for AOP

26. Software evolution in AOP AOP is effective in unanticipated software evolution because crosscutting concerns can be added or removed without making invasive modifications tooriginal programs. crosscutting concerns added concern space removed core concerns core concerns core concerns evolution

27. But, … Software evolution would be restricted if newcrosscutting concerns cannot be described with the existing JPMs. new type of crosscutting concerns cannot be added crosscutting concerns concern space core concerns core concerns core concerns evolution

28. Evolution of JPMs Evolution by language developers The effectiveness in software evolution would be restricted if language developers must extend JPMs whenever application programmers need new kinds of JPMs. Meta level (implementation of JPM) reify Reflection for AOP MOPs for JPM extensions Base level (program based on JPM) reflect Evolution by application developers It would be better for application programmers to be able to add new JPMs using MOPs within the base language.

29. From our experience • It is relatively easy to design the register-jp parameter and the computation-at-jp parameter. • It is not easy to design the eval-program parameter Reflection for AOP should be limited to adding new kinds of join point types and computation strategies.

30. Metaobject protocols for AOP JPM design layer Layer Purpose Parameters level 1 introduction eval-program of new JPMs computation-at-jp register-jp level 2 extension computation-at-jp of existing JPMs register-jp extend computation-at-jp register-one-strategy lookup-strategy MOP reflection for AOP register-one-jp lookup-jp extract-jp register-one-pcd lookup-pcd extract-ptc extend register-jp

31. 5. Related Work

32. Related Work • Versatile AOP kernel [E.Tanter et al., 2005] • XAspect [M.Shonle et al., 2003] • CME [IBM] • Josh [S.Chiba and K.Nakagawa, 2004] • abc: AspectBench Compiler [P.Avgustinov et al., 2005]

33. 6. Conclusion

34. Conclusion • We proposed the parameterized interpreter X-ASB for modeling different JPMs. • X-ASB will be helpful in rapid-prototyping a new AOP mechanism or a reflective AOP system that supports multiple JPMs. • X-ASB guides language developers in modular JPM designs.