Superimpositions and AspectOriented Programming
Marcelo Sihman
Department of Computer Science
Technion – Israel 1Institute of Technology
Outline




Classic Distributed Superimpositions
Aspect-Oriented Programming (AOP)
SuperJ
Combinations of Superimpositions





Multiple Superimpositions
Sequential Combination
Merging Combination
Superimposition Validation
Concluding Remarks
Classic Distributed Superimpositions
“A superimposition is a program module that can augment
an underlying distributed program with added functionality,
while cutting across usual language modularity constructs.”

Chandy and Misra88; Bouge and Francez88; Back and KurkiSuonio90; Katz93; Francez and Forman96; Back and Sere96

Superimposition of an algorithm over a basic program
Executes task not performed by the basic, requiring:





access to its state space
some kind of interleaving of activities
Basic is the basis and supers are the complements
Less work for the user; code already tested and proved
Classic Distributed Superimpositions
Termination Detection Algorithm



Algorithm by Topor
Basic processes form a spanning tree
Roletypes






Source
Internal
Leaf
Formal processes
Node coloring
“Waves” of tokenmsg and repeat messages
Classic Distributed Superimpositions
Illustration
Formal
Roletypes
Processes
+
Basic
Processes

Augmented
Processes
Classic Distributed Superimpositions
Correctness

Goals:








prove the correctness of a super independently of basic
prove the augmented program is correct
library of supers proved to be correct
Super assumes the basic satisfies some properties
Super specifies its achieved desired results
If basic satisfies all the assumptions, then augmented
program will have the properties of the basic plus the
properties added by the super
Only desired properties of the basic are preserved
Spectative, regulative and invasive supers
AOP & Superimpositions




Connections  KatzGil99
Super  long time subject, much research exists
AOP  newer subject
Direct connection between AOP and supers


similar goals
AOP can be improved by supers
AspectJ
Figure Editor
Display
* FigureElement
Figure
makePoint(..)
makeLine(..)
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
factory methods
moveBy(int, int)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
operations that
move elements
AspectJ
Figure Editor
aspect modularity cuts across
class modularity
Display
* FigureElement
Figure
makePoint(..)
makeLine(..)
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
moveBy(int, int)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
DisplayUpdating
AspectJ
Figure Editor
aspect DisplayUpdating {
pointcut move(FigureElement figElt):
target(figElt) &&
(call(void FigureElement.moveBy(int, int)) ||
call(void Line.setP1(Point))
||
call(void Line.setP2(Point))
||
call(void Point.setX(int))
||
call(void Point.setY(int)));
after(FigureElement fe): move(fe) {
Display.update(fe);
}
}
SuperJ
Introduction

New construct and preprocessor for supers




Collection of generic aspects & singleton classes
Separately declared, specified and verified
May be applied to different basic systems



in terms of aspects and OOP
composed of basic classes
Greater modularity, reusability and compositionality
More powerful semantics
SuperJ
New Features





Grouping related aspects
Parameterization of aspects
Interaction and interference among aspects
Combinations of supers
Superimposition Validation
SuperJ
Generic Aspects





Semantically similar to roletypes
Basic class bound to a generic aspect
Formal parameters and local variables
Advice and introduction declarations
Not connected to any basic programming unit
SuperJ
Superimposition Declaration
SuperJ
Singleton Classes and Concurrency




Unique objects instantiated in augmented system
Interact with the generic aspects
RMI for message passing
New messages


SourceIF, InternalIF and LeafIF
Increase parallelism and distribution
SuperJ
Illustration
Generic
Aspects
Singleton
Classes
+
Basic
Classes

Augmented
System
SuperJ
Preprocessor - sj2aj



Translates SuperJ to AspectJ (and then Java)
Applies a super to a basic
Generates concrete aspects for generic aspects


replaces formal parms by vars, locations, classes …
Binds concrete aspects to basic classes
SuperJ
sj2aj - Illustration
> sj2aj TerminationDetection bindfile
> cat bindfile
Basic1 Source(void msg1(),inert,children,ended)
Basic2 Internal(int msg2(),unoccupied,up,down)
Basic3 Leaf(void msg1() || void msg3(int),inactive,father)
SuperJ
Termination Detection
SuperJ
Termination Detection
Combinations of Superimpositions
Multiple Superimpositions

Sequential application of two supers A, B over a basic

DPP scheduling and Stat2Dyn

Apply the next super over the augmented processes

The order of application may change the final result
contradictory superimpositions



B assumes p, but A achieves p
cooperative superimpositions

B assumes p, and A achieves p
Multiple Superimpositions
Illustration
A
Basic
Augmented
B
Combinations of Superimpositions
Basic Idea


Combines two supers and generates a new one,
which can then be applied to some basic

sequential combination

merging combination
We can combine supers and build new libraries
Sequential Combination

New super (B/A) has each roletype of the first super (A)
augmented with each of the second (B)


Represents all possible cases of multiple supers



|B/A| = |B| * |A|
The transformations of rB (a roletype of B) are applied
to rA (a roletype of A)


