Enterprise Application Development using Dependency ... · Enterprise Application Development using Dependency Injection and Aspect-Oriented Programming STEFAN PETTERSSON Master’s

Enterprise Application Development using Dependency Injection

and Aspect-Oriented Programming

S T E F A N P E T T E R S S O N

Master of Science Thesis Stockholm, Sweden 2009

Enterprise Application Development using Dependency Injection

and Aspect-Oriented Programming

S T E F A N P E T T E R S S O N

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2009 Supervisor at CSC was Serafim Dahl Examiner was Karl Meinke TRITA-CSC-E 2009:077 ISRN-KTH/CSC/E--09/077--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Abstract

Dependency injection and aspect-oriented programming (AOP) arenot related but have the common goal of improving design, implement-ation and maintenance of software projects.

As part of the development of an enterprise application in Javabased on the Spring Framework these two technologies are consideredand evaluated based how they affect the design, maintainability andtesting of the project.

The report concludes that the use of dependency injection is easy toadopt and promotes design of less coupled modules with higher cohesion.Dependency injection is especially beneficial in regard to unit-testing byproviding simplifying the use mockup objects.

Aspect-oriented programming provides an approach to develop andmanage cross-cutting concerns in a more modularized way than conven-tional object-oriented programming. However, it requires the developerto think about the design in a new way in order to identify and designaspects, thus introducing a steep learning curve to both the developeras well as someone maintaining the project after deployment.

Referat

Användandet av dependency injection ochaspekt-orienterad programmering vid

applikationsutveckling

Dependency injection och aspect-oriented programming (AOP) är isig inte direkt relaterade, men de har ett gemensamt mål i att underlättaoch förbättra design, implementation och underhåll av mjukvaruprojekt.

Som del i utvecklandet av en enterprise-application i Java baseradpå Spring Framework har dessa två teknologier utvärderats baserat påhur de påverkar design, underhåll och testning under utvecklingsarbetet.

Rapportens slutsats är att dependency injection är relativt lätt attinföra och gynnar en design med färre och tydligare beroenden samtmer enhetlig kod. Depenceny injection fanns vara speciellt fördelaktigti samband med enhetstestning, bland annat då införandet av mockupobjekt underlättades.

Aspect-oriented programming är en programmeringsmetodologi somtillhandahåller ett sätt att utveckla och hantera så kallade cross-cuttingconcerns, aspekter av ett program som påverkar många olika bestånds-delar, på ett mer modulariserat sätt än konventionell objektorienteradprogrammering. Dock innebär detta ett ganska annorlunda sätt att an-gripa design och identifiera lämpliga kandidater som kan implemente-ras som aspekter. Detta gör att tröskeln för att börja använda aspect-oriented programming är relativt hög, både för utvecklaren så väl somför den som skall underhålla källkoden i efterhand.

Contents

1 Introduction 11.1 Problem Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Limitations and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Theory 52.1 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.4 Dependency Injection in Spring Framework . . . . . . . . . . 82.2.5 Other Dependency Injection Frameworks . . . . . . . . . . . 9

2.3 Aspect-Oriented Programming . . . . . . . . . . . . . . . . . . . . . 92.3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.5 Aspect-Oriented Programming Frameworks . . . . . . . . . . 15

3 Method 193.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Literature Study . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . 203.1.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.4 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Alternative Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Application Overview 23

4.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4.1 Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.2 Receive Application . . . . . . . . . . . . . . . . . . . . . . . 254.4.3 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.5 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.6 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . 264.5.2 Additional Requirements . . . . . . . . . . . . . . . . . . . . 27

4.6 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Architecture and Design 295.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Application Server . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.3 Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.4 Business Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.5 Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . 305.1.6 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.7 Build Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2.1 Application Design . . . . . . . . . . . . . . . . . . . . . . . . 315.2.2 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . 335.2.3 Aspect-Oriented Programming . . . . . . . . . . . . . . . . . 34

6 Evaluation 356.1 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . 366.1.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2 Aspect-Oriented Programming . . . . . . . . . . . . . . . . . . . . . 386.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7 Conclusion 437.1 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2 Aspect-Oriented Programming . . . . . . . . . . . . . . . . . . . . . 437.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Bibliography 45

Appendices 46

A References 47A.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 1

Introduction

1.1 Problem Background

Dependency injection and aspect-oriented programming are two technologies thathave gained popularity lately, partly because they are important parts of widespread application frameworks like the Spring Framework. Although the two tech-nologies are not related to each other they both have a common goal of improvingdesign, implementation and maintenance of software development projects. Theapproach to achieve this is to provide a framework that reduces coupling betweenobjects and, respectively, allow modularization of so-called cross-cutting concerns.

1.2 Purpose

However, what are the consequences of using dependency injection and aspect-oriented programming in a real-world project? How does it affect the design andarchitecture of a system? How is development and testing impacted? Are thetechnologies fire-and-forget silver bullets or is there more to it?

It is along those lines the purpose of this Master’s thesis is formulated.The purpose of this Master’s thesis is to evaluate the consequences of intro-

ducing and using dependency injection and aspect-oriented programming from apractical perspective in a real-world project. A real-world project in this context isa time-boxed project with limited resources and a real customer including unclearspecifications and changing demands.

The background of this real-world project is to develop a prototype of a web-based enterprise application that supports the Human Resource department at thecompany Avalanche Studios during the recruitment process of new employees. Thepurpose of the system is to automate parts the recruitment process or make themmore effective by supporting the recruiters from a job application is received untila decision is made about a candidate.

The system is Java based and developed using the Spring Framework. Theproject is divided into two major parts. The first part consists of requirement

1

CHAPTER 1. INTRODUCTION

analysis and producing an architecture and design for the system. The second partimplements the design using agile methods. The project is then evaluated accordingto the problem definition.

1.3 Problem definition

Considering the purpose of this Master’s project a number of questions have beenformulated that are pivotal during the project and of interest to address in theresulting evaluation section.

What does the use of dependency injection and aspect-oriented programming meanfor application design?

• In what areas are dependency injection and aspect-oriented programmingused?

• How is the design affected in terms of modularization and overall code archi-tecture?

What does the use of dependency injection and aspect-oriented programming meanfor application development?

• How is refactoring and maintainability affected?

• How is testing, especially automated unit testing, affected?

1.4 Limitations and Scope

Although dependency injection and aspect-oriented programming are techniquesapplicable to many different environments, applications and programming languagesthe focus is on Java, the Spring Framework and the particular application developedas part of this Master’s project.

One of the most important aspects in development of enterprise applications arehow they are maintained during time after initial deployment, especially by otherdevelopers than the original. Due to practical reasons this is not covered in thisMaster’s project even if related areas such as design are discussed.

The requirements gathering phase of the project does result in far more func-tionality than what is possible to implement in the prototype application. However,in order to achieve a real-world project the design and architecture is developed withall requirements in mind, although only a subset will actually be implemented.

1.5 Outline

The outline of the thesis is as follows:

2

1.5. OUTLINE

Chapter 1: Introduction (this chapter) - provides background of the thesis anda problem definition.

Chapter 2: Theory - describes the theory behind dependency injection andaspect-oriented programming with emphasize on Spring Framework.

Chapter 3: Method - describes how the thesis work is structured into differentphases involving research, design, implementation and evaluation.

Chapter 4: Application Overview - presents an overview including backgroundand requirements of the application that is developed.

Chapter 5: Architecture and Design - describes the architecture behind the ap-plication and how it is designed and implemented.

Chapter 6: Evaluation - evaluates the design and implementation in regard tothe use of dependency injection and aspect-oriented programming.

Chapter 7: Conclusion - draws conclusion based on the previous evaluation andsuggests possible future work.

3

Chapter 2

Theory

This chapter first introduces the Spring Framework which is the framework usedby the application developed as part of this thesis, next dependency injection andaspect-oriented programming will be described in detail.

The reader is assumed to have basic knowledge of design and architecture inregard to software development.

2.1 Spring Framework

The application developed as part of this Master’s project will be built using theSpring Framework.

Spring Framework is an open source application framework for Java originallydeveloped by Rod Johnson and commercially supported by the company Spring-Source.

The fundamental mission statement of the Spring Framework is to make enter-prise application development easier and less complex, especially in comparison toJ2EE [10].

