Day 1 Day 2 I really need to

Day 1 Day 2 I really need to separate my crosscutting concerns. I can redefine reasoning for you. I desperately need to separate my crosscutting concerns. SURE, but can you give up modular reasoning? Pretty much. NO WAY! Developer I DON’T THINK SO! Didn’t you hear that AOP is BAD for reasoning? SO I AM STUCK! Developer Balances expressiveness and modular reasoning for aspect-oriented software development. Hridesh Rajan, Sean Mooney, Gary T. Leavens, Robert Dyer, Rex D. Fernando, Mohammad Darab, and Bryan Welter ptolemy. cs. iastate. edu

Outline v. Why Ptolemy? What problems does it solve? v. Two precursors ØImplicit Invocation and Aspect-orientation v. Ptolemy and how it solves these problems. v. Main Language Features v. Declarative, typed events (join points in AO terms) v. Declarative, typed event announcement (no AO term) v. Declarative, typed event registration (advising in AO terms) v. Quantification based on event types (same as the AO term) v. Translucid contracts (no AO term) 2 ptolemy. cs. iastate. edu

One shall not have to choose between reasoning and separation. WHY PTOLEMY? ptolemy. cs. iastate. edu

Color-coded representation of about 19 K LOC at ASML: different colors represent different concerns in the system. Courtesy: Bruntink, Deursen and Tourwé ptolemy. cs. iastate. edu

Two similar ideas v. Implicit invocation (II) vs. Aspect-orientation (AO) v… both effective for separation of concerns v… both criticized for making reasoning hard v II criticized in early/late 90’s v. AO criticized in early 2000’s v. Ptolemy is designed to v combine best ideas from II and AO v … and to make reasoning easier ptolemy. cs. iastate. edu 5

[JHot. Draw – Gamma et al. ] RUNNING EXAMPLE ptolemy. cs. iastate. edu

Elements of a Drawing Editor v. Elements of drawing v. Points, Lines, etc v. All such elements are of type Fig v. Challenge I: Modularize display update policy v. Whenever an element of drawing changes — Update the display v. Challenge II: Impose application-wide restriction v. No element may move up by more than 100 7 ptolemy. cs. iastate. edu

Figure Elements 1 abstract class Fig { 2} v. Fig – super type for all figure elements ve. g. points, lines, squares, triangles, circles, etc. 8 ptolemy. cs. iastate. edu

Point and its Two Events 1. class Point extends Fig { 2 int x; 3 int y; 4 void set. X(int x) { 5 this. x = x; 6 } 7. . 8 void make. Equal(Point other) { 9 if(!other. equals(this)) { 10 other. x = this. x; 11 other. y = this. y; 12 }}} v v Changing Fig is different for two cases. Actual abstract event inside make. Equal is the true branch. 9 ptolemy. cs. iastate. edu

Kiczales et al. 97, Kiczales et al. 2001 ASPECT-BASED SOLUTIONS ptolemy. cs. iastate. edu

Key Similarities/Differences with II v. Events ≡ “join points” v. AO: pre-defined by the language/ II: programmer v. AO: Implicit announcement/ II: explicit v. Registration ≡ Pointcut descriptions (PCDs) v AO: declarative v. Handlers ≡ “advice” register with sets of events v. Quantification: using PCDs to register a handler with an entire set of events 11 ptolemy. cs. iastate. edu

