Logging and Simulation using Aspect Oriented Software

Contents

List of Figures

List of Tables

CHAPTER 1: Introduction
1.1 Introduction
1.2 Preliminary
1.2.1 Logging with AOP
1.2.2 Observability using AOP
1.2.3 Simulation using AOP
1.2.4 Aspect-based Testing Technique
1.2.5 Aspect Log – AutotraceAspect
1.2.6 Aspect execution
1.2.7 Logging Output
1.2.8 Test Coverage

CHAPTER 2: Aspect-Oriented Software
2.1 Object-Oriented Paradigm
2.2 Aspect-Oriented Paradigm
2.3 Weaving with AOP
2.4 Crosscutting concerns with AOP
2.5 Comparison of OOP and AOP
2.6 Advantage of using AOP
2.7 Implementation of AOP

CHAPTER 3: AspectJ
3.1 Introducing AspectJ
3.2 Dynamic Crosscutting Constructs
3.2.1 Join Point
3.2.2 Pointcut
3.2.3 Kinded Pointcuts
3.2.4 Non-kinded Pointcuts
3.2.5 Advice
3.2.6 Aspects
3.3 Static Crosscutting Constructs

CHAPTER 4: An Overview of Logging with AOP
4.1 Overview
4.2 Logging with Java
4.2.1 Apache Log4j
4.2.2 Java Logging API
4.2.3 An example of Logging using Java API and Log4j
4.3 Logging for Observability of software
4.4 Logging with AOP
4.3.1 Testing
4.3.2 Exception Handling
4.3.3 Tracing
4.3.4 Code Profiling

CHAPTER 5: Testing of Loop Join Points Using AspectJ
5.1 Overview
5.2 Unit testing
5.2.1 Unit testing using aspects
5.3 Loop Join Points
5.4 Aspect for Join Point
5.4.1 Checking Preconditions and Postconditions
5.4.2 Tracing Loop Joinpoint
5.4.3 Code Coverage

CHAPTER 6: Observability and Logging using AOP
6.1 Overview
6.2 Use of Aspect for Increasing Observability
6.3 Aspect-based Testing Technique
6.4 Aspect Log – AutotraceAspect
6.4.1 Methods in Aspect
6.4.2 Logging aspect
6.5 Aspect execution
6.6 Output Report
6.6.1 Level of Testing
6.6.2 Unit Testing
6.6.3 Integration Testing
6.6.4 System Testing
6.6.5 Inheritance Property
6.6.6 Dynamic Binding
6.6.7 Test Coverage

CHAPTER 7: Simulation with AOP
7.1 Random Variable
7.2 Stochastic process
7.2.1 Poisson Process
7.2.2 Markov Chains
7.2.3 Brownian Motion
7.3 Distribution Models
7.4 Monte Carlo Method

APPENDIX A: Examples Illustrating Important Features of OOP
A.1 Encapsulation and Information hiding
A.2 Inheritance
A.3 Overriding
A.4 Polymorphism

Bibliography

List of Figures

Figure 1.1 Simulation Levels

Figure 2.1 Weaving mechanism

Figure 2.2 Aspectual Decomposition of Concerns.

Figure 2.3 Code Tangling.

Figure 2.4 Code Scattering.

Figure 2.5 Crosscutting concerns with OOP and AOP.

Figure 3.1 AspectJ Development Tool in Eclipse 4.2.

Figure 3.2 Crosscutting methods with using aspect.

Figure 4.1 Logging design.

Figure 4.2 Logging with Java.

Figure 4.3 Example of Java program.

Figure 4.4 An example of Aspect code for Logging.

Figure 4.5 Execution details of Logging Java program.

Figure 4.6 Logging with AspectJ.

Figure 4.7 Example of Exception Handling using aspect

Figure 4.8 An example for Tracing using aspects

Figure 5.1 Example of Java program using for and if statements.

Figure 5.2 AspectJ codes for Precondition and Postcondition.

Figure 5.3 Code templates for Interface.

Figure 5.4 Snapshot of the variables defined in static type.

Figure 5.5 Internal execution details of for loop when the variable is in static.

Figure 5.6 Internal execution details of if loop when the variable is in static.

Figure 5.7 The execution details when the variable is in nonstatic type.

Figure 6.1 Example of a Link List program written in Java

Figure 6.2 Methods defined inside the aspect for logging

Figure 6.3 AspectJ code for checking preconditions and postconditions.

Figure 6.4 Logging aspect for observing internal execution details at different levels of abstraction.

Figure 6.5 Aspect weaving

Figure 6.6 Aspect execution using Eclipse-AspectJ integration

Figure 6.7 Redirecting the output to a Log File for filtering

Figure 6.8 Filtering Log File

Figure 6.9 Output of the internal execution details at unit, integration and system level.

Figure 6.10 Code fragment for loop join points

Figure 6.11 Log output of loop join point

Figure 6.12 Snapshot of internal execution details at unit level.

Figure 6.13 Snapshot of internal execution details at integration level.

Figure 6.14 The snapshot of internal execution details at system level.

Figure 6. 15 Example of a simple Java program for Inheritance and Dynamic binding.

Figure 6.16 Output showing coverage at Inheritance level.

Figure 6.17 Output showing coverage at Dynamic binding.

Figure 7.1 The internal exution details for generation of Random numbers

Figure 7.2 Simulation of Monte Carlo program using AspectJ

Figure A.1 Example of Encapsulation and Information Hiding.

Figure A.2 Example of Inheritance in Java.

Figure A.3 Example of Overriding in Java.

Figure A.4 Example of Polymorphism in Java.

List of Tables