The aim of the Spring Framework is that it should be largely non-invasive andapplications developed should not depend on the Spring API. In line with this aimSpring Framework does support integration with a range of other solutions, such asHibernate and other object-relational mapping solutions as well as web applicationframeworks like Struts. This makes it easy to use only parts of the Spring Frameworktogether with other existing solutions.

The Spring Framework provides a lot of functionality divided into modules whichmay be seen as smaller frameworks by themselves. Modules include frameworks fordata access, transaction management and security to support for remote manage-ment, messaging and testing.

What is most interesting among these modules are the inversion of control con-tainer that provides configuration of application components using dependency in-jection and the aspect-oriented programming framework. The support for depend-ency injection and aspect-oriented programming in the Spring Framework will be

5

CHAPTER 2. THEORY

described further in the corresponding sections about these topics below.

2.2 Dependency Injection

Dependency injection is introduced in this section including examples. How de-pendency injection is supported by the Spring Framework is explained followed bya brief overview of other dependency injection frameworks.

2.2.1 Background

Dependency injection originates from the concept of inversion of control. The pointof inversion of control is to achieve looser coupling and make modules more reusableby letting a container or framework take responsibility of the flow of control ofan application [9]. That is, inverting the flow of control compared to traditionalarchitecture, hence the name. Dependency injection is a special form of inversionof control where it is the acquisition of dependencies that is inverted. The termdependency injection was coined by Martin Fowler in 2004 [5].

2.2.2 Introduction

Using a dependency injection framework the responsibilities of construction, wiringand assembly of objects are removed from the clients or services themselves andinstead provided by the framework, thus inverting the flow of control.

Instead of making an object being responsible of getting hold of a service usinga factory pattern [6], service locator or creating it the object may instead simplyprovide a property that holds the reference that gets automatically set by the frame-work when the object is created.

There are three different types of dependency injection styles; constructor injec-tion, setter injection and interface injection. The difference between these types ishow they provide an object with references to dependencies.

• Constructor injection: references to dependencies are provided through theclass constructor.

• Setter injection: the object exposes a setter method that the dependencyinjection framework uses to inject the dependency.

• Interface injection: the object implements an interface that contains a methodthat allows the object receive a reference to the dependency.

Next an example is given to illustrate the use of dependency injection.

6

2.2. DEPENDENCY INJECTION

2.2.3 Example

An example will be given using a conventional approach followed by examples usingdependency injection. The examples are unrealistically small but concise enough toillustrate what is happening.

The example is a class representing a car. Characteristics (data) of the car likeweight, dimensions, engine type and so on are read from an external source andassigned to the object. The classes reading the data all implements the DataReaderinterface. The car object may look like this (only the relevant code is included):

public class Car {private DataReader reader;... // other variables representing the car

public Car() {DataReader reader = new DataFileReader("cardata.txt");

}}

It is the car object that creates the data reader explicitly using new. A somewhatmore flexible approach would be to use the factory design pattern but the mainproblem that the car itself is responsible for the type of data reader still remains.

Refactoring the car class to use dependency injection using the constructor itwould look like:


public Car(DataReader reader) {this.reader = reader;

}}

The significant difference with this solution is that the dependency is injectedinto the Car class; the Car class does not know, and should not know, what kind ofdata reader it gets.

Using setter injection the data reader property is set using a setter method afterthe object is created instead of as a constructor parameter.


public Car() { }

public void setReader(DataReader reader) {this.reader = reader;

}}

Using dependency injection neither class (Car or DataReader) need to be awareof or explicitly ask for each other. The Car class simply needs to accept a data

7

CHAPTER 2. THEORY

reader object and does not need any logic of how to create a data reader class,allowing the remaining code to focus on the ”business logic” instead of includingboilerplate infrastructure code for wiring and construction of dependencies [19].

What is left out of these examples is how the dependency injection is configured.This depends on the dependency injection framework and may be done using con-figuration files, annotations or programmatically. In the next section examples aregiven for using dependency injection in Spring Framework.

2.2.4 Dependency Injection in Spring Framework

Continuing the example in the previous section the next thing to do is configuringthe wiring of the objects. In the Spring Framework the most common way to dothis is using XML-files [11]. As of version 2.5 of the Spring Framework it is alsopossible to use annotations to configure dependency injection.

In the example a DataReader class and a Car class needs to be configured. Anexample of the XML-configuration (with XML header omitted for clarity) followsbelow.

<bean id="filereader" class="se.kth.spett.di.DataFileReader"><constructor-arg value="cardata.txt"/>

</bean>

<bean id="car" class="se.kth.spett.di.Car"><property name="reader" ref="filereader"/>

</bean>

The id is used to identify the object (bean) and the class field specifies whatclass to instantiate. In the example a DataFileReader instance is created usingconstructor injection to set the source file.

The Car object is using setter injection to automatically set a reference uponcreation to the file reader object. This is done by referencing the previously specifiedid filereader.

The following code example shows how to get a reference to the Car instanceusing a BeanFactory.

package se.kth.spett.di;

import org.springframework.beans.factory.BeanFactory;import org.springframework.beans.factory.xml.XmlBeanFactory;import org.springframework.code.io.FileSystemResources;

public class Example {public static void main(String[] args) throws Exception {

BeanFactory factory =new XmlBeanFactory(new FileSystemResource("config.xml"));

Car car = (Car) factory.getBean("car");

car.doStuff();}

}

8

2.3. ASPECT-ORIENTED PROGRAMMING

Using the getBean() method of the BeanFactory object with the previouslydefined id as an argument a reference to the instance of the Car object is retrieved.

When an object is defined the default scope is set to singleton. That meansthat there will be a single shared object instance for all subsequent requests andreferences. The opposite is the prototype scope where a new instance is createdeach and every time the prototype is referenced. Additional types exist where it ispossible to scope an object to the life-cycle of a HTTP request or session.

Auto-wiring

The Spring container does also support auto-wiring between defined objects. Usingauto-wiring it is possible to automatically let Spring resolve how object should bewired by expecting the class itself using either property name or property type.

With auto-wiring it is possible to significantly reduce or eliminate the XML-based wiring configuration. The disadvantage is that it is harder to see the rela-tionships between objects since there is no explicit configuration anywhere.

It is possible to combine auto-wiring with explicit wiring.

2.2.5 Other Dependency Injection Frameworks

Some of the other most popular Java dependency injection frameworks are brieflymentioned here.

Guice1 is an open source dependency injection framework for Java 5 developedby Google. Guice exclusively uses annotations for wiring dependencies.

Another framework is PicoContainer2 that instead of annotations or XML-filesprovides an API to programmatically configure the wiring of objects.

EJB 3 does support dependency injection of two types; field injection and setterinjection [17]. Field injection allows the container to inject a reference to a privatevariable without any public setter method.

2.3 Aspect-Oriented Programming

This section gives an overview of aspect-oriented programming (AOP), startingwith some background information and an introduction of what kind of problemsit attempts to solve. Next the terminology used is explained followed by a concreteexample of aspect-oriented programming applied to provide a solution for a typicalcross-cutting concern.

Finally, AOP frameworks are described in general, with a particular focus onthe aspect-oriented programming in the Spring Framework.

1Google Guice: http://code.google.com/p/google-guice/2PicoContainer: http://www.picocontainer.org/

9

CHAPTER 2. THEORY

2.3.1 Background

Methodologies for programming computers have evolved to make developing soft-ware more efficient. The introduction of procedural programming is a big step for-ward compared to using machine-level languages. Procedural programming evolvedand object-oriented programming is now the de facto standard for most new soft-ware development projects [15].

Object-oriented programming introduced object abstraction and makes it easierto model common behavior and encapsulate it in a modular way. Modulariza-tion makes a system more flexible, easier to maintain and quicker to develop [18].However, many programming problems are of such type that neither object-orientedprogramming nor procedural programming does provide a way to sufficiently designand implement these cross-cutting concerns [13].

This often leads to compromises where code for the particular concern is beingscattered through-out several modules. This result in code tangling that makes notonly the implementation of the concern itself, but all modules affected by it, moredifficult to develop and maintain [13].

These types of problems are called cross-cutting concerns, since they cut acrossdifferent modules, and that is what aspect-oriented programming attempts to solveby providing a way to separate these concerns into modularized aspects.

