School of computer science and informatics, cardiff university

1. Introduction

Object-oriented programming, one of the most widely used paradigms for software development, sought to improve development through modularisation and abstraction, as well as addressing the concept of separation of concerns, but only to an extent. The object-oriented focuses on modularity and abstraction, ensuring one object only deals with a given behaviour. There is still a problem with crosscutting concerns, behaviour which occurs in multiple locations, often using duplicate code, which an object-oriented approach cannot always solve.¹

The aspect-oriented paradigm, developed during the 1990s, has struggled to become accepted amongst commercial programmers due to its perceived difficulty when compared to object-oriented approaches which are the most prevalent development methods at this time. In recent years, the paradigm has become irrelevant to many, although there is still much to learn and its concept of crosscutting concerns and modularising them separately from code requiring that behaviour is still appealing for many reasons, such as redundancy reduction and an even higher level of abstraction.

This thesis discusses the use of an aspect-oriented language, AspectJ, and assesses its strengths and weaknesses through a practical experiment, making a comparison with Java and the object-oriented programming style. The experiment is then assessed using a variety of techniques to measure its success in modularising code, its maintainability as well as comprehension, and analysis of the differing design approaches.

The following sections are ordered according to the process that was followed during the compilation of this thesis. After outlining the aims and objectives in more detail, a background section provides information on the aspect-oriented paradigm and AspectJ as well as brief notes on object-oriented programming. The focus then moves to the practical exercise, first with the methodology used to ensure a fair assessment and then details on the design and implementation of two identical programs in terms of functionality, but not in their associated paradigm. This thesis concludes with an analysis of the work done and an overall opinion on aspect-oriented programming is formed.

2. Aims and Objectives

The aim of this project is to make an assessment of aspect-oriented programming, through a comparison with object-oriented programming, the most popular paradigm today, according to Sebesta [33]. Whilst this assessment could be carried out purely by looking at the theoretical background of the aspect-oriented paradigm, a more practical measure would be its usage in a real-world task, against a more recognised approach to the same problem. Gail Murphy [28, 29] and her colleagues in Vancouver have carried out case studies involving different mechanisms for the separation of concerns, including AspectJ, and their effect on coding. However, this is just measuring the alternatives to an aspect-oriented approach, and not a comparison with existing methods.

The project involves an investigation of aspect-oriented programming through research, and then developing and implementing a program which will be the basis of the assessment, using a traditional object-oriented language, Java, and an aspect-oriented language, AspectJ. The choice of languages was two-fold. Firstly, since I would be the only programmer and Java is the language I am most fluent in, it made sense to use Java rather than trying to learn another language in time, bearing in mind that I would already need to learn AspectJ. Secondly, AspectJ has become a standard for aspect-oriented languages since it was developed by the same people who developed the underlying paradigm [20, 21], which gives it credibility, and the fact it is an extension of Java would allow the Java source code to be the basis for future aspect development.

Before starting my research into the areas required for this thesis, I came up with an initial hypothesis on the results of the experiment:

“The use of aspect-oriented programming will improve the task of software development, whilst maintaining key object-oriented concepts such as inheritance and reusability, as well as maintaining, or improving, user comprehension.”

Having read a range of resources, the hypothesis was altered prior to implementing the comparison. It is this hypothesis which will be compared against when analysing the associated experiment:

“The use of aspect-oriented programming will improve the modularisation and productivity of software development, whilst maintaining key object-oriented concepts such as inheritance and reusability, as well as maintaining, or improving upon, Java’s strong user comprehension, through the use of clear and concise constructs.”

To assess the strengths and weaknesses of the aspect-oriented paradigm, a domain will be selected in which to develop a functional system encompassing a user interface, an underlying data structure, and handling database connections and queries. This system would then be developed in both Java and AspectJ, with the exact same functionality to allow for a thorough comparison. Through research, the best practice of both paradigms should be both identified and implemented as part of the development, again for a fair comparison to take place.

Once both versions of the given system are designed, some form of analysis can take place. Without considering anything further, the design, implementation and testing processes behind both systems can be assessed and compared on their usability and achievement. However, user comprehension would be difficult for just one person to assess due to a difference amongst computer scientists in their skills set. In addition, readability is such an important consideration into whether an approach is widely adopted that it should form a section of this assessment, but as I will be programming it would not make sense for me to comment on these areas. After the software development stage, a series of questions in the form of a questionnaire would be distributed to gauge outsider opinions on both systems and, by extension, both paradigms.

The choice of domain was between two database-centric systems, either a library or banking management system. After considering options in terms of the functionality available, the banking domain was chosen. This was because there seemed to be more functionality in that domain compared to a library-based system, which predominantly would be concerned with books and little else. Once the domain was identified, a number of core functions related to the banking domain would be chosen, although as the majority of them would be common sense there was no need to devote time to researching them, saving time for other tasks.