Table 2.1 Types of weaving with AOP.

Table 3.1 Join Points of AspectJ.

Table 3.2 Exposed Join Points to Pointcuts.

Table 4.1 Logging Methods.

Table 4.2 Checking Constraint

Table 5.1 Weaving capabilities in different loop types

Table 5.1 Coverage at Method, Class and Loop Join Points

Table 6.1 Output of internal execution details at unit level in tabular form.

Table 6.2 Output of internal execution details at integration level in tabular form.

Table 6.3 Coverage at line numbers, methods and classes

CHAPTER 1: Introduction

1.1 Introduction

Software testing is a process designed to make sure computer code does what it is designed to do and that it doesn’t do anything unintended. It is used to achieve quality assurance, verification, validation and reliability estimation. It is a major quality control measure used during the software development. It is based on assumed inputs that may give false test results if the assumptions are wrong [‎42]. Software should be predictable and consistent, offering no surprises to users [‎36]. Testing is the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of system or a component [‎40].

Testing of software is done at different levels of abstraction - unit, integration and system levels. During unit testing, the individual subprograms, subroutines, or process in a program are tested. Integration testing is done with already tested units integrated via relationships like inheritance and aggregation. System testing involves testing the input and output of the integrated unit.

In object-oriented software, a class is the basic unit of testing. Class is composed of data structure and a set of methods. Objects are run time instances of the class. The data structure defines the state of the object that is modified by the methods defined in the class. During unit testing, the code level behaviour of a class is tested. Already tested units integrated via relationships like inheritance, dynamic binding and aggregation are tested during integration testing. The focus is to find defects that arise when the components interact with each other. The features of object-oriented software such as encapsulation, inheritance, polymorphism and dynamic binding may introduce new kind of errors in the software. As a result, some issues arising in testing of object-oriented software are different from the conventional software testing issues. In order to handle the testing issues of object-oriented software, there is a need to improve the conventional testing technique or a new one needs to be developed.

During testing of software, there is a need to observe the internal and external execution details of the software. The internal execution details are required for the diagnosis of incorrect output during testing, and to ensure correctness of processing in case of a correct output. Without observing the internal execution details, the incorrect results may appear to be correct. Observability is the provisions required to be made in the software that facilitate observing internal execution details during testing of software.

Logging is a systematic method of recording the internal information of software. It is one of the typical examples of crosscutting concern (concerns that are common to many of the core modules that span multiple modules). By examining the log, an unexpected system behavior can be identified and corrected. It acts as a diagnostic assistant to reveal the inner working of a system. Logging is also used for different purposes like debugging, testing, auditing, performance monitoring, code profiling, etc.

Besides logging, the theory of random phenomena has always had widespread appeal not least because of its application to games of chance and speculation. The fundamental notion is that of the expected value of a bet. The Monte Carlo method computes this expected value by simulating a large number of scenarios and averaging the observed payoff of the bet over all scenarios.The simulation of the scenarios is best performed by a computer program. Computational power is becoming cheap and programming languages more powerful and more elegant. Object orientation in particular repesents a significant advance over procedural programming. The classes of an object oriented programming language allow us replicate the fundamental notions of our domain of application in the same order and with the same terminology as in the established theory.

Aspect-oriented programming (AOP) is a new programming paradigm [‎35]. It is popular for the use of modularizing concerns that cross-cut the basic functionality of a program, like, logging, exception handling, profiling, synchronization and tracing. AOP has provided a new mechanism for encapsulating crosscutting concern in a software system, in a module unit called aspect. When logging is used with AOP, aspect can be written for the logging concern. Aspect encapsulates the crosscutting concerns into a single unit; overcomes the tangling of code and modularizes the crosscutting concerns in better ways. AOP provides programming language support for logging. The code required for logging is written in a high level programming language, in an aspect, which spreads through the program automatically and generates logging information at run time. AspectJ [‎33][‎11]- an aspect oriented extension to Java, is a popular AOP programming language.

Object-oriented software is tested at unit, integration and system levels. During unit testing, it is need to observe input and output of the methods and the impact of method execution on the state of object. The sequence of execution of classes and input and output of the class is required to be observed during integration testing. The input and output of the integrated units is required during system testing. We observed that the focus of testing is different as we move from unit to system testing. The observability of internal execution details during testing shifts as we move from unit to system testing.

Provisions are required to be made in the software that facilitates observation of internal and external behavior of the software, at different level of abstraction. Logging is used with AOP for observability of internal and external execution details during object-oriented software testing. Several techniques exist Mao et al. [‎20], Xie et al. [‎85], Sokenov et al. [‎23], Bruel et al. [‎41], Afonso et al. [‎28] that use AOP to improve observability of software. Also, Stoerzer et al. [‎63], Briand et al. [‎56], Jtest [‎49] use AOP for tracing the internal execution details of software. But none of them address the issue of observing internal execution details at different level of abstraction during testing. The observation of internal execution details for the object-oriented software is discussed in [‎9]. However the authors use source-code instrumentation that requires probe to be predetermined in the software, which is difficult to build in a large software system.

We present an aspect-based testing technique that adapts logging aspect for observing the internal execution details of object-oriented software. Our technique defines a logging aspect named AutotraceAspect which is generic in nature and does not require change for new software under test. During testing of object-oriented software the AutotraceAspect is externally implemented and facilitates observing internal details of execution at different level of abstraction-unit, integration and system levels. Our technique uses AspectJ with Eclipse 4.3.2 [‎26] framework for testing object-oriented software at different levels of abstraction. The information gathered by using logging aspect is stored in a Log File and helps to generate test coverage at method, class, line number of code, inheritance and dynamic binding levels. We follow systematic approach to improve testing of object-oriented software using aspect-oriented programming. The advantages of simulation techniques using Aspect Orineted Programming over Object-Oriented are also discussed.

