Proving Aspect-Oriented Programming Laws for Deriving Refactorings

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