Welcome to weblogs.com.pk Sign in | Join | Help

AOP: Introducing Aspect Oriented Programming

Concerns in the code

 

While implementing the application, the software developer has to deal with different concerns that can easily be categorized into two types. There are some concerns dealing generally with the problem domain for which the software is being developed, and then there are certain concerns that provide the solution to the key software requirements but tends to spread through out, or cross cut the program modules that implement the primary functionality of the software systems. The first type of concerns is called Core Concerns and the second type of concerns that cross cut modules are called Cross Cutting Concerns.

 

Consider library management system; concerns dealing with book catalog, library staffs, library members and their related functionalities are all core concern, but there can certain concerns that are cross cutting modules, e.g. implementing a rule that says certain type of members can issue up to specific number of books, or certain type of library staff can perform certain actions. The concerns dealing such rules not only spread into multiple modules like issue the book and return the book but cross cut the core module i-e the code implementing them spread throughout the code.

 

void issueBook(Member issuer, int booksCount)

{

            if (LoggedInUser.isOfType(ALLOWEDTYPE)

            {

                        int IssuedBooks = issuer.IssuedBooks;

                        if (IssuedBooks+booksCount<=issuer.maximumIssueLimit)

                        {

                                    //Core Concern

                        }

            }

}

 

Implementing Cross Cutting Concerns results messiness in the code that is hard to maintain code and rigid in nature due to decreased cohesion. In the above example, you need to write such code in multiple places, and when some time down the road, you need to change the rule, you will find yourselves finding locations and updating code accordingly. Leaving a single place that you forget to update will result defects and faults in the applications.

 

Types Cross Cutting Concerns

 

Cross cutting concerns depend on the context provided by the behavior and concrete representation of the other concerns. Common types of cross cutting concerns are:

 

Design & Architectural Constraints, business policies and such constraints fall into this; the above library rule examples are design and architectural constraint.

 

Systematic Properties and Behavior, logging, security checks and error recovery/fault tolerance routines fall into this category.

 

Software Features, like plug ability, dynamic feature weaving etc, e.g. your application requires a RDBM system, and you need to add/change the support of certain RDBMS.

 

Aspect Oriented Programming (AOP)

 

AOP facilitates modularization of cross cutting concerns. AOP promises higher productivity, improved quality and better ability to implement new functionality. In AOP, all concerns should be treated as modular units, regardless of the limitations of the implementation language. In AOP, aspects are the named program units handling cross cutting concerns. Using AOP, we get increased modularity and cohesion resulting increase in understandability and ease in maintenance due to the fact that the code gets cleaner due to its division into separate modules. High quality software can be built more easily and with increased chance of successful evolution.

 

Understanding AOP

 

To understand AOP, we need to first get ourselves introduced to certain new AOP related terminologies. Please note, AOP being new in the academia and commercial environments, lacks the standards that other paradigm enjoys. Therefore AOP terminologies and its working heavily depend on the certain implementation for a certain platform and/or language. Here, we are describing ApectJ related terminologies and examples. AspectJ is an AOP framework from IBM for the Java language.

 

Joint-Points, are well defined location in the control flow of a method, i-e they are specific points in the code that can be identified. Think of them as the breakpoints in the code that modern IDE/debuggers provides.

 

Point-Cuts, are the set of pattern used to select/define the Joint Points. These are the definitions used to select the join points. AspectJ has pre-defined selection rules that are used along with the pattern definition for finding certain method.

 

Advice is a method like construct used to express the cross cutting action that must take place within the method body at the matched join-point. In AspectJ, we have three types of advices, before, which is applied/gets called before the execution of the method implementing the core concerns. Second is after, which gets called after the execution of the core method and third one is around advice. Around advice, after weaving, surround matched joint point elements and may alter the control flow and data dependencies of the method. It can by pass the join-point elements altogether or make the join-point execution control dependent upon the around advice. Visualizing before and after advices are comparatively easier, around advice appears more complex. So let us give you a sample aspect having these advices so that you can understand them.

 

Consider a factorial calculation method:

 

public class TestFactorial

{

..

public static long factorial(int n)

{

            if (n==0)

return 1;

            else

                        return n*factorial(n-1);

           

}

..

}

 

The code is simple to understand and easy to maintain, but adding caching, logging and other such things can complicate this code. AOP is here to rescue us, let’s implement logging and caching using AOP.

 

Here is the definition of our aspect.

 

public aspect OptimizeFactorialAspect

{

            pointcut factorialOperation(int n)

                        : call (   long *.factorial(int)         )

                        && args (n);

}

 

We have defined an aspect, and a point-cut, that says to find any class’s method having a name factorial which returns a long and takes an integer. Whatever input is given, it will be also harvested as an argument to the advice that we will be defining now. We have used call point cut type here that captures the execution points after the evaluation of the method call. For other types, consider reading AspectJ documents.

 

public aspect OptimizeFactorialAspect

{

            ..

            before (int n) : topLevelFactorialOperation(n)

            {

                        System.out.println(“Seeking factorial for “+n);

            }

}

 

Above we have defined a before advice, that simply logs whatever input we have received. Now we need to implement caching. When the original factorial method is called multiple times for different values, there is a good chance that similar calculations will be made for different numbers, e.g. if the function is called for 5, 7, 8, 7! will be calculated two times, 5! will be calculated three times. We can get better performance using caching techniques. Let’s add around advice for this.

 

public aspect OptimizeFactorialAspect

{

            private Map _factorialCache = new HashMap();

            ..

            long around(int n) : factorialOperation(n)

            {

                        Object cachedValue = _factorialCache.get(new integer(n) );

                        if (cachedValue!=null)

                        {

                                    return ( (long)cachedValue );

                        }

                        return proceed(n);

            }

            after (int n) returning (long result): topLevelFactorialOperation(n)

            {

                        _factorialCache.put(new integer(n), new Long(result));

            }

}

 

This is how we have modularized our concerns, separating the implementations resulting pieces of code that are easier to read and maintain. There are still certain things left uncovered. You can know more about them by reading AspectJ documentations. Whenever time permits, I will cover similar introduction for .NET AOP implementations.

 

The material presented here is extracted from the technical report, Towards the Systematic Testing of Aspect Oriented Programs by Dr. Roger T Alexander, James M Bieman and Anneliese A Andrews. This material was prepared for the presentation of the same paper in Software Quality Assurance and Management class at National University’s Lahore campus. Certain other references are used for the preparations, including Keynotes of first international concerence on Aspect Oriented Software Development 2002, Aspect Oriented Software Evolution by Tom Mens, Kim Mens and Tom Tourwe, ERCIM July 2004. AspectJ documentation and articles were also consulted.

 

If anyone is interested to read the summary of the second portion of the paper that present the problems and a model for the testing AOP, please add your feedbacks.

 

 

 

We hereby take no guarantee for the correctness of the material, and also should not be liable for any action. The material is presented here for the sake of education and awareness. If anyone has problem, please inform us, we will remove the material.

Published Monday, October 18, 2004 8:05 PM by khurram
Filed under: ,

Comments

No Comments

New Comments to this post are disabled