1.2 Preliminary

Aspect-oriented programming (AOP) is a new programming paradigm for modularizing concerns that cross-cut the basic functionality of a program. AOP provides means to encapsulate crosscutting concerns which cannot be modularized easily using traditional programming techniques. AOP methodology provides separation of crosscutting concerns by introducing a new modularizing unit called aspect. Each aspect focuses on a specific crosscutting functionality and core classes are no longer loaded with crosscutting concerns. An aspect weaver composes the final system by combining the core classes and crosscutting aspects through a process called weaving. AOP helps to create applications that are easier to design, implement and maintain [‎34].

AspectJ is an aspect-oriented extension to Java [‎83]. In addition to the regular classes, it introduces some new constructs such as join point, pointcut, advice, introduction and aspect, for better handling of crosscutting concerns. Join point is a well defined location in the code at which a concern crosscuts the application. Pointcut is a set of join point that optionally exposes some value in the execution of joinpoints. Advice is a method like mechanism which is used to declare the code that will execute at each of the join point in a pointcut. There are three kinds of advices: before, after and around. Aspect is a modular unit of crosscutting implementation. Aspect is similar to that of a class in object-oriented programming.

AspectJ provides support for two kinds of crosscutting implementation - dynamic crosscutting and static crosscutting. Dynamic crosscutting makes it possible to define additional implementation to run at certain well-defined points in the execution of program, and static crosscutting makes it possible to define new operations on existing types. AspectJ provides modularity, cohesion, understandability and maintainability of program or system. The resulting code is easier to develop and maintain.

1.2.1 Logging with AOP

One of the typical examples of crosscutting concerns is logging. Logging is a systematic method for code validation and debugging at the operating system level as well as at the application level. Logging of software is also a technique for observing internal behaviour of a system. Logging using conventional programming techniques, results in tangling of code with the other concerns, and makes it difficult to understand the system. However with the use of AOP, a few aspects can be implemented that eases the tangling of codes related to crosscutting concerns. Logging with AOP is also used for the purpose of testing and debugging, exceptional handling, tracing and profiling of software. During testing and debugging of software, aspects are created that can improve observability of software written in Java [‎20]. While using AOP, the code related to exception detection and handling gets reduced considerably. In profiling, software using AOP reveals the ability to write efficient code quickly and easily.

1.2.2 Observability using AOP

Observability mechanisms are provisions in the software that facilitate observation of internal and external behavior of the software, to the required degree of detail ‎9]. It is the ease of determining if specified inputs affect specified outputs. Moa [‎20] use AOP to improve the observability of component written in Java; for enhancing component’s testability and to direct test case selection. Aspect is similar to that of a class in object-oriented programming. It can be executed at any of the three different points after, before and around in program execution, for increasing observability through action (program statements) such as pointcut and advice.

AOP is used for checking precondition and post condition of any method type. The advice can be executed just before and just after a method is invoked to test whether the method is called with valid parameters or returns an invalid answer. The before advice is used to increase observability of a method at the beginning of its invocation just prior to its execution. It checks any calls to the method that occur either from within the class or outside the class. Also the after and around advice is used to increase observability of a method after it has been executed. Aspect can be written for standardized interface and automatically weaved into the code which facilitates observing the system’s behaviour. Easy weaving and non-invasive nature of test aspects makes them an attractive solution for testing object-oriented software.

1.2.3 Simulation using AOP

Object-oriented simulation is considered one of the most advanced techniques that have been widely used in most engineering disciplines. This

technique enables the modeler to focus on objects which is extremely important for thorough understanding of a system. Its roots go back to the simulation language SIMULA. The limitation of the OOP approach is its inability to localize concerns that do not fit into a single program module. Such concerns are defined as crosscutting concerns as they cross-cut or span multiple modules.OOP codes often suffer from tangling and scattering codes.

AOP introduces the notion of aspect, a well-modularized crosscutting concern, and shows how we can take crosscutting concerns out of modules and place them in a centralized location. Discrete event simulators implement a number of concerns, such as event scheduling, event handling, and keeping track of a simulation’s state which crosscut over multiple modules in the system. This increases the complexity and reduces the maintainability [‎92]. The levels of simulations are given as follows.

illustration not visible in this excerpt

Figure 1.1 Simulation Levels

The first level cosists of random numbers, as they are the basis of simulation study. The second level consists of simulation applied for distributional models, stochastic processes and Monte Carlo models. The third level consists of stochastic modelling applications, which focuses on applications.

1.2.4 Aspect-based Testing Technique

During testing of object-oriented software, there is need to observe the internal execution details of the software at unit, integration and system levels. Provisions are required to be made in the software to facilitate observation of internal behaviour of software at different abstractions. An “Aspect-based Testing Technique” has been developed that facilitates observation of internal execution details at unit, integration and system levels. Our technique uses logging at programming level to incorporate observability in the software, required during testing of software. For this, we use Aspect-oriented software which allows specifying an “aspect” that is non-intrusive to the program under test. We have developed our technique using AspectJ, a Java implementation of Aspect-oriented program.

