An Analysis of Aspect Oriented Programming with AspectJ

Transcription

1 An Analysis of Aspect Oriented Programming with AspectJ Advisor: Dr. Jehan Francois Paris Professor Department of Computer Science University of Houston Submitted by: Jay Gattani Department of Computer Science University of Houston CHAPTERS The Object Oriented Paradigm 1 OOP highlights and benefits 1 OOP and Separation of Concern 3 What about global concerns? 3 Aspect Oriented Programming Approach 5 Crosscutting global concerns 5 AOP solution for crosscutting concerns 5 What does AOP achieve? 6 AOP and OOP: friends or foes 8 Introduction to AspectJ 9 AOP insertion through AspectJ 9 The Join-Point model 9 Important AOP Definitions 10 Exposing context at a join-point with pointcuts 13 Named pointcuts 15 call versus execution 16 thisjoinpoint keyword 17 Wrapping it all in an Aspect 17 Case study: Development Aspects 19 Aspects to handle tracing concerns 19 Aspects to handle logging & profiling 25 Pitfalls in AspectJ 29 The infinite loop problem 29 Introductions: Problems in disguise 30 Conclusion 31 References 32 University of Houston Page 1 of 33

2 1. The Object Oriented Paradigm 1.1 OOP highlights and benefits Object Oriented Progamming is the dominant programming methodology that is being used in all forms of software Development today. The main focus of OOP is to overcome the problems of structured programming by using the various OO-principles such as encapsulation and polymorphism towards the development of software systems that are more robust, reliable and extensible. Object technology, including OO methodologies, analysis and design tools, and OO programming language, reduces the complexity in writing and maintaining complex applications such as distributed applications and graphical userinterfaces. Various design methodologies and patterns have evolved since the birth of OOP to aid in the design of a system that is extensible and easy to maintain. The main focus of OOP is to find a modular solution for a problem by breaking down the s/w system to be built into a collection of objects that encapsulate state and behavior. These objects exchange messages for communication across a well-defined interface and collectively cooperate to define and provide the functionality required. Inheritance and polymorphism provide the mechanism to organize and design the system in a hierarchy of classes by shifting the commonalities higher up in the hierarchy in the form of abstract classes and interfaces and shifting the distinct and specific features to concrete classes concentrated towards the lower end of the architecture. Principles such as Open-Close Principle 1 (OCP) and Dependency Inversion Principle 2 (DIP) provide a systematic mechanism to maintain the dependency between classes higher up in the hierarchy, thus reducing the coupling between the concrete classes and keeping the system as loosely coupled as possible. This adds to the maintainability and extensibility of the system and the resilience of the system to changes. Figure 1: Amount and location of code to handle XML parsing in org.apache.tomcat [1]. The vertical bars depict individual modules and the red line depicts the code for XML parsing. 1 OCP states that Software entities should be open to extension and closed to modification 2 DIP states that High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. University of Houston Page 2 of 33

3 Advancement in OOP have improved the ability of a software developer to achieve clear separation of concerns thus giving him the ability to analyze, identify and encapsulate cohesive functionality in the form of a well defined structure of classes. This leads to a separation of concern based analysis and design leading to a s/w solution comprising of a number of cohesive modules working in correlation towards the achievement of the final goal. 1.2 OOP and Separation of Concerns OOP undoubtedly is an efficient approach towards effectively handling local concerns. Local concerns are the concerns that are vertical in nature and can be encapsulate into a system of classes and object. The following figure depicts the amount and location of code to handle XML parsing in org.apache.tomcat: Figure [1] is a typical example of a vertical concern that can be identified easily during the design phase and a solution can be obtained in the form of a class or a system of classes that collectively provide a solution that addresses the concern in a modular manner. The code to address this issue is centralized and encapsulated within a finite and small number of classes leading to a much more modular and extensible solution. Most of the basic functional requirements of the system can be broken down into localized concerns and an OOP approach could be used to provide a solution to address these concerns. 1.3 What about Global Concerns? There are certain concerns within a system that are global in nature. These are the concerns that cut orthogonally through a system and are subparts of a set of requirements. These concerns do not fit naturally into a single s/w module or related modules but are intertwined with a number Figure 2: Amount and location of code to handle Logging in org.apache.tomcat [1]. The vertical bars depict individual modules and the red line depicts the code for Logging. University of Houston Page 3 of 33

