Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Modular Reasoning in Aspect-oriented Languages Tim Molderez Ansymo Antwerp Systems and Software Modelling."— Presentation transcript:

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

2 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

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

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

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

6 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

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

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

9 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

10 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

11 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

12 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

13 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

14 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

15 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.* 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

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

17 Restoring modular reasoning with the @advisedBy clause 17 class Bank { @pre a1.m >= m @post old(a1.m)-m=a1.m && old(a2.m)+m=a2.m @advisedBy 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 order) @advisedBy added to all* methods

18 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 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

19 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 an @advisedBy clause is used.  The expectation @advisedBy Authentication.auth could be filled in by e.g. RemoteAuthentication.auth  Satisfies the open-closed principle 19

20 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, 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

21 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

22 Effective specifications.. can be much simpler if none of the pointcuts have dynamic parts: (which is the more common case) 22

23 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 23

24 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

25 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

26 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 as @assignable clauses, which list only those variables that might change. 26

27 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

28 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

29 Summary  An approach to modular reasoning in AOP: Advice subsitution principle @advisedBy 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.

Download ppt "Modular Reasoning in Aspect-oriented Languages Tim Molderez Ansymo Antwerp Systems and Software Modelling."

Similar presentations

Ads by Google