Download presentation
Presentation is loading. Please wait.
Published bySolomon Warner Modified over 9 years ago
1
1 XAspects An Extensible System for Domain- Specific Aspect Languages Macneil Shonle (UCSD) Karl Lieberherr (Northeastern University) Ankit Shah (Northeastern University)
2
2 Talk Overview What is Aspect-Oriented Programming Limits of general purpose AOP languages How domain-specific languages can address these limits The problems with integrating several domain-specific solutions Solution: Allow principled extensions to a general purpose AOP language by using XAspects
3
3 Modular Programming Every concern goes into its own module Try to limit coupling between modules
4
4 Limitations of Modular Programming Some concerns crosscut module boundaries. Concerns become tangled. Example: logging, thread synchronization, caching, object marshalling
5
5 Aspect-Oriented Programming Encapsulate crosscutting concerns by writing separate aspects. Aspects then get woven back into the program.
6
6 Weaving Can happen at run time or compile time. weave
7
7 public class Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { return loc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { return loc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { return dim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { return dim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); } class AdjustableLocation { protected double x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronized double get_x() { return x_; } synchronized void set_x(int x) {x_ = x;} synchronized double get_y() { return y_; } synchronized void set_y(int y) {y_ = y;} synchronized void adjust() { x_ = longCalculation1(); y_ = longCalculation2(); } class AdjustableDimension { protected double width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronized double get_width() { return width_; } synchronized void set_w(int w) {width_ = w;} synchronized double get_height() { return height_; } synchronized void set_h(int h) {height_ = h;} synchronized void adjust() { width_ = longCalculation3(); height_ = longCalculation4(); } interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; } D: The First Aspect Language (Crista Lopes, 1995) Red text are synchronization concerns Green text are Remote Method Invocation concerns In this Java program, the concerns are tangled
8
8 public class Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { return loc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { return loc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { return dim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { return dim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); } class AdjustableLocation { protected double x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronized double get_x() { return x_; } synchronized void set_x(int x) {x_ = x;} synchronized double get_y() { return y_; } synchronized void set_y(int y) {y_ = y;} synchronized void adjust() { x_ = longCalculation1(); y_ = longCalculation2(); } class AdjustableDimension { protected double width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronized double get_width() { return width_; } synchronized void set_w(int w) {width_ = w;} synchronized double get_height() { return height_; } synchronized void set_h(int h) {height_ = h;} synchronized void adjust() { width_ = longCalculation3(); height_ = longCalculation4(); } interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; } public class Shape { protected double x_= 0.0, y_= 0.0; protected double width_=0.0, height_=0.0; double get_x() { return x_(); } void set_x(int x) { x_ = x; } double get_y() { return y_(); } void set_y(int y) { y_ = y; } double get_width(){ return width_(); } void set_width(int w) { width_ = w; } double get_height(){ return height_(); } void set_height(int h) { height_ = h; } void adjustLocation() { x_ = longCalculation1(); y_ = longCalculation2(); } void adjustDimensions() { width_ = longCalculation3(); height_ = longCalculation4(); } coordinator Shape { selfex adjustLocation, adjustDimensions; mutex {adjustLocation, get_x, set_x, get_y, set_y}; mutex {adjustDimensions, get_width, get_height, set_width, set_height}; } portal Shape { double get_x() {} ; void set_x(int x) {}; double get_y() {}; void set_y(int y) {}; double get_width() {}; void set_width(int w) {}; double get_height() {}; void set_height(int h) {}; void adjustLocation() {}; void adjustDimensions() {}; } D: The First Aspect Language (Crista Lopes, 1995) Instead of writing this Write this Concerns are now separated
9
9 From D to AspectJ While the D language only handled synchronization and marshalling concerns it was the inspiration for the AspectJ language. AspectJ is targeted for general crosscutting concerns…
10
10 A General Purpose AOPL AspectJ is an aspect-oriented extension to Java that allows for crosscutting concerns to be decomposed into aspects. AspectJ supports two models of separation of concerns: The Join-Point Model (dynamic) Inter-Type Declarations (static)
11
11 The AspectJ Language aspect Logging { pointcut publicMethods(): execution(public * mypackage..*(..)); Object around(): publicMethods() { System.out.println("Entering " + thisJoinPointStaticPart); Object o = proceed(); System.out.println("Leaving " + thisJoinPointStaticPart + " returning " + o); return o; } Join Point Model: Pick out dynamic events when program is running and advise these events.
12
12 The AspectJ Language Inter-Type Declarations – makes classes “open.” Keep similar methods and data together. Can make parts of the implementation aspect private. aspect Rendering { public void Particle.draw(Graphics g) { … } public void Wall.draw(Graphics g) { … } public void Vector.draw(Graphics g) { … }
13
13 Separating a Concern: The Visitor Pattern We want to visit every Book instance from a University instance. This requires two new methods. AspectJ can encapsulate the visitor pattern in a single aspect by using inter-type declarations. University Library Book University.visitBooks(BookVisitor v) Library.visitBooks(BookVisitor v)
14
14 The Visitor Pattern When the class graph is changed, new methods need to be added, and existing ones modified. University College Library Shelve Book University.visitBooks(BookVisitor v) College.visitBooks(BookVisitor v) Library.visitBooks(BookVisitor v) Shelve.visitBooks(BookVisitor v)
15
15 The Visitor Pattern Even though the aspect is encapsulated its still highly coupled to the class graph. It is coupled because the visitor concern duplicates information found in the class graph. University College Library Shelve Book University.visitBooks(BookVisitor v) College.visitBooks(BookVisitor v) Library.visitBooks(BookVisitor v) Shelve.visitBooks(BookVisitor v)
16
16 The DAJ Language A domain-specific aspect language can solve the structure dependence problem. University Library Book University College Library Shelve Book declare traversal: void visitBooks(): “from University to Book” (BookVisitor); One declaration for this concern instead of four methods. Reduced redundant information.
17
17 The DAJ Language Only by using reflection can a structure-shy solution for visitors in AspectJ work because the class graph needs to be known. The DAJ compiler itself is able to compute the class graph at compile time. The user of DAJ needs only specify the traversal requirements (e.g. where to start/end the path, what fields to bypass, what fields a visitor must go through, etc. ) Karl: Delete this slide. Karl: Delete this slide.
18
18 Domain-Specific Solutions Domain-specific solutions allow decomposition on a level unachievable with object-oriented or even general purpose aspect-oriented languages. When applied to the right problems these solutions increase productivity, the problems can be more complex, and the quality can be improved. One highly successful example are parser generator tools.
19
19 Karl remarks Parser Generator Tool? Is this the right word? Data Binding Tool seems better: JAXB is in this category and won the 2003 Java World Editor’s Choice Award (along with AspectJ) Data Binding Tool: schema (domain-specific language) defines classes and a language along with a parser and visitors (Print, Equal, Copy, …) to process the parsed object descriptions.
20
20 ( = depends on) Using Multiple Solutions Most problems cannot be solved entirely with a single domain-specific language. Yet, using multiple domain-specific languages is also difficult unless they are all tightly integrated or are highly orthogonal. E.g. a parser generator can be orthogonal to the rest of a program, while a traversal through the program cannot. Parser Generator Synchronization Language Traversal
21
21 Circular Dependencies When a domain-specific solution is not orthogonal to the program then it can create circular dependencies. Parser Generator Synchronization Language Traversal Multi-methods Karl J. Lieberherr: Example for multimethods and circular dependency on Traversal Karl J. Lieberherr: Example for multimethods and circular dependency on Traversal
22
22 Karl We position the existence of circular dependencies as the main motivation for XAspects? Is this a good strategy? Maybe you are right. In addition: need multiple communicating tools? other examples: we have two traversals and the visitors refer to the “other” traversal? We have two plug-ins, each adding to the class graph and both having traversals influenced by the addition. tool = plug-in are synonyms
23
23 What Causes Circular Dependencies? When a domain-specific plug-in needs to both create new interfaces (e.g. new types or methods) and use interfaces generated by other plug-ins. Tool A uses interfaces generated by Tool B, but Tool B uses interfaces generated by Tool A. If A goes first, it will have compilation errors and vice versa. If A and B are not tightly integrated, how can they both be used for the same project? Karl J. Lieberherr: solution = plug-in = tool? All are synonyms Karl J. Lieberherr: solution = plug-in = tool? All are synonyms Karl:2 What is the difference between the two paragraphs? Karl:2 What is the difference between the two paragraphs?
24
24 A Plug-In Architecture The circular dependency problem of tools can be solved by creating a framework such that the tools communicate using the same language. The XAspects model is a plug-in architecture to achieve this. In XAspects, tools read Java code and write AspectJ code as the only means of communication among each other.
25
25 Karl Why did we not do this 8 years ago? DemeterJ (1997) did this with the DemeterJ weaving language but the extensibility currently in XAspects was lacking. It is now easier with AspectJ, a more powerful weaving language.
26
26 Removing Dependencies XAspects splits the two different semantics of a domain-specific language: 1. The language’s external interfaces (structural meaning) 2. The language’s generated code (behavioral meaning)
27
27 Karl2 Structural meaning = external interfaces: Information for other plug-ins Includes all the information other plug-ins should know to produce their proper behavioral meaning. Could be class graph information Behavioral meaning using information from other plug-ins Might also produce more interfaces but only private interfaces that other plug-ins don’t have to know about.
28
28 Karl2 Each plug-in needs to clearly specify which context it needs because other plug-ins might modify the context. Example: A plug-in might add nodes and edges to the class graph that a traversal should not traverse. Open problem: How to specify the range of applicability of an aspect.
29
29 Compilation Phases The XAspects model breaks compilation up into six phases: 1. Source code identification 2. Generation of external interfaces 3. Initial bytecode generation 4. Crosscutting analysis 5. Generation of semantics 6. Final bytecode generation Karl: External interfaces = structural meaning. Use only structural meaning. Instead of “semantics” use behavioral meaning Karl: External interfaces = structural meaning. Use only structural meaning. Instead of “semantics” use behavioral meaning
30
30 A JC :X AJC :P LUG - INS : Source Code Identification Generation of STRUCTURAL MEANING Initial Bytecode Generation Crosscutting Analysis Generation of Behavioral meaning Final Bytecode Generation Sequence diagram for XAspects model Karl: Mention two phases with consistent terminology Karl: Mention two phases with consistent terminology Karl: Mention passive collaboration Limited approach: how far does it go is a research topic Karl: Mention passive collaboration Limited approach: how far does it go is a research topic
31
31 Source Code Identification The XAspects compiler identifies in the source code all program text that belongs to the plug-in and provides that text to the plug-in. aspect(Traversal) BookCollections { declare strategy: everyBook: “from University to Book”; declare traversal: void visitBooks(): everyBook (BookVisitor); } Traversal plug-in
32
32 Generation of External Interfaces The plug-in generates source files that define the external interface introduced by the language that the plug-in implements. aspect(Traversal) BookCollections { declare strategy: everyBook: “from University to Book”; declare traversal: void visitBooks(): everyBook (BookVisitor); } Traversal plug-in XAspects Compiler void University.visitBooks() {} ; Karl: Empty impl {} Karl: Empty impl {}
33
33 Initial Bytecode Generation The AspectJ compiler generates bytecodes from the plug-in defined external interfaces and the remainder of the program. XAspects Compiler AspectJ Compiler source code + interface stubs Java bytecodes
34
34 Crosscutting Analysis The XAspects compiler provides each plug-in the binary of the program to perform reflection or other analysis on it. XAspects Compiler AspectJ Compiler Traversal Plug-in Java bytecodes
35
35 Generation of Semantics The plug-in generates behavioral changes to the generated program in a restricted form of AspectJ code. XAspects Compiler AspectJ code Traversal Plug-in Karl: What can we say about the restriction? No structural meaning is generated in phase 2! Karl: What can we say about the restriction? No structural meaning is generated in phase 2!
36
36 Final Bytecode Generation Finally, the new behavioral code is woven into the existing code to create the complete program. XAspects Compiler AspectJ Compiler source code + new AspectJ code Final Java bytecodes
37
37 Implications A plug-in only needs to know how to read Java bytecodes (or a class graph, or other slices of a whole program) and how to write AspectJ code in order to cooperate with other plug-ins. With this technique the AspectJ language is extensible, allowing constructs to be added as if they were new language features.
38
38 The Need for DSALs? We conjecture that the gap between domain- specific aspect languages and general purpose aspect languages will always exist because any general solution cannot cover all possible ways an aspect can crosscut a system. Thus, domain-specific aspect languages can be the route for better separation of concerns.
39
39 Related Work Crista Lopes: COOL (ECOOP 94) and RIDL (OO in Operating Systems 95). Czarnecki and Eisenecker: Generative Programming Book (GP)
40
40 Domain Specific Language (DSL) A domain-specific language is a specialized, problem-oriented language. Need several DSLs to specify a complete application. General modeling DSLs (e.g., synchronization) Application oriented DSL (e.g. authorization policy) From: GP 5.5
41
41 DSLs Fixed, Separate DSLs SQL, TEX Embedded DSLs Embedded in a general purpose language, e.g. embedded SQL Modularly composable DSLs (component) Encapsulated DSLs (e.g., embedded SQL) Aspectual DSLs (e.g., synchronization)
42
42 Aspectual DSLs An aspectual DSL specification influences the semantics of other DSL specifications. Implementation of modularly composable DSLs requires a common language implementation providing the necessary infrastructure for the language plug-ins (we use AspectJ).
43
43 Advantages Of modularly composable over monolithic DSLs Reusability Scalability Fast feature turnover Have to survive based on their merits
44
44 Related Work (continued) Jim Hugunin: while aspect libraries can provide some domain- specific support in a general purpose AOP language, … some domains warrant the creation of domain-specific languages … How to extend AspectJ: XAspects is one way
45
45 Conclusions: XAspects An extensible tool to use multiple AOP approaches simultaneously. An extensible version of DemeterJ and DAJ. Works well with aspects: Data Binding, Traversal, Visitor, Synchronization. More experimentation is needed with other aspects. Future work: How to protect an aspect from misapplication. add more plug-ins, e.g. a multi-dispatch plug-in, re- engineer JAXB, JAXP, JAXM, etc. Re-engineer Quo. Connections to other aspect implementations: AspectWerkz, Nanning, JBoss, AOP Alliance, AspectC++, Jac. Karl: drop first few slides on modularity etc. (Pengcheng) Compare with Eclipse plug-ins. Karl: drop first few slides on modularity etc. (Pengcheng) Compare with Eclipse plug-ins. Karl: Sergei: main difference between Eclipse plug-ins and XAspect plug-ins is that in Eclipse there are fewer extension points while in XAspects we have a finely grained net of extension points (because AspectJ allows more extension points than Java does). Karl: Sergei: main difference between Eclipse plug-ins and XAspect plug-ins is that in Eclipse there are fewer extension points while in XAspects we have a finely grained net of extension points (because AspectJ allows more extension points than Java does).
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.