A Formal Model of Modularityin Aspect-Oriented Programming

Jonathan Aldrich

15-819: Objects and Aspects

Carnegie Mellon University

Outline AOP Modularity Challenges Open Modules A Bit of Formality Comparison to Aspect-Aware Interfaces Lessons Learned and Discussion

Modularity and Encapsulation Parnas’ advice:

Modularize a system to hide information that may change

Encapsulation A mechanism for enforcing information hiding Java classes & packages, ML modules…

Aspect-oriented Programming More flexible ways of modularizing a system

Is AOP Modular? Back to Parnas: Does AOP hide

information that is likely to change? Yes, within the aspect

Aspect code can be evolved separately

No, not within the base code Minor changes to base code break the aspect

Example: Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

Example: Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

Example: Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

aspect AssureShapeInvariants {

}

Example: Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

aspect AssureShapeInvariants {

pointcut moves() =

call(Shape+.moveBy(..));

}

Example: Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

aspect AssureShapeInvariants {

pointcut moves() =

call(Shape+.moveBy(..));

after(): moves() {

scene.checkInvariants();

}

}

Example: Broken Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

aspect AssureShapeInvariants {

pointcut moves() =

call(Shape+.moveBy(..));

after(): moves() {

scene.checkInvariants();

}

}

Change representation to use Point

Example: Broken Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1.moveBy(dx, dy);

p2.moveBy(dx, dy);

...

}

aspect AssureShapeInvariants {

pointcut moves() =

call(Shape+.moveBy(..));

after(): moves() {

scene.checkInvariants();

}

}

Change representation to use Point

Example: Broken Assurance Aspectclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1.moveBy(dx, dy);

p2.moveBy(dx, dy);

...

}

aspect AssureShapeInvariants {

pointcut moves() =

call(Shape+.moveBy(..));

after(): moves() {

scene.checkInvariants();

}

}

Change representation to use Point

Now the scene invariants are checked in the middle of a Rectangle move—when they might be broken!

Analysis Aspects can violate information hiding

Assurance aspect depends on Shape internals

Similar to OO Fragile Base Class Problem Observing impl. dependant calling patterns

Can fix each individual problem Better: use modules to forestall issue

Fix #1: external adviceclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

aspect AssureShapeInvariants {

pointcut moves():

call(Shape+.moveBy(..))

&& !within(shape.*);

after(): moves() {

scene.checkInvariants();

}

}

Only specifies calls that are external to the shape package

Fix #2: semantic pointcutclass Point extends Shape {

void moveBy(int dx, int dy) {

x += dx; y += dy;

...

}

class Rectangle extends Shape {

void moveBy(int dx, int dy) {

p1x += dx; p1y += dy;

p2x += dx; p2y += dy;

...

}

class Shape {

public pointcut moves():

call(Shape+.moveBy(..));

}

aspect AssureShapeInvariants {

after(): Shape.moves() {

scene.checkInvariants();

}

}

Move pointcut to the shape package

Now the shape maintainer is responsible for preserving its

semantics when shapes evolve

Open Modules

void moveBy(int, int);void animate(Motion);

Open ModuleOrdinary functional interface

Open Modules

void moveBy(int, int);void animate(Motion);

pointcut moves;

Open ModuleOrdinary functional interface

Semantic Pointcut• Denotes some internal event• Promise to maintain event semantics as code evolves[Gudmunson & Kiczales]

Open Modules

void moveBy(int, int);void animate(Motion);

pointcut moves;

Open ModuleClients can call interface functions

Open Modules

void moveBy(int, int);void animate(Motion);

pointcut moves;

Open ModuleClients can call interface functions

Clients can advise external calls to interface functions

Open Modules

void moveBy(int, int);void animate(Motion);

pointcut moves;

Open ModuleClients can call interface functions

Clients can advise external calls to interface functions

Clients can advise pointcuts in interface

Open Modules

void moveBy(int, int);void animate(Motion);

pointcut moves;

Open ModuleClients can call interface functions

Clients can advise external calls to interface functions

Clients can advise pointcuts in interface

Clients cannot advise any internal calls (not even to exported

functions)

X

Open Module Properties: Equivalence

Motivation Rules describe when changes could affect

clients Can be used to prove correctness of refactorings

Bisimulation-based equivalence All functions map args to same results Invoke internal pointcuts in same way

Same sequence, same context

Open Module Properties: Abstraction

Verifies correctness of equivalence rules Shows that information hiding works

Informal statement of theorem Consider two module implementations that are

equivalent according to the bisimulation rules No client code can distinguish the behavior of

these modules (even by using aspects) Note: this would fail for AspectJ!

Comparison to Aspect-Aware Interfaces AAI: more obliviousness, extensibility

Don’t have to anticipate semantic pointcuts OM: truly separate development

AAI cannot be computed in this case OM: shows technical properties of AAI

AAI is an OM interface computed by tools Abstraction supports evolvability Not all information in AAI is needed

Don’t need exact advice Don’t need pointcuts for external calls to interface functions

Tool and Language Implications Tools: Provide editable interface pointcuts

Change base code and affected pointcuts at the same time

Tools: Support dependency tracking Let you know when you’re depending on impl. Warn you to re-check pointcuts when impl.

Changes Language

Make it easier to write non-invasive pointcuts

Discussion Extensibility vs. Reasoning Tool vs. Language-based reasoning Open Modules into real AOP systems Analysis based on Open Modules

End of Presentation/Extra Slides

TinyAspect Example(* fibonacci function *)val fib = fn x:int => 1around call(fib) (x:int) = if (x > 2) then fib(x-1) + fib(x-2) else proceed x

(* caching library *)val inCache = fn ...val lookupCache = fn ...val updateCache = fn ...

(* advice to cache calls to fib *)

pointcut cacheFunction = call(fib)

around cacheFunction(x:int) =

if (inCache x)

then lookupCache x

else let v = proceed x

in updateCache x v; v

TinyAspect: Syntax

Evaluation Environment captures advice

Declarations add labels to environment

Functions are looked up just before application

Evaluation Environment captures advice

Declarations add labels to environment

Advice updates environment

TinyAspect: Values and Contexts

TinyAspect: Reduction Rules

TinyAspect: Expression Typing

TinyAspect: Declaration Typing

TinyAspect: Properties

Open Modules: Syntax

Open Modules: Examplestructure Math = struct val fib = fn x:int => 1 around call(fib) (x:int) = …

structure cacheFib = Cache(struct pointcut f = call(fib) end)end :> sig fib : int->intend

structure Cache =

functor(X : sig f : pc(int->int) end) =>

struct

around X.f(x:int) = ...

(* same definition *)

end

Open Modules: Semantics Standard type system

Signature subtyping permitted

Runtime semantics mostly standard E.g, functor application uses substitution

Sealing has operational effect Value bindings given fresh labels

External advice doesn’t affect internal calls C.f. “freeze” operator in Jigsaw, other systems

Pointcuts are unchanged

Open Modules: Semantics

Reynolds’ Abstraction Property No client can distinguish two modules that are

“observationally equivalent” (c.f. Pi-calculus) calling functions in interface advising external calls to interface advising pointcuts in interface

Means that information hiding works You can change the internals of a module w/o affecting

clients

Observational Equivalence Functions behave equivalently for all args

Expression evaluation must be bisimilar w.r.t. a set of available labels Can take any step other than looking up

Can both look up the same label in

Formal Abstraction Theorem

Proof insight Client can only advise labels in Libraries treat these labels equivalently

Key invariant Clients are structurally identical

Except for embedded equivalent values