2.3.2 Introduction

An example featuring a simplified hotel management system will be used to give anintroduction to aspect-oriented programming and what it attempts to solve. Thehotel management system is used by the hotel staff to book rooms for guests, reservetables at the dinner restaurant and so on.

At first glance the module (or class) responsible for booking a room seems prettystraight forward. First the availability of a room is checked, if it is vacant duringthe period the guest would like to stay then go ahead and reserve the room for thatparticular period.

However, not anyone in the staff should be able to book a room and hence asecurity check is needed to verify that the current user actually has the authorizationto perform this task.

In addition, every task needs to be logged in a database so it is possible to seewho did what and when, as well as statistics for the hotel management.

Inserting method calls to provide security and logging in the room bookingmethod is simple, but it adds external dependencies to other modules and thusmaking the room booking module coupling tighter. In the same way it lowers themodule cohesion since the room booking module must now also be responsible foruser authorization and to trigger logging of the task.

Figure 2.1 illustrates how the room module invokes the API of the logging andsecurity modules.

Now imagine all other modules in the hotel management system, from booking

10


Loggingmodule

Security modulebookRoom(...)

Room module

API calls

Figure 2.1. Logging and security implemented in an non aspect-oriented way. Theroom module is responsible for invoking the API of the logging and security modules.

the sauna to reserving dinner tables and managing staff vacations. It is easy to seethat concerns such as security and logging must be adhered to in many modules,scattering calls to security and logging functionality all over the system. Securityand logging are typical examples of cross-cutting concerns.

These types of cross-cutting concerns are what aspect-oriented programmingattempts to solve.

In aspect-oriented programming cross-cutting concerns such as security and log-ging may be modularized into aspects. An aspect may be configured to automaticallybe executed based on a simple set of rules to remove the responsibility from eachmodule, class or method it will be applied to.

As an example a security aspect may be automatically executed before everycall to a method with a name that starts with book (e.g. bookRoom(...)). It thenonly executes the invoked method if the current user is authorized.

Figure 2.2 illustrates the room booking implemented using aspect-oriented pro-gramming.

Using aspect-oriented programming code scattering and code tangling is reducedsince the booking modules now only contain their core logic for booking and notcalls to facilitate security and logging. This results in lower coupling and highercohesion thus improving modularization.

2.3.3 Terminology

To be able to discuss aspect-oriented programming some of the most fundamentalparts of the vocabulary need to be described more in detail.

Even though the terms may be implemented in different ways and supportedto various degrees depending on framework, they are general to aspect-oriented

11

CHAPTER 2. THEORY

Loggingaspect

SecurityaspectbookRoom(...)

Room module

Loggingmodule

Securitymodule

Automatically woven calls

API calls

Figure 2.2. Logging and security implemented using aspect-oriented programming.The aspects define when and how to invoke the logging and security API without theneed for any calls from the room module.

programming as a whole.

Advice

An advice describes what to do when an aspect is applied. It contains the code thatperforms the actual logic that should be carried out. As an example, if the purposeof the aspect is to log events that are executed in an application the advice willcontain the code that results in the appropriate string being written to the log file.

An advice can be executed before, after or around join points (which is describednext). It may replace the code of a join point, or even bypass it.

Join point

Join points are all possible places in the code where an advice may be executed.They are called join points because they represent points in code where an advicemay be joined (or plugged in).

Possible join points may be method calls, construction of objects, an exceptionbeing thrown or when a field is modified. What different types of join points thatare supported vary between different aspect-oriented programming frameworks.

In the logging example used in the advice description, join points would be allpossible locations in the code where the logging advice may be triggered.

Pointcut

A pointcut answer the question of where an advice should be executed by specifyinga set of join points. Pointcuts specifies join points usually through class or method

12


names, either explicitly or by using regular expression patterns.Exactly how pointcuts are expressed vary between different framework imple-

mentations [22]. Some does also allow the creation of dynamic pointcuts that dependon runtime decisions; such if an advice should be applied depending on the value ofa method parameter.

Continuing the logging example a pointcut decides where logging should be done(out of all possible join points), for example when methods starting with the stringbook are called.

The most common types of pointcuts include before, after and around. The firsttwo are triggered just before and after a method is invoked, while the around adviceencapsulates a method call and therefore allows code to be executed both beforeand after, including skipping the call completely.

Introduction

An introduction enables the ability to add new methods or attributes to an alreadyexisting object. This means it is possible to give existing classes new behaviorwithout changing them. The concept of introductions is analogous with mixins [3]popular in languages like Python and Ruby.

Aspect

The central unit where advice, pointcuts and introductions are combined is calledan aspect. Beside these aspect-oriented specific details it may also contain variables,methods and nested class members, just like a normal class in Java.

An aspect in the logging example defines everything there is to know aboutit, including where logging should be applied (pointcuts) and when and how thelogging should be done (advice).

Target

The target is the object that the aspect is applied to.

Weaving

Weaving is the process of combining aspects and the target objects into a completesystem. Aspects are woven into objects at the specified join points.

The weaving itself may be done in several ways; at compile time, at classload orduring runtime.

2.3.4 Example

The following examples are extremely simplified and contain no business logic sothe execution flow is easy to see. The purpose is to give a basic example of how

13

CHAPTER 2. THEORY

aspect-oriented programming looks like and how it is different compared to pureobject-oriented programming.

The main class is Room that contains the bookRoom() method that takes aninteger that identifies what room to book. The main method simply makes twocalls to illustrate the execution flow when invoking the bookRoom() method.

package se.kth.spett.aspectj;

public class Room {public void bookRoom(int id) {

System.out.println("Room " + id + " booking logic performed");}

public static void main(String[] args) {Room room = new Room();room.bookRoom(1);room.bookRoom(0);

}}

Next is the Logging aspect that performs logging before and after a call to thebookRoom() method in the Room class. The pointcut definition logging applies toall public methods in the Room class starting with ”book”, no matter of return valueand accepted parameters.

Two join points are defined to be executed before and after the logging pointcutis triggered.


public aspect Logging {public pointcut logging(): call(public* se.kth.spett.aspectj.Room.book*(*));

before(): logging() {System.out.println(

"Entering: " + thisJoinPointStaticPart.getSignature().getName());

}

after(): logging() {System.out.println(

"Exiting: " + thisJoinPointStaticPart.getSignature().getName());

}}

The Security aspect has a similar pointcut but applies an around advice andonly conditionally proceeds with the original call. The unrealistically simplifiedcode in the example may be replaced with logic that verifies if the current userhas permission to book the particular room. If not, the call will not proceed (asillustrated in the example when i is equal to zero).


public aspect Security {public pointcut access(): call(public* se.kth.spett.aspectj.Room.book*(int));

14


void around(int i): access() && args(i) {if (i == 0) {

System.out.println("Blocked call when i == " + i);return;

} else {proceed(i);

}}

}

Running this trivial example compiled with AspectJ produces the following out-put:

Entering: bookRoomRoom 1 booking logic performedExiting: bookRoomEntering: bookRoomBlocked call when i == 0Exiting: bookRoom

Each call is logged both before and after a call by the Logging aspect and inthe case when bookRoom() is called with 0 (zero) as argument the called is blockedby the Security aspect.

2.3.5 Aspect-Oriented Programming Frameworks

Depending on the framework used to enable aspect-oriented programming the fea-tures supported may be different. Differences include what kind of join points thatare exposed, how pointcuts are defined, and how and when weaving take place.

The Spring Framework is the foundation of the application developed as partof this Master’s project and the built-in support for aspect-oriented programmingin the framework will be used. AspectJ is the most widely adopted framework foraspect-oriented programming [12].

These frameworks are briefly described below with an emphasis on how aspect-oriented programming in Spring is different from AspectJ.

Spring AOP

The purpose of the support for aspect-oriented programming in the Spring Frame-work is to allow users to implement their own aspects in a simple and easy wayand to provide declarative enterprise services (most importantly transaction man-agement) in the framework itself [11].

Therefore Spring AOP is not, and does not intend to be, a full-blown AOPframework such as AspectJ.

Advice in Spring is written as a standard Java class and pointcuts are specified ina XML configuration file or by using annotations. The weaving in Spring is done inruntime by wrapping the target object with a proxy class. When a call is made theproxy class poses as the target and intercepts calls where advice should be applied.

