International Conference on Computer Systems and Technologies - CompSysTech’2003
Aspect-Oriented Programming – Case Study Experiences
Yuliyan Kiryakov and John Galletly
Abstract: This paper describes and assesses the experiences gained using aspect-oriented
programming as supported by the AspectJ language. Aspect-oriented programming is intended to support
the modularisation in the design of concerns that are inherently cross-cutting in traditional object-oriented
design.
Key words: Aspect-oriented programming, software design, AspectJ, cross-cutting concerns
INTRODUCTION
Aspect-oriented programming (AOP) is not a new idea, but it has only recently caught
the attention of software developers. In the late 80s, for instance, researchers were
making the first pioneering steps [5]. Today, the field is growing, with research institutions,
such as Xerox PARC, and universities being heavily involved. Xerox PARC report that the
number of AOP tools downloads in the period 1998-2001 rose from under 1000 to over
7000 [3]. An issue of the Communications of the ACM was recently devoted to AOP [1].
The MIT Technology Review, in the January/February 2001 issue, selected AOP as one of
"ten emerging areas of technology that will soon have a profound impact on the economy
and on how we live and work".
Object-oriented (OO) programming is now firmly established as the main
programming paradigm. But, OO development is not without its limitations, and AOP
supports the OO paradigm in those areas in which it is weak. In particular, AOP aims at
providing better means of addressing the well-known problem of the separation of
concerns [3]. (A concern is a particular goal, concept, or area of interest.) In any
reasonable-sized OO application, the software system will comprise a number of classes,
each with well-defined responsibilities, which cooperate to achieve the application’s overall
objective. However, there are usually parts of the system that cannot be viewed as being
the responsibility of only one class – these parts cross-cut (or span) the complete system
and affect sections of many classes. Examples are exception and error handling; ensuring
transaction integrity; logging of method calls; making security checks; and validating
parameters. Of course, the code that handles these parts can be added to each class
separately (but this would then violate the principle that each class has well-defined
responsibilities). The result is tangled code [3]: code that is scattered and repeated in
many places, making the program difficult to reason about and difficult to change. AOP
provides a solution to this problem by introducing a new program construct, the aspect,
which is used to capture and encapsulate the cross-cutting concerns within a separate,
modular unit and describes how the concerns code should be integrated, or woven, into
code for the system, giving a cleaner, more understandable program.
This paper describes a case study implementation of an application in AspectJ [2],
and illustrates and discusses the benefits derived from using AOP. AspectJ is a generalpurpose, aspect-oriented extension to Java and enables the modular implementation of a
wide range of cross-cutting concerns. (There is also an aspect-oriented extension for
C++.) Using AspectJ, an aspect is defined in a similar manner to a Java class: an aspect
has a name and may have its own data members and methods. Additionally, there are
further new constructs that provide extra support for the aspect.
BACKGROUND
We have implemented the client side of an e-commerce application to illustrate the
usage and advantages of AOP. Our application is very similar to the famous Java “Pet
Store” benchmark application [7], but is not constrained to pets because of our completely
-
-
International Conference on Computer Systems and Technologies - CompSysTech’2003
customisable categories and items. A client logs in to the system and can browse items
available for sale. The items he wants to buy are added to his shopping cart. When he is
ready with the order, the client confirms it and the transaction is completed.
The main Java classes in the application are as follows:
 Class CardItem – basic storage unit for a single item that a client wants to buy. Data
fields – ProductID, Quantity.
 Class Card – all the items the client wants to buy. Each of the cards contains the
id of the user and an array of CardItems that he wants to buy.
 Class DB – contains an interface for connection to the application database and for
user authentication.
 Class loginsrv – servlet used in user authentication.
 Class SessionBean – stores session information such as the Card with the items,
username, pass, connection to the database, etc.
 Class ViewCardBean – bean for the page displaying the items in the card of the
current user.
 Class ViewItemBean – bean for displaying the items to be browsed.