4 of unrelated modules and do not naturally fit in the paradigms of modular design. Just to elaborate a little more on global concerns, the figure above shows a graphical representation of the various modules in org.apache.tomcat where the red lines depict the amount and location of code that handles logging. The code for logging is not centralized within a class or a module but permeates throughout the system cutting it orthogonally. Hence there is duplication of code to address the same concern at a number of points within the system. This leads to the following side effects: Code redundancy: Multiple pieces of code providing the same functionality permeated throughout the system. Difficult to change: The code cannot be changed easily as it would require code changes at multiple places ranging a large number of modules and classes. Moreover, locating the points where the changes have to be made is a time consuming issue since the code is not centralized. Over time, as the system evolves, inconsistencies might arise due to inconsistent code changes. Less Maintainability: Code becomes less maintainable and cannot be evolved easily. It becomes difficult to grasp and understand. Less Extensibility: The entire code becomes less extensible due to code duplication to handle the global concerns. Difficult to test: Multiple test-cases for the same functionality at various points. Thus, OOP fails to provide a robust and extensible solution to handle these global concerns. There are a number of concerns such as logging, error-handling, security, transaction tracing etc. which are global in nature and cut through multiple elements in the system. These global concerns present a serious issue as they cannot be effectively handled within the OOP paradigm. This is one of the major pitfalls of OOP its inability to handle global concerns in an effective manner. University of Houston Page 4 of 33

5 2. Aspect Oriented Programming Approach 2.1 Crosscutting global concerns We say that two concerns crosscut if the methods related to those concerns intersect. In simple words, these concerns cut through the system in a such a manner that they have to be addressed and taken care of at multiple points within the system. Examples of such behavior include the following: Synchronization and concurrency Performance optimization Exception handling and event monitoring Coordination and interaction protocols Object views In additional, crosscutting concerns cannot be neatly separately from each other. Hence an OOP solution to handling crosscutting concerns results in code that is intertwined with the code handling the actual functionality for which the module is designed. This means that the module is no longer cohesive in nature as it is addressing more that one issue. A simple example of a crosscutting concern would be a requirement that states that throughout the system, whenever an exception is thrown, a log has to be entered into an error log. This is a typical requirement and is a representative of requirements that are usually observed and identified during requirement analysis. Hence, to meet this requirement the usual approach would be to enclose the code for each method into structured exception handling blocks that catches the exception and makes an entry into the log file. This would solve the problem and meet the requirement stated. However, if a little more thought is given to this solution it would be evident that we just compromised the cohesiveness of our classes and the modules. Apart from providing the base functionality for which the class/module was designed, it also performs the task of making entries into the error log. Also, the code to make the error log will be present at each and every point in the code where an exception is being caught thus leading to a permeation of duplicate code throughout the system leading to lesser maintainability. Just to get a feel of the intensity of this problem try to think what would happen if the requirement suddenly changed and the code needs to be modified such that after making an error log, an needs to be sent to the administrator of the system with detailed information about the error that occurred and the exception that was thrown. In this case the code would need to be modified at all the points where the exception is being caught which would lead to a change being made in each of the hundreds of classes within the system! Consider a scenario where a new developer joins the team and forgets to write code in his exception handlers to make the error log. This kind of a scenario could lead to inconsistencies in the system. Hence, the inability of OOP in handling these crosscutting concerns pose a severe threat to the long term maintainability of the system. 2.2 AOP solution for global concerns Aspect-oriented programming (AOP) is a new paradigm that focuses on the issue of handling University of Houston Page 5 of 33

6 crosscutting global concerns. It proposes a solution by encapsulating the crosscutting concerns into single units called aspects. An aspect is a modular unit of crosscutting implementation and is designed to encapsulate state and behavior that affect multiple classes into reusable modules. Along the lines of AOP principles, the crosscutting concerns are identified and isolated from the localized concerns earlier during the requirements analysis phase. Thus, features of the system such as error-logging etc. are separated from functional requirements such as parsing, IO etc. that are local in nature. The functionality to handle these crosscutting concerns is then encapsulated into Aspects. The rest of the functional requirements can be then designed and addressed using a conventional technique. Afterwards, the aspecting code is combined with the aspected code to form a final executable with the help of an Aspect Weaver. Figure 3: Conventional compilation model [2] Figure 4: AOP approach to aspect weaving [2] Figure 3 depicts the conventional model where the various classes are cohesively designed to encapsulate individual functionality and are coded separately. The compiler then compiles the classes and builds a single executable from the class model. Figure 4 depicts the use of Aspect Oriented programming to solve a problem. In this case the system comprises of a system of classes that handle the localized functional concerns and a system of aspects that handle the global concerns. The aspect weaving is done as a pre-compilation process where the aspects and the classes and merged together to form a representation of the code that comprises of the appropriate aspecting code inserted at the appropriate points in the code where ever the global crosscutting concerns have to be addresses. This is then compiled to get the final executable. 2.3 What does AOP achieve The entire process of identification and isolation of crosscutting concerns is a time consuming job which requires a lot of experience to master and perfect. The process of designing aspects to address these concerns involves the use of a new paradigm and requires a need to step away from the conventional way of approaching the problem thus requiring a lot of time and effort. Then what is it that AOP achieves for us that OOP can not? University of Houston Page 6 of 33