15

CHAPTER 2. THEORY

Because of this there is no need for a special compilation process, everything is pureJava and applications may be used directly in a J2EE web container or applicationserver.

The most apparent limitation of Spring AOP is that it does only support methodjoin points. The possible types of advice available are:

• Before advice: Advice is executed before a method but may not prevent exe-cution of the method unless an exception is thrown.

• After returning advice: Advice is executed after a method returns normally.

• After throwing advice: Advice is executed if a method exits by throwing anexception.

• After (finally) advice: Always executed after a method has executed.

• Around advice: Surrounds a join point and may perform custom behaviorbefore and after a method invocation, it may also decide to skip executing thecalled method altogether.

If more fine-grained advice than what is possible with method join points isneeded it is also possible to use AspectJ within the Spring Framework.

AspectJ

AspectJ is the most widely used standard for aspect-oriented programming and wasa product of the research led by Gregor Kiczales at Xerox PARC [13]. The firstpublic version of AspectJ was released in 2001. AspectJ is now an open-sourceproject in the Eclipse Foundation [1].

AspectJ is an extension to Java where the AspectJ language is used to specifypointcuts and how they should be applied and Java is used to implement the coreconcerns.

Every Java program is a valid AspectJ program and the AspectJ compiler pro-duces standard Java class files that may be executed by any compliant Java virtualmachine. AspectJ supports compile-time weaving, post-compile weaving (weavingaspects into already compiled classes) and load-time weaving (LTW). With load-time weaving the weaving takes place when Java virtual machine uses the classloader to load the class.

EJB 3

EJB 3 (Enterprise JavaBeans), part of JavaEE 5, supports aspect-oriented program-ming in terms of interceptors. The AOP features supported are limited; however,they don’t require the complexity related to introducing a full-fledged AOP frame-work like AspectJ [17].

Interceptors are objects that are automatically executed when a method is in-voked in an EJB object. The type of pointcut supported is the around advice,

16


that allow custom behavior to be executed at the beginning of a method, as wellas after the method with the possibility to react to both return value and thrownexceptions.

17

Chapter 3

Method

This chapter describes the different stages of how the project was carried out fol-lowed by a short reflection on the method used with possible alternative methods.

The main purpose of this Master’s project is to evaluate the consequences ofusing dependency injection and aspect-oriented programming in a real-world pro-ject. Hence, the method resembles very much the process of a software developmentproject at a company. Following the development phase an evaluation is conductedto recapitulate the questions put forward in the problem definition.

3.1 Overview

The sections below give an overview of the different stages of the project.

3.1.1 Literature Study

Initially a literature study was done with three goals in mind, although somewhatoverlapping.

The first goal was to gather a basic knowledge of the fundamental technologiesand tools used in the development of the prototype application. Most notable thisinvolved reading books about the Spring Framework [23], Hibernate [2] and JavaEnterprise design and development in general [10].

The second goal was to study the principles of dependency injection and aspect-oriented programming in general. Since they both are fundamental parts of theSpring Framework this was partly already covered. In order to get more generalknowledge of application of the techniques outside the Spring Framework the liter-ature study was complemented with journal articles [24] and further reading aboutAspectJ [15].

The third and final goal was to gather knowledge about related academic workabout the use and consequences of dependency injections and aspect-oriented pro-gramming. This part included reading the original paper published about aspect-oriented programming by Kiczales et al [13].

19

CHAPTER 3. METHOD

Worth noting is that there are a fairly large amount of published articles andpapers about aspect-oriented programming while those about dependency injection(and inversion of control) is much more rare. This is no surprise since the use ofdependency injection is more about introducing a design pattern [5] compared tothe introduction of a new programming paradigm [8], where the latter has receivedmuch more interest from the academic world.

3.1.2 Requirements Analysis

A requirements analysis of the application to be developed, the recruitment system,was done by meetings, discussions and interviews with users and stakeholders ofthe system. The focus of this phase was to understand the recruitment process andidentify where in the process the most benefit of a software system may be achieved.This approach was chosen, instead of asking for a set of feature specifications,because users usually don’t understand what they want or have a clear idea of theirrequirements [16]. The gathered requirements were put together and presented toverify their validity.

3.1.3 Design

Based on the identified features that are deemed as feasible to be part of the proto-type an overall architecture and design of the application was done. The goal of thedesign was to achieve best practices using the Spring Framework [23] and softwaredesign in general. What is important to note is that design decisions were madebased on factors involving requirements, feature scope, time constraints, previousknowledge and expertise. Although the use of dependency injection and aspect-oriented programming was always in mind, these principles was only used where itmade sense rather than being forcefully applied everywhere just because they arethe topic of this Master’s thesis.

3.1.4 Development

The development phase of the project was divided into four sprints (time periods)of about two weeks realized in what might resemble a one-man Scrum project [14].What this basically means is that a product backlog consisting of the identifiedfeatures is created. For each sprint the features with the highest priority (froma business perspective) is picked to be included in the backlog for the upcomingsprint (sprint backlog). When new requirements arise, both in terms of identifiednew features or fixes/additions to existing features, they are added to the productbacklog.

Although the Scrum methodology is much more than that [20] it served as agood way to prioritize what should be done during the development phase.

Actual implementation was done focusing on getting a feature to work in themost basic way and then refactoring the code as needed. Adequate testing code

20

3.2. ALTERNATIVE METHODS

for unit testing and automatic integration testing were implemented as part of eachfeature.

3.1.5 Evaluation

Finally the evaluation phase addresses the questions presented in the problem defin-ition. Although the evaluation step is the last, it does permeate the whole processfrom requirements gathering to development and deployment.

3.2 Alternative Methods

The method described that will be used is based on a subjective criterion and has aqualitative rather than quantitative approach. This is something that needs to beconsidered in the evaluation phase since background and experience of the authorin combination with the subjective nature of the evaluation is something that willbe a factor even if the goal is to minimize it as much as possible.

The choice of method is largely the result of time and resource constraints andthe circumstances around this particular Master’s thesis work.

Alternative methods would include developing two systems according to thesame requirements, one using aspect-oriented programming and dependency injec-tion and another only using an object-oriented approach. Using such a method itmay be easier to identify the differences and consequences of each approach.

Building on this alternative method a more quantitative and empirical methodwould involve several developers assigned to develop the different approaches. Toempirically evaluate aspects like readability, understandability and maintainabilityof the different approaches a set of other developers may be tasked to performchanges on the different systems. Also defined measures like CBM (coupling betweenmodules), LCO (lack of cohesion in operations) and RFM (response for a module)may be used for comparison [4] together with metrics to indicate system size likenon-comment lines of code and number of modules.

3.3 Tools

Several tools, all free open source, were used during the development of the proto-type application1. As a development environment NetBeans IDE 6.1 was used withMaven 2 for build management. Unit testing was done using JUnit while CanooWebTest was used for automated integration testing.

Subversion was used for version control and Hudson served as an automatedcontinuous integration tool.

Primarily GlassFish was used as Java application server. Also Jetty, which is alightweight servlet container, was used for testing.

1See appendix A for references and web links to the different tools mentioned here.

21

Chapter 4

Application Overview

The real-world project the questions in the problem definition are applied to is thedevelopment of a web based recruitment system. The purpose of the system isto support the Human Resource department during the recruitment process, fromreceiving an application until a decision is made to hire or decline a candidate.

The purpose of this chapter is to describe the background, requirements, scopeand interface of the system to give a better understanding of the project and whatis developed.

4.1 Background

The recruitment process at Avalanche Studios is managed more or less manuallyusing a simple Excel document to track status and keep information related to acandidate. With more than one recruiter and several technical specialists involvedin the process this is getting out of hand in regard to communication (internal andwith the candidate), managing data and files like portfolios and work examples,keeping relevant information in one place and so on.

Avalanche Studios is one of the largest game developers in Sweden developinggames primarily for Xbox 360, Playstation 3 and PC. As of July 2008 there areabout 160 employees at Avalanche Studios. Being a game developer means there areseveral categories of employees and candidates with slightly different requirementsfrom a recruitment process perspective.

A programmer, 3D artist and producer need to be evaluated differently in therecruitment process because their discipline requires different skills (technical, aes-thetical, administrative, leadership, etc).

4.2 Goal

