359C 10/1/05 Eric Wohlstadter Introductions –Name –Degree objective/Year –Research Area (or interests) Syllabus Aspect-Oriented Programming –AspectJ –AspectC

Course Format Two research papers per class Paper review for three out of four papers per week Each paper will be presented by a student in a short (10-15 minute) informal slide presentation Class discussion Introduction to new topics Throughout the term students are required to complete a programming or research project

Paper Reviews Between 3/4 and 1 page. –Suggestion: Times New Roman Font, single spacing, with 1 inch margins. Use a minimum of spacing between sections. Reviews will be graded on a 0-2 point scale and returned the following day of class Paper summary and answers to 5 questions

Question #1 Who will benefit from the research described in this paper and in what way will they benefit? Describe the individual's role (ex. programmer) the task performed by the individual (ex. debugging aspect-oriented programs), and the benefit (ex. makes clear how aspect-code relates to object-model)

Question #2 What are two contributions claimed by the paper authors?

Question #3 For each each contribution claim, describe how the claim is validated and whether you think the validation is convincing.

Question #4 Do you think each contribution is novel? Why or why not? If you are not familiar with the area, base your judgment on the credibility of any novelty arguments put forth in the paper. Also, use any other papers read in class as a basis.

Question #5 What opportunities for future research can you see in this area? If you are not familiar with the area, you can base your answer on a future research direction outlined in the paper.

Term Project Research proposal or a programming project Related to a topic covered in class Projects can be completed individually or in groups A one page preliminary proposal is required for both project options Group projects must include an additional 1/2 page describing how responsibility is to be divided 20 minute (+10 mins per person) class presentation at the end of the term

Research Project Ten page research proposal Argue why current work does not address a significant problem in software development You are not required to have a fully developed solution, only a proposed new direction The paper will consist of the following sections: Introduction, Background, Proposed Research, Proposed Validation It is required that at least ten sources not discussed in class are referenced in the paper References must come from certain acceptable conferences or journals (see web page) or checked with me before being used

Programming Project Become familiar with the tools, languages, and platforms that enable the adaptation of existing software The project presentation can be a traditional slide presentation or a "live" software demonstration Students giving a traditional slide presentation will demo their software to me in office hours Submission of all source code and an informal two page documentation is required

Attendance Attendance is required You will not be able to submit paper reviews for classes which you did not attend Exceptions will be made for students with documented medical excuses or academic related travel obligations

Grading Project proposal 10% Paper or Implementation 40% Project Presentation 20% Reviews/Presentation 30%

Software Adaptation Topics Aspect-Oriented Programming Interception Aspect-Oriented Middleware Adaptive Middleware/Servers Kernel Transport/Session Layer Context Sensitivity Resource Management Software Architecture Verification Gaming

Consider developing… a simple drawing application (JHotDraw)

Intuitively thinking of objects? Points, Lines… Drawing surfaces GUI Widgets … Display 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Shape moveBy(int, int) *

class Point extends Shape { private int x = 0, y = 0; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; display.update(this); } void setY(int y) { this.y = y; display.update(this); } fair design modularity but poor code modularity 1 Display 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Shape moveBy(int, int) * But some concerns “don’t fit” i.e. a simple Observer pattern crosscutting

aspect ObserverPattern { private Display Shape.display; pointcut change(): call(void Shape.moveBy(int, int)) || call(void Shape+.set*(..)); after(Shape s) returning: change() && target(s) { s.display.update(); } } ObserverPattern 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Shape moveBy(int, int) Code looks like the design

execution(void Line.setP1(Point)) Pointcuts a pointcut is a predicate on dynamic join points that: –can match or not match any given join point –says “what is true” when the pointcut matches –can optionally expose some of the values at that join point a means of identifying dynamic join points matches method execution join points with this signature

execution(void Line.setP1(Point)) || execution(void Line.setP2(Point)); Pointcut Composition whenever a Line executes a “void setP1(Point)” or “void setP2(Point)” method pointcuts compose like predicates, using &&, || and !

execution(void Shape.moveBy(int, int)|| execution(void Shape+.set*(*)); Semantic Pointcuts whenever moveBy is executed in the Shape class or a “set” method in any Shape subclass is executed Observer Pattern Pointcut

pointcut change(Shape shape): this(shape) && (execution(void Shape.moveBy(int, int)) || execution(void Shape+.set*(*)); Values at Join Points pointcut can explicitly expose certain values demonstration, not detailed explanation parameter mechanism being used

Intertype Declaration ObserverPattern aspect ObserverPattern { private Display Shape.display; static void setDisplay(Shape s, Display d) { s.display = d; } pointcut change(Shape shape): this(shape) && (execution(void Shape.moveBy(int, int)) || execution(void Shape+.set*(*))); after(Shape shape): change(shape) { shape.display.update(s); }

Advice ObserverPattern aspect ObserverPattern { private Display Shape.display; static void setDisplay(Shape s, Display d) { s.display = d; } pointcut change(Shape shape): this(shape) && (execution(void Shape.moveBy(int, int)) || execution(void Shape+.set*(*))); after(Shape shape): change(shape) { shape.display.update(s); }

class Shape { private Display display; abstract void moveBy(int, int); } class Line extends Shape { private Point p1, p2; Point getP1() { return p1; } Point getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; display.update(this); } void setP2(Point p2) { this.p2 = p2; display.update(this); } class Point extends Shape {... } Without AspectJ “display updating” is not modular –evolution is cumbersome –changes are scattered –have to track & change all callers –it is harder to think about

ObserverPattern is modular –all changes in single aspect –evolution is modular –it is easier to think about With AspectJ class Line extends Shape { private Point p1, p2; Point getP1() { return p1; } Point getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; } void setP2(Point p2) { this.p2 = p2; } class Point extends Shape { private int x = 0, y = 0; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; } void setY(int y) { this.y = y; } aspect ObserverPattern { private Display Shape.display; static void setDisplay(Shape s, Display d) { s.display = d; } pointcut change(Shape shape): this(shape) && (execution(void Shape.moveBy(int, int)) || execution(void Shape+.set*(*))); after(Shape shape): change(shape) { shape.display.update(s); }

AspectC - problem overview some elements crosscut layers –in particular, some align with specific execution paths path-specific customizations –concern scattering –dynamic context passing –associated layer violations

we want to modularize path-specific customizations AspectC constructs solution overview pointcut path_name(p1); explicit path structure & context before function_f(p2) && path_name(p1) { /* regular C code */ } attach code to points on path localize crosscutting concerns aspect path_spec_cust { }

OS refresher layers and abstractions –virtual memory layer abstractions: virtual addresses (VM object, VM pages, page map) focus issue: nonresident page means page fault… –file system layer abstractions: files (logical blocks, buffer cache) focus issue: services VM page faults prefetching –the crosscutting concern we want to modularize –amortize disk costs according to pattern of access normal access pattern  prefetch window around address sequential  prefetch after address

Conclusion Questions? Reading for Wednesday (Read both, review AspectC paper) –Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold. An overview of AspectJ. ECOOP –Yvonne Coady, Gregor Kiczales, Mike Feeley and Greg Smolyn. Using AspectC to improve the modularity of path-specific customization in operating system code. FSE