1. Modular Reasoning in Aspect-oriented Languages Tim Molderez Promotor: prof. dr. Dirk Janssens Ansymo Antwerp Systems and Software Modelling

2. Painting the big picture  Software can get quite big and complex  How to keep software manageable?  Software tends to change  How to keep software flexible? 2

3. How to keep it manageable?: Divide and conquer 3 a class

4. Flexibility in the real world  Subcontractors can substitute for contractors  The client shouldn’t care who gets the job done  That is, as long as the job gets done right, according to the contract! The subcontractor cannot require more than the contractor The subcontractor cannot promise less than the contractor 4

5. Flexibility in software  There are classes and subclasses  Subclasses can substitute for classes  The client of a class shouldn’t have to care  Each class has its own contracts what it requires (preconditions) and what it ensures (postconditions)  Behavioural subtyping: A subclass cannot require more than a class A subclass cannot promise less than a class 5

6. Aspect-oriented programming  Some functionality is difficult to separate in classes Spread across several places in the code Tangled with other functionality Examples: security, transaction management, …  Unless we have aspects An aspect is (like) a class, but is allowed to implicitly intervene with multiple other classes Normally, classes make use of other classes by explicitly calling them 6

7. Modular reasoning in aspect-oriented languages  Modular reasoning (about calls): If the preconditions that you expect are satisfied, you will get the postconditions that you expect (even if aspects can intervene)  Question is: How to enable modular reasoning in aspect-oriented languages? 7

8. Contributions  ContractAJ: a minimal aspect-oriented language  A two-part approach for modular reasoning  Proof that the approach is sound  Dynamic & static tools to check the approach  Frame inference analysis  Comparing frames in aspects and advised classes 8

9. 9 Switching to English

10. ContractAJ example 10 class Bank { int getBalance(Account acc) { return acc.amount; } void doDeposit(Account to, int m) { to.amount += m; } void doTransfer(Account from, Account to, int m){ from.amount -= m; to.amount += m; } }

11. Once more, with contracts 11 class Bank { … @requires from.amount >= m @ensures from.amount == \old(from.amount) – m @ensures to.amount == \old(to.amount) + m void doTransfer(Account from, Account to, int m){ from.amount -= m; to.amount += m; } }

12. A (stereo)typical example of an aspect 12 class Logger { after bankLog: call (* Bank.do*(..)) { log.write(…); } … } pointcut (specifies a set of points in time, aka “join points”) advice kind advice name advice body advice

13. Another aspect: authentication 13 class Security{ … around auth: call (* Bank.do*(Account a,..)) { if(isLoggedIn(a.owner)) { proceed(a); } … } now call Bank.do* run this advice instead of Bank.do*

14. Modular reasoning in aspect-oriented languages  Two-part approach  Key observation: Around advice are a lot like the contractor-subcontractor story 14

15. Modular reasoning in AOP 15 Bank.doTransfer pre post Security.auth Proceed: What the developer sees:What actually happens: time bank.doTransfer(acc1,acc2,50); Bank.doTransfer pre post pre’ post’

16. The advice substitution principle  Around advice Cannot require more than the method (or advice) it is replacing Cannot promise less than the method (or advice) it is replacing  An advice may replace multiple methods (or advice)! 16

17. Before and after advice  Before advice Slightly different than around advice: postconditions refer to the moment before the implicit proceed call, instead of after. Advice postconditions may not invalidate the preconditions of X.y  After advice Preconditions refer to the moment after the implicit proceed call. Advice preconditions can rely on the postconditions of X.y 17 Before advice Bank.doTransfer (implicit) pre’ post’ Bank.doTransfer (implicit) After advice pre’ post’

18. Special cases  Principle also applies if: Multiple advice share join points Advice intercept advice executions (higher-order advice) 18 Logger.log Profiler.measure TransacMgmt. perform Bank. doTransfer

19. If you can’t satisfy the advice subst. principle 19 class Security { … @requires proc @ensures if(isLoggedIn()){proc}else{true} around auth: call(* Bank.do*(Account acc,..)) { if(isLoggedIn(acc.getOwner())) { proceed(acc); } … }

20. Restoring modular reasoning with the @advisedBy clause 20 class Bank { @requires a1.m >= m @ensures old(a1.m)-m=a1.m && old(a2.m)+m=a2.m @advisedBy Security.auth void doTransfer(Account a1, Account a2, int m) { … } … }

21. Effective specifications  Presence of an @advisedBy clause Makes callers aware of the listed advice Effectively changes the pre/postconditions that must be taken into account when calling the method Listed advice become aware of each other too Dynamic conditions included in the effective specification 21

22. Soundness  Modular reasoning is guaranteed (for pre-and postconditions) if: All bodies correctly implement their own specifications (, but they can assume modular reasoning). All classes are behavioural subtypes. All advice satisfy either the ASP, or are correctly mentioned in an @advisedBy clause. ASP-compliant advice have a lower precedence than the others.  Proof by induction on reduction length Consider all possible ways a body can be reached from a method/proceed call 22

23. Dynamic enforcement  Contract enforcement advice check all contracts at runtime and produce an error when the approach is not satisfied.  Simple, but not exhaustive  AspectJ implementation (available on Github)Github 23

24. Static enforcement  Exhaustive, but only checks whether the specifications satisfy the approach  Core problem: Determine whether one contract is weaker/stronger than another  SMT solver is used to test pre meth && !pre adv  AspectJ implementation (available on Github, thanks to Luis Mayorga!)Github 24

25. Frame conditions  Frame conditions: Aside from what a body will change, it should also be specified what the body will not change  Typically specified by listing only those variables that might change 25

26. Frame conditions and aspects  Advice in @advisedBy clause: No issues here  And advice that satisfy the adv. subst. principle? How often does it happen that an advice needs to modify more? 26

27. Frame inference analysis  Writing frame conditions manually is tedious and error-prone  Compositional  Keeps track of what may/must be modified  Implemented for Java/AspectJ, using Ekeko & Soot (available on Github)Github 27

28. How often does an advice need to modify more?  Not very often, in these cases  Perhaps no need to take drastic measures to restore modular reasoning 28 NameAdviceASPBad ASP AJHSQLDB1065512 AJHotDraw474313 Healthwatcher73643 MobileMedia77545 SpaceWar13110 Telestrada46220

29. The future 29  Modular reasoning about pointcuts  A larger data set of aspect-oriented programs  Beyond AspectJ; finding the essence of aspects

30. Summary 30 The end  Modular reasoning with aspects To remain unaware of advice: Use the ASP To become aware of advice: Use @advisedBy  The approach is sound  It can be tested dynamically and statically  Frames can be inferred  Take-away: Aspects are powerful, but they can be wielded responsibly

31. Overriding advice  Overriding only has purpose when you expect one thing, but another thing is executed.  Nobody expects the execution of advice.. unless an @advisedBy clause is used.  The expectation @advisedBy Authentication.auth could be filled in by e.g. RemoteAuthentication.auth  Satisfies the open-closed principle 31

32. Effective specifications 32 Find the next advice that will be executed; dynamic parts of pointcuts become part of the specification! Fill in each occurrence of the proc keyword (with the next advice) Before/after advice must include implicit proceed call

33. Quantification  Doesn’t the act of adding all these @advisedBy clauses cancel out the benefits of quantification? Yes, if you like to add the clauses manually In AspectJ: @advisedBy annotations can be generated automatically. In ContractAJ: You can easily introduce a quantification mechanism to add clauses in the right places 33

34. Aliasing diagrams 34