The main goal of the application is, in regard to the recruitment process, to supportthe Human Resource staff (the recruiters) during the whole recruitment process andmake their work more effective. This is achieved by automating as many tasks as

23

CHAPTER 4. APPLICATION OVERVIEW

Advertisement Receive Application Selection

Communication

Interview Response

Figure 4.1. After an application is received the candidate is evaluated. The evalu-ation including selection, communication and interview is iterative, where a candidateusually is interviewed more than one.

possible in the recruitment process and by providing support for other activities byallowing the system to manage and distribute relevant information.

4.3 Actors

There are persons with different roles that will interact with the system. They arereferred to in this document as candidates, recruiters and specialists.

• Candidate: The person applying for a position by sending in a resume andother related information like a personal letter and portfolio.

• Recruiter: The person doing the recruitment including selecting candidates,conducting interviews, and so on. There are multiple recruiters using thesystem and multiple recruiters may be involved in the recruitment process ofa single candidate. The terms recruiter and user are used interchangeably inthis document since the primary user of the application is a recruiter.

• Specialist: A person in the company with specialist knowledge (like an artdirector or lead programmer) or in a management position that is involvedin the recruitment process, primarily by giving feedback on the selection ofcandidates and conducting interviews. There are several specialists and theyare different depending on candidate and position.

4.4 Process Overview

Figure 4.1 illustrates the different steps in the recruitment process. Although theprocess is generalized it does serve well as the starting point for a brief discussionabout the result of the requirements gathering phase prior to development.

The intent is to give an understanding of how the application may support eachstep in the process rather than to specify individual requirements.

24

4.4. PROCESS OVERVIEW

4.4.1 Advertisement

Open positions are advertised on the company website. Publishing and editing posi-tions are managed by recruiters using an administrative interface of the application.

The published positions are displayed on public pages that require no authen-tication. In order to integrate well with the existing company website the publicpages must support a custom look and style.

4.4.2 Receive Application

A candidate applies for a position by submitting a form on a web page associatedwith the desired position. The candidate must fill in all mandatory questions likename and email address. Next the candidate uploads related files to the applicationlike a curriculum vitae, personal letter and examples of previous work (if applicable).

Once successfully submitted a candidate profile is created in the application. Thecandidate profile is the central place where all related information of the candidateis located.

A candidate profile may also be created from within the application itself bya recruiter in case when the recruitment process is initiated without an applica-tion through the web page. An example of this situation may be when there is arecommendation of a person who have not applied herself.

4.4.3 Selection

All candidates in the application may be sorted or searched based on differentcriteria to support the selection of candidates in the recruitment process. To allowfor useful search queries a candidate is associated with a status and additional fieldssuch as type of position as well as notes and reminders.

In the selection process other people in the company may be involved (special-ists). In order to facilitate their involvement and avoid duplicating the candidateprofile (to send in an email as an example) a recruiter may give limited access to aspecialist so the specialist may review information about a specific candidate andenter feedback.

4.4.4 Communication

All communication and discussions with a candidate should be logged and availablefor others as well as for archiving in case of later review. A candidate profile in theapplication does allow for notes in terms of log entries to be stored. A log entrymay be created to associate information with a candidate together with a date andinformation about who created the log entry. This information is then visible toother recruiters reviewing the candidate.

Ultimately all communication would automatically be associated with a candid-ate, like an email conversation. This is possible by having the application interact

25


with an email server. However, this feature is considered out of scope due to thetime constraints involved with a Master’s project.

4.4.5 Interview

The interview phase of the recruitment process is a way to get more informationabout a candidate to make a better selection of which candidates to proceed withand which to reject.

The application does support the interviewing in two ways. It does provide aneasy way to review and print all information about a candidate using the candidateprofile and after an interview is finished an evaluation and summary of the candidatebased on the interview may be entered.

4.4.6 Response

The application may send out scheduled or on-demand emails to a candidate, mak-ing it possible for a recruiter to easily communicate a decision to the candidate inthe recruitment process. This specific feature was asked for when there are manyunqualified candidates applying for a position and they need to be rejected. Insteadof rejecting them initially an email may be scheduled to communicate the decisionat the same time as the period when applications are accepted has ended.

4.5 Requirements

The result of the requirements analysis includes far more functionality than whatis possible to realize within the scope of a Master’s project. Only a subset of theidentified features will be implemented as part of the prototype developed.

The main goal is not to include as many features as possible in the implement-ation as long as the scope of the application is substantial enough to provide afoundation for evaluation and addressing the questions asked in the problem defin-ition.

The previous section discussing the recruitment process and how the applicationmay support it is the result of discussions with staff from the Human Resourcedepartment over several meetings. In addition to those features there are someadditional requirements and non-functional requirements discussed below.

4.5.1 Non-Functional Requirements

Some non-functional requirements were identified during the requirement analysis.

• When designing the application the top priority should be to keep it simpleto the user. Rather fewer and more generic features than a lot of specializedfunctionality.

26

4.6. USER INTERFACE

• No prior knowledge, expect basic web browser usage, on behalf of the users ofthe application may be assumed.

• All components, including framework, libraries, development platform andhosting services (database, application server, operating system, etc) must befree and require no license cost.

• The application should require no or little additional system maintenancebeside regular duties common to all hosting (backup, security patching).

4.5.2 Additional Requirements

User authentication and authorization is needed since recruiters, specialists and can-didates are all somehow interacting with the system but should have fundamentallydifferent permissions in terms of what they may do and what information they maysee.

To manage users of the application user administration functionality must beprovided that allows creating, editing, disabling and removing users.

4.6 User Interface

The diagram in figure 4.2 illustrates a simplified overview of the different parts ofthe application from a user interface perspective.

The diagram is divided into two major sections. The internal (left) sectioncontain the different views available to recruiters and specialists; hence users mustbe authenticated to access the internal pages of the application. Authenticationis done using username and password. To the right is the public section whichrepresents the pages accessible by candidates when applying for a position.

27


Positions: List

PositionView / Edit

Candidates: List

CandidateView / Edit

User Administration

UserView / Edit

Search

Filter

Log

Reminders

Attachments

Roles

Overview Statistics

Positions: List

Info

Apply

Internal Public

Figure 4.2. User interface overview.

28

Chapter 5

Architecture and Design

This chapter describes the general architecture of the application and the differenttechnologies used followed by a more detailed design of the implementation.

The intention is to give an overview of how the application has been implementedwithout dwelling on specific solutions only relevant to requirements applicable onlyin this particular case. In the same way, specific information about the use ofthird-party and framework modules is only briefly mentioned, instead of duplicatingalready existing framework reference documentation.

5.1 Architecture

The intention is to give an overview of which components are used with a briefdescription explaining what they are and their purpose in the application.

Figure 5.1 shows the general architecture with what components are used forthe different layers to develop the application.

5.1.1 Application Server

To run the application GlassFish v2 is used. GlassFish is an open source applic-ation server for the Java Enterprise Edition (Java EE) platform headed by SunMicrosystems. It is also called Sun Java System Application Server 9.

Although GlassFish is a fully compliant Java EE 5 application server, not allfeatures are required considering the feature set of the application that is withinthe scope of the prototype. A servlet container like Apache Tomcat or Jetty wouldalso be possible to use.

5.1.2 Data Storage

Data is stored using MySQL which is a relational database management system.Due to the design and the data access layer of the application MySQL is not arequirement by itself and may be substituted by most other popular SQL databasesystems.

29

CHAPTER 5. ARCHITECTURE AND DESIGN

Rendering : JSP

Presentation Layer : Spring MVC

Business Layer : Spring Framework 2.5

Data Access (ORM) : Hibernate 3

Data Storage : MySQL 5

Application Server : GlassFish v2

Bui

ld :

Mav

en 2

Figure 5.1. Overview of components in application architecture.

5.1.3 Data Access

Persistence of objects and management of relational data is done using the JavaPersistence API (JPA) with Hibernate as the Java persistence framework.

Hibernate is an object-relational mapping (ORM) framework for Java thatmakes it possible to map classes in Java to database tables.

5.1.4 Business Layer

At the core of the application is the Spring Framework that, among many otherthings, provides modules that facilitates dependency injection and aspect-orientedprogramming.

5.1.5 Presentation Layer