The technologies used in the implementation are JDK 1.3.1; Jakarta-Tomcat 3.2.3
web server; AspectJ 1.0.6; Borland JBuilder 6.0; and MySQL DataBase Server.
AN ASPECTJ PROGRAM
An aspect-oriented program introduces a new terminology into the language. An
aspect is the new concept similar to a Java class that allows the capture of a cross-cutting
concern in one place. Join points are locations in the program structure that can be used
as hooks for aspects. Examples of join points are method calls, method entry and exit
points, data access, etc. A pointcut is where to apply an aspect in terms of join points.
Advice is what the aspect should do at the join point and weaving is applying aspects to
code.
Figure 1
These concepts are illustrated in Figure 1. The calls to CheckSecurity() in the various
classes have been removed and an aspect, aspect_Security(), has been added to provide
the original functionality. In this aspect, the pointcut keyword indicates that a join point (in
any of the Java classes) occurs whenever a method call to generateContents() is made.
The before keyword is an example of an advice and, in this case, identifies the code to be
executed immediately before the given join point is reached. Here, it is specified that
CheckSecurity() is called.
-
-
International Conference on Computer Systems and Technologies - CompSysTech’2003
The AspectJ toolkit offers the developer two choices: either to create .class files
directly, or to create .java files that incorporate both the aspect and the traditional Java
code and after that pass these .java files to the standard Java complier (javac). Figure 2
illustrates the second choice – the Java class code and the aspect code is “merged” to
form standard Java code before being passed to the Java compiler.
Figure 2
EXAMPLES
The following lists the advantages of using AOP, as cited in the literature [4, 6], and
also names specific examples within our code where such advantages may be found:
- Increased modularity – the separation of cross-cutting concerns and their capture in
a single class. Examples: aspect_Security, aspect_Logging, aspect_DBConnManagement
- Less code needs to be written – applications may be developed faster. Example:
aspect_Logging
- Easier maintenance – code is no longer scattered throughout an application but
localized. Examples: aspect_Security, aspect_Logging, aspect_DBConnManagement,
aspect_QuantManagement
- Easier code reuse – since cross-cutting concerns are localized, they may be easily
reused. Examples: aspect_Logging, aspect_DBConnManagement,
- Easier understanding, while maintaining optimisation – the code is no longer
tangled, thereby allowing easier comprehension. Examples: aspect_QuantManagement,
aspect_Security, aspect_DBConnManagement,
- More flexibility – with aspects there are more ways to code the same thing. aspect_Security, aspect_Logging, aspect_DBConnManagement
- Reduced inheritance anomalies – the use of aspects allows a simpler class
hierarchy.
The following examples, taken from our AspectJ implementation of the “Pet Store”,
illustrate some of these advantages for the software developer. In the actual application,
aspects have been used extensively.
 aspect aspect_Security: the first example demonstrates how an aspect can cope
with an application-wide problem from just one place - code that would normally be
scattered throughout the application may be captured in a single class using an aspect.
This example deals with user authentication – the application makes sure that a user is
logged in before he is allowed to view any application web page. This is diagrammatically
illustrated in Figure 1. The actual aspect code is displayed in Figure 3.
-
-
International Conference on Computer Systems and Technologies - CompSysTech’2003
Figure 3
 aspect aspect_Logging: The next example illustrates how the writing of many lines
of code may be saved across the whole application. For debugging and optimisation
purposes, it is frequently necessary to log function call. Such calls to the logging methods
would virtually be in every function. Again, using an aspect, all the code is concentrated in
one place, not scattered all over the application. The aspect code is given in Figure 4.
Figure 4
In this code, pointcut identifies a join point to be whenever a call to any function in the
estore package is made. The around keyword is another advice which specifies that,
whenever the join point is reached, control should be passed to this advice, and it then can
decide what to do. In this case, the actual code of the original aspect-calling function is
invoked via the proceed call.
With the aspect, logging can be easily switched off if no more debugging and
optimisation is needed, and back on when something goes wrong and logging is required
again.
 aspect aspect_DBConnManagement: The third example shows an aspect being
