1 / 26

Proving Aspect-Oriented Programming Laws for Deriving Refactorings

This study focuses on proving the aspect-oriented programming laws for deriving complex refactorings, using a bi-directional transformation approach. The study also introduces the AspectJ laws and defines an equivalence notion for aspect-oriented programs. The effectiveness of the laws is evaluated through a comparison of the evaluation trees.

rieth
Download Presentation

Proving Aspect-Oriented Programming Laws for Deriving Refactorings

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. Informatics Center Federal University of Pernambuco Brazil Proving aspect-oriented programming laws Leonardo Cole Paulo Borba Alexandre Mota (lcn,phmb,acm@cin.ufpe.br)

  2. Deriving Refactorings • Primitive laws of programming • simple, localized, intuitive and easier to understand • Two transformations • Bi-directional • Guarded by pre-conditions • We compose the laws to • Derive complex and global refactorings • Verify that an existingrefactoring preserves behaviour

  3. ts privileged aspectA { pcs as } ts aspectA { pcs as } = () Advice bodies from as do not refer to private members declared in ts. Make Aspect Privileged

  4. Problem • Current definition relies on the simplicity and intuition of the laws It is necessary to formallyprove the laws to increase the confidence that they preserve behaviour

  5. Solution • Aspect-oriented semantics for Method Call Interception (MCI) • Equivalence notion for aspect-oriented programs

  6. Outline • AspectJ Laws • MCI • Equivalence Notion • Add Before Execution Law • Conclusions

  7. ts classC { fs ms Tm(ps) { body } } paspect A { ... before(context) : exec(C.m) && bind(context) { body’ } ... } ts classC { fs ms Tm(ps) { body’; body } } paspectA { ... } = Add before-execution () body’ does not declare or use local variables; body’ does not call super; …

  8. Example publicclass Account { privatedouble balance; ... public void debit(double amount) { Access.check(new Permission(…)); //debit logic } ... } publicaspectPermissionAspect{ }

  9. Applying Add Before-Execution Law publicclass Account { privatedouble balance; ... public void debit(double amount) { //debit logic } ... } privilegedaspect PermissionAspect { before(Account cthis, double amount): execution(void Account.debit(double) && this(cthis) && args(amount) { Access.check(new Permission(…)); } }

  10. Summary of laws

  11. Method Call Interception - MCI • Operational semantics • Extends an object-oriented language to introduce aspect-oriented features • Superimpose construct • On dispatch • On enter • On exit

  12. Domain: Object-Store

  13. O2Call Rule

  14. MCI Call Rule

  15. Equivalence Notion • We compare field values (heaps) resulting from the two program’s execution • Strong notion (equal heaps) • Same number of objects • Same number of fields • Simplest notion to our objective • The laws do not change program’s data structure First component of the object-store must be equal for both programs

  16. Mapping AspectJ to MCI • Before-call x On dispatch • Before-execution x On enter • After-execution x On exit • args, this and target • Aspect x Main method

  17. ts classC { fs ms Tm(ps) { body } } classM { voidmain() { superimposebody’ onenter classC&& methodm&& argumentps; sis; mainBody } } ts classC { fs ms Tm(ps) { body’; body } } classM { voidmain() { sis; mainBody } } = MCI Add Before Execution

  18. Evaluation Tree: Left

  19. Evaluation Tree: Right

  20. Comparing Trees Circled nodes may update object-store

  21. Comparing • Circled nodes are syntactically equal in both sides • The order of execution is the same • Pre-conditions not necessary for the MCI law

  22. Other Laws • Add before-call • Add after-execution returning • Merge advices • Remove target parameter • Remove this parameter

  23. Conclusions • Increase confidence that aspect-oriented programming laws preserve behaviour • Equivalence notion for aspect-oriented programs • Formal argumentation about the soundness of some laws

  24. Conclusions • Static semantics not considered • Formal proof using induction • Prove the remaining laws • Extend MCI • Choose another semantics

  25. Informatics Center Federal University of Pernambuco Brazil Proving aspect-oriented programming laws Leonardo Cole Paulo Borba Alexandre Mota (lcn,phmb,acm@cin.ufpe.br) Software Productivity Group http://www.cin.ufpe.br/spg

  26. Comparing Trees

More Related