7 The following are the benefits that accrue from the use of AOP to handle crosscutting concerns: 1. Modular Development: Aspects are independent s/w entities just like classes. They are designed to encapsulate behavior and functionality required to address global concerns and can also be designed to hold some state information. Since they are individual s/w units they have their own identity and can be developed, managed and treated separately from the rest of the system and can be built in a modular fashion. 2. Centralization of Aspecting code: The code that addresses the issues related to the global concern is centralized and neatly encapsulated within an aspect instead of being permeated throughout the system. Hence, the code is not duplicated thus making the system more consistent and maintainable. Any change to a crosscutting concern requirement can be easily handled since the change can be easily made at a single point within the code with minimal rippling effect. This also allows the addition or removal of aspecting functionality and gives a better control oven the functionality of the system. 3. Non-Intrusive approach to handling global cross-cutting concerns: AOP presents a perfectly non-intrusive approach towards handing crosscutting concerns. The code that is to be aspected is completely isolated and independent of the aspecting code before compilation. In the example discussed in section 2.1, if an AOP approach was taken then there would be a single aspect that would take care of the error-handling. Hence, there is no modification that is to be made to the existing code. Consider the situation where you want to perform this kind of error logging in a legacy system with a huge code base. AOP provides a mechanism by which you can non-intrusively introduce this kind of functionality into the system with little or no change to the existing code base by building an aspect hierarchy providing this functionality. By non-intrusiveness my focus is towards the fact that functionality to address crosscutting concerns can be added, modified or deleted without changing the current code base. This feature of AOP also enhances the extensibility of the system from a crosscutting concern perspective. 4. Increases cohesiveness of modules: Since aspects take care of the crosscutting concerns, the various classes and modules of the system remain independent of these concerns. Hence the modules are designed and developed to provide and cater to a single functionality leading to an increase in the cohesiveness of the modules and the system as a whole. 5. Logical separation of aspect code: AOP leads to a logical isolation and separation of the code to handle global concerns in the form of aspects from the rest of the system. This aid in an easy visualization of the system as a whole and in the identification of local and global functionality of the system. The logical separation is at the code level only since the final executable that is created after the AOP compilation contains the aspecting code intertwined with the regular code in the binary. But at the code level there is a crisp and distinct boundary between the aspects and the rest of the code. University of Houston Page 7 of 33

8 2.4 AOP and OOP: friends or foes Aspect Oriented Programming Object Oriented Programing Structured Programming Figure 3: Layering and dependence of programming paradigms A possible question that comes to mind is: Is AOP the next step after OOP? Will AOP replace OOP? OOP evolved due to the fact that Structured Programming could not address certain critical issues such as centralization and encapsulation of state and behavior. OOP proposed various mechanisms such as Inheritance and Polymorphism to deal with s/w complexity by modular development of systems through the realization of objects and classes. OOP however, did not discard the ideas of structures programming but actually formed a layer over it. In a similar fashion, AOP does not neglect or discard existing technologies and paradigms such as OOP but forms a layer over it. An aspect is nothing but a specialized class that handles the issue of global concerns. The OOP approach is to find commonality between classes and move it up the class hierarchy whereas AOP aims at identifying scattered concerns as crosscutting concerns and ejecting them horizontally from the object structure in the form of aspects. It layers over OOP and provides an efficient mechanism beyond the boundaries of methods and Inheritance to localize the functionality to address global concerns in the form of aspects that can be reused. Thus, the aim of AOP is not to replace OOP but to layer over OOP and provide additional capabilities to handle certain issues that the OOP paradigm is not capable of handling. University of Houston Page 8 of 33

9 3. Introduction to AspectJ 3.1 AOP insertion through AspectJ AspectJ is a general purpose aspect oriented extension for Java. The motivation that led to the creation of AspectJ was to provide an extension to Java that could provide AOP support through the use of a specialized Aspect description language (ADL). AspectJ is a freely available implementation which can be downloaded and provides a command line interface for AOP support as well as IDE support for tools like Eclipse and JBuilder. The following diagram shows how the process of aspect oriented compilation takes place. The aspects addressing the various crosscutting concerns are expressed through the use of a designed specialized syntax in an ADL 3 understood by AspectJ. These aspects along with the regular Java classes are fed as input to the AspectJ compiler which compiles the aspects and the classes as well as performs the aspect code intertwining. The result is a set of.class 4 binary Figure 4: Graphical representation of Aspect-Weaving through Aspect files which contain the regular code as well as the aspect code in an executable compatible with any Java Virtual Machine (JVM). 3.2 The Join-Point model Any AOP language support comprises of three important parts: a join-point model, means of identifying join-points and expressing the aspects associated with these join-points and a means of affecting the implementation at the join-points. Hence understanding the concept of a join-point is extremely crucial to grasp the fundamentals of AOP. 3 Aspect Description Language 4.class files are the complied files that are created when the java compiler is used to compile java code University of Houston Page 9 of 33