The different parts of our technique are (1) Aspect log – AutotraceAspect, (2) Aspect execution, and (3) Output Report. The purpose of the aspect log is to define an aspect that facilitates observation of the internal execution details at different levels of abstraction. We have defined and developed an aspect “AutotraceAspect” which allows observing internal execution details of software. This aspect is generic, so it can be used during the testing of any kind of software without changes to the aspect. During testing, aspect execution requires, using of the AutotraceAspect—for observing the internal execution details of software. This will require weaving the code of the aspect with the software under test during the compilation of the software. The output report shows the information of the internal execution details of the software gathered by using the technique and stores it in a Log File. The output stored in the Log File is analyzed and filtered to obtain the desired execution details of the program. The internal execution details are observed at unit, integration and system levels.

The information generated during testing with logging aspect is used to generate test coverage. It includes test coverage at method, class, inheritance and dynamic binding levels.

1.2.5 Aspect Log – AutotraceAspect

Provision is required to be made inside the aspect to facilitate observing internal execution details while testing of object-oriented software. This requires defining and designing the aspect functions such as join points, pointcuts, advice, introduction and so forth. In our technique a logging aspect-AutotraceAspect is developed with AspectJ [‎11] to facilitate observation of the internal execution details of software during testing. The aspect functions are designed so that it facilitates observing the execution details of software during testing. The pointcuts inside the logging aspect are designed so that when invoked with advice, they allow identifying and capturing the context of all types of join points. The pointcut is also modified to limit logging for join points occurring in a lexical scope of classes or methods. The logging aspect encapsulates the constructs such as pointcuts, advice and introduction which facilitate logging the internal execution of software. The logging aspect collects the state of each method’s execution or call and also encourages the reuse of testing code. the logging aspect-AutotraceAspect is woven with the existing code and implemented externally without affecting the source code, facilitating observability of the software. During testing of object-oriented software there is a need to observe the internal execution details inside the public, protected and private methods. Public methods are invoked from outside the class. Protected methods are private to the class but can be invoked from the derived class. The level numbers are defined inside the aspect, based on the type of methods and pointcuts capturing the join points; L1 for the public methods of the classes that interact with other integrated units; L2 in the public method of rest of the classes and L3 in private and protected methods of classes. To access private members of classes the aspect is defined as privileged. The level numbers L1, L2 and L3 defined inside the advice body that are invoked with logging aspect help to categorize the internal execution details of the software at unit, integration and system levels, respectively.

1.2.6 Aspect execution

During testing of object-oriented software, aspect execution is required, means the logging aspect-AutotraceAspect is externally implemented with the existing software without affecting the source code. The AutotraceAspect is generic in nature, i.e., it does not require changes in the aspect body when used with a new software under test. Aspect code is woven with the software under test and compiled using AspectJ compiler. In AutotraceAspect, pointcuts inside the aspect body are designed to facilitate observing the internal execution details at unit, integration and system levels. Aspect functions are designed to get insight in the flow of the software.

AutotraceAspect incorporates reflection support in AspectJ, when invoked with the advice to provide access to the join point’s static and dynamic information through a small interface.This information is used to gain more insight into the system inner workings. The dynamic and static information together produce an enriched log output. To categorise the log output at system, integration and unit levels, the level number L1, L2 and L3 are introduced, respectively, inside the aspect body.

1.2.7 Logging Output

The output of program execution using logging aspect-AutotraceAspect is redirected to a Log File. All the internal execution details of the program flow with their level numbers specifying the testing levels are stored in the log file. This output is further analysed and filtered to obtain the desired execution details of the program at unit, integration and system levels. The Log File stores details of inheritance hierarchy i.e. classes, and, declared and inherited methods of each class, and class to which inherited method belongs. It stores details of dynamic binding such as dynamically bound methods and from where the dynamically bound methods are invoked. It also stores the details of the software such as class name, method name/type, constructor name/type, source locations, type of arguments, signature type, and so forth that are required during testing. The execution details with the level number L1, L2, and L3 are filtered for the system, integration and unit testing levels respectively. The behaviour of the software can be observed by analysing and filtering the execution details from the Log File.

1.2.8 Test Coverage

Test coverage of software is required to find the extent of the software that has been invoked during testing. In object-oriented software, in addition to the method coverage and class coverage, the coverage of inheritance and dynamic binding relationship is required to ensure adequate testing. Our technique shows the inheritance hierarchy level, based on inheritance category by displaying the method name, signature, their source location and inherited method. The class invoking the inherited method can be identified from their source location and signatures types. Our technique also helps dynamic binding relationship by displaying type of join point, class name and method name from where it is invoked. The method invoked is the method enclosing call to the dynamically bound method.

We generate test coverage at method, class, inheritance and dynamic binding levels. The logging output shows the sequence of path coverage, for test data adequacy. The uncovered line number helps to locate the untested code. The coverage report can be viewed as in percentage coverage of the line numbers and join points traced by the aspect.

CHAPTER 2: Aspect-Oriented Software

Object-oriented software is an important evolution in programming methodology. It encourages modular design and software reuse. Object-oriented programming (OOP) is commonly used for handling the core concerns of software. However, handling the crosscutting concerns such as logging, authorization, security, etc, often lead to scattering and tangling of code. Aspect-oriented programming (AOP) is a new programming paradigm, popular for modularising crosscutting concerns. With the use of AOP, a few aspects can be implemented that ease the tangling and scattering of code related to crosscutting concerns ^[77]. In this chapter we compare the features of OOP and AOP. We analyse the implementation of crosscutting concerns in AOP as well as in OOP.

2.1 Object-Oriented Paradigm

Object-oriented programming is the most common and dominant programming paradigm, having replaced the procedural programming paradigm. It is a practical and useful programming methodology that encourages modular design and software reuse. In OOP, object has a specific functionality that is exposed to its users. In most object-oriented programming languages, an object must be created as an instance of an object blueprint, called “class”. A class is usually made up of two kinds of member- attributes and methods. Every object created from a class has all members defined in the class.

