IMPLEMENTING THE DATA ACCESS OBJECT PATTERN

USING ASPECTJ

André Luiz de Oliveira, André Luis Andrade Menolli and Ricardo Gonçalves Coelho

Informatics Department, State University of the North of Paraná, Br 369 highway Km 54, Bandeirantes, Brazil

Keywords: Data Access Object pattern, aspect oriented implementation, metrics.

Abstract: Due to the constant need of access and information storage, there is a constant concern for implementing

those functionalities in large part of the currently developed applications. The most of those applications use

the Data Access Object pattern to implement those functionalities, once that this pattern makes possible the

separation of the data access code of the application code. However your implementation exposes the data

access object to others application objects, causing situations in that a business object access the data access

object. With the objective of solving this problem, this paper proposes an aspect oriented implementation of

this pattern, followed by a quantitative evaluation of both, object oriented (OO) and aspect oriented (AO),

implementations of this pattern. This study used strong software engineering attributes such as, separation

of interests, coupling and cohesion, as evaluation criteria.

1 INTRODUCTION

A lot of applications frequently need implementing

some access mechanism and data persistence, once

that the organizations often need access and storage

its information in some kind of database. To access

this information surely and efficiently some patterns

were introduced by several authors, not only in the

object-oriented software development (OOSD) but

also in the aspect-oriented software development

(AOSD).

In literature we can find several patterns that

implement the data persistence, such as Persistence

Data Collections (Massoni et. al. 2001), that

provides a set of class and interfaces to separate data

access code and business rules from user interface,

promoting the modularity. Among others patterns

with the same purpose is the Decoupling Patterns,

that is a set of data access patterns proposed by

Nock (2003), that describes strategies to uncouple

data access components from others parts of the

application, and the Data Access Object (Sun

Microsystems 2002), that is one of the data access

patterns more often used, due to fact of this pattern

isolates the whole data access code of the

application code facilitating migration processes for

other storage systems.

There are several forms of implementing the data

access functionalities of the application. As seen in

Sun Microsystems (2002), it can be adopted a data

access objects factory strategy, in situations in which

the applications access more than one storage

mechanism, or create a generic data access object, in

order to determine a common access point to the

data access functions of the application.

Both implementations previously mentioned are

good solutions that isolate the data access code from

others application functions, optimizing the

legibility and the modularity of the developed

application, facilitating future maintenance and

extension processes of the application, providing the

reuse of several components of the system.

It was verified in Sun Microsystems (2002), that

Data Access Object pattern allows the business

object to using the data source without having the

knowledge of the specific details of its

implementation, providing a transparent access to its

functionalities, once that those details of the data

source implementation are encapsulated within the

data access object. That whole transparency causes

the exposition of the data access object to others

application objects, causing situations in which a

business object access the data access object,

harming the modularity, the legibility and the

encapsulation of the application code, besides the

need of adding an extra object layer between the

data client and the data source so that its

implementation benefits this pattern.

With the objective of solving this problem, this

study proposes an alternative implementation of the

523

Luiz de Oliveira A., Luis Andrade Menolli A. and Gonçalves Coelho R. (2008).

IMPLEMENTING THE DATA ACCESS OBJECT PATTERN USING ASPECTJ.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - DISI, pages 523-530

DOI: 10.5220/0001714805230530

 SciTePress

Data Access Object pattern using the aspect oriented

programming with AspectJ language. This solution

provides the encapsulation of the data access

functions of the application developed, once that the

business object and others application components

not more need access the data access functions of the

application, all the control of the calls to the data

access and persistence operations is made by

aspects. This way, the others application objects do

not need anymore know the implementation details

of the classes and methods responsible by the data

access functions of the application, optimizing the

application modularity and legibility.

In this study, we identified some situations where

it is profitable to change the Data Access Object

pattern implementation to an aspect oriented

implementation of this pattern. Those situations

occur when there is a constant need of isolating all

the data access functions implementation of the

application, in order to avoid the exposition of the

data access object to others application objects. Your

application provides a better separation of concerns

of data access which is verified by the outcomes

presented in the section 4.

The results of this study were obtained through a

comparative study between object oriented (OO) and

aspect oriented (AO) implementations of the Data

Access Object pattern. The comparison between OO

and AO implementations of traditional patterns is

not so new. Some papers have already made this

kind of comparison, like Hannamann and Kiczales

(2002) and Garcia et. al. (2005). This paper presents

an alternative implementation of the Data Access

