AspectOriented Programming and Modular Reasoning G Kiczales M

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

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

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 3

Example: Java interface Shape { public move. By(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public int get. X() { return x; } public int get. Y() { return y; } public void set. X(int x) { this. x = x; Display. update(); } public void set. Y(int y) { this. y = y; Display. update(); } public void move. By(int dx, int dy) { x += dx; y += dy; Display. udpate(); } } class Line implements Shape { private Point p 1, p 2; public Point get. P 1() { return p 1; } public Point get. P 2() { return p 2; } public void move. By(int dx, int dy) { p 1. x += dx; p 1. y += dy; p 2. x += dx; p 2. y += dy; Display. update (); } } 4

Example: Aspect. J interface Shape { public move. By(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public int get. X() { return x; } public int get. Y() { return y; } public void set. X(int x) { this. x = x; } public void set. Y(int y) { this. y = y; } public void move. By(int dx, int dy) { x += dx; y += dy; } } class Line implements Shape { private Point p 1, p 2; public Point get. P 1() { return p 1; } public Point get. P 2() { return p 2; } public void move. By(int dx, int dy) { p 1. x += dx; p 1. y += dy; p 2. x += dx; p 2. y += dy; } } aspect Update. Signaling { pointcut change(): execution(void Point. set. X(int)) || execution(void Point. set. Y(int)) || execution(void Shape+. move. By(int, int)); after() returning: change() { Display. update(); } } 5

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

Example: Aspect-aware Interfaces Shape void move. By(int, int) : Update. Signaling – after Update. Signaling. move(); Point implements Shape int x; int y; int get. X(); int get. Y(); void set. X(int) : Update. Signaling – after returning Update. Signaling. move(); void set. Y(int) : Update. Signaling – after returning Update. Signaling. move(); void move. By(int, int) : Update. Signaling – after returning Update. Signaling. move(); Line implements Shape void move. By(int, int) : Update. Signaling – after returning Update. Signaling. move(); Update. Signaling after returning: Update. Signaling. move(): Point. set. X(int), Point. set. Y(int), Point. move. By(int, int), Line. move. By(int, int); 7

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

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

Formulation of Aspect-Aware Interfaces(1) p Intensional descriptions Line implements Shape void move. By(int, int) : Update. Signaling – after returning Update. Signaling. move(); 10

Formulation of Aspect-Aware Interfaces(2) p Extensional descriptions Update. Signaling after returning: Update. Signaling. move(): Point. set. X(int), Point. set. Y(int), Point. move. By(int, int), Line. move. By(int, int); 11

Formulation of Aspect-Aware Interfaces(3) p Point abstraction or reduction Update. Signaling after returning: Update. Signaling. move(): Point. set. X(int), Point. set. Y(int), Point. move. By(int, int), Line. move. By(int, int); p Including advice kind Line implements Shape void move. By(int, int) : Update. Signaling – after returning Update. Signaling. move(); 12

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

Modularity Analysis: Non-AOP p Localized implementation n p Descriptive well-defined interface n p 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 n p Interfaces are clearly defined, but they fail to say anything about the included display update behavior Abstraction n p Textually local, but the boundary also includes display update The interfaces are enforced in that the Java type checker, loader and virtual machine ensure type safety Composability n The Java loader can load these with other classes in different configurations 14

Example: Java interface Shape { public move. By(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public int get. X() { return x; } public int get. Y() { return y; } public void set. X(int x) { this. x = x; Display. update(); } public void set. Y(int y) { this. y = y; Display. update(); } public void move. By(int dx, int dy) { x += dx; y += dy; Display. udpate(); } } class Line implements Shape { private Point p 1, p 2; public Point get. P 1() { return p 1; } public Point get. P 2() { return p 2; } public void move. By(int dx, int dy) { p 1. x += dx; p 1. y += dy; p 2. x += dx; p 2. y += dy; Display. update(); } } 15

Modularity Analysis: AOP p Localized implementation n p 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 n 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 16

Example: Aspect. J interface Shape { public move. By(int dx, int dy); } class Point implements Shape { int x, y; //intentionally package public int get. X() { return x; } public int get. Y() { return y; } public void set. X(int x) { this. x = x; } public void set. Y(int y) { this. y = y; } public void move. By(int dx, int dy) { x += dx; y += dy; } } class Line implements Shape { private Point p 1, p 2; public Point get. P 1() { return p 1; } public Point get. P 2() { return p 2; } public void move. By(int dx, int dy) { p 1. x += dx; p 1. y += dy; p 2. x += dx; p 2. y += dy; } } aspect Update. Signaling { pointcut change(): execution(void Point. set. X(int)) || execution(void Point. set. Y(int)) || execution(void Shape+. move. By(int, int)); after() returning: change() { Display. update(); } } 17

Modularity Analysis: AOP (2) p Abstraction n p Interface enforcement n p 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 Type checking works in the usual way, and in addition the advice is called when it should be and at no other times. Composability n It is possible to automatically produce a configuration that includes the shape classes but not the Update. Signaling aspect. 18

Modularity Analysis: Comparison 19

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 p Expanded modular reasoning means also consulting the implementations of referenced modules p Global reasoning means having to examine all the modules in the system or subsystem p 20

Reasoning about Change: Non. AOP p p int x, y; //intentionally package public private int x, y; Step 1: Global Reasoning public void move. By(int dx, int dy) { p 1. x += dx; p 1. y += dy; p 2. x += dx; p 2. y += dy; Display. update(); } TO public void move. By(int dx, int dy) { p 1. set. X(p 1. get. X() + dx); p 1. set. Y(p 1. get. Y() + dy); p 2. set. X(p 2. get. X() + dx); p 2. set. Y(p 2. get. Y() + dy); Display. update(); //double update } 21

Reasoning about Change: Non-AOP(2) Step 2: Reasoning about the change p A description of the invariant n Implementation of the Display class or it’s documentation p p expanded modular reasoning Structure of update signaling n n 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 set. X and set. Y 22

Reasoning about Change: AOP p p int x, y; //intentionally package public private int x, y; Step 1: Global Reasoning public void move. By(int dx, int dy) { p 1. set. X(p 1. get. X() + dx); p 1. set. Y(p 1. get. Y() + dy); p 2. set. X(p 2. get. X() + dx); p 2. set. Y(p 2. get. Y() + dy); } after() returning: change() && !cflowbelow(change()) { Display. update(); } 23

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

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

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