A Formal Model of Modularity in Aspect-Oriented Programming Jonathan Aldrich : 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 Aspect class Point extends Shape { void moveBy(int dx, int dy) { x += dx; y += dy;... }

Example: Assurance Aspect class 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 Aspect class 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 Aspect class 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 Aspect class 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 Aspect class 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 Aspect class 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 Aspect class 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 advice class 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 pointcut class 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 Module Ordinary functional interface

Open Modules void moveBy(int, int); void animate(Motion); pointcut moves; Open Module Ordinary 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 Module Clients can call interface functions

Open Modules void moveBy(int, int); void animate(Motion); pointcut moves; Open Module Clients can call interface functions Clients can advise external calls to interface functions

Open Modules void moveBy(int, int); void animate(Motion); pointcut moves; Open Module Clients 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 Module Clients 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 => 1 around 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: Example structure 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->int end 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