Modular Reasoning in Aspect-oriented Languages Tim Molderez Ansymo Antwerp Systems and Software Modelling

Aspect-oriented programming (AOP)  Typically extension of object-oriented language  Aims to improve separation of concerns by modularizing crosscutting concerns  Crosscutting concerns: Scattered in several places Tangled with other concerns Examples: logging, authentication, caching, profiling, … 2

A (stereo)typical example: logging 3 class Logger { … after bankLog: call(* Bank.do*(..)) { log.write(stuff); } … } advice pointcut (specifies a set of “join points”) kind (before/after/around) name body After every call to Bank.do*(…), update the log * Not AspectJ code; this is ContractAJ

Another example: authentication 4 class Security{ … around auth: call(* Bank.do*(Account acc,..)) { if(isLoggedIn(acc.getOwner())) { proceed(acc); } … } calls Bank.do* Execute advice instead of Bank.do*

AOP and obliviousness  Obliviousness: Advice is executed implicitly 5 I’m calling silver bullet! With AOP, we can implement crosscutting concerns independent of everything else! AOP considered harmful! An advice could break my existing code at any time! Chill out you guys! There’s a middle ground here.

Modular reasoning  The ability to reason about a module’s behaviour, considering only the module itself (and anything it explicitly refers to)  In imperative languages: no surprises…  In OOP: All classes must be behavioral subtypes (LSP)  … but what about AOP? 6

Modular reasoning  To benefit from obliviousness, advice may not cause any surprising behaviour. 7

Modular reasoning in OOP 8 Bird.fly pre post Duck.fly pre’ post’ Bird bird = new Duck(); bird.fly(); What the developer sees:What happens at runtime: time

Modular reasoning in OOP  To avoid surprising behaviour, the Liskov substitution principle should be respected.  All classes should be behavioural subtypes: Precondition may not be strengthened Postcondition may not be weakened Invariants must be preserved 9

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

Modular reasoning in AOP  Similar to OOP, if all advice are seen as around advice: An advice effectively substitutes for whatever it advises.  Advice substitution principle (ASP): Advice’s precondition may not be stronger than the precondition of the advised join point Postcondition may not be weakened Invariant must be preserved 11

So.. that’s all there is to it?  Yes*  *.. well, there are some big buts (and I cannot lie) Before and after advice Higher-order advice Multiple advice sharing join points Quantification Call and execution pointcuts What if you can’t satisfy the advice substitution principle?  Quantification  Call and execution pointcuts  Before and after advice …… 12

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 13 Before advice Implicit proceed pre post Implicit proceed After advice pre post

Special cases  Principle also applies if: Multiple advice share join points Advice intercept advice executions  Example Advice 1,2 and 3 only need to comply with Method’s contracts Meta-advice complies with Advice 3’s contracts 14 Advice 1 Advice 2 Meta-advice Advice 3 Method

Quantification  ASP defined in terms of a single join point  However, pointcuts are a quantification mechanism and can match with many different join points An advice may need to comply with many different contracts (e.g. Bank.do* can match with several methods..) Complying with the ASP becomes more difficult as the number of contracts grows Scaling problem can be mitigated using contract enforcement tools, as well as using definitions of observers/spectators 15

What if you can’t satisfy the ASP? 16 class Security { if(isLoggedIn()){proc}else{true} around auth: call(* Bank.do*(Account acc,..)) { if(isLoggedIn(acc.getOwner())) { proceed(acc); } … } ASP violation: This postcondition is weaker than the postcondition of Bank.do* ASP violation cannot be prevented : The advice’s very purpose is to block (the postcondition of) Bank.do* when necessary.

Restoring modular reasoning with clause 17 class Bank a1.m >= old(a1.m)-m=a1.m && Security.auth, Transaction.commit void doTransfer(Account a1, Account a2, int m) { … } … } Explicitly expecting to be advised by Security.auth and Transaction.commit (in that added to all Bank.do* methods

Quantification  Doesn’t the act of adding all clauses cancel out the benefits of quantification? Yes, if you like to add the clauses manually. In annotations can be generated fully automatically. In ContractAJ: You can easily introduce a quantification mechanism to add clauses in the right places.  Sidenote: It goes to show that programming concerns more than just the language; the tools around it can be a crucial component too. 18

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

Effective specifications  Presence of clause Makes callers aware of the listed advice Effectively changes the pre/postconditions that must be taken into account when calling the method, aka the “effective pre/postconditions” Likewise, listed advice become aware of each other too, as the effective pre/postcondition of proceed calls changes too  Intuition behind effective pre/postcondition: Pre/postcondition of the first advice that will be executed, as far as you can tell statically 20

Effective specifications 21 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

Effective specifications.. can be much simpler if none of the pointcuts have dynamic parts: (which is the more common case) 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 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 23

Dynamic enforcement  Contract enforcement advice check all contracts at runtime and throw an exception when the approach is not satisfied.  Simple, but not exhaustive  AspectJ implementation: 24

Static enforcement  Work in progress (see Luis’s internship & thesis)  Core problem: Determine whether one contract is weaker/stronger than another  Can be done with an SMT solver (Z3) by converting contracts to SMT-lib format  pre super && !pre sub should not have a solution 25

Frame conditions  Basic pre/postconditions and invariants don’t cut it to perform formal verification.  Frame conditions: Aside from what a body will do, it should also be specified what the body will not do.  Typically defined clauses, which list only those variables that might change. 26

Inferring frame conditions  Built on top of Ekeko and Soot  Flow-sensitive: Traverse CFG of each body, keeping track of aliases and modifications  Path-insensitive: Information is merged when if/while branches join  Incremental: Only update what’s necessary  Modular: Okay to assume modular reasoning 27

Frame conditions in AOP  Frame conditions can be used for multiple purposes Detect which fields an ASP-compliant advice is allowed to modify Detect which properties a proceed call can preserve Detect which advice can be executed concurrent to the body being advised 28

Summary  An approach to modular reasoning in AOP: Advice subsitution clause  The approach is sound, and can be enforced both dynamically and statically. 29 Modular reasoning in AOP is possible; there is a useful middle ground.