Object pattern, followed by a quantitative evaluation

of both OO and AO implementations of this pattern.

It is important to point out that this work does not

propose an approach that substitutes the Data Access

Object pattern, but certainly is an alternative

approach for the implementation of this pattern,

which can be applied to the applications

environment previously mentioned, providing a

better separation of concerns of this pattern.

In order to explicit the foundation of the

proposed solution, the present work is organized in

eight sections. The section 2 presents the

organization of the developed study that includes the

illustration of the OO and AO implementations of

the Data Access Object pattern, the metrics used in

the validation of this study and the evaluation

procedures adopted. The section 3 exposes the

outcomes obtained in the comparison of the OO and

AO implementations of the Data Access Object

pattern. The section 4 illustrates the constraints of

this study. The section 5 approaches some related

works to this study. And finally, the section 6

exposes the conclusions and the future research

proposes.

2 ORGANIZATION OF THE

STUDY

This section describes the configuration of that

empirical study. This study approaches an

alternative implementation of the Data Access

Object pattern, using the aspect oriented

programming, with the AspectJ language. In order to

explicit the foundations of proposed solution, the

section 2.1 presents the object oriented

implementation of the Data Access Object pattern

and later the aspect oriented implementation of this

pattern. Already the section 2.2 introduces the

metrics used in the evaluation process of the

proposed solution. And finally, the section 2.3

describes the evaluation procedures applied in this

study.

2.1 Data Access Object Pattern

Implementation

As seen previously, the Data Access Object aims at

avoiding direct dependence situations between the

application code and the data access code (Sun

Microsystems 2002). When analyzing this pattern, it

was verified that it defines two roles for its

participant classes that corresponds to the Business

Logic and the Data Access. The Business Logic role

is responsible by the whole control of the business

logic of the application, that means, it treats the

input data before of those data have been passed into

the call of one data access function, besides

manipulating the obtained data of a data access

function, to summarize that role is a data client (Sun

Microsystems 2002). The Data Access role

represents the object that abstracted the underlying

data access implementation (Sun Microsystems

2002) to the Business Logic role, enabling

transparent access to the data source, which means,

it provides all the access and storage data

functionalities to the Business Logic role. The

Figure 1 illustrates the oriented object

implementation of this pattern applied in the present

work. When analyzing this figure it is assumed that

the Data Access role implementation is dispersed by

all classes of the pattern. Since the Business Logic

role is implemented by the BusinessObject and

TransferObject classes.

ICEIS 2008 - International Conference on Enterprise Information Systems

524

Figure 1: Object oriented model of the Data Access Object

pattern.

The Figure 2 presents the source code of the

BusinessObject class. The code spaces that do not

implement the Business Logic role are shaded. This

class possesses a reference to DataAccessObject and

TransferObject classes (line 09-10), that are

instantiated in the constructor method of the class

(line 14- 15). This class contains the insert method

(line 17-26), that modifies the attribute values of the

LaboratoryReservation object (line 19-23), and

passes this object as argument to the insert method,

which is present in the LabReservationDAO (line

24) class, to register a new reservation.

Figure 2: Business Object class in the OO implementation.

As it is observed in Figure 2, the shadowed code

implements the Data Access role within the Business

Logic role implementation. Those shadowed points

are places where there is a concern switch in the

pattern implementation, once that the data access

concern is interlaced with the business logic

manipulation concern.

In order to solve this problem, the aspect

oriented implementation of this pattern avoids that

the business components, in this case the

BusinessObject class, have the knowledge of the

data access objects of the application, totally

isolating those objects of the application code,

providing a better separation of the Business Logic

and Data Access roles, as illustrates the Figure 3.

Figure 3: Aspect oriented model of the Data Access

Object pattern.

In the diagram previously shown, the business object

acts as a Facade (Gamma et. al. 1995) object that

works as an access interface to functionalities

present in the subsystem, in your conventional

implementation. But in the AspectJ implementation,

this object acts as one interface that contains only

the method body (assign, parameters list and the

return value) needed for the execution of the data

access functionalities of the application.

The DAOAspect object, showed in the Figure 3,

is the key point of the AO implementation of the

Data Access Object pattern proposed in this work,

due to fact this object makes the whole control of the

data access logic of the application, through the

pointcuts definition, that contains the join points that

will be captured her for the execution of the data

access functions of the application, implemented in

the advices, as displayed in full detail the class

diagram of Figure 4. This diagram is based on an

