Ptolemy.cs.iastate.edu Balances expressiveness and modular reasoning for aspect-oriented software development. Developer I really need to separate my crosscutting.

Slides:



Advertisements
Similar presentations
Mohamed ElBendary and John Boyland University of Wisconsin-Milwaukee.
Advertisements

Aspect Oriented Programming. AOP Contents 1 Overview 2 Terminology 3 The Problem 4 The Solution 4 Join point models 5 Implementation 6 Terminology Review.
An Aspect-Oriented Approach For Web Application Access Control Presented by: Mohamed Hassan Carleton University Carleton University
ASTA Aspect Software Testing Assistant Juha Gustafsson, Juha Taina, Jukka Viljamaa University of Helsinki.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development.
1 An Aspect-Aware Outline Viewer Michihiro Horie and Shigeru Chiba Tokyo Institute of Technology, Japan.
Wicca v2 demo Dynamic weaving using the.NET 2.0 Debugging APIs Marc Eaddy Columbia University.
Aspect-Oriented Programming In Eclipse ® Aspect-Oriented Programming in Eclipse with AspectJ Dr Helen Hawkins and Sian January.
University of British Columbia Software Practices Lab Fluid AOP Join Point Models Terry Hon Gregor Kiczales.
Java.sun.com/javaone/sf | 2004 JavaOne SM Conference | Session BUS JavaOne 2004 What is AOP? Gregor Kiczales AspectMentor.com and University of.
Review Amit Shabtay. March 3rd, 2004 Object Oriented Design Course 2 Review What have we done during the course? Where to learn more? What is for the.
ASPECT ORIENTED SOFTWARE DEVELOPMENT Prepared By: Ebru Doğan.
University of British Columbia Software Practices Lab CAS Seminar 06 Fluid AJ - A Simple Fluid AOP Tool Terry Hon Gregor Kiczales.
Aspect Oriented Programming Written by Michael Beder.
Data Abstraction and Object- Oriented Programming CS351 – Programming Paradigms.
Session 15 Modeling Traceability of Concerns in Architectural Views Mark Stobbe October 29,
Generative Programming. Generic vs Generative Generic Programming focuses on representing families of domain concepts Generic Programming focuses on representing.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
A Formal Model of Modularity in Aspect-Oriented Programming Jonathan Aldrich : Objects and Aspects Carnegie Mellon University.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Deriving AO Software Architectures using the AO-ADL Tool Suite Luis Fernández, Lidia Fuentes, Mónica Pinto, Juan A. Valenzuela Universidad de Málaga
Outline Introduction Problem Statement Object-Oriented Design Aspect-Oriented Design Conclusion Demo.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Debugging Support.
Introduction to Aspect Oriented Programming Presented By: Kotaiah Choudary. Ravipati M.Tech IInd Year. School of Info. Tech.
Aspect Oriented Programming Razieh Asadi University of Science & Technology Mazandran Babol Aspect Component Based Software Engineering (ACBSE)
Aspect Oriented Programming Scott Nykl CSSE 411 Senior Seminar.
1 An Aspect-oriented Weaving Mechanism Based on Component-and-Connector Architecture Naoyasu Ubayashi (Kyushu Institute of Technology) February 12, 2008.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development 1.
Implementation of Programming Languages 17 October 2015 | Software Technology Group | 1 Topics on EScala Vaidas Gasiunas, Lucas Satabin.
Aspect Oriented Programming Sumathie Sundaresan CS590 :: Summer 2007 June 30, 2007.
1 A Parameterized Interpreter for Modeling Different AOP Mechanisms Naoyasu Ubayashi(Kyushu Institute of Technology, Japan) Genki Moriyama(Kyushu Institute.
POSL (Principles of Software Languages) Gr. Kyushu Institute of Technology, Japan Pointcut-based Architectural Interface.
Guided Notes Ch. 9 ADT and Modules Ch. 10 Object-Oriented Programming PHP support for OOP and Assignment 4 Term project proposal C++ and Java Designer.
Aspect Oriented Programming Gülşah KARADUMAN.
On the Modularity Assessment of Aspect- Oriented Multi-Agent Systems Product Lines: a Quantitative Study Camila Nunes
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
A Distributed Aspect-Oriented System for J2EE Applications Muga Nishizawa and Shigeru Chiba (Tokyo Institute of Technology, Japan) Background - As benefits.
Design Rules for Increasing Modularity with CaesarJ Carlos Eduardo Pontual Advisor: Paulo Borba 17/06/2010.
AOSD1 Aspect-Oriented Software Design Karl Lieberherr Theo Skotiniotis.
TRANSPARENT EXTENSION OF SINGLE- USER APPLICATIONS TO MULTI-USER REAL-TIME COLLABORATIVE SYSTEMS An Aspect Oriented Approach to Framework Integration ICEIS.
AOP-1 Aspect Oriented Programming. AOP-2 Aspects of AOP and Related Tools Limitation of OO Separation of Concerns Aspect Oriented programming AspectJ.
Aspect-Oriented Programming and Modular Reasoning G. KiczalesM. Mezini Presented by Alex Berendeyev.
IDENTIFYING SEMANTIC DIFFERENCES IN ASPECTJ PROGRAMS Martin Görg and Jianjun Zhao Computer Science Department, Shanghai Jiao Tong University.
The Ptolemy Programming Language Modularizing Crosscutting Concerns with Ptolemy Hridesh Rajan with Gary T. Leavens,
Aspect-Oriented Action Semantics Descriptions Luis Menezes University of Pernambuco
A Two-Dimensional Separation of Concerns for Compiler Construction Carl (Xiaoqing) Wu, Suman Roychoudhury, Barrett R. Bryant and Jeffrey G. Gray The University.
AspectJ – AOP for Java Tom Janofsky. Instructor at Penn State Abington Consultant with Chariot Solutions JUG Member.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 13. Review Shared Data Software Architectures – Black board Style architecture.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
1 Contract-based Verification for Aspect-oriented Refactoring Naoyasu Ubayashi(Kyushu Institute of Technology) Jinji Piao(Kyushu Institute of Technology)
Applying Translucid Contracts for Modular Reasoning about Aspect and Object Oriented Events Mehdi Bagherzadeh Gary T. Leavens Robert Dyer Foundations of.
Alloy-based Lightweight Verification for Aspect-oriented Architecture Naoyasu Ubayashi(Kyushu Institute of Technology) Yuki Sato(Kyushu Institute of Technology)
aspectj tools new and noteworthy Mik Kersten University of British Columbia Adrian Colyer IBM Hursley OOPSLA, October
AOSD'04, Lancaster, UK 1 Remote Pointcut - A Language Construct for Distributed AOP Muga Nishizawa (Tokyo Tech) Shigeru Chiba (Tokyo Tech) Michiaki Tatsubori.
Lecture 2: Review of Object Orientation. © Lethbridge/La ganière 2005 Chapter 2: Review of Object Orientation What is Object Orientation? Procedural.
R R R A Brief Introduction to Aspect-Oriented Programming.
Thesis Proposal Defense 12/13/06 Marc Eaddy. 12/13/2006Thesis Proposal2 Motivation Modularity is unnecessarily limited by the presence of crosscutting.
AspectScope: An Outline Viewer for AspectJ Programs Michihiro Horie, Shigeru Chiba Tokyo Institute of Technology, Japan.
Class Relationships Lecture Oo08 Polymorphism. References n Booch, et al, The Unified Modeling Language User Guide, Chapt 10 p.125 n Fowler & Scott, UML.
1 Aspectual Caml an Aspect-Oriented Functional Language Hideaki Tatsuzawa Hidehiko Masuhara Akinori Yonezawa University of Tokyo.
Modular reasoning in the presence of event subtyping 14 th international conference on Modularity 1 Mehdi Bagherzadeh Robert Dyer Rex D. Fernando Jose.
ECE 750 Topic 8 Meta-programming languages, systems, and applications Automatic Program Specialization for J ava – U. P. Schultz, J. L. Lawall, C. Consel.
Liang, Introduction to Java Programming, Eighth Edition, (c) 2011 Pearson Education, Inc. All rights reserved Fall 2013 Chapter 10 Thinking.
An Interface Mechanism for Encapsulating Weaving in Class-based AOP
Software Engineering Fall 2005
Aspect-Oriented Programming with the Eclipse AspectJ plug-in
Demeter Aspects Who We Are Aspectual Collaborations
Object Oriented Analysis and Design
Aspect-oriented programming
Presentation transcript:

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

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

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

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

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

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

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

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

ptolemy.cs.iastate.edu 9 Point and its Two Events 1.class Point extends Fig {  int x;  int y;  void setX(int x) {  this.x = x;  } ..  void makeEqual(Point other) {  if(!other.equals(this)) {  other.x = this.x;  other.y = this.y;  }}}  Changing Fig is different for two cases.  Actual abstract event inside makeEqual is the true branch.

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

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

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

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

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

ptolemy.cs.iastate.edu 15 Limitations: Pervasive Join Point Shadows  For each join point shadow, all applicable aspect should be considered (whole-program analysis) 1 x = o1.m1(a.e1(), b.e2()); 2 y = o2.m2(c.e3(), x); 8 Join Points

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

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

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

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

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

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

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

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

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

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

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

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 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’ Eval E: e ==> e’ Checker T |-- e : t 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 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’ Eval E: e ==> e’ Checker T |-- e : t Checker T |-- e : t Printer

ptolemy.cs.iastate.edu Goal: Separation of Operations AST Nodes 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 AST Nodes 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’ Eval E: e ==> e’ Checker T |-- e : t Checker T |-- e : t Printer AST Events

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

ptolemy.cs.iastate.edu DEMO

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

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

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

ptolemy.cs.iastate.edu Balances expressiveness and modular reasoning for aspect-oriented software development. Developer I really need to separate my crosscutting concerns. Language Expert 1 SURE, but can you give up modular reasoning? Language Expert 2 I DON’T THINK SO! Didn’t you hear that AOP is BAD for reasoning? NO WAY! Developer I desperately need to separate my crosscutting concerns. SO I AM STUCK! Day 1 Day 2 I can redefine reasoning for you. Pretty much. 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 HyperJ [Ossher, Tarr, Harrison 2001] HyperJ [Ossher, Tarr, Harrison 2001] AspectJ [Kiczales et al. 2001] AspectJ [Kiczales et al. 2001] Eos [Rajan and Sullivan 2003, 2005] Eos [Rajan and Sullivan 2003, 2005] XPI [Sullivan et al. 2005] XPI [Sullivan et al. 2005] XPI - AspectJ [Griswold et al. 2006] XPI - AspectJ [Griswold et al. 2006]

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

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

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

ptolemy.cs.iastate.edu 41 II: Components Declare Events 1 abstract class Fig { 2 List changeObservers; 3 void announceChangeEvent(Fig changedFE){ 4 for(ChangeObserver o : changeObservers){ 5 o.notify(changedFE); 6 } 7 } 8 void registerWithChangeEvent(ChangeObserver o){ 9 changeObservers.add(o); 10 } 11 } 12 abstract class ChangeObserver { 13 void notify(Fig changedFE); 14 }

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

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

ptolemy.cs.iastate.edu 44 II: Disadvantages  Coupling of observers to subjects void registerWith(Fig fe) { fe.registerWithChangeEvent(this);... }  Lack of quantification void registerWith(Point p){ p.registerWithChangeEvent(this); } void registerWith(Line l) { l.registerWithChangeEvent(this); }

ptolemy.cs.iastate.edu 45 II: Disadvantages  No ability to replace event code class MoveUpCheck extends … { void notify(Fig targetFE, int y, int delta) { if (delta < 100) { return targetFE } else{throw new IllegalArgumentException()} }