One of the principal advantages of object-oriented programming technique over procedural programming technique is that they enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify. Common object-oriented programming languages are- Smalltalk, C++ and Java. Some of the important features of the object-oriented paradigm are-(1) Encapsulation and information hiding, (2) Inheritance, (3) Overriding, and (4) Polymorphism.

Encapsulation means ability to hide information. In OOP, the code and the data are combined into a single unit. Encapsulation separates implementation of the class from its interface. This separation of interface from its implementation allows changes to be made in the class without affecting its interface.

Inheritance allows a new class, called the superclass (derived class) derived from an already existing class known as the subclass (base class). Inheritance relationship is organized into an inheritance hierarchy. In single inheritance, the derived class inherits the data and method from single superclass. When a class is derived from inheriting one or more base classes, it is being supported by multiple inheritance.

In addition to inheriting a feature, a subclass can override the feature of its superclass. The advantage of overriding is the ability to define a behaviour that's specific to the subclass type; which means a subclass can implement a parent class method based on its requirement.

Polymorphism means ability to take several forms. It refers to an entity changing its form depending on the circumstance. It allows different objects to respond to the same message in different ways. It is implemented using static and dynamic binding. Static binding occurs at compile time by the overloading of operator or method name. Dynamic binding refers to the resolution of method invocation call to their associated methods at runtime.

The unique features of object-oriented software promote the concept of modularity, reusability, and maintainability; and also encourage modular design and coding. These features are illustrated with examples in Appendix A.

2.2 Aspect-Oriented Paradigm

Aspect-oriented paradigm is a new programming paradigm which supports separation of concerns in software development ^{[35] [54] [53] [70]}. AOP was first introduced by Cristina Lopes and Gregor Kiczales in 1995 at the Palo Alto Research Center (PARC), a subsidiary of Xerox Corporation. Later in 1996, Gregor gave the name “AOP”. AOP is a new methodology that provides separation of crosscutting concerns by introducing a new modularizing unit called aspect that crosscut other modules. A crosscutting concern can affect several units of a software system and usually cannot be modularized by traditional object-oriented design techniques. Some examples of crosscutting concerns are logging, synchronization, exceptional handling, and resource sharing. With AOP, the crosscutting concerns are implemented in aspects instead of fusing them around other concerns. AOP is not meant to replace OOP or other object-based methodologies. Instead, it supports the separation of concerns, typically using classes, and provides a way to separate aspects from the concerns. AOP has been proposed as an effective technique for modulating separate concerns, which facilitates the maintenance and evolution of software system. AOP provides modularity, cohesion, understandability and maintainability of program or system.

AOP introduce an aspect weaver, which is a complier-like entity. Aspect weaver composes the final system by combining the core and crosscutting modules through a process known as weaving. AOP modularizes the crosscutting concerns in an easy way, providing a system architecture that is easy to design, implement and maintain.The implementation of AOP must specify a language to implement the individual concerns and a language to implement the weaving rule. A join point model, a means of identifying join point and a means of affecting implementation at join point, are critical elements of aspect oriented language ^[34].The major components of an AOP language are as follows:

Join point: A join point is a well-defined location within the primary code where a concern will crosscut the application. Join points can be method calls, constructor invocations, exception handlers, or other points in the execution of a program.

Pointcuts: Pointcuts are the constructs that tell aspect-oriented language to match the join points, since the join points are well defined execution point in the application. For instance, to match the join point only when it is used in a call from one object to another or possibly a call from within the same object; we use the specified function call to handle this situation.

Advice: In most AOP specifications, advice code can execute at three different places when a join point is matched: before, around, and after. In each case, a pointcut must be triggered before any of the advice code will be executed. Once a pointcut has triggered, the appropriate advice code must execute.

Aspects: Aspects are units of modular crosscutting implementation, composed of pointcuts, advice, and ordinary Java member declarations. Some of the characteristics of aspects presented in ^[75] are as follows:

Aspects are dependent on the context of other classes.

Aspects are tightly coupled to the classes they are weaved in.

Aspect weaving: It is a process which allows both aspect and non-aspect code to run together. The AspectJ compiler uses aspect weaving to compose the code of base classes and the aspects to ensure that applicable advice runs at the appropriate join point ^[76].

2.3 Weaving with AOP

Weaving is a phenomenon of composing together the component source code and aspects to produce a desired total system operation. The process of causing the relevant advice at each join point to be executed is called weaving ^[67]. It specifies how to integrate the implemented concerns in order to form the final system. For instance, when logging concerns are implemented in a module, we need to introduce logging into the system. The weaving rules in this case specify the log points, the information to be logged and so forth. In essence, the weaving rules determine the final form of system. It is defined in aspects that are separate entities from the individual modules. The source code of the individual classes and aspects are pre-processed by the aspect complier to produce woven source code. The aspect compiler then converts this woven code to the base language compiler to produce the final executable code. Using this approach, a Java-based AOP implementation converts individual source input files into woven Java code and it is then converted into byte code by the Java compiler. The weaving mechanism of OOP code with AOP code is shown in Figure 2.1.

illustration not visible in this excerpt

Figure 2.1 Weaving mechanism

The process that combines the individual concerns according to weaving rule is called weaving and the processor doing this work is called weaver. Aspect weaver works by generating a join point representation of the component program, and executing (or compiling) the aspect programs with respect to it. Weaving several aspects at the same join point can be difficult if a join point is simply defined as a strict sequence of messages, because aspects previously woven might have inserted messages in between. The only way to support multiple static weaving is to define each aspect in function of the other aspects, which is clearly not acceptable ^[45]. To solve this problem of multiple weaving, there is a need of definitions of joint points which allow the detection of join points where some events occur between the events specified in the pointcut. The different types of weaving in AOP are shown in Table 2.1(adapted from ^[44] ).

