Aspect-Oriented Programming and Modular Reasoning G. KiczalesM. Mezini Presented by Alex Berendeyev

2 Overview  Goals  Example  Aspect-aware Interfaces and Their Properties  Modular Reasoning in AOP  Reasoning about Change  Open Issues

3 Goals To identify the key properties of aspect-aware interfaces and their effect on modularity Show that full power of AOP is compatible with modular reasoning

4 Example: Java interface Shape { public moveBy(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public public int getX() { return x; } public int getY() { return y; } public void setX(int x) { this.x = x; Display.update(); } public void setY(int y) { this.y = y; Display.update(); } public void moveBy(int dx, int dy) { x += dx; y += dy; Display.udpate(); } } class Line implements Shape { private Point p1, p2; public Point getP1() { return p1; } public Point getP2() { return p2; } public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; Display.update (); }

5 Example: AspectJ interface Shape { public moveBy(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public public int getX() { return x; } public int getY() { return y; } public void setX(int x) { this.x = x; } public void setY(int y) { this.y = y; } public void moveBy(int dx, int dy) { x += dx; y += dy; } } class Line implements Shape { private Point p1, p2; public Point getP1() { return p1; } public Point getP2() { return p2; } public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; } aspect UpdateSignaling { pointcut change(): execution(void Point.setX(int)) || execution(void Point.setY(int)) || execution(void Shape+.moveBy(int, int)); after() returning: change() { Display.update(); }

6 Definition of Aspect-aware Interfaces Aspect-aware interfaces are conventional interfaces augmented with information about the pointcuts and advice that apply to a module.

7 Example: Aspect-aware Interfaces Shape void moveBy(int, int) : UpdateSignaling – after UpdateSignaling.move(); Point implements Shape int x; int y; int getX(); int getY(); void setX(int) : UpdateSignaling – after returning UpdateSignaling.move(); void setY(int) : UpdateSignaling – after returning UpdateSignaling.move(); void moveBy(int, int) : UpdateSignaling – after returning UpdateSignaling.move(); Line implements Shape void moveBy(int, int) : UpdateSignaling – after returning UpdateSignaling.move(); UpdateSignaling after returning: UpdateSignaling.move(): Point.setX(int), Point.setY(int), Point.moveBy(int, int), Line.moveBy(int, int);

8 Properties of Aspect-aware Interfaces  Interfaces depend on deployment Aspects contribute to interface of classes Classes contribute to interface of aspects  Therefore, A complete system configuration is necessary to define interfaces A system may have different interfaces

9 Statements  Modules remain the same  Composition leads to new crosscutting interfaces  Modular Reasoning requires a global analysis of deployment configuration

10 Formulation of Aspect-Aware Interfaces(1)  Intensional descriptions Line implements Shape void moveBy(int, int) : UpdateSignaling – after returning UpdateSignaling.move();

11 Formulation of Aspect-Aware Interfaces(2)  Extensional descriptions UpdateSignaling after returning: UpdateSignaling.move(): Point.setX(int), Point.setY(int), Point.moveBy(int, int), Line.moveBy(int, int);

12 Formulation of Aspect-Aware Interfaces(3)  Point abstraction or reduction UpdateSignaling after returning: UpdateSignaling.move(): Point.setX(int), Point.setY(int), Point.moveBy(int, int), Line.moveBy(int, int);  Including advice kind Line implements Shape void moveBy(int, int) : UpdateSignaling – after returning UpdateSignaling.move();

13 Modular Reasoning: Criteria  Localized implementation Code is textually local  Descriptive well-defined interface Describes how a module interacts with the rest of the system  Abstraction abstracts implementation  Interface enforcement Type checking (e.g. by a compiler)  Composability Modules can be composed automatically (e.g. by a class loader)

14 Modularity Analysis: Non-AOP  Localized implementation Textually local, but the boundary also includes display update  Descriptive well-defined interface Interfaces are clearly defined, but they fail to say anything about the included display update behavior  Abstraction The internal details of the classes could change without changing the interface. The coordinates of a Point could be stored differently for example  Interface enforcement The interfaces are enforced in that the Java type checker, loader and virtual machine ensure type safety  Composability The Java loader can load these with other classes in different configurations

15 Example: Java interface Shape { public moveBy(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public public int getX() { return x; } public int getY() { return y; } public void setX(int x) { this.x = x; Display.update(); } public void setY(int y) { this.y = y; Display.update(); } public void moveBy(int dx, int dy) { x += dx; y += dy; Display.udpate(); } } class Line implements Shape { private Point p1, p2; public Point getP1() { return p1; } public Point getP2() { return p2; } public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; Display.update(); }

16 Modularity Analysis: AOP  Localized implementation Locality is improved over the non-AOP implementation because the update signaling behavior is not tangled into the Point and Line classes  Descriptive well-defined interface The interfaces are now a more accurate reflection of their behavior – update signaling is reflected in the interfaces as arising from the interaction between the aspects and the classes

17 Example: AspectJ interface Shape { public moveBy(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public public int getX() { return x; } public int getY() { return y; } public void setX(int x) { this.x = x; } public void setY(int y) { this.y = y; } public void moveBy(int dx, int dy) { x += dx; y += dy; } } class Line implements Shape { private Point p1, p2; public Point getP1() { return p1; } public Point getP2() { return p2; } public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; } aspect UpdateSignaling { pointcut change(): execution(void Point.setX(int)) || execution(void Point.setY(int)) || execution(void Shape+.moveBy(int, int)); after() returning: change() { Display.update(); }

18 Modularity Analysis: AOP (2)  Abstraction There is room for material variation in how each is implemented. For example, a helper method could be called to do the signaling, or the signaling could be logged  Interface enforcement Type checking works in the usual way, and in addition the advice is called when it should be and at no other times.  Composability It is possible to automatically produce a configuration that includes the shape classes but not the UpdateSignaling aspect.

19 Modularity Analysis: Comparison

20 Definitions  Modular reasoning means being able to make decisions about a module while looking only at its implementation, its interface and the interfaces of modules referenced in its implementation or interface  Expanded modular reasoning means also consulting the implementations of referenced modules  Global reasoning means having to examine all the modules in the system or sub-system

21 Reasoning about Change: Non-AOP  int x, y; //intentionally package public  private int x, y; Step 1: Global Reasoning public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; Display.update(); } TO public void moveBy(int dx, int dy) { p1.setX(p1.getX() + dx); p1.setY(p1.getY() + dy); p2.setX(p2.getX() + dx); p2.setY(p2.getY() + dy); Display.update(); //double update }

22 Reasoning about Change: Non-AOP(2) Step 2: Reasoning about the change  A description of the invariant Implementation of the Display class or it’s documentation  expanded modular reasoning  Structure of update signaling global reasoning – to find all calls to update and discover the complete structure of display update signaling OR expanded modular reasoning – to just find the calls from setX and setY

23 Reasoning about Change: AOP  int x, y; //intentionally package public  private int x, y; Step 1: Global Reasoning public void moveBy(int dx, int dy) { p1.setX(p1.getX() + dx); p1.setY(p1.getY() + dy); p2.setX(p2.getX() + dx); p2.setY(p2.getY() + dy); } after() returning: change() && !cflowbelow(change()) { Display.update(); }

24 Reasoning about Change: AOP(2) Step 2: Reasoning about the change  A description of the invariant Documented in UpdateSignaling  one-step expanded modular reasoning Documented in Display  two-step expanded modular reasoning  Structure of update signaling The interface of UpdateSignaling is enough  modular reasoning

25 Reasoning about Change: Comparison  global reasoning is required to find all the references to the x and y fields.  documenting and allowing the programmer to discover the invariant  discovering the structure of update signaling Non-AOPAOP one-step expanded modular reasoning one (two)-step expanded modular reasoning global reasoning OR expanded modular reasoning modular reasoning

26 Open Issues  expand our concept of aspect-aware interfaces and the analysis here to full AspectJ (call, get and set join points)  higher-order value typing like generic types, state typing, behavioral specification  increase the expressive power and abstraction of pointcuts  Support for use of annotations