aspect oriented modelling notation proposed by

Jacobson and Ng (2003).

Figure 4: Class diagram of the aspect oriented

implementation of the Data Access Object pattern.

Due to that solution, it can be observed that the

aspect makes the whole control of the data access

logic of the application, capturing a join point,

executing a data access operation and returning the

operation value to this join point.

The AO implementation of the Data Access

Object pattern approached in this work avoids that

the business object instantiating a data access object,

in order to have access to its functionalities, once

that the aspect captures the join points present in the

business object, executes the required operation and

returns the resultant value of its execution to this

join point.

IMPLEMENTING THE DATA ACCESS OBJECT PATTERN USING ASPECTJ

525

The presented solution provides the

encapsulation of all data access functionality of the

application, contributing to the modularity and

legibility of the development application, once that

in this solution the business object does not need to

interact with the data access object that is

implemented as one aspect that controls all the data

access functions defined in the business object. The

optimization of those software engineering attributes

was verified through the application of a

measurement process of this solution which is

described in the next sections of this work.

In the AO solution of the Data Access Object

pattern, the code that implement the Data Access

role is textually localized in the aspect DAOAspect,

that encapsulates all the data access functions of the

application, isolating I from the remaining the

application code, as illustrates Figure 5.

Figure 5: DaoAspect implementation.

The related code to the Data Access role

implementation is shaded and contains a reference to

the GenericDAO object (lines 12 and 16), that

corresponds to the data source implementation and a

reference to the LaboratoryReservation object (line

13), which is the object that implements part of the

business rules of the application.

The whole implementation process of the data

access concern ponders in the insert pointcut (line

19-23), that captures the insert join point, defined in

the BusinessObject class, and in the around advice

(line 25-40), that executes a database manipulation

operation around the call of a join point, returning

the resultant value of that operation to the same joint

point. That implementation removes the whole data

access concern from the class that implements the

business rules of the application due to the fact those

classes do not depend on the data access classes of

the application anymore. This independence can be

better visualized in Figure 6 that illustrates the

BusinessObject class implementation after the

insertion of the data access aspect DAOAspect.

Figure 6: BusinessObject class after of the DaoAspect

implementation.

As displays Figure 6, in the AO implementation of

the Data Access Object pattern, the whole data

access concern code was removed from the classes

that carry out the Business Logic role, making them

more modulated and maintained, once that in those

classes it is pondered only the Business Logic

concern, that corresponds to shaded code of the

Figure 6 and there is not dependence on calls in

relation to the data access functions of the

application, as illustrated in the conventional object

oriented implementation in the Figure 2. This is

possible due to the whole call control and execution

of the data access functions of the application is

pondered in a data access aspect.

2.2 Metrics Used

This study selected a group of metrics of separation

concerns, coupling, cohesion and size (Sant’Anna et.

al. 2003) to evaluate the foundations of the aspect

oriented implementation of the Data Access Object

pattern approached in this work. Those metrics have

already been used in four different studies (Garcia

2004; Garcia et al. 2005; Garcia et. al. 2004; Soares

2004). Some of them have been automated in the

context of a query based tool for the measurement

and analysis of aspect oriented programs (Alencar

et. al. 2004). Those metrics were defined based on

the reuse and refinement of some classical and

object oriented metrics (Chidamber and Kemerer

1994). The original definitions of object oriented

metrics (Chidamber and Kemerer 1994) were

extended to be applied in a paradigm independent

way, supporting the generation of comparable

results.

The separation of concern metrics measures the

degree to which a single concern in the system is

mapped for the design components (classes and

aspects), operations (methods and advices), and lines

of code (Sant’Anna et. al. 2003). The Table 1

presents a brief definition of each metric applied in

this study, and associates them with the attributes

measured by each one. More detailed information

about those metrics can be found in Garcia (2004)

and Sant’Anna et. (2003).

ICEIS 2008 - International Conference on Enterprise Information Systems

526

Table 1: Metrics.

2.3 Assessment Procedures

With the purpose of comparing the OO and AO

implementations of the Data Access Object pattern,

both versions of the pattern implement the same

functionalities, with the same style of codification.

This pattern has several implementation forms, in

which this study chose the one that seemed to be the

most suitable. A few modifications happened in the

aspect oriented solution in relation to the object

oriented solution, in which some methods were

modified or excluded, some attributes and a class

were excluded and an aspect was added. Likewise to

the HK study, this work treats each role as a

crosscutting concern, because the roles are primary