Table 2.1 Types of weaving with AOP.

illustration not visible in this excerpt

From security perspective, weaving may be problematic. The program that is known to be secured without aspects, even when loading extra untrusted code, become unsecure after weaving in aspects because security-specific values become publicly readable and writable ^[12]. The implementation technique of weaving gives rise to two security issues: the erroneous assignment of aspects to protection domains and the violation of namespace separation ^[4]. Unfortunately, the oblivious nature of the weaving process makes it difficult to figure out the augmented system behaviour ^[58].

Sanchez ^[69] states that AOP weaving has to go beyond conventional model transformations and model composition. It will allow developers to specify transformation rules of a higher level of abstraction.

2.4 Crosscutting concerns with AOP

A concern is a specific requirement or consideration that must be addressed in order to satisfy the overall system goal. A concern can be divided into two categories: core concern that captures central functionality of the module, and crosscutting concerns that capture system-level, peripheral requirement-cross multiple modules. Traditional structuring techniques do not suffice to clearly and cleanly separate all concerns in the software, and the implementation of some concerns will spread across parts of the application, such concerns are called as crosscutting concerns ^[22].

In mathematical terms: AOP is based on the assumption that crosscutting concerns are scalars that can be factored out of a vector (a program) without leaving a trace, and that this factoring out (separation of concerns) can be reversed without any loss in meaning; however, weaving an aspect into a program is not always as simple as multiplying a scalar with a vector ^[31].

Typical examples of crosscutting concerns are logging, authentication, exception handling, resource pooling, performance, storage management, data persistence, security, multithread safety, transaction integrity, error checking, policy enforcement, etc. All these concerns crosscut several subsystems. For instance, logging concerns affect every significant module in the system, and the authorisation concern affects every module with access control requirements. Crosscutting constructs that affect static join points are called static crosscutting constructs and crosscutting concerns that affect dynamic join points are called dynamic crosscutting constructs. Static crosscutting constructs are typically implemented by intertype declarations and weave-time declarations; dynamic crosscutting constructs are typically implemented by advice ^[6]. The details of these crosscutting constructs are described in Chapter 3.

Crosscutting concerns differ in their structure ^[1]: Homogeneous crosscuts apply the same code at different join points whereas heterogeneous crosscuts apply different code. A different point of view is that homogeneous crosscuts interact with the base program in a one-to-n pattern and heterogeneous crosscuts in a m-to-n pattern. If a modularization technique does not provide explicit mechanism for encapsulating homogeneous crosscuts, the programmer has to refine each join point with separate structural elements that contain redundant code, e.g. refining a set of methods with a set of new methods that all contain the same code ^[79]. These so-called crosscutting concerns generally result in implementations scattered over multiple operations. If a crosscutting concern cannot be treated as a single module, its adaptability and reusability are likely to be reduced ^[54].

The complexity of design and implication can be reduced by focusing on each individual concerns separately. This is possible by decomposing the set of requirements into set of concerns. The Figure 2.2 shows the aspectual decomposition, where the requirements are decomposed into individual concerns.

illustration not visible in this excerpt

Figure 2.2 Aspectual Decomposition of Concerns.

This figure shows a three-dimensional concern space with the persistence, security and logging crosscutting concerns as the dimensions split out from the single requirement. AOP helps alleviate one of the most challenging facts of software development; the detangling of code through the separation of cross-cutting concerns. Beyond increasing modularity due to this separation, additional promises include increased programmer specialization, increased parallel development, and improved application debugging, introspection, and reconfiguration. It is important to separate and identify the concerns while developing a software system, as each of the concerns can be addressed independently.

2.5 Comparison of OOP and AOP

AOP doesn’t mean to replace OOP or other object-based methodologies. Instead, it supports the separation of components, typically using classes, and provides a way to separate aspects from the components. In comparison, AOP is similar to OOP, in that both have classes, interfaces, methods, packages, etc. Obviously, any Java program is a degenerate case of an AspectJ program that has no aspects. Thus, type of faults that can occur in a Java program can also occur in AspectJ program. AOP presents additional concepts beyond those present in OOPs.

In case of crosscutting concerns, OOP is not sufficient to handle the situation. In OOP, the core modules can be loosely coupled through interface, but there is no easy way of doing the same for crosscutting concerns. Crosscutting concerns with OOP leads to non-modularization and it is classified into two categories: code tangling and code scattering.

Code Tangling: It is caused when a module is implemented that handles multiple concerns simultaneously. Crosscutting concerns such as logging, synchronization, performance and so forth, lead to the simultaneous presence of elements from each concern’s implementation and result in code tangling. Figure 2.3 shows code tangling caused by multiple simultaneous implementations of various concerns.

illustration not visible in this excerpt

Figure 2.3 Code Tangling.

Code Scattering: It is caused when a single issue is implemented in multiple modules. Since crosscutting concerns spread over many modules, related implementation are also scattered over all those modules. It can be categorised as duplicated code block and complementary code block. In duplicated code block there is repetition of code of a nearly identical nature. For instance, resource pooling will typically involve adding nearly identical code to multiple modules to fetch a resource from a pool and return the resource back to the pool. In case of complementary code block, several modules are implementing complementary parts of the concern. The Figure 2.4 shows code scattering into multiple modules.

illustration not visible in this excerpt

Figure 2.4 Code Scattering.

Code tangling and code scattering influence the software design and development in many ways such as:

