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

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

2Point

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 modularitybut poor code modularity

1

Display

2Point


Line


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

2Point


Line


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 ora “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 DeclarationObserverPattern

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); }}

AdviceObserverPattern






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; }}






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 & contextbefore 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 2001.

– Yvonne Coady, Gregor Kiczales, Mike Feeley and Greg Smolyn. Using AspectC to improve the modularity of path-specific customization in operating system code. FSE 2001.

http://www.cs.ubc.ca/~wohlstad/classes.html

Documents

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