used for database connection management, i.e. making sure that there are no open
connections between the SQL server and the JSP server while the users are idle.
-
-
International Conference on Computer Systems and Technologies - CompSysTech’2003
Figure 5
The connection of the Session Bean is opened whenever a call to the
generateContents function is made, and closed with the exit from the function. This
actually saves a lot of trouble, considering whether or not we have an open connection,
whenever we need to execute an SQL statement.
As in the example above, the pointcut keyword specifies the join point, while the
around keyword instructs what action is to be taken when the join point is reached.
 aspect aspect_QuantManagement: The last example illustrates an aspect which
manages the quantity of goods in the store. It decreases the quantity of goods available for
sale whenever a client confirms his order. This can be done in OOP by code in the
procedure confirming the order, but this will make the code less readable as it will be
mixed with code performing other tasks, resulting in harder development, debugging and
maintenance. For example, consider what will happen when we also add quantity
management code to the software that manages the supply of goods, and to the software
that manages the dispatch of orders to the customers. A later change in the design would
require finding the code about quantity management in all these parts of the application
and updating it. AOP facilitates maintenance by keeping the code in just one place. With
an aspect, if changes are needed, there would be no need to search for the places to
apply them. As the changes may have to be done by people who did not initially build the
system, AOP with its increased readability and better understanding of the source code,
would further facilitate the work.
Figure 6
-
-
International Conference on Computer Systems and Technologies - CompSysTech’2003
LESSONS LEARNED
In the previous section, we described our use of AOP in a medium-sized Java
application. This description is the final view - naturally, some modifications occurred as
we gained more and more experience with the technology. In this section, we provide a
higher-level perspective, discussing some of the lessons we learned over the course of the
development, and illustrating some of the challenges that others may face when using the
aspect technology.
We can confirm the advantages cited for AOP – with aspects, less code does need to
be written; code is more easily re-used; the code is easier to understand; etc. Balanced
against this is the lead-time required to learn the new technology. But, as this time is oneoff, the list of advantages to be gained from using AOP far outweighs this inconvenience.
However, AOP can be difficult to apply to an already completed project. If AOP is to
be used, this should be known at the design phase. Initially, we tried to illustrate the use of
aspects by modifying the original Pet Store Java source code. However, we soon found
out that this is not the best practice. It is very difficult to extract all the code that belongs to
a particular aspect into a single place, because one has to be very familiar with and go
through all the code of the project.
One should also consider the fact that AspectJ is still a programming language in the
process of development. While working on our application, we were unpleasantly surprised
by some minor compatibility issues with some of the Java classes.
CONCLUSION
This paper has described a case study AOP implementation of the famous Java “Pet
Store” application in AspectJ and reported the experiences. AOP proved to live up to our
expectations. Though a still new technique, AOP is already making a great progress in the
computer world. We think that it has a great potential and its popularity will be increasing
until some day it makes the now traditional OOP obsolete.
REFERENCES
[1] AOP Issue, Communications of the ACM, Volume 44, Number 10, 2001
[2] AspectJ. Available from http://www.eclipse.org/aspectj/
[3] AspectJ Group. Tutorial - Aspect-Oriented Programming with AspectJ. AspectJ
Workshop, Xerox PARC, 2002 http://www.parc.xerox.com/groups/csl/projects/aspectj/
[4] Elrad, T. M. Askit, G. Kiczales, K. Lieberherr, H. Ossher. Discussing Aspects of
AAOP. CACM, Volume 44, Number 10, 2001
[5] Elrad, T, R. Filman, A. Bader. Aspect-Oriented Programming. CACM, Volume 44,
Number 10, 2001
[6] Feng, L, A. Marcus, K. Schaffer. An Overview of Aspect-Oriented Programming
http://trident.mcs.kent.edu/~amarcus/aop/AOP_Presentation.ppt
[7] Sun Microsystems Java Pet Store specification
http://developer.java.sun.com/developer/releases/petstore/
ABOUT THE AUTHORS
1. Yuliyan Kiryakov, Department of Computer Science, American University in
Bulgaria, Е-mail: JKK000@aubg.bg.
2. Prof. John Galletly, PhD, Department of Computer Science, American University in
Bulgaria, Phone: +359 73 88 466, Е-mail: JGalletly@aubg.bg
-
-