1. Superimpositions and Aspect- Oriented Programming Marcelo Sihman Department of Computer Science Technion – Israel 1Institute of Technology

2. 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

3. 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

4. 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

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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. SuperJ New Features  Grouping related aspects  Parameterization of aspects  Interaction and interference among aspects  Combinations of supers  Superimposition Validation

13. 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

14. SuperJ Superimposition Declaration

15. 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

16. SuperJ Illustration GenericAspectsSingleton Classes Classes + Basic Basic Classes Classes  Augmented System System

17. 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

18. 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)

19. SuperJ Termination Detection

21. 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

22. Multiple Superimpositions Illustration ABBasic Augmented

23. 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

24. 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

25. Sequential Combination Illustration BB/AA

26. Sequential Combination SuperJ

27. 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) {…} }}

28. Sequential Combination SuperJ

29. 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);}}

30. 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) {…} }}

31. 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

32. Sequential Combination Feasibility Check

33. 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

34. Merging Combination Illustration B+ABA

35. 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(..)){…}}

36. Merging Combination Feasibility Check

37. 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

38. 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

39. 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.]

40. 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)

41. 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

42. 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

43. 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

44. Superimposition Validation Monitoring’s Asm Verification Superimposition

45. 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

46. 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