Superimpositions and Aspect- Oriented 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 Multiple Superimpositions Sequential Combination Sequential Combination Merging 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.” “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 Kurki- Suonio90; 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 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 Source Internal Internal Leaf Leaf  Formal processes  Node coloring  “Waves” of tokenmsg and repeat messages

Classic Distributed Superimpositions Illustration Roletypes Formal FormalProcesses + Basic BasicProcesses  Augmented Processes Processes

Classic Distributed Superimpositions Correctness  Goals : prove the correctness of a super independently of basic prove the correctness of a super independently of basic prove the augmented program is correct prove the augmented program is correct library of supers proved to be 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 similar goals AOP can be improved by supers AOP can be improved by supers

operations that move elements factory methods Display * 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Figure makePoint(..) makeLine(..) FigureElement moveBy(int, int) AspectJ Figure Editor

aspect modularity cuts across class modularity DisplayUpdating Display * 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Figure makePoint(..) makeLine(..) FigureElement moveBy(int, int) 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); } AspectJ Figure Editor

SuperJ Introduction  New construct and preprocessor for supers in terms of aspects and OOP in terms of aspects and OOP  Collection of generic aspects & singleton classes  Separately declared, specified and verified  May be applied to different basic systems composed of basic classes composed of basic classes Greater modularity, reusability and compositionality Greater modularity, reusability and compositionality More powerful semantics 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 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 SourceIF, InternalIF and LeafIF Increase parallelism and distribution Increase parallelism and distribution

SuperJ Illustration GenericAspectsSingleton Classes Classes + Basic Basic Classes Classes  Augmented System 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 … 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

Combinations of Superimpositions Multiple Superimpositions  Sequential application of two supers A, B over a basic DPP scheduling and Stat2Dyn 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 B assumes  p, but A achieves p  cooperative superimpositions B assumes p, and A achieves p B assumes p, and A achieves p

Multiple Superimpositions Illustration ABBasic Augmented

Combinations of Superimpositions Basic Idea  Combines two supers and generates a new one, which can then be applied to some basic sequential combination sequential combination merging combination merging combination We can combine supers and build new libraries 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 ) Stat2Dyn/DPP Stat2Dyn/DPP  Represents all possible cases of multiple supers | B/A | = | B | * | A | | B/A | = | B | * | A |  The transformations of rB  (a roletype of B ) are applied to rA (a roletype of A ) added to rA ’s transformations in rB/rA added to rA ’s transformations in rB/rA  Which variables of rA bind to which parameters of rB Increases reliability and avoids errors Increases reliability and avoids errors

Sequential Combination Illustration BB/AA

Sequential Combination SuperJ

aspect DPP-Heavy(EAT_METHOD,…,MY_ID) perthis(within(BOUND_CLASS)) { private int forks = 0; private int forks = 0; private void checkGuard(BOUND_CLASS C) { private void checkGuard(BOUND_CLASS C) { synchronized(C) {…} synchronized(C) {…} } after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) { after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) { … forks++; forks++; } void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) { void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) { … forks = 0; forks = 0; } declare parents: BOUND_CLASS implements HeavyIF; declare parents: BOUND_CLASS implements HeavyIF; public void BOUND_CLASS.forkmsg() throws RemoteException {} public void BOUND_CLASS.forkmsg() throws RemoteException {} void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) { void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) { forks++; forks++; synchronized(C) {…} synchronized(C) {…} }}

Sequential Combination SuperJ