Spring MVC, the Model-View-Controller framework of the Spring Framework isused for web related logic and the presentation layer.

30

5.2. DESIGN

5.1.6 Rendering

JavaServer Pages (JSP) is used to render the actual view of the Model-View-Controller architecture provided by Spring MVC. Also a number of custom madeand publicly available tag libraries was used, most notable those part of the SpringFramework. Additionally, Display Tag was used to enhance the display of tables inthe application.

5.1.7 Build Tool

Apache Maven is a build automation tool somewhat similar in functionality to themore well-known Apache Ant. One key difference is that Maven may automaticallydownload component and library dependencies from the Internet, making it easierto maintain a complex project.

5.2 Design

This section describes the overall design of the application in terms of how it isimplemented. The general design is described followed by a discussion about theparticular use of dependency injection and aspect-oriented programming in the ap-plication.

5.2.1 Application Design

The implementation design of the application is illustrated in figure 5.2. Theblocks with text in italic font are non-custom components (Spring MVC and SpringSecurity is part of the Spring Framework) and Hibernate is a component by itself.The fact that the implementation uses the Spring Framework may be imagined asanother box encapsulating the whole figure.

As illustrated in the figure the security module of the Spring Framework calledSpring Security is leveraged to provide authentication and security throughout theapplication.

What is described is the general implementation design of the application ratherthan details that only relates to specific functionality.

DAO

Data Access Objects (DAO) are used to abstract and encapsulate all access to theunderlying persistence system and data base. All Hibernate specific code is locatedin Data Access Objects. Typically there is a DAO for each object in the domainmodel.

31


Spring MVC

View

Controller

ServiceManager

DAO

Hibernate

DB

Model

Model

Spring S

ecurity

Figure 5.2. Cross-section diagram of application implementation design.

ServiceManager

It is in the service managers where all business logic code resides. Controllers useone or more service manager objects and each service manager object use one ormore DAOs.

Model-View-Controller

The Model-View-Controller (MVC) architectural pattern is used to separate busi-ness logic from presentation in the web interface. This is implemented using theSpring MVC module that is part of the Spring Framework.

The model represents the actual content that is manipulated or displayed andthe controller manages and determines what is to be displayed. The view is theactual rendering of the model.

32

5.2. DESIGN

In this application the model often resembles a persistent java bean. A controlleris a servlet and the view is a JSP page.

A typical scenario is when a user clicks a link on a web page of the applica-tion. Then a HTTP GET request is made that is managed by a dispatch servlet.Depending on the URL the dispatch servlet forwards the request to the appropri-ate controller that populates a model. The model is rendered using a view andultimately displayed as a HTML page.

Design by Interface

To achieve decoupling, classes interact with each other using interfaces rather thanspecific implementations in form of classes. This technique is called design by in-terface [21].

The purpose with design by interface is to have looser coupling between differentparts of the application and have less dependencies on specific implementations. Thetechnique is applicable on both class part of the standard Java library as well asapplication specific classes.

As an example, by accepting a java.util.Map (which is an interface) as amethod parameter instead of a java.util.HashMap (which is an implementation)it is possible to replace the implementation of the map without breaking anything.This is possible since the dependencies exist only to the interface, and not the actualimplementation.

This technique together with dependency injection is especially powerful. Whenperforming unit testing mockup objects are inserted instead of full implementations.As long as they implement the correct interface the object that is tested will notknow the difference.

5.2.2 Dependency Injection

Dependency injection, and the Inversion of Control container in the Spring Frame-work providing the dependency injection, is such a central part so it is used moreor less throughout the whole application.

It is used to create objects, everything from DAOs to services and controllers,and configure them by using injection dependencies either using setters or in theconstructor.

Here are some examples of how it is used. All DAO classes are instantiated andinjected with a reference to the Hibernate session factory which enables persistence.Service implementations in the service layer are injected with the needed DAOinstances and controllers are injected with the requested services.

Beside the injection of references to other objects it is used for property con-figuration of objects. As an example, a controller object managing a web form hasa property called successView that decides what view to render if the submittedform was successfully validated. This property value is specified in an XML-file andset upon object instantiation via dependency injection.

33


5.2.3 Aspect-Oriented Programming

Aspect-oriented programming is applied in two different ways, both related to se-curity.

In the service layer an around advice has been applied to methods that ensureonly users authenticated as administrators may access those specific methods. If theuser is not an administrator the invoked methods are not executed and an exceptionis thrown resulting in an error page being displayed to the user.

The other advice is responsible for enforcing security and only allowing admin-istrators to edit a user, except when users edit themselves. This is also done inthe service layer by explicitly naming the saveUser() method of the UserManagerclass in the pointcut definition. The advice makes use of both the types before andafter.

34

Chapter 6

Evaluation

In this chapter the results of using dependency injection and aspect-oriented pro-gramming in the development of the aforementioned application are evaluated anddiscussed with the problem definition in mind.

The chapter is divided into two sections, one discussing dependency injection andone discussing aspect-oriented programming. In each section the most significantfindings are presented divided into sub sections after the original questions posedin the problem definition. The sub sections are design, maintainability and testing.

Design is about how the application architecture and design of implementationis affected by the use of the technology in question.

Maintainability deals with the consequence of how easy the implementation isto maintain (for the original developer but more importantly for someone else notfamiliar with the code) as a result of the use of dependency injection and aspect-oriented programming. Maintainability includes properties such as readability, im-pact on refactoring and overall understandability of the code.

Finally testing includes testing of the application as a whole as well as featuresintroduces by the technology itself.

These three aspects are not discrete and may often overlap, as an example,something that improves the design and architecture of an implementation mayoften also make the implementation easier to maintain.

The evaluation, discussion and possible conclusions in this chapter are all madeby the author based on the experience gathered from the design and implementationof the application described in this master thesis.


6.1.1 Design

Easy to implement

Dependency injection is such an integral part of the Spring Framework that it ismore or less not possible to be without it unless just single modules of the Spring

35

CHAPTER 6. EVALUATION

Framework are used. Classes in the Spring Framework are all designed to havedependencies injected where possible.

Hence there is no question if dependency injection should be used or not if thepower of the Spring Framework is leveraged, instead it is more interesting to lookat the impact of design using dependency injection on objects not coupled with theframework itself.

The use of dependency injection does not affect any business logic or object-oriented design of objects. What it does is it to provide an alternative way to getreferences to dependent objects. Because of this little or no modifications to theoverall design of a system is required to change in order to use dependency injection.

Framework or not

If using the Spring Framework or another framework where dependency injectionis included there is no reason not to use it.

However, if for various reasons a framework that provides dependency injectionmay not be used the concept and pattern of dependency injection is still useful whendesigning classes.

By implementing the classes with interfaces designed for setter- and constructorinjection and creating them using a factory like pattern much of the benefit ofdependency injection remains without the need to introduce a complete framework.

6.1.2 Maintainability

Less boilerplate code

In general less boilerplate code is required when relying on dependency injectioninstead of conventional lookup or creation of dependent objects. This is the case be-cause dependencies are injected typically using a setter method or in the constructorinstead of being created and instantiated, retrieved through lookup methods codeor using factories.

Less boilerplate code results in higher object cohesion since the code focuses lesson infrastructure issues such as construction and retrieval dependent objects andmore on performing the application logic.

Exposed dependencies

By consequently using dependency injection all dependencies of an object are re-trieved using constructor or setter injection. This means that it is possible to identifyall external dependencies by only looking at the signature of the constructor andthe public setter methods.

Another approach is to consider the configuration of dependency injection tosee what references are injected into each object. Using Spring the dependencyinjection is typically in XML. Worth noting is that if auto-wiring is used the abilityto identify dependencies by looking at the configuration is significantly reduced.

36

6.1. DEPENDENCY INJECTION

The conventional way without using dependency injection would require readingall method implementations line by line.

The risk is when conventional dependency lookup is used together with depend-ency injection. Then it is easy to miss dependencies only visible in code of methodimplementations if only looking at the method signatures or dependency injectionconfiguration.

Refactoring

Dependency injection promotes the design of less coupled code since an object’sdependencies are injected rather than retrieved using infrastructure code in theobject itself. This by itself often makes refactoring easier.

