1 / 23

An AOP Implementation Framework for Extending Join Point Models

ECOOP 2004 Workshop on Reflection, AOP and Meta-Data for Software Evolution. RAM-SE’04. An AOP Implementation Framework for Extending Join Point Models. Naoyasu Ubayashi (Kyushu Institute of Technology, Japan) Hidehiko Masuhara (University of Tokyo, Japan)

brock-diaz
Télécharger la présentation

An AOP Implementation Framework for Extending Join Point Models

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. ECOOP 2004 Workshop on Reflection, AOP and Meta-Data for Software Evolution RAM-SE’04 An AOP Implementation Framework for Extending Join Point Models Naoyasu Ubayashi (Kyushu Institute of Technology, Japan) Hidehiko Masuhara (University of Tokyo, Japan) Tetsuo Tamai (University of Tokyo, Japan) June 15, 2004

  2. Overview • Motivation -- Join Point Model evolution • MOPs for Join Point Model extensions • Towards reflection for AOP • Related work • Conclusion

  3. 1. Motivation

  4. 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

  5. But, … Software evolution would be restricted if newcrosscutting concerns cannot be described with the existing JPMs (join point models). new type of crosscutting concerns cannot be added crosscutting concerns concern space core concerns core concerns core concerns evolution

  6. JPM --- Essence of AOP • Join points • Means of identifying the join points (pointcut) • Means of raising effects at the join points (advice)

  7. When do we need new kinds of JPMs? • We want to extend the existing JPMs slightly in order to adapt to application-specific purposes. • We want to use more than one JPM simultaneously.

  8. Motivating example Version 1 AspectJ JPM aspect ProtocolCheck { pointcut someProtocol(): call(void *.someMethod*()) ; before() : someProtocol() { code for logging } } classA classC classB aspect ProtocolCheck someMethodA() someMethodC() someMethodB()

  9. Motivating example (cont.) Version 2 AspectJ JPM aspect ProtocolCheck { pointcut someProtocol(): call(void *.someMethod*()) ; before() : someProtocol() { code for logging } pointcut someProtocolError(): !calling-sequence(void *.{someMethodA(), someMethodB(), someMethodC()}) ; before() : someProtocolError() { code for error handling } } But, we cannot add a new pointcut because we cannot extend AspectJ JPM. classA classC classB aspect ProtocolCheck someMethodA() someMethodC() someMethodB() we want to add a checking for calling sequence (someMethodA -> someMethodB -> someMethodC)

  10. 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. • There are crosscutting concerns that may not be modularized with current JPMs.

  11. Our research Goal: Computational Reflection for AOP Meta level (implementation of JPM) reify MOPs for JPM extensions reflect Base level (program based on JPM) This talk focuses on MOPs for JPM extensions(our initial result). We developed X-ASB (eXtensible Aspect Sand Box) , a framework for rapid-prototyping new JPMs.

  12. 2. MOPs for Join Point Model extensions

  13. EFFB - means ofeffecting B - program EFFA IDB IDA- means ofidentifying META -weavingparameter X - computation or program XJP- join point MOPs for JPM extensions MOP AOP Language Model eval-program [Program execution model] policy of program execution (AspectJ-like policy, traversal policy, etc.) [Join point model] join point pointcut (evaluator for selecting join point) advice (computation at a join point) register-jp register-pcd lookup-A-ID lookup-B-ID effect-A A-ID effect-B B-ID Masuhara & Kiczales model [ECOOP 2003] <X, XJP, A, AID, AEFF, B, BID, BEFF, META>

  14. Steps for modular weaver construction • Step 1: define kinds of join points • Step 2: define kinds of pointcuts • Step 3: define a body of weaver, and computation at join points

  15. Construction of AspectJ-like weaver Weaver [written in Scheme] (define weaver (lambda (pgm meta) (register-jp) (register-pcd) (eval-program pgm meta))) MOPs eval-program program execution tree register-jp Step 3: define a body of weaver, and computation at join points (define call-method (lambda (mname obj args) (computation-at-jp ((lookup-jp-generator 'call-method) mname obj args) null))) (define computation-at-jp (lambda (jp param) (let* ((A-ID (lookup-A-ID jp param)) (B-ID (lookup-B-ID jp param))) (effect-B B-ID jp (lambda () (effect-A A-ID jp param)) param)))) Step 1: define kinds of join points (define register-jp (lambda () (register-one-jp 'call-method generate-call-jp))) Step 2: define kinds of pointcuts (define register-pcd (lambda () (register-one-pcd 'call call-pcd?))) register-pcd lookup-A-ID call-method join point lookup-B-ID effect-A effect-B weaver

  16. Extension of AspectJ-like weaver MOPs A new pointcut designator (calling-sequence) can be added to AspectJ-like weaver eval-program program execution tree register-jp (define register-pcd (lambda () (register-one-pcd 'calling-sequence calling-sequence-pcd?))) register-pcd lookup-A-ID call-method join point lookup-B-ID effect-A effect-B weaver

  17. 3. Towards reflection for AOP

  18. 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. Reflection for AOP Evolution by application developers It would be better for application programmers to be able to add new JPMs using MOPs within the base language.

  19. Reflection in X-ASB Scheme-based language Base level (class sample-protocol-error-detection object (method int m1 () (...)) (method int m2 () (...)) (method int m2 () (...)) (after (calling-sequence (not (list 'm1 'm2 'm3))) (write 'invalid-calling-sequence) (newline))) Meta level (class sample-calling-sequence object (method void register-pcd () (meta register-one-pcd 'calling-sequence 'calling-sequence-pcd?) (super register-pcd)) (method boolean calling-sequence-pcd? ...)) ---power of reflection is still limited

  20. 4. Related Work

  21. Related Work • XAspect [Shonle, Lieberherr, and Shah, 2003]: extensible domain-specific AOP language that adopts plug-in mechanisms. Adding a new plug-in module, we can use a new kind of aspect-oriented facility. • Josh [Chiba and Nakagawa, 2004]: open weaver that can define a new pointcut construct as a boolean function. Using X-ASB, we can add not only new pointcut constructs but also new kinds of join points and advice.

  22. 5. Conclusion

  23. Conclusion • We proposed mechanisms for extending JPMs in order to support unanticipated software evolution. • Using X-ASB, we can introduce new kinds of JPMs when we face new kinds of crosscutting concerns that cannot be handled by existing JPMs.

More Related