Mehdi Bagherzadeh Hridesh Rajan Gary T. Leavens Iowa State Univeristy Iowa State University University of Central Florida mbagherz@cs.iastate.edu hridesh@cs.iastate.edu leavens@eecs.ucf.edu Translucid Contracts for Aspect-oriented Interfaces 9th Workshop on Foundations of Aspect-Oriented Languages (FOAL ’10)
Background Motivation Translucid Contracts summary Overview Modular Reasoning & Pointcut Fragility for AO Programs ◮ Many proposals to solve these problems ◮ OM [Aldrich’05], AAI [Kiczales & Mezini ’05], XPI [Sullivan et al. ’05,’09], Event Types [Rajan and Leavens’08], etc. ◮ Common theme: We need AO interfaces ◮ AO interfaces solve fragility problems . . . ◮ . . . and allow writing contracts between base and aspects Behavioral Contracts Insufficient for AO Interfaces ◮ Specification of advice input/output isn’t enough ◮ Need access to internal states that cause control effects Translucid Contracts: Grey Box Specification ◮ Provide access to some internal states . . . ◮ . . . so we can understand and enforce control effects http://www.cs.iastate.edu/~ptolemy/ 2 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Outline Explain Translucid Contracts via a Candidate AO Interface ◮ Quantified, Typed Events [Rajan and Leavens’08] ◮ Brief background on Ptolemy ◮ Translucid contracts in Ptolemy Discuss Properties of Translucid Contracts ◮ Focus on control flow effects ◮ Illustrate via Rinard et al. ’s classification ◮ . . . and beyond Applicability of Translucid Contracts ◮ Open Modules and XPI (other ideas in paper) http://www.cs.iastate.edu/~ptolemy/ 3 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Ptolemy via an Example: Declaring an Event Type 1 Fig event Changed { Fig fe; 2 3 } Event types act as interfaces. http://www.cs.iastate.edu/~ptolemy/ 4 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Ptolemy via an Example: Announcing an Event Fig event Changed{ 4 class Fig { } 1 Fig fe; 5 class Point{ 2 } int x; int y; 3 6 Fig setX( int x){ 7 announce Changed( this ){ 8 this .x = x; this 9 } 10 } 11 12 } ◮ Point is a subject in Ptolemy (II) terminology. ◮ Subjects are only aware of event types. ◮ Subjects can be compiled with just event types. http://www.cs.iastate.edu/~ptolemy/ 5 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Ptolemy via an Example: Advising an Event 1 Fig event Changed{ 13 class Update { Fig fe; when Changed do update; 2 14 3 } Update init(){ 15 register ( this ) 16 } 17 Display d; 18 Fig update( thunk Fig rest, 19 Fig fe){ 20 d.update(fe); 21 invoke (rest) 22 }} 23 ◮ Update is a handler in Ptolemy (II) terminology. ◮ Handlers are only aware of event types. ◮ Handlers can be compiled with just event types. http://www.cs.iastate.edu/~ptolemy/ 6 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Adding Behavioral Contracts to AO Interfaces 1 Fig event Changed { Fig fe; 2 requires fe != null 3 ensures fe != null 4 5 } ◮ Advantage of AO Interfaces: can specify contracts ◮ Sullivan et al. [XPI ’05,’09] show how to do that ◮ Specify precondition of event announcement ◮ Specify postcondition that a handler must ensure http://www.cs.iastate.edu/~ptolemy/ 7 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary
Background Motivation Translucid Contracts summary
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Translucid Contracts 1 Fig event Changed { Fig fe; 2 fe != null requires 3 assumes { 4 preserves fe == old (fe); 5 invoke ( next ) 6 } 7 fe != null ensures 8 9 } ◮ Based on grey box specification [Büchi & Weck ’99] ◮ requires describes precondition of ◮ event announcement and invoke expressions ◮ ensures describes postcondition of ◮ event announcement and invoke expressions ◮ assumes block describes behavior of the handlers http://www.cs.iastate.edu/~ptolemy/ 10 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work A Closer Look at Assumes /* Contract */ /* Handler Method */ requires fe != null Fig update( thunk Fig rest, assumes { Fig fe){ preserves refining preserves fe == old (fe); fe== old (fe){ d.update(fe); } ; invoke ( next ) invoke (rest) } } ensures fe != null ◮ assumes shows parts of a handler and hides the rest ◮ Hiding is done using specification expressions ◮ All invoke expressions are explicit http://www.cs.iastate.edu/~ptolemy/ 11 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Handler Verification Step I (Details in our Report) ◮ Each handler for event p must match assumes block of p ◮ Checking this requires handler code and the event type p ◮ Thus, this step is modular /* Contract */ /* Handler Method */ fe != null Fig update( thunk Fig rest, requires assumes { Fig fe){ preserves refining preserves fe == old (fe); fe== old (fe){ d.update(fe); } ; invoke ( next ) invoke (rest) } } ensures fe != null http://www.cs.iastate.edu/~ptolemy/ 12 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Handler Verification Step II (Details in our Report) ◮ Replace (lazily) each invoke in handler method by: either { 1 requires fe!= null ensures fe!= null 2 } 3 or { 4 preserves fe== old (fe) ; 5 invoke (rest) 6 } 7 ◮ and apply weakest precondition-based reasoning. ◮ This also requires only handler code and the event type p ◮ Thus, this step is modular also http://www.cs.iastate.edu/~ptolemy/ 13 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Subject Verification (Details in our Report) ◮ Replace (lazily) each announce by: either { 1 requires fe!= null ; 2 this .x = x; this 3 ensures fe!= null 4 } 5 or { 6 preserves this == old ( this ) ; 7 invoke (rest) 8 } 9 ◮ and apply weakest precondition-based reasoning. ◮ This also requires only subject code and the event type p ◮ Thus, this step is modular also http://www.cs.iastate.edu/~ptolemy/ 14 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Outline for Rest of the Talk ◮ Analyze our proposal from two different perspectives ◮ Expressiveness: what kinds of control effects can we specify? ◮ Rinard et al. ’s classification [FSE ’04 ] ◮ augmentation, replacement, narrowing, combination ◮ Properties beyond this classification ◮ Applicability: is our idea limited to Ptolemy? ◮ Apply it to other AO interfaces ◮ XPI [Sullivan et al ’05, ’09] ◮ AAI [Kiczales & Mezini ’05] ◮ Open Modules [Aldrich ’05] http://www.cs.iastate.edu/~ptolemy/ 15 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Event Type Permitting After Augmentation 1 Fig event Changed { Fig fe; 2 requires fe != null 3 assumes { 4 invoke ( next ); 5 preserves fe== old (fe) 6 } 7 ensures fe != null 8 9 } ◮ Similar to before augmentation. ◮ Handler must run exactly one invoke. http://www.cs.iastate.edu/~ptolemy/ 16 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Event Type Permitting Narrowing Handlers are allowed to not invoke under certain conditions 1 class Fig { int fixed;} 2 Fig event Changed { Fig fe; 3 requires fe != null 4 assumes { 5 if (fe.fixed == 0){ invoke ( next ); } 6 else { preserves fe== old (fe) } 7 } 8 ensures fe != null 9 10 } ◮ Illustrates use of conditionals in contract ◮ Only the event’s context variable may be named in the assumes block of that event http://www.cs.iastate.edu/~ptolemy/ 17 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Event Type Permitting Replacement Handlers do not invoke, thus they replace event body 1 Fig event Moved { Point p; 2 int d; 3 requires p!= null && d>0 4 assumes { 5 preserves p!= null && p.y == old (p.y) 6 } 7 ensures p!= null 8 9 } ◮ If there is no invoke in the assumes block then a handler may not invoke http://www.cs.iastate.edu/~ptolemy/ 18 Translucid Contracts for Aspect-oriented Interfaces
Background Motivation Translucid Contracts summary Solution Expressiveness Applicability Related Work Event Type Permitting Combination Handlers may invoke multiple times assumes { 1 while (fe.colorFixed==0){ 2 // ... 3 invoke ( next ); 4 // ... 5 } 6 } 7 ◮ Conforming handlers must have a loop at the same position for the structure to match ◮ The test condition of loop must match also http://www.cs.iastate.edu/~ptolemy/ 19 Translucid Contracts for Aspect-oriented Interfaces
Recommend
More recommend