An example of when refactoring is needed is when dependencies change. Forexample a collection of data changes from one data type to another. The refactoringis potentially made significantly easier with a system using dependency injectioncompared to conventional design. This is especially the case when dependencyinjection is used together with the concept of design by interface (see section 5.2.1).

The reason why refactoring becomes easier in this case is because dependenciesare injected and the only ”contract” between the dependency and the object per-forming logic on the dependency is the interface. If a dependency changes but stillimplements the same interface little or no changes need to be done to the object.

6.1.3 Testing

Following the discussion about refactoring it is easy to see that unit testing benefitsas well from dependency injection. In general less coupled objects are easier to unittest, but when there are dependencies they sometimes need to be replaced by mockobjects.

A mock object is an object that simulates the behavior of a real object whenthe real object is impractical to use in a unit test. There are several reasons whymock objects may be used, examples are objects with special states that are hardto reproduce (like network errors) or too slow (certain database queries). In unittesting of web applications it is common to use a mock object representing an HTTPrequest.

Dependency injection allow easy replacement of objects with mock counterpartswhere needed. If dependencies were not as easy exposed this might potentially bea very troublesome operation.

37



6.2.1 Design

Separation of concerns

Compared to dependency injection aspect-oriented programming has big impact onthe design and implementation of an application. With the concept of separatingscattered concerns into aspects a solution would be designed significantly differ-ent when using aspect-oriented programming instead of only conventional object-oriented programming.

With successful use of aspect-oriented programming, cross-cutting concerns pre-viously scattered throughout a system may be largely put into an aspect that isapplied where necessary. This has two immediate effects. Code invoking cross-cutting concerns may be removed from objects, thus letting the objects focus ontheir application logic and thereby receive higher cohesion. The flip side of this isthat the implementation and triggering of the cross-cutting concerns are centralizedinto aspects, hence making changes now only requires modification in the aspectsinstead of (in worst case) all places in the application invoking the cross-cuttingconcern. A typical example of such cross-cutting concern is logging.

Identifying aspects

Aspect-oriented programming introduces a new dimension to design by allowinga code flow different compared to object-oriented programming. This requires asomewhat new way of thinking to take advantage of aspect-oriented programming.

Since aspect-oriented programming is a complement to object-oriented program-ming and not a replacement there is nothing that forces a design to use aspects.Hence the developer must identify what concerns are suitable to be implemented asaspects or not.

From designing the application in this Master’s project two approaches to identi-fying aspects emerged.

The first approach is to identify cross-cutting concerns during requirements ana-lysis and the initial stage of designing the architecture before starting implement-ation. This approach involves identifying business aspects that cross-cut severalmodules.

The second approach is to implement modules and objects in a conventionalway and then refactor concerns into aspects once it is obvious that they are cross-cutting. A typical example of this is when the same type of code is repeated inseveral places; the objects are refactored to use an aspect instead of repeating thesame type of code.

38


Aspects or not

What became apparent during the development of the application is that it is fairlyeasy to use aspects for the typical solutions used in many papers as examples;security, logging and transaction management.

However, looking beyond these typical applications of aspect-oriented program-ming the choice often becomes a question of solving something using aspect-orientedprogramming or the way it was done before. More often than not the latter waschosen.

There are several likely reasons for this. First of all it is always easier to dosomething "the usual way" compared to introducing something new that the de-veloper is likely less familiar with. Secondly most design problems are not new, andtherefore there already exist accepted proven solutions for many of these. This isespecially the case when using the Spring Framework. Although the Spring Frame-work has its own Spring AOP support, there are already provided many convenientways of solving problems that otherwise might have been good candidates to beimplemented using aspect-oriented programming.

In the same way using design patterns solves several common design problems.Where applicable it is often more convenient to use a proven design pattern insteadof introducing an aspect-oriented solution. Worth noting is a quantitative studywhere the 23 Gang-of-Four [6] patterns were implemented both using object-orientedsolutions and aspect-based and then compared. Although it was concluded thatmost aspect-oriented solutions improved the separation of pattern-related concerns,only four of the 23 patterns exhibited significant reuse in projects [7].

Another factor that must be taken into account is that although a better separ-ation of concerns may be achieved using an aspect-oriented solution it may, in somecases, also result in more lines of code and more complicated design. In such casea more conventional approach may be desirable.

Many of these issues are related to that aspect-oriented programming is a re-latively new way of designing applications compared to object-oriented program-ming. When a developer become more accustomed with aspect-oriented solutionsthe desire to instead use conventional solutions because they are more familiar willgradually be reduced.

6.2.2 Maintainability

Understanding aspects

With regard to maintaining an application using aspect-oriented programming thefundamental issue is whether or not the person changing the code (given it issomeone not familiar with the code) is used to aspect-oriented programming.

Since aspect-oriented programming is complementing object-oriented program-ming the code flow may not be as straight forward to understand. This is especiallytrue since simply looking at an object and dissecting the code in each method maynot reveal that the execution flow may be altered by aspects when methods are

39


invoked. Trying to understand or debug such as system without a firm grasp ofexactly what aspects are applied is troublesome.

This is where it is important that the IDE does support aspect-oriented pro-gramming and thus may provide hints or symbols to the reader that denotes thatan aspect is applied. Even for someone well-versed with aspect-oriented program-ming this may be of great help when interpreting the result of complex conditionalpointcuts.

Higher cohesion

Using an aspect-oriented approach code that performs the logic for cross-cuttingconcerns may be removed from each and every method and instead modularizedinto an aspect. This was discussed in the design section previously.

This naturally leads to higher cohesion of the objects and thus makes refactoringeasier. Both because there are less and more focused code, but also because theresponsibility of invoking the cross-cutting concern logic is moved from the objectmethods to the aspect.

Refactoring cross-cutting concerns

Making it easier to refactor cross-cutting concerns is one of the most importantadvantages of an aspect-oriented solution.

Use logging as an example. Calls to log state changes and actions are notuncommonly scattered across many methods and objects. If the logging module isto be refactored changes may in worst case be needed in the scattered invoking codeacross the whole application. This naturally makes refactoring more error prone andtroublesome.

With an aspect-oriented solution such changes are isolated to the logging aspectthat encapsulates both the logic as well as determine how and when it should beinvoked using pointcuts.

Object refactoring impact on aspects

There is a risk that the intent of an aspect may break when objects which the aspectis applied to are refactored.

Pointcuts may be defined using method names and thus the developer refactoringa target object must follow this naming convention if the aspect should be executedas expected.

This means that it is necessary for the developer doing the refactoring to knowabout the applied aspects even if the refactoring itself has nothing to do with thecross-cutting concerns of the aspect. Neglecting this may result in hard to find bugssince the developer changing or adding a method may not know about the relevantaspects that may or may not be triggered.

40


6.2.3 Testing

In a conventional design cross cutting concerns cannot be unit tested, since they arescattered and therefore not in a unit. In an aspect-oriented design the cross cuttingconcern is modularized into an aspect, so now there is a unit.

However, unit testing aspects is not as straight forward as testing plain objectssince the logic an aspect performs is always applied to a target object. Duringdevelopment of the application three different testing approaches were identified.

Integration test

Probably the simplest way is to perform unit testing on objects where aspects areapplied. This becomes a sort of integration test since both the non-aspect-orientedobjects are tested together with the aspect itself that is applied to the object.

This is easy to setup since the unit test is not any different from any other unittests. However, extra care should be taken so that the test will also fail if not onlythe object logic itself fails but also if the aspect behaves in an unexpected way.

Mockup target object

The downside with the previous approach of integration test is that the testing ofthe aspect is not isolated. So if the target object fails then the aspect test will alsofail even if it is correct.

A possible solution to this is to create a mockup target object that the aspectis applied to. From the perspective of the aspect the object is no different than anyother target object.

The purpose of the mockup target object is that it should only include code thathelp verifying the code flow and that the advice are correctly triggered at the rightjoin points. It should not include any other logic from the typical target objects(since they are separately unit tested).

The benefit of using a mockup target object is that the aspect logic may betested in isolation. The downside is that potentially many mockup target objectsmust be created if the pointcut definitions span many different kind of join points.

Delegation to objects

The third approach is to delegate all aspect logic into separate objects and then dounit testing on those objects.

This approach verifies the actual logic performed within an aspect but it failsto verify when the advises are triggered by the pointcut definition. Because of thatthis approach may very well be combined with using mockup target objects.