Poor traceability: Scattering and tangling of several concerns obscure the mapping of the concern to its implementation. This causes difficulty in tracing requirements to their implementation, and vice versa.

Lower productively: Simultaneous implication of multiple concerns also shift the focus from the main concern to the peripheral concerns. The lack of focus then leads to lower productivity as developers are sidetracked from their primary objective in order to handle the crosscutting concerns.

Lower code reuse: When module is implementing multiple concerns, other system requiring similar functionality may not be able to readily use the module due to a different set of concerns they might need to implement.

Poor quality: Code tangling makes it more difficult to examine code and spot potential problems, and performing code reviews of such implements is harder.

Difficult evolution: Non-modularised means modifying many modules. An incomplete perspective and limited resource often result in a design that addresses only current concerns.

Using AOP methodology, the crosscutting concerns are modularised by identifying a clear role for each one in the system. AOP aims at improving the quality of software by decreasing the level of code scattering and tangling ^[53]. These two phenomena are also known as symptoms of non-modularization ^[76]. Figure 2.5 shows the difference between OOP and AOP in handling crosscutting concerns.

illustration not visible in this excerpt

Figure 2.5 Crosscutting concerns with OOP and AOP.

In case of OOP paradigm, the objects are scattered across multiple modules, and there is no single place to identify the concerns. The overall effect is an undesired tangling between the codes. In AOP the objects are woven using an aspect, now the crosscutting (functional) requirements are mapped directly to one single module-aspect. In this way, use of aspects modularize crosscutting concerns and ease tangling and scattering of codes. Modularising crosscutting concerns provides simple code easy to use and maintain, and also has greater potential for reuse. One of the interesting concepts of AOP is to implement standard crosscutting concerns as reusable aspects, which are then made available in aspect libraries.

There are mainly two ways of using AOP. One way is to separate concerns that cut across the functional component. Another way of using aspects is to modify existing application in order to integrate a feature which has not been foreseen during the design phase of the software engineering process. Both ways will immediately yield a cleaner design and substantial code savings. Aspect can address both functional (what the system does) and non-functional (how the system behaves with respect to some observable attributes like performance, reusability, reliability, etc) behaviour. Implementing a functional behaviour using aspect requires that at least certain structure for the function already exists in the system. On other hand implementing a non-functional behaviour would have no impact on the design or implementation of the existing system.

2.6 Advantage of using AOP

AOP is a brand-new methodology which is popular for modularising crosscutting concerns. Crosscutting concerns are modularised by encapsulating them into single unit called an aspect. Core concerns no longer embed the crosscutting concerns. AOP marks the beginning of new ways of dealing with the software system by viewing it as a component of mutually independent concerns. Some of the advantages of using AOP are as follows:

Cleaner Implementation: AOP allows a module to take responsibility only for its core concern; a module is no longer liable for other crosscutting concerns. For example, a module implementing business logic is no longer responsible for the security functionality. This results in a cleaner assignment of responsibilities, reduces code clutter, and lessens duplication. It also improves the traceability of requirements to their implications.

Higher modularization: AOP provides a mechanism to address each concern separately with minimal coupling. This result in modularised implementation even in the presence of crosscutting concerns. Modularised implementation leads to a system that is easy to maintain and understand.

Easier system evolution: AOP modularises the individual aspects and makes core module oblivious to aspects. Introducing a new functionality is now a matter of including a new aspect and requires no change to core module. When we add a new core module to the system, the existing aspect crosscut it, helps to create a coherent evolution.

Reduce code tangling: Use of AOP reduces code tangling and makes simpler test code, spot potential problems, and perform code reviews. This leads to higher quality code.

Reduce code scattering: Use of AOP reduces scattering of codes and avoid the cost of modifying many modules to implement a crosscutting concern. Thus, AOP makes it cheaper to implement a crosscutting feature and also reduce cost of core concerns.

Code reusable: The key to greater code reuse is a more loosely coupled implementation. AOP implements each aspect as a separate module; each module is more loosely coupled then individual. Each module is loosely coupled than equivalent conventional implementations. The advantage of using an aspect is that code changes can be localised to the aspect, even if their effects aren’t ^[87].

Simplified design: Using AOP, the architect can delay making design decisions for further requirements because it is possible to implement those as separate aspects and focus on current requirement of system. AOP help to add features incrementally through the introduction of aspects, often without modifying the rest of the code.

Aspect-oriented programming has been successfully used for some kind of dynamic program analysis; examples include profilers ^{[17] [86]}, memory leak detectors ^{[5] [18]}, data race detectors ^[25], and testing tools ^[6].

2.7 Implementation of AOP

There exists number of aspect-oriented software such as AspectJ ^{[11] [34]}, JBoss ^[47], Sally ^[81], Hyper/J ^[39], and AspectC++ ^[68] which are either extensions of an object-oriented base language or frameworks written in such a base language. AspectJ is an aspect oriented extension to Java ^[83] and it is the most popular and best implementation of AOP. AspectJ enables the modular implementation of wide range of crosscutting concerns. JBoss is an open source application server, offers an AOP solution that includes a pointcut language similar to that of AspectJ. Sally is a general purpose aspect language that is highly inspired by AspectJ. Similar to AspectJ, Sally provides a pointcut language that is used to identify points in the code where weaving is meant to occur. Hyper/J is a tool that facilitates improved modularization, adaptation, composition, integration, and even non-invasive re-modularization of Java software. AspectC++ is new language extension to C/C++ that provides powerful language elements to facilitate AOP even in domains with tight resource limitations. In ^[86] use parametrized interpreter to implement different AOP mechanism found in AspectJ and Hyper/J.

