Post on 24-Dec-2015
transcript
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