sources of crosscutting structures (Garcia et. al.

2005).

In this measurement process, the data were

gathered with base on the code analysis, using the

Eclipse 3.3 tool (Eclipse Project). The measures of

separation of concerns (CDC, CDO and CDLOC)

were preceded by the shade of all classes and aspects

in both pattern implementations. This shade was

accomplished with the roles found in the Data

Access Object pattern implementation. Likewise to

the Hannemann and Kiczales (2002) study, in this

study each pattern role was treated as a concern,

once roles are primary source of crosscutting

structures [8]. The Figures 2, 5 and 6 exemplify the

shade of some classes and aspects in both the Java

and AspectJ implementations of this pattern,

considering the Business Logic and Data Access

roles. After the shade, the separation of concerns

data metrics was manually collected.

3 RESULTS

This section presents the measurement process

results. The data have been collected with base on

the metrics defined in section 2.3. The objective of

that measurement process is to describe the results

of the metrics application in the OO and AO

implementations of the Data Access Object pattern,

in order to compare and prove the foundations of the

aspect oriented implantation of this pattern,

proposed in this work. This analysis is divided in

two parts. The section 3.1 focus on the analysis of

what extent aspect oriented and object oriented

solutions provide support to the separation of the

pattern-related concerns. The section 3.2 presents

the results toward the coupling, cohesion and size

metrics.

In the exhibition of the results of this study

graphics are used to represent the data gathered in

the measurement process. The results of the graphs

present the data obtained from the OO and AO

implementations of the Data Access Object pattern.

The Y-axis of the graphic presents the absolute

values gathered by the metrics. Each bar pair, that

corresponds to the metric values gathered from the

OO and AO implementations of the pattern, is

attached to a percentage value, which represents the

difference between the OO and AO results. A

positive percentage means that the AO

implementation was superior, while the negative

percentage means that the AO implementation was

inferior. Th0se graphics support the analysis toward

how the introduction of new classes and aspects

affect both solutions in relation to the selected

metrics. The results presented in the graphics were

IMPLEMENTING THE DATA ACCESS OBJECT PATTERN USING ASPECTJ

527

gathered based on the pattern point view that means

that they represent the metric values associated with

all classes and aspects for each pattern

implementation.

In order to obtain the separation concerns metric

values of both OO and AO implementations of the

Data Access Object pattern, firstly it was verified the

presence of two roles in this pattern implementation.

This was made because the roles are primary sources

of crosscutting structures (Garcia et. al, 2005).

3.1 Separation of Concerns

The Figure 7 presents the separation of concerns

metrics results for the OO and AO implementations

of the Data Access Object pattern. As it is observed

in Figure 8, most of the measurements favoured

significantly the AO implementation of this pattern.

This solution reduced the coupling between the

classes that play the Business Logic role, and

consequently the number of operations for

implementing this role, besides demanding few

concerns switches between the components that play

the Business Logic and Data Access roles.

Figure 7: Results of separation of concerns metrics.

An analysis of the Figure 7 shows that those

improvements were reached through separating the

pattern roles in aspects. The definition of the

Business Logic role demanded 3 classes in the OO

solution, while the aspects application reduced that

number to 2, providing a better separation of that

role in relation to the OO solution. That

improvement is equal to the 33% of AO solution

superiority with relation to the OO implementation.

The results were even better for the concern

diffusion over components (CDC) and diffusion of

concerns over lines of code (CDLOC) metrics in the

implementation of the Business Logic role, which

reached optimizations of 87,5% in relation to OO

implementation.

In addition, it can be observed that good results

were reached in the modularization of the defining

role, which is the case of the Business Logic. After

this analysis, is ended that the AO implementation of

the Data Access Object pattern optimized about 69%

the isolation of the implemented concerns by the

Business Logic role in comparison with the OO

solution.

One of the reasons for the superiority of the AO

implementation over the OO implementation is that

in the OO solutions there are several operations

implementations mixed with the specific code of the

role.

3.2 Coupling, Cohesion and Size

In this section are presented the results of coupling,

cohesion and size metrics. It was used graphs for the

representation of the gathered results, which

represents the metric values associates with all

classes and aspects for each pattern implementation,

with the exception of the DIT metric. The results of

DIT represent the maximum value of this metric for

all the implementation.

In the OO implementation of the Data Access

Object pattern the improvements were reached only

in the NOA metric, as illustrates the Figure 8. The

use of aspects led the reduction of only 0,5% of the

