Modular Reasoning in Aspectoriented Languages Tim Molderez Promotor

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

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

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

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

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

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

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

Contributions § Contract. AJ: 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

Switching to English 9

Contract. AJ example class Bank { int get. Balance(Account acc) { return acc. amount; } void do. Deposit(Account to, int m) { to. amount += m; } void do. Transfer(Account from, Account to, int m){ from. amount -= m; to. amount += m; } } 10

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

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

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

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

Modular reasoning in AOP bank. do. Transfer(acc 1, acc 2, 50); What the developer sees: What actually happens: pre’ pre time pre Bank. do. Transfer post Security. auth Proceed: Bank. do. Transfer post’ 15

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

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 pre’ Before advice Bank. do. Transfer (implicit) After advice post’ 17

Special cases § Principle also applies if: • Multiple advice share join points • Advice intercept advice executions (higher-order advice) Logger. log Profiler. measure Transac. Mgmt. perform Bank. do. Transfer 18

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

Restoring modular reasoning with the @advised. By clause class Bank { @requires a 1. m >= m @ensures old(a 1. m)-m=a 1. m && old(a 2. m)+m=a 2. m @advised. By Security. auth void do. Transfer(Account a 1, Account a 2, int m) { … } 20

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 • Listed advice become aware of each other too • Dynamic conditions included in the effective specification 21

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 22

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

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 premeth && !preadv § Aspect. J implementation (available on Github, thanks to Luis Mayorga!) 24

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

Frame conditions and aspects § Advice in @advised. By 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

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

How often does an advice need to modify more? Name Advice ASP Bad ASP AJHSQLDB 106 55 12 AJHot. Draw 47 43 13 Healthwatcher 73 64 3 Mobile. Media 77 54 5 Space. War 13 11 0 Telestrada 46 22 0 § Not very often, in these cases § Perhaps no need to take drastic measures to restore modular reasoning 28

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

Summary § Modular reasoning with aspects • To remain unaware of advice: Use the ASP • To become aware of advice: Use @advised. By The end § 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 30