School of computer science and informatics, cardiff university
Download 174.27 Kb.
|
- Navigate this page:
- Aspect-Oriented Programming
- AspectJ
- Current Status
3. BackgroundBefore going in depth on the actual assessment, some background information is required to set the scene. This section discusses both paradigms being used, as well as the languages associated with them, and the current status of aspect-oriented programming both in research and in real-world usage. There are also definitions of key concepts, especially aspect-oriented concepts; that will be mentioned throughout the rest of this thesis. Aspect-Oriented ProgrammingA concern in programming is a requirement that needs to be addressed when designing a given system, and can be split into two types. Concerns can either be considered as core, the central functionality of a particular module, or crosscutting, which are concerns which Ladadd describes as “peripheral requirements” [23]. Aspect-oriented programming deals with the latter through the encapsulation of these crosscutting concerns, which exist across multiple modules. Rather than being used instead of another methodology, aspect-oriented is used in conjunction with existing methods, such as object-oriented programming, allowing implementation of core concerns in the base language and adding constructs to encapsulate concerns inside aspects, which are regularly compared to classes [22, 37]. Through modularising crosscutting concerns, aspect-oriented programming addresses two issues of multiple concerns in one module. Code tangling [4, p302] is caused when a module controls multiple concerns simultaneously. Code scattering, which causes the same concern to be repeatedly implemented in many modules, is also an issue, taking the form of repeated code in multiple modules or different modules having different tasks in the same concern. These issues become more pronounced in object-oriented development as the program’s complexity grows. Aspect-oriented programming deals with two types of crosscutting concerns, either static or dynamic [21]. Static crosscutting represents concerns that are addressed at compile time, such as declaration of extensions and implementations of interfaces, while dynamic crosscutting represents concerns at a certain point in execution at which some action or behaviour should be executed at runtime. Dynamic crosscutting requires constructs, defined as:
Filman and Friedman [9] state their belief that aspect-oriented programming has two key properties, quantification and obliviousness. Those programming in the aspect-oriented paradigm should consider quantification, that when a condition is met, such as a particular point being reached, then some action should take place. The term obliviousness refers to the fact that the base code is not aware of the aspect code, and vice versa, before weaving. This point can be beneficial to the evolution of software systems, and is an area to measure against in this assessment. As aspect-oriented programming builds upon an existing methodology, a more sophisticated approach to compilation is required. In AOP, the process of weaving is used to combine the base code and aspect code [16, 23]. The aspects form the rules by which the aspect are weaved into the base system, using pointcuts. Pointcuts are points of execution in a program, at which a crosscutting aspect should occur, with the behaviour defined in the associated aspect. The aspects are combined with the base code by the aspect-oriented compiler, which then outputs the final system. An illustration of this process is depicted in Figure . 
Figure : Weaving Process Illustration (Source: Laddad [14], p25) AspectJAspectJ is an extension of Java which implements the aspect-oriented paradigm, and was developed by a group from Xerox PARC, with the first version released in 2002, with a stable release in 2003 as AspectJ 1.1 [11]. After a growth in popularity in 2004, particularly with IBM developers [4, 11], the language struggled2 due to increased competition with new framework approaches, and being regarded as a step up from current practice. This sub-section describes some basic principles to follow when using the language, as well as examples of syntax which will provide a basis for the AspectJ system discussed later. The team behind AspectJ [20, 21] chose to develop the language as an extension of the popular Java language, whilst ensuring that AspectJ was compatible with it. Compatibility meant that legal Java systems should also be legal AspectJ systems, which also lead to AspectJ being compatible with the Java virtual machine. Consistency should also be available in terms of the tools available and the ease of extension. This compatibility was used in part to improve the chances of the language being supported and adopted for real-world design. One important element in aspect-oriented languages is the join point model [20]. The model is the reference for the definition of structuring crosscutting concerns, which requires join points and advice. A join point is a well-defined point in program execution at which a piece of advice is executed. These points are restricted by AspectJ, with the most frequently used join point being method join points, which can either be at the point of calling a method or when the body of a method is executed [23]. These join points are defined in a pointcut, and can be grouped together with other join points, all of which are denoted by pointcut designators, through the use of logical operators such as “OR”, “NOT” and “AND”.
A pointcut definition contains an access specifier, which is optional and is set as public by default, followed by the pointcut keyword. The pointcut name is written like a method in Java, and can include parameters if required, followed by a colon “:”. The remainder of the definition is made up of one or more types of pointcut designators, with each associated to a signature, which for example could be a method. Figure includes the logical operator “||”, representing OR. If the signature is a method, the parameters can be included by listing their types, or the parameters can be ignored by placing “..” into the brackets, which can represent one or more parameters. In addition to the form of pointcuts shown above, pointcuts can be made less specific through the use of wildcards, denotes by an asterisk “*”. A wildcard allows anything to take its place in the pointcut designator, such as a method name or a return type. Figure shows an example of a pointcut at the execution of some method in MyClass with an integer argument.
AspectJ also allows advice to have access to values associated with join points, allowing execution context to be exposed. This mechanism can be achieved by passing variables as parameters directly from pointcuts to any advice, with values obtained through pointcut designators. For example, in Figure , an integer value is obtained from the execution of a method using the args(..) designator. This can be passed to the advice, as shown in Figure , and used for some statement in the body of the advice. Reuse is just as important in AspectJ as in object-oriented programming, with various constructs and patterns available. However, Hanenberg and Unland [14] discuss that reuse of aspect-specific code can be achieved through the use of some rules of thumb. Pointcuts should not be associated with more than one advice because adaption would become problematic, although it can be necessary if additional behaviour must occur both before and after a method call, for example, pre- and post-validation. AspectJ is designed to dismiss any recursion of pointcuts, with an incremental definition required. The use of abstract aspects, similar in nature to abstract classes, is encouraged as well. Whilst the pointcuts identify the points at which to perform some behaviour, the behaviour itself is defined within advice. As stated previously, this advice can take different forms, before, around or after. In AspectJ, these are the keywords for the different types. The body of advice is basic Java code. before(int i) : wildcardExample(i) { System.out.println(“Inside pointcut advice: ”+i); } Figure : Example of before advice in AspectJ Aspects in AspectJ are defined in a similar way to classes in Java, and contain pointcuts and advice. In addition, aspects can define new objects for a certain Java class. This process is called inter-type declaration [8]. Aspects can define fields, methods and constructors, which are added to other types, provided the aspect is declared as privileged, a key word designating if an aspect has access to internal variables of classes. Aspects can also import packages in the same way as Java classes. Weaving in AspectJ, the process of compilation; is done by a compiler which takes AspectJ bytecode and Java source code, outputting Java bytecode [16]. The process is two-fold; firstly the inputs are compiled into intermediary Java bytecode with annotations referring to pointcuts and advice, and secondly the annotations are implemented to produce the final weaving of base code and aspects. The annotations correspond to pointcuts and advice, with advice compiled as a normal method with the body of the method matching the advice body. Front-end compilation is executed through an extension of Java, and can be complicated by static advice declarations such as inter-type declarations and the declaring of parent classes.
Download 174.27 Kb. Share with your friends:
|