LOC metric in relation to the object oriented project,

therefore is assumed that this difference is

insignificant. In spite of the data access code retreat

of the classes that carry out the Business Logic role,

the aspect that carry out the Data Access role has

more code lines than the OO implementation of that

role.

Figure 8: Coupling, cohesion and size metrics results.

In relation to the NOA metric results, the AO

implementation obtained 7,1% of superiority in

relation to the OO solution. This occurs in virtue of

in the OO solution, the classes that carry out the

Business Logic role possesses a reference to the data

access object that in the AO project was retired.

In relation to the CBC and LCOO metrics, the

results were same to both OO and AO

implementations. This similarity happens due to the

ICEIS 2008 - International Conference on Enterprise Information Systems

528

occurrence of just one a coupling inversion between

the business object and data access object

components in both implementations of the pattern.

In the OO implementation, the business object

component has a dependence relationship with the

data access object. On the other hand in the AO

implementation, the data access object component

possesses a dependence relationship with the

business object component, as shown in the Figure

3. In relation to the cohesion metrics, its values

continued constant in both solutions, once that they

use the same operations and references to the

attributes.

The value of the WOC metric was the only in

which the AO implementation obtained result

inferior to the solution OO. This inferiority

corresponds to 32,5%. The reason of this is based on

the fact that the AO implementation has declarations

of advices with many parameters, and this does not

happen in the OO solution.

4 STUDY CONSTRAINTS

In relation to the metrics used in this study, it was

verified in Garcia et. al. (2005) that there are some

criticisms about its application. Those critics refer to

the theoretical arguments related to the use of

conventional size metrics that are commonly applied

to the traditional software development. In spite of

the simplicity of those metrics, they have been the

target of several criticisms (Zuze 1995). The reason

of those criticisms is the difficulty of evaluating

software quality attributes, for instance, the LOC

measures are difficult to interpret, since in certain

situations a high value of LOC can mean a better

modularization, or mean code replication by the

project components.

It was verified in Garcia et. al. (2005) that due to

the limitations of those metrics, they not can be

analyzed in an isolated way. However they are

extremely useful when analyzed together with others

metrics. In addition, it was verified in Garcia et. al.

(2005) that some researchers, as Henderson-Sellers

(1997), have criticized the lack of a solid theoretical

base and empirical validation of the cohesion

metrics.

The AO implementation of the Data Access

Object pattern presented in this study can restrict the

extrapolation of the results obtained in this work.

The evaluation process of the presented

implementation is restricted to one specific instance

of the Data Access Object pattern in this case the

most used was selected.

5 RELATED WORKS

There are a few related works focusing on the

quantitative evaluation of aspects oriented solutions

to modularize crosscutting concerns of the classic

design patterns. It was verified in Garcia et al (2005)

that early experiments (Hannamann and Kiczales

2002) were based on qualitative measures. On the

other hand the study undertaken by Garcia et al.

(2005) presented a quantitative evaluation of the OO

and AO implementations of the 23 design patterns of

the GoF (Gamma et. al. 1995).

The section 4 exposed some criticism about the

cohesion metrics. Seeking to optimize those metrics,

the studies of Zao (2002) and Xu (2004) have

proposed new cohesion measures that considerer the

peculiarities of the AO abstractions and

mechanisms. Those metrics are based on a

dependence model for AO software that consists in a

group of dependence graphs. In that study the

authors have show that their measures have satisfied

some properties good measures should have.

However, as seen in Garcia et. al. (2005), those

metrics have not been validated or applied to the

assessment of realistic AO systems yet.

6 CONCLUSIONS

This study presents an alternative aspect oriented

implementation of the Data Access Object pattern,

and makes a comparative evaluation between the

OO and AO of this pattern. The results of this study

have been showing that the AO implementation

improves the separation of concerns, reduces the

amount of the lines of code (LOC) and optimizes the

number of attributes (NOA) of the pattern. In

relation to the coupling and cohesion metrics, there

not was difference between the results in both

implementations, due to the occurrence of

dependence inversion between the BusinessObject

and DAO components and due to the use of the

same attributes and methods in both

implementations. This occurs because the use of

aspects increases the cohesion and reduces the

coupling only in patterns that posses roles that are

highly interactive. Meanwhile the WOC metric was

the only metric that obtained inferior result in

relation to the OO implementation. This result is a

reflex of the advices declarations with many

parameters in the AO solution.

With the obtained results, it can be conclude that