AOP also generates interest in the .NET world. Due to the use of byte code representations and the possibility of using proxies, .NET offers choices similar to those available in the Java world. In addition to Spring.NET, prominent AOP solutions in .NET include PostSharp ^[72] and Aspect# ^[10]. LOOM.NET ^[60] is a research project that’s exploring static and dynamic weaving in .NET.

CHAPTER 3: AspectJ

AspectJ ^{[34] [11] [33]} is an aspect-oriented extension to Java programming language. With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting constructs-dynamic and static crosscutting constructs. Dynamic crosscutting construct is the weaving of new behaviour into the execution of program. Most of the crosscutting that happens in AspectJ is dynamic. Static crosscutting construct is the weaving of modifications into the static structure; the class, interface, and aspects of the system. This chapter illustrates the uses of dynamic and static crosscutting constructs with examples of AspectJ code.

3.1 Introducing AspectJ

AspectJ is one of the most popular existing AOP language to address crosscutting concerns. Like any AOP implementation, AspectJ consists of language specification which define grammar and semantics of the language; and language implementation, which include weavers that take various forms such as complier and linker. The AspectJ development environment, AspectJ Development Tools (AJDT) ^[8], basically on-the-fly provides programmers with information about applying aspects. The AJDT project provides Eclipse platform based tool support for Aspect-oriented software development (AOSD) with AspectJ language. The Eclipse 4.2 framework can be downloaded from the site mentioned in ^[26].

illustration not visible in this excerpt

Figure 3.1 AspectJ Development Tool in Eclipse 4.2.

Figure 3.1 shows a screen shot of an outline view available in AJDT. The base module, affecting advice or any other relevant aspect construct can be seen and traced back to the relevant aspect code.

AspectJ is designed so as to have a compatible extension to Java that will facilitate adoption by current Java programmers ^[33]. Meaning of compatible is stated as follows:

Upward compatibility — all legal Java programs must be legal AspectJ programs.

Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

Tool compatibility — it must be possible to work with AspectJ using existing tools, including integrated development environments (IDEs), documentation and design tools.

Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

Like Java, AspectJ is a general-purpose rather than domain-specific language.

AspectJ extends the Java language with new keywords and support two kinds of crosscutting implementation. The first makes it possible to define additional implementation to run at certain well defined points in the execution of the program. We call this the dynamic crosscutting mechanism. The second makes it possible to define new operations on existing types. We call this static crosscutting because it affects the static type signature of the program. The Figure 3.2 shows aspect crosscut methods in Points and Lines classes.

Figure 3.2 Crosscutting methods with using aspect.

illustration not visible in this excerpt

Dynamic crosscutting in AspectJ is based on the small but powerful constructs-join points, pointcuts, advice, aspects. Static crosscutting constructs includes inter-type and weave-time declarations. These constructs are the building blocks of AspectJ. The details of these constructs are discussed in the following sections.

3.2 Dynamic Crosscutting Constructs

Dynamic crosscutting is the weaving of new behaviour into the execution of the program. Dynamic crosscutting replaces the core program execution flow in a way that cut across modules, thus modifying the system behaviour. Dynamic crosscutting in AspectJ is based on a small but powerful set of constructs. Such constructs such as join point, pointcut, advice and aspects. The following sections present the details of these constructs.

3.2.1 Join Point

Join point is a well defined location in the code at which a concern crosscuts the application. It is an identifiable execution point in a system. A call to a method or execution of method is a join point, and so is a field access. A for loop or an if statement is also a join point. AspectJ exposes only a subset of all possible join points. For instance, AspectJ exposes join points for a method call and a field access, but not for loop join points, such as for loop or an if statement. In Chapter 4 we discuss our technique for exposing loop join points. Exposed join points are the only places where we can inject crosscutting actions. The AspectJ join points model encourage to write robust and maintainable systems by limiting access to more program constructs. The different types of join points provided by AspectJ are given in Table 3.1.

Table 3.1 Join Points of AspectJ.

illustration not visible in this excerpt

Method join points: AspectJ provides two kinds of join points for the method: execution and call join points. The method execution join point covers all the code within the body of the method. This following code shows an example of the method execution join point for the display() method. The join point for the execution of the method display() covers the whole method body.

The method-call join point occurs at the place where the method is being invoked. The following code shows an example of the method-call join point for the display() method.

The call join point is a call to the display() method. The call join points allow collecting the caller object’s context that is sometimes difficult with execution join points.

Constructor join points: Constructor join points are similar to method join points, except they represent the execution and invocation of object construction. The join point covers the execution of the code within the body of a constructor for an object. The following code shows an example of the constructor-execution join point for the Link class.

The constructor execution join point covers the entire constructor body.

Constructor call join points represent the points that invoke the creation of an object. When an object is built and that object's initial constructor is called (i.e., not for "super" or "this" constructor calls). The object being constructed is returned at a constructor call join point, so its return type is considered to be the type of the object, and the object itself may be accessed with after returning advice.

Field access join point: This join point corresponds to the read and write access to an instance of class member of a class. It is possible to mark an object directly whenever a field in it is modified. The following code shows field-access join point in the class Link.

The join point for field’s read access covers reading the field as part of creating the string representation of an object in the method st(). Join point for the field’s write access represents the argument a in the constructor. AspectJ provides an access to instance variables as well as class variables (static field) but not to local variables. The field access join point doesn’t match access through the refection application programming interface .

Exception-handler join points: The exception handler join point represents the handler block (the catch block) of an exception type to make sure crosscutting is possible. The following is the exception handler join point.

Exception handler join point covers the entire catch block.

[...]