IMPROVE AOP POINTCUT DEFINITION WITH ONTOLOGY-BASED ABSTRACTIONS
by Zifu Yang A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Computer Science
at The University of Wisconsin-Milwaukee May 2007
IMPROVE AOP POINTCUT DEFINITION WITH ONTOLOGY-BASED ABSTRACTIONS
by Zifu Yang
A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Computer Science
at The University of Wisconsin-Milwaukee May 2007
Major Professor
Date
Graduate School Approval
Date
ii
ABSTRACT IMPROVE AOP POINTCUT DEFINITION WITH ONTOLOGY-BASED ABSTRACTIONS by Zifu Yang The University of Wisconsin-Milwaukee, 2007 Under the Supervision of Professor Tian Zhao
Aspect-oriented programming (AOP) provides support for modular design and implementation of crosscutting concerns. Crosscutting concerns are design decisions and concepts that scatter or tangle with the natural modules of the program and cannot be decoupled from them cleanly. In this thesis, we mainly focus on AspectJ which is a realization of AOP for Java programming language. In AspectJ’s dynamic join point model, Join points are certain well-defined points in the execution of a program (e.g. execution of a method, call of a method). A pointcut is a set of join points that are selected according to some specific conditions. Advice is a piece of code that is associated with the pointcut, and the code is executed when the join points specified by the pointcut are reached during the program execution. Aspects are the units of modular implementation of crosscutting concerns by using this join point model. The current join point model has some drawbacks. The first problem is that pointcuts select join points by matching the syntactic structure of the base program (e.g. method signature, type signature). As the base program evolves, the pointcuts may accidentally capture the unintended join points or omit necessary join points due to program refactoring or functionality changes. This is known as fragile pointcut problem. The second problem is that the structural pointcut is so flexible that it can break any module boundary that is protected by encapsulation, which affects the iii
modularity of the base program and also makes local reasoning difficult. We are trying to solve the two problems by means of defining pointcuts based on contracts of the base program instead of the syntactic structure. Our contract is a program view which is an abstraction of the architecture and design decisions of the base program. A program view contains modules and messages. A module is a set of Java types(classes) and a message is a set of Java methods. A module can send and receive messages. Our view-based pointcut is defined for those join points where one module sends messages to another module. This kind of pointcut only relies on the program view instead of syntactic structures. Thus the first problem can be solved. The pointcut can only select the join points that are exposed in the program view leaving the rest of program protected. Thus the second problem can be solved. The correctness of program view is ensured by the consistency checking that validates whether the program view is conforming to the base program. The correctness of pointcut is ensured by constraints checking that validates whether the pointcut definition is allowed on the program view. Finally, the validated view-based pointcut is translated into regular AspectJ code. In our implementation, both program views and pointcut definition are represented in Web ontology language, which make constraints checking and consistency checking convenient and systematic.
Major Professor
Date
iv
TABLE OF CONTENTS
Chapter 1 Introduction
1
1.1
Aspect Oriented Programming . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Reading Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Aspect Oriented Programming 2.1
2.2
5
Introduction to AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Join points . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.2
Pointcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.3
Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.4
Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.5
Capture Crosscutting Concern using AspectJ
. . . . . . . . . .
9
Problems with AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.1
Fragile Pointcut Problem . . . . . . . . . . . . . . . . . . . . . .
10
2.2.2
Encapsulation Violation Problem . . . . . . . . . . . . . . . . .
12
3 OWL Web Ontology Language
13
3.1
Main Components Definition in OWL Ontology . . . . . . . . . . . . .
13
3.2
Ontology Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.1
Ontology Reasoning with Class Axioms . . . . . . . . . . . . . .
15
3.2.2
Ontology Reasoning with Class Descriptions . . . . . . . . . . .
15
v
3.3
3.2.3
Ontology Reasoning with Property characteristics . . . . . . . .
16
3.2.4
Benefit of reasoning . . . . . . . . . . . . . . . . . . . . . . . . .
16
Convert a Java Program to Ontology . . . . . . . . . . . . . . . . . . .
17
4 View Construction and Constraint Checking
18
4.1
Introduction to Program View . . . . . . . . . . . . . . . . . . . . . . .
18
4.2
Introduction to View-Based Pointcut . . . . . . . . . . . . . . . . . . .
19
4.2.1
View-Based Pointcut Definition . . . . . . . . . . . . . . . . . .
19
4.2.2
Generating AspectJ compatible code . . . . . . . . . . . . . . .
21
Program View Construction and Constraint Checking in Ontology . . .
23
4.3.1
Example Extension . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3.2
OWL ontology class: JavaType . . . . . . . . . . . . . . . . . .
25
4.3.3
ontology class: Jar . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3.4
OWL ontology class: JavaParameter . . . . . . . . . . . . . . .
27
4.3.5
OWL ontology class: JavaMethod . . . . . . . . . . . . . . . . .
28
4.3.6
OWL ontology class: JavaMethodNamePattern . . . . . . . . .
29
4.3.7
ontology class: JavaTypeNamePattern . . . . . . . . . . . . . .
30
4.3.8
ontology class: JavaAnnotation . . . . . . . . . . . . . . . . . .
30
4.3.9
OWL ontology class: Message . . . . . . . . . . . . . . . . . . .
31
4.3.10 OWL ontology class: Module . . . . . . . . . . . . . . . . . . .
33
4.3.11 OWL ontology class: Pointcut . . . . . . . . . . . . . . . . . . .
36
4.3.12 Generating AspectJ code from Pointcut definition . . . . . . . .
38
AOP problems revisit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.4.1
Fragile Pointcut Problem Revisit . . . . . . . . . . . . . . . . .
38
4.4.2
Encapsulation Problem Revisit . . . . . . . . . . . . . . . . . .
40
4.4.3
Sub Typing Problem . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3
4.4
5 Implementation and Case Study 5.1
43
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
43
5.2
5.1.1
Java Parsing Phase . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.1.2
Manually Editing Phase . . . . . . . . . . . . . . . . . . . . . .
45
5.1.3
Consistency Checking Phase . . . . . . . . . . . . . . . . . . . .
45
5.1.4
Expander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.1.5
Constraint Checker . . . . . . . . . . . . . . . . . . . . . . . . .
46
Case Study of Robocode . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.2.1
Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.2.2
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.2.3
Pointcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6 Related Work and Conclusion
54
6.1
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.2
Limitation and Future Work . . . . . . . . . . . . . . . . . . . . . . . .
58
Bibliography
59
vii
LIST OF FIGURES
Figure 2.1
Java code for Point, Line and Shape. Assume that all of them are in a package called example . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
AspectJ Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1
Car Ontology classes hierarchy . . . . . . . . . . . . . . . . . . . . . . .
15
4.1
A simple program view . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2
Java Ontology classes hierarchy . . . . . . . . . . . . . . . . . . . . . .
23
4.3
Ontology classes dependency . . . . . . . . . . . . . . . . . . . . . . . .
24
4.4
construction for JavaType. Point, Shape, Line and ShapeClient are names of individuals, then follows the property name and property values. The double quotes mean string. . . . . . . . . . . . . . . . . . . .
25
4.5
example.ShapeClient . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.6
construction for Jar. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.7
construction for JavaParameter . . . . . . . . . . . . . . . . . . . . . .
28
4.8
construction for JavaMethod . . . . . . . . . . . . . . . . . . . . . . . .
29
4.9
construction for JavaMethodNamePattern . . . . . . . . . . . . . . . .
30
4.10 construction for JavaTypeNamePattern . . . . . . . . . . . . . . . . . .
31
4.11 construction for JavaAnnotation . . . . . . . . . . . . . . . . . . . . . .
32
4.12 construction for Message . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.13 construction for Module . . . . . . . . . . . . . . . . . . . . . . . . . .
35
viii
4.14 construction for Pointcut . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.15 Generated AspectJ pointcut code . . . . . . . . . . . . . . . . . . . . .
39
4.16 Java Ontology properties . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.1
Implementation Skeleton. The oval represents operation. The rectangle represents data.
5.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Modules and Pointcuts for robocode. The modules are in ovals. The names of pointcut are labeled with edges. The messages are not displayed in this graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3
battle module for robocode . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.4
WhoScanWho for robocode . . . . . . . . . . . . . . . . . . . . . . . .
51
5.5
pointcut for graphics update . . . . . . . . . . . . . . . . . . . . . . . .
51
5.6
pointcut WhoScannedWho . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.7
Graphics Interface of OntPointcut . . . . . . . . . . . . . . . . . . . . .
53
ix
ACKNOWLEDGEMENTS
First I want to thank my advisor professor Tian Zhao for offering me the opportunity to do research on program languages. His suggestions and guidance led me throughout this thesis. I would like to thank professor Ethan Munson, professor K. Vairavan for being committee members for my thesis defense. Thanks to professor John Boyland for his great teaching in CS552 and CS732. Thanks to professor George Davida for his great teaching in CS755 and CS759. Thanks to my entire family who have supported me since I was born. Particularly I want to thank my parents for all their love. Thanks to my friends Liangchuan Mi, Liubo Sang, Wei Zhu, Pengfei Ye for their unlimited support, encouragement, and friendship. Thanks to my friends Morgyn Stranahan, Shane Nimmer, Paul Riedl, Julie Riedl for making me feel like at home in Milwaukee.
x
1
Chapter 1 Introduction
Aspect-Oriented Programming (AOP), first introduced in [8], improves the modular design of a program by separating crosscutting concerns from the base program. However, the current design models bring new problems including fragile pointcut problem [12, 7, 15] and encapsulation violation [2, 13] that makes local reasoning difficult. We are trying to solve such problems by defining pointcuts based on program views. 1.1
Aspect Oriented Programming Aspect-oriented programming provides support for modular design and imple-
mentation of crosscutting concerns. Crosscutting concerns are the features of the program that scatter or tangle with the natural modularity of a system, and they cannot be cleanly separated from the rest of the system and placed in modules. For example, security policy is a kind of crosscutting concern. Consider adding some security policy to an existing program. To enforce the security policy, programmers will insert access control checks at places where untrusted code calls security-sensitive operations and consequently, many units of the program will have code that enforces security checks. Moreover, the security policy must be uniformly applied to every unit. Thus both the implementation and the maintenance of the program are difficult. There are many different design models of AOP in different programming languages. In this thesis, we mainly focus on the AspectJ, which is a realization of AOP
2 for Java programming language. In AspectJ’s dynamic join point model, Join points are certain well-defined points in the execution of a program. For example, joint points can be constructor call, method call, method execution, exception handler execution, field get, field set etc. A pointcut is a set of join points that are selected according to some specific conditions. And how to specify this condition is the heart of AOP. AspectJ specifies the condition using primitive pointcut designators together with method signature, type signature, name patterns, annotations, and a logic combination of them. Advice is a piece of code that is associated with the pointcut, and the code is executed when associated join points are reached during the program execution. The code is shared and reused for those join points. Aspects are the units of modular implementation of crosscutting concerns by using this join point model. 1.2
Motivation As we stated in previous section, specifying conditions for selecting join points is
very important for AspectJ. Unfortunately, the problems come from it too. The first problem is that pointcuts select join points by matching syntactic structure of the base program including method signatures and type signatures. As the base program evolves, the pointcuts may accidentally capture the unintended join points or omit intended join points due to program refactoring or functionality changes. This is known as fragile pointcut problem. The second problem is that the structural pointcut is so flexible that it can break module boundaries that are protected by encapsulation, which affects the modularity of the base program and also makes local reasoning difficult. We are trying to solve the two problems by means of defining pointcuts based on some contracts of the base program instead of the syntactic structure. Our contract is a program view which abstracts the architecture and design decisions of the base program. A program view simply contains modules and messages. A module is a set
3 of Java types (classes) and a message is a set of Java methods. A module can send and receive messages. Our view-based pointcut is defined for those join points where one module sends messages to another module. In other words, the condition of selecting join points is “whether one module sends messages to another module”. The key idea about the program view is that aspects no longer directly depend on the concrete structure of the base program. Instead, it depends on the program view as a contract. As long as the program view is consistent with the base program, the aspect is consistent with the base program. Since a program view can semantically describe the base program, it is more robust than the syntactic structure of the base program. Therefore the view based pointcut is more robust than the regular pointcut, which addresses the fragile pointcut problem. Moreover, the view-based pointcut can only select join points allowed by the program views, which means that the program behavior of the rest of base program will not be observed or modified by the aspects. This can prevent breaking encapsulation boundaries. As we stated, the correctness of view based-pointcut highly relies on the consistency of the program view. By consistency, we mean everything represented in the program view must be the same as that in the base program. We enforce the consistency by automatically parsing the base program and comparing the parsed information with the content of the program view. The definition of view-based pointcut has several constraint rules, which will be presented in Chapter 4. These rules are enforced by a constraint checker over the valid program view. Finally we translate the valid view-based pointcut into the regular AspectJ code in three styles, enumeration, name pattern, and annotation. Users can choose any of three and use it for weaving aspects into the base program. The generated code is fully compatible with existing join point model in AspectJ. This avoids additional work of changing the AspectJ compiler.
4 In our implementation , both program views and pointcut definitions are represented in OWL Web ontology language. OWL is designed to process the content of information instead of just presenting the information like XML. OWL is good at conceptually and semantically describing information, which is suitable for our purpose of describing the semantics of a program. Furthermore, the OWL ontology reasoning and the OWL ontology editor Protege are becomes very useful in our program view construction and pointcut constraint checking. 1.3
Reading Guide The rest of the paper is organized as following: Chapter 2 introduces the concepts
of aspect-oriented programming and present a simple example of AspectJ. Chapter 3 introduces the basics of OWL Web ontology languages and explains how this language applies to program view construction and pointcut definition. Chapter 4 presents the detailed steps of constructing a program view and the constraint rules. Chapter 5 discusses the implementation of our tool OntPointcut and the case study for a Java project called robocode. Chapter 6 discusses the related work.
5
Chapter 2 Aspect Oriented Programming
Aspect-oriented programming (AOP) was first introduced in [8]. It provides support for modular design and implementation of crosscutting concerns. Crosscutting concerns are the concerns that scatter or tangle with the natural modularity of a system and cannot be decoupled from them cleanly such as error handling, synchronization, tracing, logging, and security policy enforcement. The way AOP works for crosscutting concern is analogous to the way that object-oriented programming works for common hierarchical concerns. 2.1
Introduction to AspectJ AspectJ is a realization of AOP for Java Programming language. AspectJ has
two crosscutting mechanisms. The first defines additional implementation at run time at certain join points. This is called dynamic join point model. The second contributes new operations to existing types. For example, we can add a new field or new method for some Java type from the aspect. This is called static crosscutting model. In this thesis, we will mainly focus on the dynamic join point model in AspectJ.
2.1.1
Join points
Join points are points that are certain well-defined points in the execution of a program. In AspectJ, joint points can be method call, method execution, constructor call, field select, field update, etc.
6 Figure 2.1 illustrates a simple Java program about graphics. Three Java types Point, Line, and Shape are provided. Point and Line are concrete shapes. The static function Display.update() is called when the location of a shape is changed. In this example, A field get join point is located in method Line.getP1() when the field p1 is read. The call join point is located in method setX(int y) when Display.update() is called from some object of Point. 2.1.2
Pointcut
A pointcut is a set of join points that are picked out from the base program according to some specific conditions. And optionally it can expose some context variables in the execution of the program. AspectJ has several primitive pointcut designators which are the core mechanism for matching join points. Complex pointcut designators can be composed using primitive designators including within (typeSignature), withincode (methodSignature), call (methodSigature), execution (methodSignature) and so forth, plus logic opertors including OR ||, AND &&, NOT !. For example, in Figure 2.1, we can make primitive pointcut designators such as call (public void setX(int)), within (Point), and execution(public void moveBy(int, int). And we can define complex named pointcut designators by combining primitive pointcut designators as following.
pointcut change (): ( c a l l ( public void setX ( int )) || c a l l ( public void moveBy ( int , int )) ) && within ( Point )
Name pattern and annotation are also supported by the primitive pointcut designator. For example, call (* set*(..) is a pointcut designator with name pattern * set*(..) which matches any Java method whose name begins with “set”. And call
7
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 .update (); } } 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 () } }
Figure 2.1: Java code for Point, Line and Shape. Assume that all of them are in a package called example
8 (@Set * *(..) is a pointcut designator with annotation @Set, which matches any call of the Java method that is annotated with @Set. 2.1.3
Advice
Advice is a piece of method-like code that is associated with the pointcut, and the code is executed when join points selected by the pointcut is reached during the program execution. AspectJ supports before, after, around advices for the associated pointcut. before advice runs as a join point is reached, before the program proceeds with the join point[26]. For example, in the following before advice, the message is printed before the method body of void setX(int) starts running, just after the integer argument is evaluated.
before (): c a l l ( void setX ( int )){ System . out . println ( " about to setX ! " ); }
after advice on a join point runs after the program proceeds with that join point[26]. There are three kinds of after advice: after returning, after throwing and the plain after. after returning advice runs when a join point terminates normally. after throwing advice runs when a joint point throws an exception. The plain after could be either of them. If all of them are declared for the same join point, the plain after advice runs after the other two kinds of after advices. For example, in the following advice, the message “changed!” is printed after the join points selected by the pointcut change are finished. In other words, according to the definition of pointcut change in previous section, the message is printed after the method body of public void setX(int) or public void moveBy(int, int) has run, just before control is returned to the caller.
9 a f t e r (): change (){ System . out . println ( " changed ! " ); }
around advice on a join point runs as the join point is reached, and has explicit control over whether the program proceeds with the join point[26]. We can consider it as wrapping around the join point. 2.1.4
Aspects
Aspects are the units of modular implementation of crosscutting concerns by using this join point model. It includes the pointcut and advice. For example, the pointcut change and the advice after():change() forms the aspect ChangeTracking.
aspect ChangeTracking { pointcut change () ( c a l l ( public void setX ( int )) || c a l l ( public void moveBy ( int , int )) ) && within ( Point ); a f t e r (): change (){ System . out . println ( " changed ! " ); } }
2.1.5
Capture Crosscutting Concern using AspectJ
In Figure 2.1, We observed that Display.update() is called at the end of four methods Point.setX, Point.setY, Point.moveBy and Line.moveBy. The concern is that whenever the location of Line or Point changes, the function Display.update() must be called to tell Display class to update the graphics. Display.update() scatters all over the example program and this concern is a crosscutting concern. To explicitly and modularly capture this crosscutting concern, we design an aspect UpdateSignaling. The code is illustrated in Figure 2.2. Display.update()
10 is removed from the base program and put in the aspect. Pointcut change() picks out the calls to the methods Point.setX, Point.setY or Shape+.moveBy (Note that Shape+ is a type name pattern and represents Shape and Shape’s subtype). The ad-
vice {after () returning:
change()} means that after any of the calls specified
by pointcut change() is returned, Display.update() must be executed. As we see, UpdateSignaling accomplishes the same functional goal as what we did in Figure 2.1 but it provides better modularization. 2.2
Problems with AspectJ In AspectJ, there are several ways of specifying pointcut designators. The first is
to explicitly enumerate the type signature or method signature. The second is using a name pattern which is naming convention implicitly applied to the base program. The third is annotation. The way of enumeration introduces a high degree of coupling between the base program and aspect. This makes aspect reuse difficult. The way of name pattern was designed to reduce the coupling of base program and aspect. However, the naming convention is not enforced by the compiler or any other tool, resulting in easy mismatches and error-prone aspect. Enumeration and name pattern cause the fragile pointcut problem which we will discuss in Section 2.2.1. Using annotation improves the robustness of aspect. However, whether a method should be annotated is hard to verify. Also, annotation can’t address the encapsulation violation problem that we will discuss in Section 2.2.2.
2.2.1
Fragile Pointcut Problem
With enumeration and name pattern, the pointcut can easily be broken when the base program changes. Considering the following frequently used operations listed on the refactoring menu of Eclipse IDE.
11
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 (): c a l l ( void Point . setX ( int )) || c a l l ( void Point . setY ( int )) || c a l l ( void Shape +. moveBy ( int , int )); a f t e r () returning : change () { Display .update (); } }
Figure 2.2: AspectJ Solution
12 • Rename: Take the example in Figure 2.2. If we rename the type Point to MyPoint, then {call (void Point.setX(int)} is empty. • Change method signature: If we change the signature of void setX(int) to void setX(double), then {call (void Point.setX(int)} is broken. • Move: Suppose originally all of the classes are in the package example, and a pointcut designator within (example.*) is used. If we move Point to another package, this designator is broken. • Pull up or Push Down: If we pull up or push down a method to its parent class or subclass, and if that method is specified by method signature in aspect, the pointcut will be broken because the original method doesn’t exist any more. The above examples are about refactoring. When it comes to semantic changes of the base program, maintaining pointcut is even harder. This kind of problem is called the fragile pointcut problem. It hinders the software evolution.
2.2.2
Encapsulation Violation Problem
In the current model of AspectJ, it doesn’t provide effective ways to control the exposure of join points to the aspects. Every join point in the base program is visible to the aspects without any protection. In other words, we don’t have a straightforward way to specify the rule “Point class cannot be affected by any aspects”. This is called the aspect encapsulation violation problem. In Chapter 4, we will discuss how the view based pointcut addresses the above two problems.
13
Chapter 3 OWL Web Ontology Language
In this chapter we will introduce the Web Ontology language (OWL)[22]. This language is used for us to construct the program view and view-based pointcuts. OWL is good at conceptually and semantically describing the information. It is designed to process the content of information instead of just presenting the information like XML and RDF. It works like a knowledge base with formal semantics along with it. Therefore, OWL satisfies our needs of storing Java base program information along with the constraint checking rules on it. OWL classifies information into ontology classes, and it defines properties which are the binary relations for individuals and data values. A reasoner is designed to determine if an ontology is consistent and may further infer more information from the initial ontology according to class axioms, class descriptions, and the characteristics of properties. This chapter is arranged as following. First, we introduce the basic concept and terminology about OWL. Second, we introduce how to do reasoning for OWL. Finally, we will briefly explain how to convert a Java program to OWL. The details of doing this is in Chapter 4. 3.1
Main Components Definition in OWL Ontology The main components of OWL includes class, property, and individual. The
definitions of them are given as following.
14 • Class: A class is a group of individuals.
The individuals in the same
group share the same properties defined for this group. One class can be subclassOf another class. If class A is subClassOf class B, that means the individuals in class A is a subset of class B. • Individual: Individuals are instances of classes. Individuals in the same class C share the same properties whose domain is C or greater than C. • Property: Properties are used to state relationships between individuals or between individuals and data values (string, int, etc.). A property has domain and range. The domain limits the individuals to which the property can apply. The range of a property limits the individuals or data values that the property may have as its values. As an example, we take cars as our domain of interest. We see from Figure 3.1 that ToyotaCar is a subclass of Car. That means any individual car in class ToyotaCar must be in class Car. This makes sense because Toyota car is a kind of car. We define two individuals which are ToyotaCar 1 and ToyotaCar 2. They are instances of the ontology class ToyotaCar. We define two properties hasEngine and hasVehicleID. hasEngine links Car to Engine. Here Car is the domain and Engine is the range. Since Engine is a set of individuals, this property is called ObjectProperty. hasVehicleID links Car to string. Since string is a data type, this property is called DataProperty. 3.2
Ontology Reasoning As we mentioned earlier, the OWL web ontology language is designed not only
for presenting information, but also for providing formal semantics for reasoning. The rules used for ontology reasoning can be class axioms, property restrictions, relations between properties, property characteristics etc. In this section, we shall give some examples about doing ontology reasoning.
15
Figure 3.1: Car Ontology classes hierarchy
3.2.1
Ontology Reasoning with Class Axioms
The class axioms include subClassOf, equivalentClass, and disjointWith etc. We shall give an example about disjointWith. In our car ontology, you might ask “Can one individual belong to both the ontology class BMWCar and ToyotaCar?” The intuitive answer is No, otherwise everyone would like to buy BMW with a Toyota price. But how can we let the reasoner tell us it can’t happen? The disjointWith axiom will apply to such situation. In our definitions of BMWCar and ToyotaCar, if we put an axiom saying that BMWCar disjointWith ToyotaCar, and if someone accidentally put ToyotaCar 1 into the class BMWCar, a reasoner will report the violation of disjoint. 3.2.2
Ontology Reasoning with Class Descriptions
The class descriptions include enumeration, property restriction, union, intersection etc. Note that, the property restriction only applies for the specified ontology class. It is different from the property characteristics which globally applies to all ontology classes. The property restriction for ontology class can be value constraints such as allValuesFrom, someValuesFrom and hasValue. It can also be cardinality constraints such as maxCardinality, minCardinality or cardinality. As an example, if we want any individual in the class Car to have exactly one engine, no more, no less, what should we do? To achieve the condition “at least one”,
16 we put the someValuesFrom(existential) on the property hasVehicleID for the class Car. To achieve the condition “at most one”, we can either set the maxCardinality to one for Car or set the property characteristics of hasVechivleID to functional which is introduced in next section. Now if ToyotaCar 1 has two ID(#1234567 and #321456) or has no ID, the reasoner can report the inconsistency.
3.2.3
Ontology Reasoning with Property characteristics
A property has domain and range descriptions. Besides, a property can be a sub property of another property. A property can be equivalentProperty to another property or be inverseOf another property. A property can be functional which is a global cardinality constraint saying that this property can only have one value (unique). We give an example about doing reasoning with the domain and range descriptions. Suppose there is an individual XYZ which says nothing about which class it belongs to, but in the ontology, there is a relation that {XYZ hasEngine en-toyota1991E}. Since we already know hasEngine maps from Car to Engline and XYZ must satisfy the domain, the reasoner can infer XYZ must be an individual belonging to class Car. For more details about OWL Web Ontology language, refer to [22] and [23].
3.2.4
Benefit of reasoning
The benefit of ontology comes from the semantics and the reasoning which make maintenance of large ontology feasible. When we construct an ontology, we don’t need to make it complete at the beginning. We only have to provide the intuitive knowledge such as intuitive classes hierarchy and intuitive property relations. A reasoner can help to infer the complete class hierarchy (e.g. multiple inheritance), report constraint rules violation, and yield a consistent and precise ontology. This is a strong reason for us to choose OWL web ontology language as our tool for pointcut checking.
17 3.3
Convert a Java Program to Ontology We create the ontology classes such as JavaType, JavaMethod, JavaParameter,
Module, Message etc, and create properties such as hasName, send, receive etc. After that we take the elements and relations (e.g. Java method A is declared in Java type B) in a Java program and put them as individuals and property values. This ontology can then be used for reasoning and constraints checking. In order to take advantage of the reasoner, we should use ontology class axioms, class descriptions, property characteristics etc as much as possible. For example, since we know that a Java type can be uniquely identified by its qualified name, we can set the property hasName to functional and even inverse functional for JavaType. The idea is that we want to reveal as many restrictions of a Java program as possible to the standard rules of ontology to have the full checking power of a standard ontology reasoner. There are some specific rules which are beyond the standard rules. For example, in our car ontology, if we want to enforce a rule that “The best car has the highest price”, the standard OWL reasoner has no idea about the highest price which must be computed by iterating all of the car individuals and comparing the prices. Instead, we need to make an extra tool for such checking and inference. We will discuss the customized checking rules for the program view which is represented in ontology in chapter 4.
18
Chapter 4 View Construction and Constraint Checking
The program view is a contract to a base program. Aspects rely on program view instead of the detailed structures of the base program. In this chapter, we first introduce some basic characteristics of the program view in section 4.1. Then we introduce the definition of the view-based pointcut and how to translate it to the regular AspectJ code in section 4.2. Next, we shall introduce the steps for construction of a program view. Readers who are not interested in the details can ignore the section 4.3. Finally, we revisit the problems we stated in Chapter 2 with the approach of view-base pointcuts. 4.1
Introduction to Program View Figure 4.1 illustrates a simple program view. There are three modules in this
figure, Shape Client A, Shape Client B and Shape Host C. Module C includes all of the Java Shape classes such as Point and Line. Module A and B are some functional modules that are doing operations on Module C. Just consider module A and B as some extension to the sample Java program in Figure 2.2. In figure 4.1, the solid arrow means there is a message sent from one module to another module. The dashed arrow is used to demonstrate the relation between the two modules in the base program but not exposed in the current program view (It could be in another program view for different purposes). In this figure, the only message exposed is the message Change sent from Module A to Module C. An important
19
Figure 4.1: A simple program view
property of the program view is • A program view doesn’t need to expose any relation in the base program but only the ones that we are interested in and we intend to expose. The exposed relations are open to the aspect while the unexposed relations are protected. Figure 4.1 abstracts the semantics of the base program in an architectural level. Even if there are changes for the members of Module C or Module A, the relation that Module A sends the message Change to Module C remains unchanged. Consequently, the pointcut defined upon this relation is still valid. Another property of the program view is • A program view should abstract ”send-receive” relation semantically. The relation is unlikely to change when the base program evolves. 4.2
Introduction to View-Based Pointcut
4.2.1
View-Based Pointcut Definition
We define the view-based pointcut as below to capture the relation that Shape Client Module A sends message Change to Shape Host Module C.
20 pointcut ModuleA2ModuleC (): within ( moduleA ) && t a r g e t ( moduleC ) && c a l l ( change );
The within limits the sender to “Module A”. The target limits the receiver to “Module C”. The call statement limits the message from change. This exactly captures the “send-receive” relation in the program view. If someone makes a pointcut like this:
pointcut ModuleB2ModuleC (): within ( moduleB ) && t a r g e t ( moduleC ) && c a l l ( change );
This pointcut states the relation that Module B sends a message change to Module C which may actually happens in the base program. However, it violates the program view because the relation is not existed in the program view. In addition, we can expose context variables such as “this” variable and common parameters to the pointcut. A complete version of view-based pointcut is designed as:
pointcut ModuleA2ModuleC ( ExposedThisType thisObject , Expo sedTargetType targetObject , Expo sedParameter1 p1 Expo sedParameter2 p2 ...): within ( moduleA ) && t a r g e t ( moduleC ) && c a l l ( change ) && t h i s ( thisObject ) && t a r g e t ( targetObject ) && args ( p1 , p2 ..)
The expression this(thisObject) exposes the the context variable thisObject which is the current caller object. target(targetObject) exposes the context vari-
21 able targetObject which is the callee object. args(p1,p2..) exposes the common parameters of the methods in a message.
4.2.2
Generating AspectJ compatible code
The pointcut defined in previous section has a small problem because it doesn’t compile in the current AspectJ system. Module A, Module C, and Message change are not recognized by the compiler. There are two ways to solve this problem. One way is to extend the compiler to support this syntax; the other way is to translate the view-based pointcut into AspectJ compatible code. We chose the second way because it is more flexible and practical. The view-based pointcut can be translated into three styles of regular AspectJ code. The first is enumerating all of the elements in a module and a message. In this style, the module or message is translated to a combination of every single Java type or Java method . For example, we assume that module A has only one Java class ShapeClient. The module C has two Java classes Point and Line. And all of the Java classes are located in the example package. Then the AspectJ code is generated as following.
pointcut ModuleA2ModuleC ( example . ShapeClient thisObject , example . Shape targetObject ): within ( example . ShapeClient ) && ( c a l l ( void example . Shape . Move ( int , int )) || c a l l ( void Point . setX ( int )) || c a l l ( void Point . setY ( int )) ) && ( t a r g e t ( example . Point ) || t a r g e t ( example . Line )) && t h i s ( thisObject ) && t a r g e t ( targetObject ) && args ( int ,..);
We see in the above code, the expression {call (change)} is replaced by {(call (void example.Shape.Move(int, int)) ||call (void Point.setX(int)) ||call
22 (void Point.setY(int))}. The expression {within(moduleA)} is replaced by {within (example.ShapeClient)}. And the expression {target(moduleC)} is replaced by {(target(example.Point) || target(example.Line))}. The second style is called name pattern style, in which the module or message is translated to AspectJ name patterns. The example code is as following. We see that the call expression is translated to {call (void *.set*(..))
||call (void
*.move*(..))}.
pointcut ModuleA2ModuleC ( example . ShapeClient thisObject , example . Shape targetObject ): within ( example . ShapeClient ) && ( c a l l ( void *. set *(..)) || c a l l ( void *. move *(..)) ) && ( t a r g e t ( example . Point ) || t a r g e t ( example . Line )) && t h i s ( thisObject ) && t a r g e t ( targetObject ) && args ( int , ..);
The third style is called annotation style. In this style, the module or message is translated to some Java annotation. For example, in the following generated code, the call expression is translated to {within (@example.Client *)}. It means within any class that is annotated with example.Client.
pointcut ModuleA2ModuleC ( example . ShapeClient thisObject , example . Shape targetObject ): within ( @example . Client *) && c a l l ( @example . Change * *(..)) && @target ( example . Host ) && t h i s ( thisObject ) && t a r g e t ( targetObject );
a question is raised, “Are the three kinds of generated code equal?” The answer is Yes. users can choose any of the three for use. The three kinds of pointcuts are equal iff
23 they imply the same set of members for module A, module C and the message change. This constraint is checked during in the program view construction. Refer to 4.3.9 and 4.3.10 for more information. 4.3
Program View Construction and Constraint Checking in Ontology In this section, we introduce the details of program view construction using OWL
ontology. We shall use the same Java example from Chapter 2 but with some extension. Readers who are not interested in the details of construction might ignore this section and go directly to section 4.4. Figure 4.2 illustrates all of the ontology classes we have designed. It is a simple class hierarchy without any subclassing relation. Figure 4.3 illustrates the dependencies for the ontology classes. The arrows indicate the composition relations. For example, Module is used to compose Pointcut. 4.16 is a complete list of all properties we designed. One can look up the domain, range and other characteristics for property definitions in this figure.
Figure 4.2: Java Ontology classes hierarchy
24
Figure 4.3: Ontology classes dependency
25 (JavaType) Point hasName:
"example.Point"
hasName:
"example.Line"
Line Shape hasName: ShapeClient hasName:
"example.Shape" "example.ShapeClient"
Figure 4.4: construction for JavaType. Point, Shape, Line and ShapeClient are names of individuals, then follows the property name and property values. The double quotes mean string.
4.3.1
Example Extension
We extend the code in Figure 2.1 with a new Java class ShapeClient which uses the shapes such as Point and Line. The extended code is put in Figure 4.5. We assume that, all of the classes are in a package called example. Then the qualified name for the class Shape is example.Shape, the qualified name for the class Line is example.Line, and analogously for the rest of them.
4.3.2
OWL ontology class: JavaType
The ontology class JavaType is defined as a set of Java types including Java class and Java Interface. JavaType has one property hasName which is defined as domain:JavaType → range:string. The value of this property represents the qualified name of a Java type by which a Java Type can be uniquely identified. Individuals in JavaType are our basic elements for constructing higher level individuals like modules and messages. Figure 4.4 illustrates four individuals we have constructed from the example Java code. Point, Shape, Line, and ShapeClient are names of individuals, then follows the property name and property values. The constraint checking rule for this ontology class is as following. It makes sure the ontology is consistent with the
26
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 ; } } class ShapeClient { void drawLine (){ line . setX (0); line . MoveBy (2 ,2); ... } void drawPoint (){ point . setY (10); point . MoveBy (2 ,2); } }
Figure 4.5: example.ShapeClient
27 base Java program. • For any individual, the Java type specified by hasName must exist in the current Java base program. 4.3.3
ontology class: Jar
The ontology class Jar is used to record where the Java base program is. It doesn’t participate in the program view. An individual of Jar represents exactly one Java Jar file. A Java base program can contain several individuals of Jar. The only property for this ontology class is hasPath which is defined as {domain:Jar → range:string}. Suppose that the example Java code in Figure 4.5 is compressed into a jar file called example.jar. Then we can make an individual to represent example.jar as in Figure 4.6. It says that the example.jar is located at ./lib/example.jar". (Jar) example.jar hasPath:
"./lib/example.jar"
Figure 4.6: construction for Jar.
4.3.4
OWL ontology class: JavaParameter
JavaParameter has two properties. The first property parameterType is defined as {domain:
JavaParameter → range:
JavaType}. From figure 4.16, at the char-
acteristics column, we can see that this property is functional by which it means one parameter has exactly one declared Java type, no more and no less. If this condition is not satisfied, the ontology will be considered as inconsistent for a general ontology reasoner. The other property javaParameterPosition is defined as {domain: JavaParameter → range:
int}. This property is used to denote the index of a pa-
rameter. When we expose parameters in view-based pointcut, AspectJ supports the index of a parameter. For example, args(*, int) says the second parameter must be
28 int. The index information is helpful for a constraint checker. In other words, in a
pointcut definition, if a parameter of type int with index 0 is exposed, the constraint checker must check whether every method in the declared message has type int as the first parameter. Figure 4.7 shows two individuals int 0 and int 1. (JavaParameter) int_0 hasParameterPosition: parameterType:
0 int
hasParameterPosition: parameterType:
1 int
int_1
Figure 4.7: construction for JavaParameter
4.3.5
OWL ontology class: JavaMethod
Analogously, individuals from JavaMethod are also basic elements to construct higher level components like Module and Message. JavaMethod has two properties. hasName is defined as {domain:
JavaMethod → range:
string}. The value of
this property represents a Java method signature which can uniquely identify a Java method. The other property hasJavaParameter is defined as {domain:JavaMethod → range:JavaParameter}. We see that the second property duplicates some information in the first property, because the parameters of a Java method can be inferred from the signature of a Java method. This obeys our “simple” rules mentioned earlier in chapter 3. The reason is that the extra duplicated information is used frequently in the constraint checking. To avoid extra computation, we store this information statically as the property value. For example, if the checker needs to check if the exposed context parameter actually exists for some Java methods, it can directly retrieve information from this property without doing any string parsing from the hasName property.
29 The good thing is we don’t need to worry about maintaining the correctness of these redundant values, because it will be taken care of by an ontology expander which infers a precise ontology from the initial simple ontology. Whenever the signature changes, the inference will be done again. This concept was mentioned in Chapter 3 before. We name this kind of characteristics ReadOnly which means read only to the ontology maintainer, but it is writable for the expander. Figure 4.8 illustrates three individuals of JavaMethod. Notice that hasJavaParameter property is an object property, thus its value is some other individuals int 0 and int 1 which were already defined in Figure 4.7. (JavaMethod) PointSetX hasName: "example.Point::void setX(int)" hasJavaParameter: int_0 PointSetY hasName: "example.Point::void setY(int)" hasJavaParameter: int_0 MoveBy hasName: "example.Shape::void moveBy(int, int)" hasJavaParameter: int_0 int_1 Figure 4.8: construction for JavaMethod
The constraint checking rule for this ontology class is: • For any individual, the Java Method specified by hasName must exist in the current Java base program.
4.3.6
OWL ontology class: JavaMethodNamePattern
JavaMethodNamePattern has two properties. The first property hasPatternStr is defined as {domain:JavaMethodNamePattern ∪ JavaTypeNamePattern → range: string}. The domain here is shared by two ontology classes. It can be considered as the union of two sets. The second property inferredJavaMethod is defined as
30 {domain:JavaMethod ∪ JavaAnnotation → range:
JavaMethod}. The domain is
also shared. The value of this property is “ReadOnly” because it is automatically inferred by the expander. When an individual of JavaMethodNamePattern is declared, we can take it to compare with all of the existing Java methods in Java base program. If they are matched, we put the matched JavaMethodindividual as a value of inferredJavaMethod. If the individual of the matched Java method is not declared so far, the expander will automatically create an individual for it. There are two reasons we have inferredJavaMethod for JavaMethodNamePattern. The first reason was mention earlier. It is to avoid extra computation. The second reason is that one can visually view the results of the name pattern and check if they are intended to be added. Figure 4.9 shows an individual of JavaMethodNamePattern. There are two pattern strings void *.set*(..)" and ‘‘void *.move*(..)". They together match three Java methods. (JavaMethodNamePattern) change_pattern hasPatternStr: "void *.set*(..)" "void *.move*(..)" inferredJavaMethod: PointSetX PointSetY MoveBy Figure 4.9: construction for JavaMethodNamePattern
4.3.7
ontology class: JavaTypeNamePattern
JavaMethodNamePattern is quite analogous to JavaMethodNamePattern. In Figure 4.10 there is one individual named examplePackage trying to capture all of the Java types in the package “example”.
4.3.8
ontology class: JavaAnnotation
JavaAnnotation has three properties. inferredJavaMethod, inferredJavaType,
31 (JavaTypeNamePattern) examplePackage hasPatternStr: "example.*" inferredJavaType: Point Line Shape ShapeClient Figure 4.10: construction for JavaTypeNamePattern
and annotationType. The first two of them were already mentioned in previous sections because of shared domain. The third one is defined as {domain:JavaAnnotation → range:JavaType}, which denotes which Java type implements this annotation. This property is functional because one annotation can be implemented by exactly one Java type. For example, if we have a Java annotation individual @Host, which is implemented by a Java type example.Host, then example.Host will be stored as a value of annotationType to uniquely identify this Java annotation. The expander will search the whole Java base program for Java types and Java methods that are annotated with @Host and put the results to inferredJavaMethod and inferredJavaType.
Suppose we have three Java annotations in our java project, @Client, @Host and @Change. Their corresponding java types are example.Client, example.Host and example.Change respectively. Assume that @Client annotates the Java type example.ShapeClient. @Host annotates Java types example.Point, example.Line, and example.Shape. @change annotates void example.Shape.moveBy(int, int), void example.Point.setX(int), and void example.Point.setY(int). Figure 4.11 illustrates three individuals of JavaAnnotation under our assumption. 4.3.9
OWL ontology class: Message
The individual of Message essentially represents a set of individuals selected from JavaMethod. There are totally three ways of doing the selection. hasJavaMethod is de-
fined as {domain: Message → range: JavaMethod}, which is used for selecting Java methods by enumeration. hasJavaAnnotation property is defined as {domain:Message
32
(JavaAnnotation) @Client annotationType: inferredJavaType: inferredJavaMethod:
"example.Client" ShapeClient
annotationType: inferredJavaType: inferredJavaMethod:
"example.Change"
annotationType: inferredJavaType: inferredJavaMethod:
"example.Host" Point Line Shape
@Change
MoveBy
PointSetX
PointSetY
@Host
Figure 4.11: construction for JavaAnnotation
33 → range:JavaAnnotation}, which is used for selecting Java methods by annotation. hasJavaMethodNamePattern is used for selecting Java methods by method name pattern. The property hasCommonParameter is defined as {domain: Message → range: JavaParameter}, the values of which is “ReadOnly” because the common parameters
can be automatically computed from the set of selected Java methods. Figure 4.12 illustrates how to construct the Change message in several ways. Note that the alternative configuration 3 used all of the three primitive ways at the same time. We require that, if any of the two or more primitive ways are used for one individual at the same time, they must be equivalent, which means the annotation, name pattern or enumeration must imply the same set of Java methods. For example, in configuration 3, the Java method implied by Change pattern must be {MoveBy, PointSetX, PointSetY}. The Java methods implied by @Change must be the same set too. With the equality checking, we can guarantee that all of the three styles of generated AspectJ code are equivalent. And also the equality check can help detect errors when program evolves, the example is shown in section 4.4. The constraint checking rule for this ontology class is: • For any individual, the equality must be satisfied if multiple ways of selection are used for the same individual.
4.3.10
OWL ontology class: Module
The individual of Module represents a set of Java types. The properties hasJavaType, hasJavaTypeNamePattern and hasJavaAnnotation are analogous to those in Message.
They are three different ways of composing a module. The value of property hasCommonSuperType represents the common super type of a Module individual. It is “ReadOnly” because the common super Java type can be automatically computed from the Java type elements in a module.
34
(Message) (Configuration 0) Change hasJavaMethod: MoveBy PointSetX PointSetY hasJavaMethodNamePattern: hasJavaAnnotation: hasCommonParameter: int_0 (Configuration 1) Change hasJavaMethod: hasJavaMethodNamePattern: hasJavaAnnotation: @Change hasCommonParameter: int_0 (Configuration 2) Change hasJavaMethod: hasJavaMethodNamePattern: Change_pattern hasJavaAnnotation: hasCommonParameter: int_0 (Configuration 3) Change hasJavaMethod: MoveBy PointSetX PointSetY hasJavaMethodNamePattern: Change_pattern hasJavaAnnotation: @Change hasCommonParameter: int_0
Figure 4.12: construction for Message
35 (Module) Client_Mod hasJavaType: ShapeClient hasJavaTypeNamePattern: hasJavaAnnotation: @Client hasCommonSuperType: send: Change receive: Host_Mod hasJavaType: Point Line hasJavaTypeNamePattern: hasJavaAnnotation: @Host hasCommonSuperType: send: receive: Change Figure 4.13: construction for Module The other two interesting and important properties are send and receive, both of which have {range:
Message} and are one of the core characteristics for a module.
By send a message, we mean at least one Java type in this module calls at least one Java method in the message. By receive some message, we mean that at least one Java type in this module has declared or implemented at least one Java method in the message. By putting a message in send or receive, the programmer is exposing (exporting) the interfaces of the message to the outside. Our checking tool will verify whether the exposed message is truly sent or received by this module. Figure 4.13 lists two modules. One is Client Mod, and the other is Host Mod. The Client Mod is specified by using annotation and enumeration. We require that the set of Java types specified by enumeration and annotation are equal. This constraint rule is similar to that in Message. If any two or more primitive ways of selection are used, they must imply the same set of Java types. In figure 4.13, we didn’t use any name pattern because there isn’t an appropriate name pattern for them in this example. The constraint checking rule for this ontology class is: (1) For any individual, the equality must be satisfied for multiple ways of doing
36 elements selection. (2) For any individual, the messages specified by send property must be sent by this module according to our definition. (3) For any individual, the messages specified by receive property must be received by this module according to our definition.
4.3.11
OWL ontology class: Pointcut (Pointcut) UpdateSignaling args: call: target: within: targetType: thisType:
int_0 Change Host_Mod Client_Mod Shape ShapeClient
Figure 4.14: construction for Pointcut
Everything we have done so far was to prepare for the definition of Pointcut. Pointcut has six properties args, within, call, target, targetType, thisType . They
all have the same domain Pointcut. And refer to Figure 4.16 for ranges of these properties. args tells the method parameters we want to expose in a pointcut. within,call and target correspond to the key words within, call and target in AspectJ respectively. targetType tells which Java type can be exposed to a pointcut for a target variable. thisType tells which Java type can be exposed to a pointcut for this variable. Each property must be configured by users and the constraint checker will enforce the following checking rules: (1) For a pointcut individual, the exposed parameter must be some common parameter for all of the messages specified by the property call. To verify that,
37 we can iterate all of the message individuals in the property call. For each message, we can retrieve the set of values in property hasCommonParameter and check if the exposed parameter is in that set. For example, in figure 4.14, we need to check if all of the methods MoveBy, PointSetX, and PointSetY have int 0 as their parameter. In other words, we need to check if all of those methods has type int as the first parameter. (2) For any pointcut individual, the message in the property call must be sent by the module in the property within. To verify that, we can retrieve the set of values from the property send of the specified module and check whether the message is in that set. For example, in figure 4.14, we need to check if the module Client Mod has the message Change in its property send. (3) For any pointcut individual, the message in the property call must be received by the module in the property target. To verify that, we can retrieve the set of values from the property receive of the specified module and check whether the message is in that set. For example, in figure 4.14, we need to check if the module Host Mod has the message Change in its property receive. (4) For any pointcut individual, the exposed Java type specified by the property thisType must be a common super type for all java types implied by the module
in the property within. To verify that, we can retrieve the set of values from the property hasCommonSupertype of that specified module and check if the exposed Java type is in that set. (5) For any pointcut individual, the exposed Java type specified by targetType must be a common super type of all java types implied by the module in the property target. The checking is the same as the previous one. In figure 4.14, the pointcut UpdateSignaling selects the join points where Client Mod is sending a message Change to Host Mod. The exposed types of context variables are
38 ShapeClient and Shape. 4.3.12
Generating AspectJ code from Pointcut definition
We have introduced all of the elements in a program view and the definition of pointcuts. The final step is to generate AspectJ code in three kinds of styles including enumeration, annotation and name pattern. And they are enforced to be equivalent. Figure 4.15 illustrates the AspectJ code of the pointcut definition in Figure 4.14. In Style 1, everything is explicitly written. In style 2, the call part is replaced with some method name patterns. In style 3, the within, call, and target parts are replaced with annotations. An enumeration style can always be generated no matter which way is used in the program view construction. But if the name pattern or annotation is not used in the composition of modules or messages, their styles of AspectJ code can’t be generated. 4.4
AOP problems revisit
4.4.1
Fragile Pointcut Problem Revisit
In Chapter 2, section 2.2, we discussed about the problems with AOP. We shall visit those problems with our new approach in this section. First, for those refactoring operations: • Rename: If we rename the Java type Point to Java type MyPoint, then the individual representing the Java type Point becomes invalid according to our checking rule of JavaType discussed in section 4.3.2. The error report will direct us to change the property value from “example.Point” to “example.MyPoint”. What we need to do is generating the AspectJ code again without changing anything about the pointcut definition. • Change method signature: If we change the signature of void setX(int) to void setX(double), then the individual representing void setX(int) be-
39
( style 1:) pointcut updateSignaling ( example . ShapeClient thisObject , example . Shape targetObject ): within ( example . ShapeClient ) && ( c a l l ( void example . Shape . Move ( int , int )) || c a l l ( void Point . setX ( int )) || c a l l ( void Point . setY ( int )) ) && ( t a r g e t ( example . Point ) || t a r g e t ( example . Line )) && t h i s ( thisObject ) && t a r g e t ( targetObject ); ( style 2:) pointcut updateSignaling ( example . ShapeClient thisObject , example . Shape targetObject ): within ( example . ShapeClient ) && ( c a l l ( void *. set *(..)) || c a l l ( void *. move *(..)) ) && ( t a r g e t ( example . Point ) || t a r g e t ( example . Line )); && t h i s ( thisObject ) && t a r g e t ( targetObject ); ( style 3:) pointcut updateSignaling ( example . ShapeClient thisObject , example . Shape targetObject ): within ( @example . Client *) && c a l l ( @example . Change * *(..)) && @target ( example . Host ); && t h i s ( thisObject ) && t a r g e t ( targetObject );
Figure 4.15: Generated AspectJ pointcut code
40 comes invalid according the checking rule of JavaMethod. The error report will direct us to fix that error. We only have to generate AspectJ code again without worrying about the definition of pointcut. • Pull up or Push Down: It is analogous to the previous cases. In addition, we look at the problems caused by adding new functionality to the base program. If we add a new method setID which has nothing to do with the location of a shape to the Java type to Point, and if the generated AspectJ code is of name pattern style, will the pattern (void *.set*(..) capture setID unexpectedly? The answer is no. The checking tool can report this error. setID results that the definition of the message Change doesn’t satisfy the “equality” rule, because the set of enumeration and set of name pattern of this message are not equal any more. The set implied by the name pattern has one more element setID than the set implied by the enumeration. Then we will be notified to fix the error and generate AspectJ code again. We can either remove the inappropriate pattern or change it to avoid the unexpected capture.
4.4.2
Encapsulation Problem Revisit
If we add a new Java type example.Circle into our base program. Circle implements the Java type Shape. If we make the decision that Circle should not work the same as other shapes such as Point and Line. In other words, if we don’t want Circle to be affected by the aspect code, then we just keep the ontology as before without any changes. The generated AspectJ code will also be the same as before. The condition that target(example.Point)|| target(example.Line) prevents example.Circle from being affected. Therefore, we achieve the goal of encapsulation protection. If the Java type example.Circle is e not exposed in the ontology, it will not be affected. On the other hand, If we want example.Circle to work the same as other shapes,
41 we only have to add example.Circle to the Host module and generate the AspectJ code again.
4.4.3
Sub Typing Problem
In most of cases, the program view works well for handling fragile problem and encapsulation problem of AOP. But we observed that there is a potential problem in our approach currently. What if someone put example.Shape which is a super type of other shape classes in the module Host Mod? In that case, the newly added Circle will be captured unexpectedly because the generated AspectJ code has (target(example.Point) || target(example.Line) || target(example.Shape)) which can not protect Circle
from being affected. Because example.Circle is a sub type of example.Shape. However, this won’t happen for the pointcut code of annotation style if we don’t declare the inheritance characteristics for an annotation. To solve this problem for enumeration style and name pattern style, we can report a warning during the module construction. If some module contains Java type T but doesn’t contain the sub type of T, the warning will be reported and the only style we can generate is the annotation style. Or we can make a new expanding rule that will automatically add sub types into the module. For the sub typing problem, we can put one more checking rule for the ontology class Module. • The sub-typing relation on the set of a module must be a closure.
Figure 4.16: Java Ontology properties 42
43
Chapter 5 Implementation and Case Study
In this chapter, we will introduce the main components and the techniques used in our implementation. This tool is called OntPointcut which is implemented as a Protege Plug-in [24]. Protege is an open source ontology editor and knowledge-base framework. Protege parses the OWL ontology and represents it in an OWL model. A plugin can read or write ontology directly by using this model without worrying about the details of OWL syntax. Figure 5.1 illustrates a brief design skeleton of the program. In the skeleton, we put descriptions along with numbers for easy reference in our discussion. Figure 5.7 illustrates the graphic interface of this tool. Next, as a case study, we use OntPointcut to define pointcuts for Robocode. Robocode is a programming game for which players can write their own code for an individual robot or a robot team using the standard APIs provided by this platform. In this game, a robot is simply a tank. The code written by the player can control the tank’s movement, firing and scanning. Tank robots can fight each other in a battle. 5.1
Implementation
5.1.1
Java Parsing Phase
In figure 5.1, the byte code or source parser 2 reads Java base program 1 and output the base program information 5. We used a library called BCEL [27] for Java byte code parsing. The outputted information includes Java class declaration, method declaration, inheritance relation, invocation relation etc. These information is stored
44
Figure 5.1: Implementation Skeleton. The oval represents operation. The rectangle represents data.
45 in a general way so that we can support multiple parsers. 5.1.2
Manually Editing Phase
The brief ontology of program view 4 is composed manually by someone who is aware of design decisions. The developer only has to select the Java classes or Java methods from the repository and click the button to convert them to ontology individuals. They don’t need to know OWL syntax. 5.1.3
Consistency Checking Phase
This phase is illustrated in Consistency Check 6 in Figure 5.1. This phase has two sub phases, the standard ontology consistency checking and customized consistency checking. The first one only involve the standard ontology class restrictions and the standard property constraints. It is general checking for any ontology. Refer to Chapter 3 for details. The second one is our own customized checking which concentrates on the consistency between the ontology and the Java base program. It reads the parsed information of the Java program and the initial ontology. Then it verifies whether the ontology satisfies the checking rules for ontology classes JavaType, JavaMethod, JavaTypeNamePattern, JavaMethodNamePattern etc. Those checking rules were discussed in Chapter 4.
For example, it checks if the JavaType individuals are ex-
isted in the Java Program.
It checks if the name pattern expressions defined in
JavaTypeNamePattern individuals are valid. This phase generates a consistent ontology that can be used by expander 9. 5.1.4
Expander
The ontology expander 9 reads the base program information 5 and the consistent brief ontology 8. Then it expands the initial ontology to a precise ontology 10. The
46 expander is designed to do inference for “ReadOnly” properties which we discussed in Chapter 4. There are two kinds of expanding. One is duplicating the information such as expanding parameter information from the method signature. The other kind of expanding is computing for new information such as expanding the implied Jave methods from the Java method name pattern. For evaluating Java method name pattern and Java type name pattern, we used APIs from [26].
5.1.5
Constraint Checker
The Pointcut Constraint Checker 11 reads the existing valid precise ontology and applies the constraint rules that we have defined for Pointcut in chapter 4. If the constraint is is violated, the error information will be reported, Otherwise, a fully validated ontology is ready to generate AspectJ code. 5.2
Case Study of Robocode In the figure 5.7, it illustrates an overview of our tool called OntPointcut. From
left to right, the frames are Java source code tree, ontology classes tree, individuals list and ontology properties widgets. One can select the elements from the Java source code tree and click the “convert” button to convert them to OWL ontology individuals. Figure 5.2 illustrates the modules and pointcuts we have defined for robocode.
5.2.1
Modules
In figure 5.2, we have constructed six modules for robocode. • Battle module is the engine of robocode. The whole program is driven by this module. It handles Graphics update, robots movement, Bullets movement, event queuing etc. • BattleView is responsible for displaying the graphics of a battle. It draws tanks, bullets, battle field etc. on the screen.
47
Figure 5.2: Modules and Pointcuts for robocode. The modules are in ovals. The names of pointcut are labeled with edges. The messages are not displayed in this graph.
48 • The module BulletPeer handles the states of bullets. Bullets can be fired by robots. • EventManager handles the tasks of events dispatching and event listener registration. The robot tank is event driven, which means a developer can write code to register the events and make actions when the events happen. For example, when a tank is notified by a hitByWall event, it can turn around and move ahead in some other direction. • Robot module contains the the code written by players. RobotPeer module is the internal delegate for Robot module. It handles the states of a robot. For example, the tank’s position, the gun’s heading, the tank’s energy etc. Robot module has no direct access to RobotPeer. It can only call the standard APIs provided by the platform to control the robot. Otherwise, the developer can cheat. The dashed line in Figure 5.2 is used to illustrate this relation which is not considered in the program view but in the actual code. Figure 5.3 shows an example of constructing the Battle module using three ways including enumeration, annotation, and name pattern. 5.2.2
Messages
We have defined the following messages for robocode. • The message makeBullet is sent from the module RobotPeer to the module BulletPeer because a bullet is created by a robot. • The message MoveBullets is sent from Battle to BulletPeer because when a bullet is flying, the Battle module is responsible for updating the location of the bullet. • The message onHitByBullet is an event sent from the module EventManager to the module Robot. It notifies that the robot has been hit by a bullet. The
49
Figure 5.3: battle module for robocode
50 message onScanRobotEvent is another an event sent from EventManager to Robot. • The message setEnergy is sent from Battle to RobotPeer whenever a robot’s energy needs to be changed. The energy decides how much life is left for the robot. • The message UpdateRobots is sent from Battle to RobotPeer to update every robot’s state for every game-time interval. • The message UpdateGraphics is sent from Battle to BattleView in every graphics updating interval.
5.2.3
Pointcuts
Figure 5.2 shows the pointcuts we have defined for robocode. For example, WhoScannedWho, EnergyTraccking, BattleUpdateRobots etc. We only demonstrate two pointcuts in this section. It is straightforward to understand the rest of them. If we want to track how frequently the graphics is updated, we can use the pointcut Battle Update GraphicsView which is defined as { within:
Battle, call:
UpdateGraphics , target BattleView }. The generated AspectJ code for this pointcut is illustrated in Figure 5.5. A more interesting pointcut is WhoScannedWho. This pointcut can be used for statistics for a battle. If we want to know how many times a robot scanned another robot in a battle, we can use this pointcut WhoScannedWho which is defined as { within: EventManager, call:
onScanRobotEvent , target Robot }. Figure 5.4 shows how
this pointcut is constructed in our tool. The generated AspectJ code for this pointcut is in Figure 5.6.
51
Figure 5.4: WhoScanWho for robocode
pointcut B a t t l e _ u p d a t e _ G r a p h i c s V i e w (): ( within ( robocode . battle . Battle )) && ( c a l l ( void robocode . battleview . BattleView .update ())) && ( t a r g e t ( robocode . battleview . MirroredGraphics ) || t a r g e t ( robocode . battleview . BattleView ) || t a r g e t ( robocode . battlefield . DefaultBattleField ) || t a r g e t ( robocode . battlefield . BattleField ));
Figure 5.5: pointcut for graphics update
52
pointcut WhoScannedWho ( robocode . peer . robot . EventManager thisObject , robocode . Scan nedRob otEvent p_0 , robocode . Robot targetObject ): ( within ( robocode . peer . robot . EventManager )) && ( c a l l ( void robocode . Robot . onScannedRobot ( robocode . ScannedRobotEvent )) ) && ( t a r g e t ( targetObject )) && ( t a r g e t ( sample . MyFirstRobot ) || t a r g e t ( sample . Tracker ) || t a r g e t ( sample . Crazy ) || t a r g e t ( sample . Walls ) || t a r g e t ( sample . Target ) || t a r g e t ( sample . SittingDuck ) || t a r g e t ( sample . RamFire ) || t a r g e t ( sample . Fire ) || t a r g e t ( sample . TrackFire ) || t a r g e t ( sample . SpinBot ) || t a r g e t ( sample . Corners )) && t h i s ( thisObject ) && args ( p_0 ,..);
Figure 5.6: pointcut WhoScannedWho
Figure 5.7: Graphics Interface of OntPointcut 53
54
Chapter 6 Related Work and Conclusion
This thesis is based on the work we have done in [1]. The goal of AOP is to provide modular implementation of crosscutting concern, but the current join point model introduces tight coupling between aspect and the base program, which paradoxically reduce the natural modularity of the program. This is called AOP paradox in [20]. In order to make more robust pointcut with low coupling to the base program, we need to have “more semantics in the join point model, more semantics in the aspect languages, and more semantics in the contextual assumptions”[18]. Better AOP systems are more oblivious. The ideal model is that “The base program programmer just programs like before. The AOP programmer will add aspect to it later”[21]. However, in practice, it is believed that clean implementation of aspects should be considered in the early design stage of program[9]. The common approach is to build a semantic contract for the base program and the aspect. The model-based pointcuts [7] allow pointcuts to be based on conceptual models which is essentially a contract. This contract is constructed using intentional view [14] which is composed of various binary relations between modules such as reference relation, call relation, and implement relation. The intentional view can be synchronized with the base program. As long as the the intentional view correctly classifies the elements such as types and methods, the pointcut remains correct. This thesis can be seen as another instantiation of the conceptual model. The
55 difference is that: First, the contract we build is represented in OWL ontology which conceptually describes the program view and is supported by more advanced editing and reasoning tools. Second, Our tool is designed for Java while theirs is designed for SmallTalk. Third, they introduced a new syntax for pointcut declaration which doesn’t expose any context variable. Instead, we generate three styles of AspectJ code according to the abstract definition. And we can expose context variables in the pointcut. Fourth, they didn’t check the constraints between the pointcut declaration and the intentional view. For example, there’s no discussion about what would happen if a model-based pointcut is syntactically valid but yields an empty set of join points. Such kind of constraints were pointed out in our approach in Chapter 4. Another similar approach is presented in “On the Need for SetPoints” [3]. Their contract is represented in OWL ontology [5] too. The difference is that their implementation is for Microsoft C#. And the instantiation of the ontology model for a base program is merely through annotation which is not flexible and convenient enough. The instantiation only instantiates the elements of the conceptual modules, but doesn’t instantiate the relations between those modules. Thus it doesn’t further check if a relation defined by a model-based pointcut is really existed in the base program. They created a new aspect language called LENDL which is translated to C# but doesn’t expose any context variable. Some other approaches make contracts for some specific interface instead of a conceputal model for the whole base program. ‘Open modules” [2] export both interfaces and pointcuts to the outside of the module. Only the exported interfaces and pointcuts can be advised by clients outside the module. The rest of the code in the module is thus protected from the aspects outside. In addition, it is the module designer’s responsibility to maintain the semantics and ensure robustness of exported interfaces and pointcuts. That approach is useful in the early design stage of a single module or library.
56 However, we see that the base program developer needs to predict what pointcuts will be used for this module and do extra work to maintain the exported pointcut when the program evolves. This doesn’t seem very oblivious from [21]. Sometimes, the crosscutting concerns are hard to predict because it is a system wide concern and it occurs when the modules in a whole system interacts with each other. For example, initially, a shape library might only be designed for geometry computation but later it could be used in graphics display. The crosscutting concern of updating the display is hard to predict in the early stage. In addition, if there are different ways to classify modules, for example, elements in the base program might belong to different modules for different purposes, and then the maintenance work will explode. We believe that for fundamental and irreducible modules, it is good to have contracts like exported interfaces and exported pointcut, which can later be used as primitive constraints for making better program view and other abstract models. Crosscut Programming Interface (XPI) [4] is a semantic specification which is also a contract. XPI states preconditions that must be satisfied at each point where an advice can run and postconditions that must be satisfied after an advice runs. This is analogous to the concept of exporting pointcut in [2]. It focuses more on a single module instead of the whole program. Interestingly, in our approach, the send and receive properties defined for the modules can be considered as some common precondtion for all of the view-based pointcuts. Moreover, it is possible to define additional properties for modules to enforce some postconditions too. PCDiff [12, 15]is a tool to compare the sets of join points matched by pointcuts on different versions of the base program. It helps aspect programmers to identify accidental matches or omissions of join points after the program changes. PCDiff is a good way to report the error. The diff report can help direct the aspect programmer to fix the pointcut, but it doesn’t provide an effective way to improve the robustness of the pointcut.
57 Kiczales and Mezini [10] discussed the interaction of annotation, advice, pointcut, and procedure for the purpose of separation of concerns. They also explained the tradeoff between the pointcuts based on annotations, enumerations, and name-patterns. In our work, we can define the view-based pointcut and generate AspectJ code with all of the three ways. Each style of pointcuts is a concrete representation of the view-based pointcuts and they are enforced to match the same set of joint point. Join point encapsulation [13] provides a mechanism of join point encapsulation. They construct pointcuts and advices using the current AspectJ language to impose a join-point-visibility policy. This mechanism is a practical way to export visible interfaces to the asepct and protect the invisible interfaces from the aspect. The enforcement is done by aspect itself instead of a checking tool or a compiler. Kiczales and Mezini [9] proposed the concept of aspect-aware interfaces so that the local modular reasoning is possible even in the presence of aspect affection. Their key idea is to provide aspect-aware interface which visibly let the base program developer know what aspects are contributing to an interface. Then developer will respect more to the aspects when changing the base program. However, the problem is that, in a large program, the number of aspect-aware interfaces becomes large and may scatter with the whole system the same as the crosscutting concern does. The aspect-aware interface improves local modular reasoning, but it is not oblivious [21] and may introduce another scattering problem. The concepts of program views in this thesis are relatively simple compared to other models such as Conceptual Modules [19], which are used to analyze the logical structure of C code iteratively with tool support. Multi-dimensional separation of concerns of Tarr et al. [17] presents more complex scenario of how concerns can be specified separately as hyperslices and composed together as hypermodules using central rules. Aspects can be seen as hyperslices but each aspect has its own rules (pointcuts) to specify how it is woven in the base program. Since program view can restrict the
58 join points captured by view-based PCDs, it may serve as a form of central rules for weaving related aspects into the base classes. 6.1
Summary Aspect-oriented languages allow us to modularize cross-cutting concerns but the
interaction of aspects with the base program can be hard to comprehend. Maintaining the correctness of pointcuts as base program evolves can also be difficult because the pointcuts directly depends on the structure of the base program. We have presented an approach to write more robust pointcuts based on program views instantiated by OWL ontology. A program can have several domain-specific views and the corresponding pointcuts. We check the base program after its revision to ensure that it is consistent with the program views and we check the pointcut definitions to make sure that they also satisfy the constraints of the program views. Programmers can also use the program view as a design guide to understand the interaction of the aspects with the base program. 6.2
Limitation and Future Work Currently we only support one kind of definition ({within, call, target})for
the view-based pointcut. For future work, we will examine the interaction of other pointcut designators such as cflow and execution with program views. In our implementation, the expander is currently hard coded in Java. We can switch to use an OWL rule-based inference language which is more systematic.
59
Bibliography
[1] Zifu Yang, Tian Zhao. Improve pointcut definitions with program views, In proceedings of Software Engineering Properties of Languages and Aspect Technologies (SPLAT 2007), a workshop affiliated with Conference on AspectOriented Software Development (AOSD), March 12, 2007 [2] J. Aldrich. Open Modules: Modular Reasoning about Advice. In Proceedings of the European Conference on Object-Oriented Programming, pages 144–168, 2005. [3] R. Altman, A. Cyment, and N. Kicillof. On the Need for SetPoints. In European Interactive Workshop on Aspects in Software, 2005. [4] W. Griswold, M. Shonle, K. Sullivan, Y. Song, Y. Cai, N. Tewari, and H. Rajan. Modular Software Design with Crosscutting Interfaces. IEEE Software, pages 51–60, January/February 2006. [5] T. Gruber. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. In International Workshop on Formal Ontology, 1993. [6] W. Havinga, I. Nagy, and L. Bergmans. Introduction and Derivation of Annotations in AOP: Applying Expressive Pointcut Language to Introductions. In European Interactive Workshop on Aspects in Software, 2005. [7] A. Kellens, K. Mens, J. Brichau, and K. Gybels. A Model-driven Pointcut Language for More Robust Pointcuts. In Proceedings of the European Conference on Object-Oriented Programming, pages 501–525, 2006. [8] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J. M. Loingtier, and J. Irwin. Aspect-Oriented Programming. In Proceedings of the European Conference on Object-Oriented Programming, pages 220–242, 1997. [9] G. Kiczales and M. Mezini. Aspect-Oriented Programming and Modular Reasoning. In Proceedings of International Conference on Software Engineering, 2005. [10] G. Kiczales and M. Mezini. Separation of Concerns with Procedures, Annotations, Advice and Pointcuts. In Proceedings of the European Conference on Object-Oriented Programming, 2005.
60 [11] H. Knublauch, R. W. Fergerson, N. F. Noy, and M. A. Musen. The Protege OWL Plugin: An Open Development Environment for Semantic Web Applications. In Third International Semantic Web Conference, 2004. [12] C. Koppen and M. Stoerzer. PCDiff: Attacking the Fragile Pointcut Problem. In First European Interactive Workshop on Aspects in Software, 2004. [13] D. Larochelle, K. Scheidt, and K. Sullivan. Join Point Encapsulation. In Proceedings of the Workshop on Software Engineering Properties of Languages for Aspect Technologies, 2003. [14] K. Mens, A. Kellens, F. Pluquet, and R. Wuyts. Co-evolving code and design with intensional views - a case study. Computer Languages, Systems and Structures, 32(2-3):140–156, 2006. [15] M. Stoerzer and J. Graf. Using Pointcut Delta Analysis to Support Evolution of Aspect-Oriented Software. In Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM’05), pages 653–656, 2005. [16] K. Sullivan, W. Griswold, Y. Song, Y. Cai, M. Shonle, N. Tewari, and H. Rajan. Information Hiding Interfaces for Aspect-Oriented Design. In Proceedings of the Symposium on the Foundations of Software Engineering joint with the European Software Engineering Conference (ESEC/FSE), pages 166–175, 2005. [17] P. Tarr, H. Ossher, W. Harrison, and J. Stanley M. Sutton. N Degrees of Separation: Multi-Dimensional Separation of Concerns. In Proceedings of International Conference on Software Engineering, 1999. [18] M. Wand. Understanding Aspects. In Proceedings of the eighth ACM International Conference on Functional Programming, pages 299–300, 2003. [19] E. L. A. Baniassad and G. C. Murphy. Conceptual Module Querying for Software Reengineering. In Proceedings of International Conference on Software Engineering, 1998. [20] Tom Tourwe, Johan Brichau, and Kris Gybels. On the Existence of the AOSDEvolution Paradox In AOSD 2003 Workshop on Software-engineering Properties of Languages 2003. [21] Robert E. Filman, Daniel P. Friedman Aspect-Oriented Programming is Quantification and Obliviousness. In Workshop on Advanced Separation of Concerns, OOPSLA 2000, Minneapolis, Oct. 2000 http://trese.cs.utwente.nl/Workshops/ OOPSLA2000/papers/filman.pdf [22] OWL Web Ontology Language Overview. In W3C Recommendation 10 February 2004 http://www.w3.org/TR/owl-features/
61 [23] Matthew Horridge, Holger Knublauch, Alan Rector, Robert Stevens, Chris Wroe. A Practical Guide To Building OWL Ontologies Using The Protege-OWL Plugin and CO-ODE Tools Edition 1.0 August 27, 2004 http://www.coode.org/resources/tutorials/ProtegeOWLTutorial.pdf [24] http://protege.stanford.edu/ [25] Robocode [26] AspectJ
http://robocode.sourceforge.net/ http://www.eclipse.org/aspectj/
[27] Byte Code Engineering Library http://jakarta.apache.org/bcel/
![[Indo-Book.com] Foundations of AOP for J2EE Development.pdf ...](https://p.pdfkul.com/img/300x300/indo-bookcom-foundations-of-aop-for-j2ee-developme_5a20405a1723dd587e1490c7.jpg)
