Modular Reasoning in Aspectoriented Languages Tim Molderez Ansymo

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 After every call to Bank. do*(…) , update the log kind (before/after/around) name pointcut (specifies a set of “join points”) class Logger { … after bank. Log: call(* Bank. do*(. . )) { log. write(stuff); body } … advice } * Not Aspect. J code; this is Contract. AJ 3

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

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

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 Bird bird = new Duck(); bird. fly(); What the developer sees: pre time What happens at runtime: pre’ Bird. fly post Duck. fly post’ 8

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 bank. do. Transfer(acc 1, acc 2, 50); What the developer sees: pre time What happens at runtime: pre’ Proceed: Bank. do. Transfer post Security. auth post’ Bank. do. Transfe r 10

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 pre post § After advice • Preconditions refer to the moment after the implicit proceed call. • Advice preconditions can rely on the postconditions of X. y Before advice Implicit proceed pre After advice post 13

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 Advice 1 Advice 2 Meta-advice Advice 3 Method 14

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? ASP violation: This postcondition is weaker than the postcondition of Bank. do* class Security { … @pre proc @post if(is. Logged. In()){proc}else{true} around auth: call(* Bank. do*(Account acc, . . )) { if(is. Logged. In(acc. get. Owner())) { proceed(acc); } } ASP violation cannot be prevented : … The advice’s very purpose is to block (the } postcondition of) Bank. do* when necessary. 16

Restoring modular reasoning with the @advised. By clause class Bank { @pre a 1. m >= m @post old(a 1. m)-m=a 1. m && old(a 2. m)+m=a 2. m @advised. By Security. auth, Transaction. commit void do. Transfer(Account a 1, Account a 2, int m) { … } • Explicitly expecting to be advised by … Security. auth and Transaction. commit } (in that order) • @advised. By added to all Bank. do* methods 17

Quantification § Doesn’t the act of adding all these @advised. By clauses cancel out the benefits of quantification? • Yes, if you like to add the clauses manually. • In Aspect. J: @advised. By annotations can be generated fully automatically. • In Contract. AJ: 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 an @advised. By clause is used. § The expectation @advised. By Authentication. auth could be filled in by e. g. Remote. Authentication. auth § Satisfies the open-closed principle 19

Effective specifications § Presence of an @advised. By 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 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 21

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 an @advised. By 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 § Aspect. J implementation: https: //github. com/timmolderez/adbc 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 (Z 3) by converting contracts to SMT-lib format § presuper && !presub should not have a solution 25

Frame conditions § Basic pre/postconditions and invariants don’t cut it to performal 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

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 principle • @advised. By clause § The approach is sound, and can be enforced both dynamically and statically. Modular reasoning in AOP is possible; there is a useful middle ground. 29