10 A join point is a well-defined point in the execution flow of a program. AspectJ has several kinds of well-defined join points: Method/constructor call join-points Method/constructor execution join-points Field get and set join-points Exception handler execution join-points Static and dynamic initialization join-points Join point does mot refer to a point within the physical code but a point within the execution flow of a program. For example, call to a method is an example of a join-point. Suppose we are interested in calls to a method named foo() of a class named xyz from anywhere in the application then this means that any point in the execution flow of the running program, where a call to this method, is made is a potential join-point for us. Hence, the entire course of execution of a program can be visualized as a collection of joinpoints such as method-calls, construction-calls etc. The processing at a join-point can be crisply divided into three parts: execution of the code until the join-point is reached, execution of the join-point itself (e.g. method that is called) and the execution of the code after the join-point. This view of the execution flow allows the identification of a join-point as a logical piece of executable that is surrounded by a certain context. For example, if the join-point is a call to a method then legal candidates for the context of the join-point would be the arguments being passed to the join-point, the return value from the method etc. Hence each and every join-point within the flow of execution has the following characteristics: 1. A valid point of entry 2. Context information for the join-point 3. A valid point of exit for the join-point 3.3 Important AOP Definitions 1. Pointcut A pointcut is used to select a small subset of join points out of the entire set of join-points associated with a particular executable context on the basis of well-defined filtering criteria. As defined in the previous section, any executable context could comprise of a large set of join-points where specific subsets of the join-points cater to a single crosscutting concern. For example, if we are interested to use AOP for error handling functionality like logging error information whenever an exception is thrown, then we would be interested in all the points in the execution flow where an exception is being caught. Each of these points actually represents a valid join-point. We are interested in all these join-points which are scattered over the entire span of execution flow at various different locations in the flow. These University of Houston Page 10 of 33

11 collectively form a subset of the entire collection of join-points within this particular execution context and we need a mechanism to express an interest in this particular subset of join-points. The concept of pointcut is designed specifically for this particular purpose. A simple example of a pointcut in AspectJ would be as follows: call (void GeometricFigures.DrawFigure (int)) The above statement is a pointcut that pick out each join-point that is a call to the method DrawFigure() on any object of class GeometricFugures which returns a void type and accepts an integer. call is an AspectJ keyword which is used to express calls to method, constructors etc. A pointcut can be built on other pointcuts with the use of operators such as and, or and not. Hence, the following pointcut definition is used to filter out all join-points that are calls to the DrawFigure() method of any object of the Circle or the Rectangle class. call (void Circle. DrawFigure (int)) call (void Rectangle. DrawFigure (int)) AspectJ supports the use of wildcard characters in the expression of pointcuts. For example, the following statement is used to select the join-points which are calls to a method of any object of a class named GeometricFigures with its name starting with the character sequence Draw, followed by zero or more characters and which accepts an int and returns a void. call (void GeometricFigures.Draw*(int)) Similarly, the following pointcut selects all join-points which represent calls to any method of an object of the class GeometricFigures. call (void GeometricFigures. *(int)) Sometimes there is a need to filter out join-points which are method calls but the actual sequence and type of the arguments which are being accepted by the method is not important. A typical example would be a case where we want to keep a count of the number of times any method of a class is being invoked at runtime. In this case we can use the wildcard character... call (void GeometricFigures. *(..)) The above statement is used to select the join-points which are calls to any method of any object of a class named GeometricFigures that accepts any number, sequence and type of arguments and returns a void. In the same lines the following statement is used to select the join-points which are calls to any method of any object of a class named GeometricFigures that accepts any number, sequence and type of arguments where the last argument is of type int and returns a void. University of Houston Page 11 of 33