Stat2Dyn/DPP
added to rA’s transformations in rB/rA
Which variables of rA bind to which parameters of rB
Increases reliability and avoids errors
Sequential Combination
Illustration
A
B
B/A
Sequential Combination
SuperJ
Sequential Combination
SuperJ
aspect DPP-Heavy(EAT_METHOD,…,MY_ID) perthis(within(BOUND_CLASS)) {
private int forks = 0;
private void checkGuard(BOUND_CLASS C) {
synchronized(C) {…}
}
after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) {
…
forks++;
}
void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) {
…
forks = 0;
}
declare parents: BOUND_CLASS implements HeavyIF;
public void BOUND_CLASS.forkmsg() throws RemoteException {}
void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) {
forks++;
synchronized(C) {…}
}
}
Sequential Combination
SuperJ
Sequential Combination
SuperJ
abstract aspect Common {
public class Coordinator {…}
protected static final Coordinator coord = new Coordinator();
protected int nCalls = 0;
abstract protected pointcut allMethodCalls();
after(): allMethodCalls() {nCalls++;}
}
aspect Constant(END_METHOD) extends Common perthis(within(BOUND_CLASS)) {
…
after(): set(* BOUND_CLASS.*) && !cflow(initialization(BOUND_CLASS.new(..))) {
throw new Exception("Constant err: illegal assignment");
}
after():execution(* BOUND_CLASS.END_METHOD(..)){coord.conMethodCount(nCalls);}
}
aspect Mutable(END_METHOD) extends Common perthis(within(BOUND_CLASS)) {
…
protected int nAssigns = 0;
after(): set(* BOUND_CLASS.*) {nAssigns++;}
after(): execution(* BOUND_CLASS.END_METHOD(..))
{coord.mutMethodCount(nCalls); coord.mutAssignCount(nAssigns);}
}
Sequential Combination
SuperJ
aspect Constant/DPP-Heavy(EAT_METHOD,…,MY_ID,END_METHOD)
extends Common perthis(within(BOUND_CLASS)) {
private void checkGuard(BOUND_CLASS C) {
synchronized(C) {…}
nCalls++;
}
after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) {
…
forks++;
}
void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) {
…
forks = 0;
throw new Exception("Constant err: illegal assignment");
}
void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) {
forks++;
throw new Exception("Constant err: illegal assignment");
synchronized(C) {…}
}
}
Sequential Combination
Correctness

Feasibility check






desired results of A contradict B’s assumptions
B’s assumptions contradict A’s, A’s results do not annul
them
If a test fails, then B/A is illegal
If test fails for a rB/rA, then B/A will not have rB/rA
If test fails for a rB/procA, then B/A is illegal
B’s assumptions that are invariants of A are discarded
Sequential Combination
Feasibility Check
Merging Combination

Merges B and A and returns C (B+A)




No mutual influences
C contains the merging of all pairs rB and rA (rC)
Different feasibility check



TerminationDetection+Monitoring
checks only direct contradictions
Conjunction of assumptions and results of B and A
Interference check
Merging Combination
Illustration
A
B
B+A
Merging Combination
SuperJ
aspect DPP-Heavy_Constant(EAT_METHOD,…,MY_ID,END_METHOD)
extends Common perthis(within(BOUND_CLASS)) {
…
private void checkGuard(BOUND_CLASS C) {…}
after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) {…}
void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) {…}
declare parents: BOUND_CLASS implements HeavyIF;
public void BOUND_CLASS.forkmsg() throws RemoteException {}
void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) {…}
…
after(): set(* BOUND_CLASS.*) && !cflow(initialization(BOUND_CLASS.new(..))) {…}
after():execution(* BOUND_CLASS.END_METHOD(..)){…}
}
Merging Combination
Feasibility Check
Correctness Verification
Ideal Goal : Verifying Supers





Show once and for all that:
For every basic satisfying assumptions of e
super,
For any legal combination (weaving) of the
aspect and the underlying system,
The new functionality will be true for the
combination, and
All previous desirable properties are still OK
Correctness Verification
The Problem: Impracticality



Such a proof must be inductive
No one really does inductive proofs for
software using existing tools
Requires generalizations hard to express on
every software architecture within a class, or
every weaving of a certain type
Correctness Verification
Another Way: Superimposition Validation





Show each application of an aspect over a
system is correct
Still formal verification, but for each instance
Key idea: set-up is manual, but then the proof
for each instance is automatic
Proves that applications so far are correct
First used for Compiler Validation [Pnueli,
et.al.]
Superimposition Validation
Software Model Checking





Bandera: Tool that allows augmenting (Java)
code, abstracting domains, expressing
properties to be checked
Success means the checked property holds
Often ends with a counter-example
Can fail due to state explosion, giving no info
Algorithmic (except for finding abstractions)
Superimposition Validation
Verification Superimpositions


Augmentations to be added to Applications
of Superimpositions over Basic Programs
For each Application Super, build 2 VS’s:




Asm: Assumptions of the Application
Res: Desired results of the Application
Contain new fields, predicates,…for each
application aspect and for the super.
For each Basic program, need another VS:

Spec: specification of the Basic system
Superimposition Validation
The Validation Process



Apply Spec to Basic, and activate model
checker (usually done earlier)
Apply Asm to Basic, activate model checker
Apply Application over Basic,



apply Spec to result, activate model checker
Apply Res to result, activate model checker
Note: 3--4 activations of model checking
Superimposition Validation
Case Study



Monitoring over a Basic Bounded Buffer
Monitoring that also stops the basic if a
condition is violated: regulatory
It could affect liveness properties of the
BBuffer
Superimposition Validation
Monitoring’s Asm Verification Superimposition
Superimposition Validation
How to Validate Superimpositions



Build VS’s (manual)
Apply the stages for each combination
Activating the model checker =




Apply appropriate VS
use Bandera to generate model checker input
apply appropriate model checker to input
Once the VS’s are built, the rest is automatic
Concluding Remarks

Superimposition with aspects




generic parameterized aspects
distribution & parallelism
combinations of generic aspects
Correctness

Combinations
of
supers
encourages
the
organization of supers into libraries
Greater modularity, reusability, compositionality

Superimposition Validation



full modularization of the VS’s allows automatic appl
Supers provide right module for spec and reuse