the alternative implementation of the Data Access

Object, approached in this work, provides a larger

IMPLEMENTING THE DATA ACCESS OBJECT PATTERN USING ASPECTJ

529

modularity and legibility in the development

application code, facilitating maintenance and

extension processes of the application, once that this

solution provides the encapsulation of all data access

functionalities of the application, due to fact that the

business objects not more need to interact with the

data access object, that is implemented with an

aspect, which controls all the data access functions

defined in the business object.

The approach presented in this work allows that all

the data access layer of the application be

implemented through aspects, providing a total

isolation of the data access functions of the

application. The positive results obtained by the

application of this solution confirmed the

optimization of legibility and modularity aspects in

the development application, could be implemented

in any application that needs access and persistence

of data functionalities.

As a proposal for future researches it can be set a

quantitative study about the OO and AO

implementations of the Core J2EE patterns, aiming

at verifying in which patterns the aspect oriented

programming provides a better modularization in

relation to the object oriented implementations.

Other proposal for future researches is the

project of one aspect oriented software architecture,

based on the discussed approach in this writing. This

proposal has the purpose of reducing the increase in

the complexity and dimension of the software

systems projects currently caused by the increase in

the complexity of the user’s requirements and by the

constant need of the integration of applications

through several platforms, with the purpose of

making possible the global access to the

information.

REFERENCES

Alencar, P. et al. A Query-Based Approach for Aspect

Measurement and Analysis. TR CS-2004-13, School

of Computer Science, Univ. of Waterloo, Canada, Feb

2004.

Chidamber, S. & Kemerer, C., 1994, ‘A Metrics Suite for

OO Design’. IEEE Trans. on Soft. Eng., 20-6, 476-

493.

Eclipse Project. http://www.eclipse.org.

Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1995.

Design patterns: elements of reusable object-oriented

software, Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA.

Garcia, A., Sant'Anna, C., Figueiredo, E., Kulesza, U.,

2005, ‘Modularizing Design Patterns with Aspects: A

Quantitative Study’, International Conference on

Aspect-Oriented Software Development (AOSD'05),

Chicago, USA. ACM Press. Pages 3-14.

Garcia, A. et al., 2004, ‘Separation of Concerns in Multi-

Agent Systems: An Empirical Study. In Software

Engineering for Multi-Agent Systems’, II, Springer,

LNCS 2940.

Garcia, A., Silva, V., Chavez, and C., Lucena, C., 2002,

’Engineering Multi-Agent Systems with Aspects and

Patterns’, J. of the Brazilian Computer Society, 1, 8

(July), 57-72.

Hannemann, J. & Kiczales, G., 2002, ‘Design Pattern

Implementation in Java and AspectJ’, Proc.

OOPSLA’02, 161-173.

Henderson-Sellers, B., 1996. Object-Oriented Metrics:

Measures of Complexity, Prentice Hall.

Jacabson, Ivar and Ng, Pan-Wei, 2004. Aspect Oriented

Software Development with Use Cases. Addison-

Wesley.

Java Reference Documentation. http://java.sun.com/refer

ence/docs/index.html.

Massoni, T.; Alves, V. and Soares, S., 2001, ‘PDC:

Persistent Data Collections pattern’, First Latin

American Conference on Pattern Languages of

Programming, Rio de Janeiro, Brazil.

Nock, Clifton, 2003, ‘Data Access Patterns: Database

Interactions in Object-Oriented Applications’,

Addison-Wesley.

Sant’Anna, C. et al. On the Reuse and Maintenance of

Aspect-Oriented Software: An Assessment

Framework. Proc. of Brazilian Symposium on

Software Engineering (SBES’03), Manaus, Brazil, 19-

34.

Soares, S., 2004, ‘An Aspect-Oriented Implementation

Method’, Doctoral Thesis, Federal Univ. of

Pernambuco.

Soares, S. et. al., 2002, ’Implementing distribution and

persistence aspects with AspectJ’, ACM. In

Proceedings of the OOPSLA' 2002, pp. 174-190,

Seattle, USA.

Sun Microsystems 2002, ‘Core J2EE Patterns: Data

Access Object’, viewed 01 November 2007,

http://java.sun.com/blueprints/corej2eepatterns/Pattern

s/DataAccessObject.html.

Zuse, H., 1995, ‘History of Software Measurement.

viewed 27 October 2007, http://irb.cs.tu-berlin.de/~

ICEIS 2008 - International Conference on Enterprise Information Systems

530