Aspect-based Solution 1 aspect Update { 2 Fig around(Fig fe) : 3 call(Fig+. set*(. . )) && target(fe) 4 || call(Fig+. make. Eq*(. . )) && args(fe){ 5 Fig res = proceed(fe); 6 Display. update(); 7 return res; 8} 12 ptolemy. cs. iastate. edu

Limitations: Fragility & Quantification v Fragile Pointcuts: consider method “settled” 1 Fig around(Fig fe) : 2 call(Fig+. set*(. . )) && target(fe) 3 || call(Fig+. make. Eq*(. . )) && args(fe){ 4. . . v Quantification Failure: Arbitrary events not available 1 Fig set. X(int x){ 2 if (x. eq(this. x)) { return this; } 3 /* abstract event change */ 4 else { this. x = x; return this; } 5} 13 ptolemy. cs. iastate. edu

Limitations: Context access v. Limited Access to Context Information v Limited reflective interface (e. g. “this. Join. Point” in AJ) v Limited Access to Non-uniform Context Information 1 Fig around(Fig fe) : 2 call(Fig+. set*(. . )) && target(fe) 3 || call(Fig+. make. Eq*(. . )) && args(fe){ 4. . . 14 ptolemy. cs. iastate. edu

Limitations: Pervasive Join Point Shadows 1 x = o 1. m 1(a. e 1(), b. e 2()); 2 y = o 2. m 2(c. e 3(), x); 8 Join Points v For each join point shadow, all applicable aspect should be considered (whole-program analysis) 15 ptolemy. cs. iastate. edu

Ptolemy (Claudius Ptolemaeus), fl. 2 d cent. A. D. , celebrated Greco -Egyptian mathematician, astronomer, and geographer. ptolemy. cs. iastate. edu

Design Goals of Ptolemy v Enable modularization of crosscutting concerns, while preserving encapsulation of object-oriented code, v enable well-defined interfaces between objectoriented code and crosscutting code, and v enable separate type-checking, separate compilation, and modular reasoning of both OO and crosscutting code. 17 ptolemy. cs. iastate. edu

First and foremost v Main feature is event type declaration. v Event type declaration design similar to API design. v. What are the important abstract events in my application? v. When should such events occur? v. What info. must be available when such events occur? v Once you have done it, write an event type declaration. 18 ptolemy. cs. iastate. edu

Declaring an Event Type Fig event Changed { Fig fe; } Event Type Declaration ptolemy. cs. iastate. edu

Declaring an Event Type Fig event Changed { Fig fe; } Event Type Declaration v Event type is an abstraction. v Declares context available at the concrete events. v Interface, so allows design by contract (DBC) methodology. 20 ptolemy. cs. iastate. edu

Announcing Events in Ptolemy Subject 1 class Fig {bool is. Fixed; } 2 class Point extends Fig{ 3 int x, y; 4 Fig set. X(int x){ 5 announce Changed(this){ 6 this. x = x; return this; 7 } 8 } 9 } Event Announcement v Explicit, more declarative, typed event ptolemy. cs. iastate. edu announcement. 21

More Event Announcements Subject class Point extends Fig{. . Fig move. Up(int delta){ announce Move. Up. Event(this){ this. y += delta; return this; } } } Event Announcement v Explicit, more declarative, typed event ptolemy. cs. iastate. edu announcement. 22

Advising Events v. No special type of “aspect” modules v. Unified model from Eos [Rajan and Sullivan 2005] Observer(Handler) class Display. Update { } 23 ptolemy. cs. iastate. edu

Quantification Using Binding Decls. v. Binding declarations v. Separate “what” from “when” [Eos 2003] Observer(Handler) class Display. Update { when Changed do update; Quantification } 24 ptolemy. cs. iastate. edu

Dynamic Registration v. Allow dynamic registration v. Other models can be programmed Observer(Handler) class Display. Update { void Display. Update(){ register(this)} Fig update(Changed next){ Registration } when Changed do update; } Quantification 25 ptolemy. cs. iastate. edu

Controlling Overriding v. Use invoke to run the continuation of event v. Allows overriding similar to Aspect. J Observer(Handler) class Display. Update { void Display. Update(){ register(this)} Fig update(Changed next){ invoke(next); Display. update(); System. out. println(“After Invoke"); Registration Running continuation of the event } when Changed do update; } Quantification 26 ptolemy. cs. iastate. edu

DEMO ptolemy. cs. iastate. edu

Expressions and Operations ASTNodes e : : = v | (lambda (v). e ) | (e e) e : : = … | true | false | Num | e == e | e <= e | e && e | e `||’ e |e+e|e*e|e–e Eval E: e ==> e’ Checker T |-- e : t Printer ptolemy. cs. iastate. edu

Goal: Separation of Concerns ASTNodes e : : = v | (lambda (v). e ) | (e e) e : : = … | true | false | Num | e == e | e <= e | e && e | e `||’ e |e+e|e*e|e–e Eval E: e ==> e’ Checker T |-- e : t Printer ptolemy. cs. iastate. edu

Goal: Separation of Operations AST Nodes e : : = … | true | false | Num | e == e | e <= e | e && e | e `||’ e |e+e|e*e|e–e AST Events e : : = v | (lambda (v). e ) | (e e) Eval E: e ==> e’ Checker T |-- e : t Printer ptolemy. cs. iastate. edu

Enabling modular verification CONTRACTS IN PTOLEMY ptolemy. cs. iastate. edu

DEMO ptolemy. cs. iastate. edu

Conclusion v Motivation: intellectual control on complexity essential v Implicit invocation (II) and aspect-orientation (AO) help v. . . but have limitations v Ptolemy: combine best ideas of II and AO v Quantified, typed events + arbitrary expressions as explicit events v Translucid contracts v Benefits over implicit invocation v decouples observers from subjects v ability to replace events powerful v Benefits over aspect-based models v preserves encapsulation of code that signals events v uniform and regular access to event context v robust quantification v Last but not least, more modular reasoning 33 ptolemy. cs. iastate. edu

Opportunities to Contribute v. Language design efforts v. Ptolemy# to come out in June, testing underway (Extension of C#) v. Transition to less front-end changes (for Ptolemy. J) v. Verification efforts v. More expressive support for embedded contracts v. Practical reasoning approaches for heap effects v. Better verification error reporting 34 ptolemy. cs. iastate. edu

Opportunities to Contribute v. Case study efforts – compiler supports metrics v. Showcase applications, examples for Ptolemy v. Comparison with other languages/approaches v. Infrastructure efforts v. Support in Eclipse, other IDEs v. Better error reporting, recovery v. Language manuals, descriptions, … All are welcome!!! Open source MPL 1. 1 License 35 ptolemy. cs. iastate. edu

Day 1 Day 2 I really need to separate my crosscutting concerns. I can redefine reasoning for you. I desperately need to separate my crosscutting concerns. SURE, but can you give up modular reasoning? Pretty much. NO WAY! Developer I DON’T THINK SO! Didn’t you hear that AOP is BAD for reasoning? SO I AM STUCK! Developer Balances expressiveness and modular reasoning for aspect-oriented software development. Hridesh Rajan, Sean Mooney, Gary T. Leavens, Robert Dyer, Rex D. Fernando, Mohammad Darab, and Bryan Welter ptolemy. cs. iastate. edu

Evolution of the Ptolemy Language Hyper. J [Ossher, Tarr, Harrison 2001] Aspect. J [Kiczales et al. 2001] Eos [Rajan and Sullivan 2003, 2005] XPI [Sullivan et al. 2005] XPI - Aspect. J [Griswold et al. 2006] ptolemy. cs. iastate. edu

Advantages over II v. Ease of use due to quantification v. By not referring to the names, handler code remains syntactically independent 38 ptolemy. cs. iastate. edu

Reiss’ 92, Garlan and Notkin’ 92 IMPLICIT INVOCATION ptolemy. cs. iastate. edu

Key Ideas in II v Allow management of name dependence v when “Point’s coordinates changes” update Display v. . . but Point shouldn’t depend on Display v. . . complicates compilation, test, use, etc v Components (subjects) declare events v e. g. when “Point’s coordinates changes” v provide mechanisms for registration v. . . and for announcement v Components (observers) register with events v e. g. invoke me when “Point’s coordinates changes” v Subjects announce events v e. g. when “Point’s coordinates changes” v “change in coordinates” event announced 40 ptolemy. cs. iastate. edu

II: Components Declare Events 1 abstract class Fig { 2 List change. Observers; 3 void announce. Change. Event(Fig changed. FE){ 4 for(Change. Observer o : change. Observers){ 5 o. notify(changed. FE); 6 } 7 } 8 void register. With. Change. Event(Change. Observer o){ 9 change. Observers. add(o); 10 } 11 } 12 abstract class Change. Observer { 13 void notify(Fig changed. FE); 14 } 41 ptolemy. cs. iastate. edu

II: Components Announce Events 1 class Point extends Fig { 2 int x; int y; 3 void set. X(int x) { 4 this. x = x; 5 announce. Change. Event(this); 6 } 7 void make. Equal(Point other) { 8 other. x = this. x; other. y = this. y; 9 announce. Change. Event(other); 10 } 11 } v Event announcement explicit, helps in understanding v Event announcement flexible, can expose arbitrary points 42 ptolemy. cs. iastate. edu

II: Component Register With Events 1 class Update extends Change. Observer { 2 Fig last; 3 void register. With(Fig fe) { 4 fe. register. With. Change. Event(this); 5 } 6 void notify(Fig changed. FE){ 7 this. last = changed. FE; 8 Display. update(); 9 } 10 } v Registration explicit and dynamic, gives flexibility v Generally deregistration is also available 43 ptolemy. cs. iastate. edu

II: Disadvantages v Coupling of observers to subjects void register. With(Fig fe) { fe. register. With. Change. Event(this); . . . } v Lack of quantification void register. With(Point p){ p. register. With. Change. Event(this); } void register. With(Line l) { l. register. With. Change. Event(this); } 44 ptolemy. cs. iastate. edu

II: Disadvantages v No ability to replace event code class Move. Up. Check extends … { void notify(Fig target. FE, int y, int delta) { if (delta < 100) { return target. FE } else{throw new Illegal. Argument. Exception()} } } 45 ptolemy. cs. iastate. edu