abstract aspect Common { public class Coordinator {…} public class Coordinator {…} protected static final Coordinator coord = new Coordinator(); protected static final Coordinator coord = new Coordinator(); protected int nCalls = 0; protected int nCalls = 0; abstract protected pointcut allMethodCalls(); abstract protected pointcut allMethodCalls(); after(): allMethodCalls() {nCalls++;} after(): allMethodCalls() {nCalls++;}} aspect Constant(END_METHOD) extends Common perthis(within(BOUND_CLASS)) { … after(): set(* BOUND_CLASS.*) && !cflow(initialization(BOUND_CLASS.new(..))) { after(): set(* BOUND_CLASS.*) && !cflow(initialization(BOUND_CLASS.new(..))) { throw new Exception("Constant err: illegal assignment"); throw new Exception("Constant err: illegal assignment"); } after():execution(* BOUND_CLASS.END_METHOD(..)){coord.conMethodCount(nCalls);} after():execution(* BOUND_CLASS.END_METHOD(..)){coord.conMethodCount(nCalls);}} aspect Mutable(END_METHOD) extends Common perthis(within(BOUND_CLASS)) { … protected int nAssigns = 0; protected int nAssigns = 0; after(): set(* BOUND_CLASS.*) {nAssigns++;} after(): set(* BOUND_CLASS.*) {nAssigns++;} after(): execution(* BOUND_CLASS.END_METHOD(..)) after(): execution(* BOUND_CLASS.END_METHOD(..)) {coord.mutMethodCount(nCalls); coord.mutAssignCount(nAssigns);} {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)) { extends Common perthis(within(BOUND_CLASS)) { private void checkGuard(BOUND_CLASS C) { private void checkGuard(BOUND_CLASS C) { synchronized(C) {…} synchronized(C) {…} nCalls++; nCalls++; } after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) { after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) { … forks++; forks++;} void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) { void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) { … forks = 0; forks = 0; throw new Exception("Constant err: illegal assignment"); throw new Exception("Constant err: illegal assignment"); } void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) { forks++; forks++; throw new Exception("Constant err: illegal assignment"); throw new Exception("Constant err: illegal assignment"); synchronized(C) {…} synchronized(C) {…} }}

Sequential Combination Correctness  Feasibility check desired results of A contradict B ’s assumptions desired results of A contradict B ’s assumptions B ’s assumptions contradict A ’s, A ’s results do not annul them 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 ) TerminationDetection+Monitoring TerminationDetection+Monitoring  No mutual influences  C contains the merging of all pairs rB and rA ( rC )  Different feasibility check checks only direct contradictions checks only direct contradictions  Conjunction of assumptions and results of B and A  Interference check

Merging Combination Illustration B+ABA

Merging Combination SuperJ aspect DPP-Heavy_Constant(EAT_METHOD,…,MY_ID,END_METHOD) extends Common perthis(within(BOUND_CLASS)) { extends Common perthis(within(BOUND_CLASS)) { … private void checkGuard(BOUND_CLASS C) {…} private void checkGuard(BOUND_CLASS C) {…} after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) {…} after(BOUND_CLASS C): initialization(BOUND_CLASS.new(..)) && target(C) {…} void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) {…} void around(BOUND_CLASS C): execution(EAT_METHOD) && target(C) {…} declare parents: BOUND_CLASS implements HeavyIF; declare parents: BOUND_CLASS implements HeavyIF; public void BOUND_CLASS.forkmsg() throws RemoteException {} public void BOUND_CLASS.forkmsg() throws RemoteException {} void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) {…} void around(BOUND_CLASS C): execution(void HeavyIF.forkmsg()) && target(C) {…} … after(): set(* BOUND_CLASS.*) && !cflow(initialization(BOUND_CLASS.new(..))) {…} after(): set(* BOUND_CLASS.*) && !cflow(initialization(BOUND_CLASS.new(..))) {…} after():execution(* BOUND_CLASS.END_METHOD(..)){…} 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 Asm: Assumptions of the Application Res: Desired results 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 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 Spec to result, activate model checker Apply Res 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 Apply appropriate VS use Bandera to generate model checker input use Bandera to generate model checker input apply appropriate model checker to 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 generic parameterized aspects distribution & parallelism distribution & parallelism combinations of generic aspects combinations of generic aspects Correctness 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 full modularization of the VS’s allows automatic appl Supers provide right module for spec and reuse Supers provide right module for spec and reuse