aop

Aspect Oriented Programming

The history of our industry is rife with examples of improvements in our approach to building software, from the introduction of high-level languages, structured programming, and the object-oriented approach, to the development of spiral and iterative methods, and so on. One of the latest entrants in this lineup is aspect-oriented programming. In this column, let’s have an overview of AOP and make some observations on its promise.

AOP attempts to aid programmers in the separation of concerns, or the breaking down of a program into distinct parts that overlap in functionality as little as possible. In particular, AOP focuses on the modularization and encapsulation of cross-cutting concerns. A concern is a general term that refers to any particular piece of interest or focus in a program. Older programming methodologies including procedural programming and object-oriented programming, similarly focus on separation and encapsulation of concerns into single entities. For example, procedures, packages, classes etc., help programmers encapsulate concerns into manageable entities. Nevertheless some concerns defy such easy encapsulation. These are called crosscutting concerns, because they exist in many parts of the program. Message logging is a prototypical example of cross cutting concern, as it may crosscut all logged classes, methods and procedures. Ease of software evolution, maintenance and reuse are some of the benefits of AOP in software development.

Typically, an implementation of an AOP language seeks to encapsulate these types of crosscutting concerns through the introduction of a new construct called an aspect. An aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) over a quantification of join points (points in the structure or execution of a program), called a pointcut (a logical description of a set of join points).

“AOP is thus the desire to make programming statements of the form;

In programs P, whenever condition C arises, perform action A

over ‘conventionally’ coded programs P.”

This implies that the semantic definition of an AOP language ought to be characterized in terms of three kinds of conditions:

P: The points in the program on which actions can take place. This includes the join points, and what contextual information about the program is available to the aspects.

A: The aspects.

C: The conditions that tie the aspects to the program.

The quantification claim is that “aspect languages” have quantification conditions, C, that talk about sets of P and allow A to be defined separately from P; the obliviousness claim is that real aspect languages do not require P to mention A.

Aspect Oriented Software Development

Based on the type of requirements, an application can be any of the two types: application concerns and system level concerns. Application concerns address the functional requirements at the implementation level while System level concerns address the non-functional requirements of application such as tracing, security, synchronization, error handling etc. In OO methodology, the application specific requirements are implemented in one dimension. In other words, the implemented code matches functional and non-functional requirements unidirectionally. When system level concerns are implemented in one dimension, the code written crosscuts across the application resulting a tangling code that is hard to trace and maintain. AOSD provides a solution to the above problem by separating system level concerns from application concerns during implementation i.e. AOSD provides independent implementation of system level concerns, what you came across as already known to be an aspect; a unit or piece of code that crosscuts across the application.

AOSD does not end with separation of concerns. At application execution time, the aspects and application functionalities have to be merged. This merging (also called weaving) is done using dynamic weavers. AOSD consists of two key activities. One is the separation of aspects from application during software development and the second the weaving of aspects to application during its execution.

In real-world applications there are numerous such aspects that can be separated including tracing, error handling, synchronization, security etc. To get a feel of how AOSD might be useful in ones’ applications, have a look at the examples from the LINK.

Advantages:

Aspect-oriented technology has many potential benefits. It provides a way of specifying and encapsulating cross-cutting concerns in a system. This might, in turn, allow us to do a better job of maintaining systems as they evolve — and we do know that they will evolve.

AOP would let us add new features, in the form of concerns, to existing systems in an organized manner. The improvements in expressiveness and structure might allow us to keep systems running longer, and to incrementally improve them without incurring the expense of a complete rewrite.

Disadvantages:

With AOP, however, we can no longer reason about a class just by looking at the code for it. We do not know whether the code might be either augmented by advice from some aspect or completely replaced by such advice.

A second, more practical issue regarding the potential widespread adoption of AOP is the development of tools and techniques for testing, especially unit testing. Because code may be changed by an aspect, unit tests that run perfectly on a class may behave quite differently when the class is integrated into an AOP system.

References:

1 G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-oriented programming. In ECOOP'97---Object-Oriented Programming, 11th European Conference, LNCS 1241, pages 220--242, 1997. http://citeseer.ist.psu.edu/kiczales97aspectoriented.html

2 Filman, R.E. "What Is Aspect-Oriented Programming, Revisited," Workshop on Advanced Separation of Concerns, 15th European Conference on Object-Oriented Programming, Budapest, Jun. 2001. http://citeseer.ist.psu.edu/filman01what.html

3 Gary Pollice, A look at aspect-oriented programming, http://www-128.ibm.com/developerworks/rational/library/2782.html

Any corrections/suggestions/missed-references please don't hesitate to mail me.