12 call (void GeometricFigures. *(.., int)) 2. Advice An advice in AspectJ is used to define additional code that should be executed at a join-point. We have identified the join-points that we are interested in and created selection criteria to filter out these join-points as they are discovered during the flow of execution via pointcuts. However, in order to implement crosscutting behavior there should be a mechanism that would aid in specifying that a particular piece of code that has to be executed at a pointcut. This is expressed through the use of advice. An advice is nothing but a mechanism used to connect a pointcut to a body of code that needs to be executed at that pointcut. AspectJ has the following advices: 1. before advice: In this case the advice code executes when a join point is reached but before the computation proceeds. For example consider the following advice declaration: before (): call (void GeometricFigures.DrawFigure (int)) System.out.println( About to draw ); The above piece of code will be executed just after the call to the method is made and just before the method starts executing. 2. after advice: In this case the advice code executes just after the method body has run and just before control is returned to the caller. Java programs can leave a method call joinpoint 'normally' or by throwing an exception. To take care of these scenarios there are three kinds of after advice: after returning, after throwing, and plain after which runs after returning or throwing, like Java's finally. For example the following code will be executed after() returning: call (void GeometricFigures.DrawFigure (int)) System.out.println( Just drew successfully ); on a successful return from the method just before the control is returned to the caller. 3. around advice: In this case the advice code executes instead of the actual join-point when the join point is reached and conditions specified in the advice are satisfied. For example, in the following case the advice would be executed instead of the actual joinpoint, i.e. the entire join-point execution will be completely skipped. void around(): call (void GeometricFigures.DrawFigure (int)) System.out.println( Executed instead of Draw ); University of Houston Page 12 of 33

13 The original action associated with the join-point can be invoked through the special proceed keyword. void around(): call (void GeometricFigures.DrawFigure (int)) System.out.println( Executed before proceeding to Draw ); Proceed(); System.out.println( Executed after proceeding to Draw ); The above would be extremely useful in the conditional execution of the method depending upon some functions such as the value of a particular parameter being passes being in a certain range or checking the security context of the caller and denying execution of the method if the security criteria is not met. 3. Introduction or inter-type declarations An introduction in AspectJ provides a mechanism to introduce new members into an existent class definition or change the inheritance relationships between classes. The difference between introduction and advice is that the introductions take place at compile time and directly affect the structure of a class or the inheritance hierarchy of a system. The use of introduction becomes clear if we want to handle concerns such as adding a timestamp field within the classes of the application that we are building. The OOP solution would be to introduce fields into the class diagrams for this particular purpose. However if AOP is used then this would be possible with the help of introduction such that the field to be introduced is expressed in the form of an aspect and the actual introduction is made only at compile time thus providing a clear separation of these crosscutting concerns from the rest the code. To make alterations to the introductions we need to make changes only to the aspect, thus localizing the changes. 3.4 Exposing context at a join-point with pointcuts Apart from providing a mechanism to filter out the join-points, pointcuts also provide a method to expose the execution context at the join-point. I had discussed the execution context associated with a join-point earlier by taking the example of a method call join-point. The context exposed by a pointcut can be passed on to the advice method body in the form of parameters and arguments for usage. These can then be accessed and manipulated as regular variable within the body of the advice. The concept of exposing the context at a join-point will become clear with the following example. Consider a case where we are interested in trapping calls to the following: void GeometricFigures.DrawFigure (int) University of Houston Page 13 of 33

14 However there is an additional condition that we want to allow the call to the above method to proceed only if the value of the int variable being passed to it is greater than zero. The AOP solution to this problem would be to design a pointcut to filter out the required joinpoints and then access the variable being passed to the method. This would be possible by using the call keyword and an around advice since the around advice in this case would be executed just after the call is made to the method. At this point there is some execution context associated with the join-point which also includes the integer type argument being passed to the method. Hence in the advice body we need to access the argument somehow such that we can perform the test and depending upon the results either allow or disallow the call to proceed. The following piece of code does exactly what we have just discussed: around (GeometricFigures figure, int x): call (void GeometricFigures.DrawFigure (int)) && target(figure) &&args(x) if(x>0) System.out.println( Executed before proceeding to Draw ); Proceed(); System.out.println( Executed after proceeding to Draw ); else System.out.println( Condition not met ); System.out.println( Call to Draw aborted ); There are a couple of new concepts introduced in the above code that are extremely interesting. The most interesting part is the way the filtering of join-points is being done in order to expose the context. The expressed pointcut selects those join-points that are calls to the DrawFigure() method on objects of type GeometricFigures that accepts an int. It then exposed the context associated with these join-points through the use of the following statement: && target(figure) && args(x) target is a keyword which is used to express that when the above method is called then the object on which the method is being called should be exposed and the name of this object would be figure. This name is a temporary name used to associate the exposed object with the corresponding parameter being passed to the advice. The target, if exposed at the execution context is always the first parameter passed to the advice. The args keyword is University of Houston Page 14 of 33

