Template

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

4
Classic Distributed SuperimpositionsTermination
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

5
Classic Distributed SuperimpositionsIllustration
Formal Processes
Basic Processes
Augmented Processes

• Roletypes

6
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

7
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

8
AspectJ Figure Editor
9
AspectJ Figure Editor
aspect modularity cuts across class modularity
DisplayUpdating
10
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)
11
SuperJIntroduction

• New construct and preprocessor for supers
• 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
• ? Greater modularity, reusability and
  compositionality
• ? More powerful semantics

12
SuperJNew Features

• Grouping related aspects
• Parameterization of aspects
• Interaction and interference among aspects
• Combinations of supers
• Superimposition Validation

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

14
SuperJSuperimposition Declaration
15
SuperJSingleton 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

16
SuperJIllustration

• Generic
• Aspects

Singleton Classes
Basic Classes
Augmented System


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

18
SuperJsj2aj - Illustration

• gt sj2aj TerminationDetection bindfile
• gt 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
SuperJTermination Detection
20
SuperJTermination Detection
21
Combinations of SuperimpositionsMultiple
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

22
Multiple Superimpositions Illustration
A
Basic
Augmented
23
Combinations of SuperimpositionsBasic 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

24
Sequential Combination

• New super (B/A) has each roletype of the first
  super (A) augmented with each of the second (B)
• Stat2Dyn/DPP
• 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)
• added to rAs transformations in rB/rA
• Which variables of rA bind to which parameters of
  rB
• ? Increases reliability and avoids errors

25
Sequential Combination Illustration
B/A
26
Sequential CombinationSuperJ
27
Sequential CombinationSuperJ

• 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)

28
Sequential CombinationSuperJ
29
Sequential CombinationSuperJ

• 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(..))c
  oord.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(..))
  

30
Sequential CombinationSuperJ

• aspect Constant/DPP-Heavy(EAT_METHOD,,MY_ID,END_M
  ETHOD)
• 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)

31
Sequential CombinationCorrectness

• Feasibility check
• desired results of A contradict Bs assumptions
• Bs assumptions contradict As, As 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
• Bs assumptions that are invariants of A are
  discarded

32
Sequential CombinationFeasibility Check
33
Merging Combination

• Merges B and A and returns C (BA)
• TerminationDetectionMonitoring
• No mutual influences
• C contains the merging of all pairs rB and rA
  (rC)
• Different feasibility check
• checks only direct contradictions
• Conjunction of assumptions and results of B and A
• Interference check

34
Merging Combination Illustration
BA
35
Merging CombinationSuperJ

• aspect DPP-Heavy_Constant(EAT_METHOD,,MY_ID,END_M
  ETHOD)
• 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(..))
  

36
Merging CombinationFeasibility Check
37
Correctness VerificationIdeal 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 VerificationThe 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 VerificationAnother 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 ValidationSoftware 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 ValidationVerification
Superimpositions

• Augmentations to be added to Applications of
  Superimpositions over Basic Programs
• For each Application Super, build 2 VSs
• 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

42
Superimposition ValidationThe 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

43
Superimposition ValidationCase 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 ValidationMonitorings Asm
Verification Superimposition
45
Superimposition ValidationHow to Validate
Superimpositions

• Build VSs (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 VSs are built, the rest is automatic

46
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 VSs allows automatic
  appl
• Supers provide right module for spec and reuse