Modular Reasoning inAspect-oriented Languages

Tim Molderez

Promotor: prof. dr. Dirk Janssens

AnsymoAntwerp 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?

3

How to keep it manageable?:Divide and conquer

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

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

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

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?

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

9

Switching to English

10

ContractAJ exampleclass 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

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

class Logger {

after bankLog: call (* Bank.do*(..)) {

log.write(…);}…

}

pointcut(specifies a set of points in time,

aka “join points”)

advice kindadvice name

advice body

advice

13

Another aspect: authentication

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

15

Modular reasoning in AOP

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)!

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

Before advice

Bank.doTransfer(implicit)

pre’

post’

Bank.doTransfer(implicit)

After advicepre’

post’

18

Special cases Principle also applies if:

• Multiple advice share join points• Advice intercept advice executions

(higher-order advice)

Logger.log

Profiler.measure

TransacMgmt.perform

Bank.doTransfer

19

If you can’t satisfy the advice subst. principle

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

clauseclass Bank {

@requires a1.m >= m@ensures old(a1.m)-m=a1.m && old(a2.m)

+m=a2.m@advisedBy Security.authvoid 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

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

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)

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 premeth && !preadv

AspectJ implementation (available on Github, thanks to Luis Mayorga!)

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

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?

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)

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

Name Advice ASP Bad ASP

AJHSQLDB 106 55 12

AJHotDraw 47 43 13

Healthwatcher 73 64 3

MobileMedia 77 54 5

SpaceWar 13 11 0

Telestrada 46 22 0

29

The future Modular reasoning about pointcuts

A larger data set of aspect-oriented programs

Beyond AspectJ; finding the essence of aspects

30

Summary

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