15 used to convey that the first argument passed to the method should be exposed and published under the name x. The advice has a list of parameter which contains the Target type as the first parameter, if it is being exposed by the pointcut, followed by a list of all the types being exposed. The names of the arguments to the advice should match the names being published by the pointcut. In case there is no need to expose the target then we could simply achieve the required functionality through the following piece of code: before (int x): call (void GeometricFigures.DrawFigure (int)) && args(x) if(x>0) System.out.println( Executed before proceeding to Draw ); Proceed(); System.out.println( Executed after proceeding to Draw ); else System.out.println( Condition not met ); System.out.println( Call to Draw aborted ); In the above case, the target object is still a part of the execution context associated with the filtered join-point but it is not exposed and cannot be accessed in the advice. But we are still exposing the int type being passed and hence the argument list of the advice has a single argument of int type with the published name which can be accessed in the method body. 3.5 Named Pointcuts It is possible to provide a name for a pointcut to identify it. The advice can then be linked to the pointcut using the published name of the pointcut. The advantage of this approach is that it allows the programmer to associate a name to the pointcut and then link multiple advice blocks with the same pointcut. In the absence of this, the same pointcut would have to be expressed multiple times, once for each pointcut. The following example assigns a name to the pointcut and then associated two advice with it. pointcut drawing(int x): call (void GeometricFigures.DrawFigure (int)) && args(x) before(int x): drawing (x) University of Houston Page 15 of 33

16 System.out.println( Before Draw ); after(int x): drawing (x) System.out.println( After Draw ); Firstly, a unique name is given to the filtering criteria. Next step is to place name of the pointcut with the advice to link the filtering criteria with the advice. The arguments being passed are present along with the pointcut name declaration as well as the advice declaration. 3.6 call versus execution There are two interesting and distinct join-points associated with a method or constructor call. The call keyword is provided in AspectJ to refer to the join-point encountered just after a call is made to a method. In this case the enclosing code and the execution context is that of the calling method. Hence we use the call keyword in a pointcut declaration to filter out the join-points associated with a particular signature call. However, if we are interested in filtering out the join-points that occur just after control is passed to the called method and just before the first instruction is execute, we would use the keyword execution. In this case the enclosing code and the execution context is that of the called method. To highlight the difference between the two consider the following two pointcut declarations: pointcut drawing(int x) : call (void GeometricFigures.DrawFigure (int)) && withincode(void GeometricFigures.DrawFigure (..)) pointcut drawing(int x) : execution(void GeometricFigures.DrawFigure (int)) && withincode(void GeometricFigures.DrawFigure (..)) i ii There is a new keyword used in the above piece of code that is extremely interesting. The new keyword withincode is used to add additional restrictions to the filtering criteria by mentioning the code that should be executing when the join-point is reached. Hence it is possible to express an interest in a particular join-point only when the enclosing code is from a particular executing entity. In case of the first statement the pointcut filters out those join-points that are calls to the mentioned method and the enclosing code is again within the same method. This will effectively trap all recursive call to GeometricFigures.DrawFigure (..). The second one however filters out those join-points that are executions of the method and the enclosing code is the same method. Now a point to be noted is that at an execution join-point, the method is already being executed and hence the enclosing context is of the same method. Hence it is similar to saying: pointcut drawing(int x) : execution(void GeometricFigures.DrawFigure (int)) University of Houston Page 16 of 33