Another disadvantage is that in some cases it is hard or inconvenient to extractthe logic into separate objects.

41

Chapter 7

Conclusion

This chapter concludes the evaluation in two sections; discussing dependency in-jection and aspect-oriented programming. Then a possible continuation of thisMaster’s thesis is briefly covered in the section about future work.


Dependency injection is easy to understand and does not require substantial changesof an application class architecture, still it promotes a design pattern which resultsis less coupled modules and less boilerplate code.

The use of dependency injection is especially beneficial when it comes to testingand unit-testing in particular. When an object is no longer responsible itself forlooking up or creating its dependent objects and resources it becomes much easierto unit test objects. Partly because they are less coupled but most importantlybecause dependencies are so easily replaced with mockup objects.

Many of the particular frameworks, like the Spring Framework as used in theproject of this Master’s thesis, include support for dependency injection. Then theuse of dependency injection is easy and straightforward. If the use of a dependencyinjection framework is not possible by any reason some of the benefits may still beleveraged by following the inversion of control principle.


The main purpose of aspect-oriented programming is to develop and manage cross-cutting concerns in a more modularized way than what is the result of conventionalobject-oriented programming.

This is done by introducing the concept of aspects that are applied to targetobjects. A pointcut language is used to determine where, when and how changes invariables or invocations of methods of the target object are intercepted with codefrom the aspect. This is realized through weaving. In case of AspectJ weaving ismost commonly done using the AspectJ compiler. In the case of Spring AOP (the

43

CHAPTER 7. CONCLUSION

aspect-oriented programming support of the Spring Framework) the weaving is doneat runtime and therefore does not require a special compiler, making it potentiallyeasier to adopt aspect-oriented programming.

To benefit from aspect-oriented programming a more or less new way of thinkingis required in order to identify concerns as candidates to be implemented as aspects,in contrast to using a conventional object-oriented approach.

Although there are many situations where the benefit of aspect-oriented pro-gramming is clear, it introduce a complexity because the code flow of the targetobjects may be changed without it being visible in the code.

The introduction of aspects does also require changes to how testing, and espe-cially unit-testing, is conducted. Three different testing approaches were identified;integration testing where unit-testing is performed on the target objects, the useof mockup-target objects to more easily isolate and verify the functionality of theaspect and delegation to objects where the logic of an aspect is split into one ormore objects that may be unit-tested separately as any other object.

7.3 Future Work

The most immediate continuation of the work presented in this Master’s thesis is tolook more closely into maintainability of the code in a more quantitative approach.Having the two systems developed after the same requirements, one in a pure object-oriented way and the other using aspect-oriented programming.

Then task equally experienced programmers where half performs changes on theobject-oriented developed system and the other half on the on the aspect-orientedsystem. The result may be evaluated based the quality of the changes (accordingto a predefined, but unknown to the developers, set of unit tests), the time ittook and the complexity of the solution. Possibly more in-depth interviews withthe programmers may be conducted afterwards to get an understanding of theirapproach.

44

Bibliography

[1] The Aspectj Project at the Eclipse Foundation.http://www.eclipse.org/aspectj/.

[2] Christian Bauer and Gavin King. Java Persistence with Hibernate. ManningPublications Co., Greenwich, CT, USA, 2006.

[3] Jonas Boner. Aspectwerkz - dynamic AOP for Java. In Proceeding of the 3rdInternational Conference on Aspect-oriented software development, New York,NY, USA, 2004. ACM.

[4] M. Ceccato and P. Tonella. Measuring the effects of software aspectization. In1st Workshop on Aspect Reverse Engineering, 2004.

[5] Martin Fowler. Inversion of Control Containers and the Dependency Injectionpattern. http://martinfowler.com/articles/injection.html, 2004.

[6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. DesignPatterns. Addison-Wesley Professional, January 1995.

[7] Alessandro Garcia, Cláudio Sant’Anna, Eduardo Figueiredo, Uirá Kulesza,Carlos Lucena, and Arndt von Staa. Modularizing design patterns with as-pects: a quantitative study. In AOSD ’05: Proceedings of the 4th internationalconference on Aspect-oriented software development, pages 3–14, New York,NY, USA, 2005. ACM.

[8] Timothy Highley, Michael Lack, and Perry Myers. Aspect oriented program-ming: A critical analysis of a new programming paradigm. Technical report,Charlottesville, VA, USA, 1999.

[9] Ralph E. Johnson and Brian Foote. Designing reusable classes. Journal ofObject-Oriented Programming, 1(2):22–35, 1988.

[10] Rod Johnson. Expert One-on-One J2EE Design and Development. Wrox PressLtd., Birmingham, UK, UK, 2002.

[11] Rod Johnson et al. The Spring Framework - Reference Documentation.http://static.springframework.org/spring/docs/2.5.x/reference/.

45

BIBLIOGRAPHY

[12] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, andWilliam G. Griswold. An overview of aspectj. In ECOOP, volume 2072, pages327–353. Springer, 2001.

[13] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, CristinaLopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming.In Proceedings European Conference on Object-Oriented Programming, volume1241, pages 220–242. Springer-Verlag, Berlin, Heidelberg, and New York, 1997.

[14] Henrik Kniberg. Scrum and XP from the Trenches. InfoQ, 2007.

[15] Ramnivas Laddad. AspectJ in Action: Practical Aspect-Oriented Programming.Manning Publications Co., Greenwich, CT, USA, 2003.

[16] Steve McConnell. Rapid Development: Taming Wild Software Schedules. Mi-crosoft Press, Redmond, WA, USA, 1996.

[17] Debu Panda, Reza Rahman, and Derek Lane. Ejb 3 in Action. ManningPublications Co., Greenwich, CT, USA, 2007.

[18] D. L. Parnas. On the criteria to be used in decomposing systems into modules.pages 139–150. Yourdon Press, Upper Saddle River, NJ, USA, 1979.

[19] Dhanji R. Prasanna. Dependency Injection. Manning Publications Co., Green-wich, CT, USA, 2008.

[20] Ken Schwaber. Agile Project Management With Scrum. Microsoft Press, Red-mond, WA, USA, 2004.

[21] Robb Shecter. Design by interface. Dr. Dobb’s Journal, pages 96–101, february1999.

[22] Maximilian Storzer and Stefan Hanenberg. A classification of pointcut lan-guage constructs. In Software-engineering Properties of Languages and AspectTechnologies, March 2005.

[23] Craig Walls. Spring in Action. Manning Publications Co., Greenwich, CT,USA, 2007.

[24] Jeremy Weiskotten. Dependency injection: Designing loosely coupled and test-able objects. Dr. Dobb’s Journal, pages 10, 12, 14–15, may 2006.

46

Appendix A

References

This appendix contains references to tools, components, libraries and other techno-logies used in the development of the application.

A.1 Tools

• Canoo WebTest - automated web testinghttp://webtest.canoo.com/

• DbUnit - a JUnit extension used for database population when testinghttp://www.dbunit.org/

• GlassFish - Java application serverhttp://glassfish.dev.java.net/

• Hudson - continuous integration serverhttps://hudson.dev.java.net/

• Jetty - lightweight servlet container for testinghttp://jetty.mortbay.com/

• JUnit - Unit testinghttp://junit.org/

• Maven 2 - build managementhttp://maven.apache.org/

• NetBeans - Integrated Development Environment (IDE)http://www.netbeans.org/

• Subversion - version control systemhttp://subversion.tigris.org/

47

APPENDIX A. REFERENCES

A.2 Components

• Apache Commons - library of many useful and reusable componentshttp://commons.apache.org/

• Display Tag - Java tag library with support functionality for displaying tableshttp://displaytag.sourceforge.net/

• Hibernate - Java object-relational mapping (ORM) libraryhttp://www.hibernate.org/

• Log4j - used for logginghttp://logging.apache.org/log4j/

• Spring Framework - open source Java application framework developed bySpringSource, led by Rod Johnsonhttp://www.springframework.org/

48

TRITA-CSC-E 2009:077 ISRN-KTH/CSC/E--09/077--SE

ISSN-1653-5715

www.kth.se

Documents

Enterprise Application Development using Dependency ... · Enterprise Application Development using Dependency Injection and Aspect-Oriented Programming STEFAN PETTERSSON Master’s