Aspect-Oriented Programming (AOP) is a programming model that tackles a specific problem: capturing consistent units of a software system that the traditional programming models force to be spread among several modules of the program implementations. In this light, aspects are those consistent units that happen to crosscut other units. A concrete example will make these definitions more clear.

Take a telecom system, with Customers, Calls and Connections. The basic operation of this system relates to the calls that customers make, including conference calls and merging of different connections into the same call. Over this basic operation, there is a timing feature which tracks the connection time per customer. And over that, there may be a billing feature that charges costumers for the calls they make, according to the amount of time they used and the types of calls they made.

Think for a moment how you would implement this using, say, an Object-Oriented Programming model. Customers, calls and connections are natural candidates for objects whose behavior is defined by class implementations. The timing feature could also be implemented by a group of classes, including, at least, a timer. Even though you may be able to isolate the functionality of the timing feature into a group of classes, there must be some code in the basic classes that invokes the timing feature at appropriate points in the operation of the telecom system. So, for example, it's plausible that everytime there is a new connection we must start a timer; it's also plausible that calls made by certain special customers are not timed. The points at which the timing feature is invoked by the basic objects is an important and consistent part of this system, and its specification can change independent of all the other parts.

Using a language that supports AOP, we can capture these dependencies in implementation modules of their own. In this case, we can have one module in the program that encapsulates the information about when the timing feature is invoked. Doing things this way, we can trace changes in the specification of the timing feature into one consistent unit of the program implementation. We can even unplug the timing feature from the system without having to change a single line of code of the basic classes, preserving the integrity of the basic operation.

What else? There are many more examples of how thinking in terms of aspects can have a positive impact in software development. Software developers out there have already embraced some of these ideas, especially for helping them develop their systems by having aspects such as tracing, profiling and testing. You can find out much more about how developers are using AOP by following the links to the AOP-related sites listed on the left.

The quest for better software development models and tools doesn't end with the current state of AOP. A lot more can be done in this field. For project ideas and general information, please contact Prof. Crista Lopes.