17 The keyword within can be used to express that the enclosing executing code should be within a particular class. This will include all the methods of the class including the constructors. Both the keywords can be used to further limit the join-points that are selected for consideration. The following example is used to trap the pointcuts which are call to the DrawFigure() method on any object of class GeometricFigures residing in the namespace Geometry. However there is an additional constraint in the declaration which says that that the pointcut should be encountered within the scope of the same class. Hence this would trap calls to the method from the collection of method within the class Geometry.GeometricFigures which includes the constructor as well as the Draw() method itself. This will exclude calls to the method from anywhere else in the application. pointcut drawing(int x) : call (void Geometry.GeometricFigures.DrawFigure (int)) && within(geometry.geometricfigures) 3.7 thisjoinpoint keyword What if you want to refer to the join-point itself within an advice body? There is a special reference variable in AspectJ, thisjoinpoint, of type org.aspectj.lang.joinpoint designed for this purpose. This keyword can be used to access the object that contains reflective information about the current join point for the advice to use. The thisjoinpoint variable can only be used in the context of advice, just like this can only be used in the context of nonstatic methods. A simple use of this would be to access the arguments associated with a joinpoint within the advice body as follows: thisjoinpoint.getargs() In addition, it holds an object consisting of all the static information about the join point such as corresponding line number and static signature: thisjoinpoint.getstaticpart() If you only need the static information about the join point, you may access the static part of the join point directly with the special variable thisjoinpointstaticpart. Using thisjoinpointstaticpart will avoid the run-time creation of the join point object that may be necessary when using thisjoinpoint directly. One more reflective variable is available: thisenclosingjoinpointstaticpart. This, like thisjoinpointstaticpart, only holds the static part of a join point, but it is not the current but the enclosing join point. So, for example, it is possible to print out the calling source location (if available) with the following declaration: before (): call (void GeometricFigures.DrawFigure (int)) System.out.println( University of Houston Page 17 of 33

18 thisenclosingjoinpointstaticpart. getsourcelocation(); 3.8 Wrapping it all in an aspect Aspects are used to wrap up and encapsulate pointcuts, advice, and introductions into a modular unit of crosscutting implementation. It is defined very much like a class, and can have methods, and fields in addition to the crosscutting members. AspectJ provides a new keyword aspect to declare an aspect. Because only aspects may include these crosscutting members, the declaration of these effects is localized. The following example wraps up all the code that we have written so far into an aspect by the name FigureDrawingTracker : aspect FigureDrawingTracker pointcut drawing(int x): call (void GeometricFigures.DrawFigure (int)) && args(x) before(int x): drawing (x) if(x>0) System.out.println( Executed before proceeding to Draw ); Proceed(); System.out.println( Executed after proceeding to Draw ); else System.out.println( Condition not met ); System.out.println( Call to Draw aborted ); System.out.println( thisenclosingjoinpointstaticpart. getsourcelocation(); after(int x): drawing (x) System.out.println( After Draw ); University of Houston Page 18 of 33

19 Like classes, aspects may be instantiated, but AspectJ controls how that instantiation happens and hence Java's new form cannot be used to build new aspect instances. By default, each aspect is a singleton and only one aspect instance is created. Hence the aspect class can have static fields that can be used to hold state information between the various advice bodies associated with a pointcut. University of Houston Page 19 of 33

20 4. Case study: Development Aspects We have discussed the various advantages of AOP over OOP in handling crosscutting concerns, defined the various concepts like join-points and pointcuts, dissected and studied the anatomy of an aspect and the syntax provided by AspectJ. Let us put it all together with the help of a couple of sample examples. The following problems are representatives of a number of similar problems encountered in day-to-day development activities which could be better solved using AOP. 4.1 Aspects to handle tracing concerns One of the most common activities associated during the development of production code is tracing. Developers spend a lot of time in writing code that traces common events during execution such as calls to methods or constructors, entering/leaving a method etc. This code is sometimes included in the actual source code with the intention of tracing and debugging during development. However, the approach taken to perform these activities is to permeate the code with a number f scattered statements which do the tracing job from different points within the program. There is no way of centralizing this task. One possible OOP approach would be to encapsulate the code to do the tracing within a class and access it through an interface. However, this would still result in tracing code being inserted into the application at various points that gets the job done by invoking methods of a class. Hence, in the end we end up permeating the existing code with method calls to do the job! Also, once this code has been TwoDimensionalFigures - x: int - y: int + getx(): double + gety(): double + getarea(): double + tostring(): string Circle - radius: int + getradius(): double - side: int Square + getside(): double + getdiagonallength(): double Figure 5: Class diagram for the geometricfigures class library University of Houston Page 20 of 33

21 inserted in multiple places, apart from the issue of code duplication there is also the question of removing this code if it is not needed. In this case, the entire code base needs to be searched to locate the small pieces of scattered tracing code to be cleaned up. The point that I am trying to make is that an OOP approach would fail to provide complete control over the tracing code. Full control would include an ability to add, remove or alter the tracing code by centralizing it at a single location in a non-intrusive manner such that there would be no need to modify the existing code apart from the tracing code. An AOP solution to the above problem would provide all the capabilities that an OOP solution could not provide. An initial analysis of the above problem reveals one important feature of the problem at hand it is a crosscutting concern. Tracing is a valid example of a crosscutting concern since this concern cuts orthogonally across a number of classes and requires coding in a number of places to perform the same task. But the points at which we have to perform tracing such as method calls, event invocation etc. are all join-points in one form or the other. Hence we can use AOP to solve this problem if we go the following route: Identify individual groups of join-points of interest for tracing activities Design pointcuts to filter out these groups Associate advice with these pointcuts to perform the logging activities The following section shows the details of how to go about this implementation by taking the University of Houston Page 21 of 33

22 Figure 6: Snap-shot of code for class TwoDimensionalFigures Figure 7: Snap-shot of code for class Circle that extends class TwoDimensionalFigures Figure 8: Snap-shot of code for class Square that extends class TwoDimensionalFigures University of Houston Page 22 of 33

23 example of a class hierarchy of geometric figures. Figure [5] is a class diagram with an abstract class TwoDimensionalFigures in the geometricfigures namespace which is the base class for all geometric figures. It has the properties and behavior characteristic of all geometric figures including two abstract methods: getarea() and tostring(). Two concrete classes Circle and Square extend this class providing implementations for the abstract methods as well as some properties and methods characteristic of the concrete classes. This completes the sample test hierarchy. The sample application also includes a driver class that acts as the user of this class library and creates and uses object by invoking methods on them. Figure 9: Snap-shot of code for the driver class MainDriver Figures [6-9] are screen-shots displaying the code written for these four classes: In the main method two objects of Circle and Square are created using a pointer of base type University of Houston Page 23 of 33

24 Figure 10: Snap-shot of the console window displaying the output for the above program and then it is used to invoke methods on the respective objects. If the above code was executed as it is now then the output would be as in the snap-shot shown in figure 10. At this point we can start introducing aspects into the code to perform the tracing. The following snapshot is of an aspect named MethodCallTracer. This aspect has a named pointcut, trace, that filters out join-points that are calls to the tostring() method on any object that is of type geometricfugures.twodimensionalfigures. Note that since this is an abstract class, it cannot be instantiated. However, the classes that extend this class are fully substitutable in Figure 11: Snap-shot of MethodCallTracer aspect for tracing on method calls University of Houston Page 24 of 33

25 the place of the parent in a well-designed OOP system 5. Hence, calls to the derived or extended methods on object of the concrete classes would also be trapped by this pointcut. The aspect also has an anonymous aspect to trap calls to the getarea() method. It also contains the associated advices to perform the necessary tracing functions. To demonstrate that multiple aspects could be included in the same project, I have included the following aspect to trap calls to the getdiagonallength() of the Square class and the corresponding advice to perform tracing. Figure 12: Snap-shot of SquareClassLogger aspect Figure 13 is a screen-shot displaying the final output after the aspects are included into the project. Join-points that are calls to the methods inherited from the base class by the derived classes, invoked on objects of the derived classes are trapped by the corresponding pointcuts defined in the MethodCallTracer aspect. The pointcuts have associated before advice which is given a chance to perform the required tracing functions before the call is allowed to proceed. The advice body just prints tracing on the console for simplicity. However, advice body can be developed to perform advance tracing functions such as writing trace information to a trace file etc. Similarly the SquareClassLogger is designed to trap calls to a specific method of a concrete class and perform tracing activities by using the associated 5 A well des designed OOP solution would follow Liskov s substitutability Principle (LSP) which states that An object of a base class should be fully substitutable by an object of the base class without loss of functionality. University of Houston Page 25 of 33

26 advice. If two pointcuts end up selecting the same join-point based on the given filtering criteria then the order in which the associated advice bodies will be executed is undetermined and none of the logic used should be based on the sequence in which the method bodies execute. Figure 13: Snap-shot of the console window displaying the final output There are several advantages to this approach as compared to the OOP approach which can be summarized as follows: Since the tracing code is centralized and wrapped in an aspect, the modularity and cohesiveness of the other modules is preserved. Changes to the tracing code can be made easily by making changes to the aspects without changing any other code. Pointcuts could be generic or specific as depicted in the above example depending upon how specific is the filtering criteria. Tracing functionality can be easily added, modified or deleted in a non-intrusive manner giving complete control on tracing for the entire application. Pointcuts can be carefully designed to take care of join-points associated with discrete points in an inheritance hierarchy. 4.2 Aspects to handle logging & profiling The next sample problem, to further emphasize the ability of AOP, is of another common crosscutting concern: Logging and Profiling. Logging activities such as error logging is an important requirement in many software applications. Again, this particular concern is global in nature and an appropriate target for an AOP solution. The following application includes a calculator class that provides basic calculating functions. There are two static methods in this class, PositiveNumberAdder() & PositiveNumberSubtractor() which are used to perform check on the input arguments and if they are found to be negative then a custom exception of type NegativeNumberException is thrown. There is a class CalculationPerformer that uses the above class to perform some computations as shown. Figure [16] is a snap-shot of the output if the code was run as it is. The second method call in the function causes an exception to be thrown which is caught by the exception handler and printed on the console. University of Houston Page 26 of 33

27 Figure 14: Snap-shot of the Calculator class in the mathpackage namespace Figure 15: Snap-shot of the console output To add the error logging functionality an aspect is introduced into the solution: ErrorLogger. This aspect contains an anonymous pointcut definition to trap all join-points that are calls to any method on any type of object. This is achieved with the use of the wildcards in the following expression: call (* *(..)) The above expression would trap calls to any method of any class which accepts zero or more arguments of any type independent of the return type which could also be a void type. University of Houston Page 27 of 33