TOWARDS AN APPROACH FOR ASPECT-ORIENTED SOFTWARE

REENGINEERING

Vinicius Cardoso Garcia, Daniel Lucr

edio, Antonio Francisco do Prado

Federal University of S

ao Carlos, Department of Computer Science

P.O. Box 676 – S

ao Carlos, Brazil

Eduardo Santana de Almeida, Alexandre Alvaro, Silvio Romero de Lemos Meira

C.E.S.A.R. – Recife Center for Advanced Studies and Systems

P.O. Box 7851 – Recife, Brazil

Keywords:

Software Reengineering, Aspect Mining, Refactoring, AOP, MVCASE, Software Transformation.

Abstract:

This paper presents a reengineering approach to help in migrating pure object-oriented codes to a mixture of

objects and aspects. The approach focuses on aspect-mining to identify potential crosscutting concerns to be

modeled and implemented as aspects, and on refactoring techniques to reorganize thecode according to aspect-

oriented paradigm by using code transformations it is possible to recover the aspect-oriented design using a

transformational system. With the recovered design it is possible to add or modify the system requirements in

a CASE tool, and to generate the codes in an executable language, in this case AspectJ.

1 INTRODUCTION

Software reengineering is being used to recover

legacy systems and allow their evolution. Several en-

terprises are being forced to move their legacy sys-

tems to newer languages or are looking for new ways

to improve their existing software systems. This is

done mainly to reduce maintenance costs, improve

development speed and improve systems readability.

Current uses of reengineering include existing soft-

ware development techniques, such as component-

based development and object-orientation, rebuilding

legacy systems into more reusable and maintainable

systems. However, some limitations that are inher-

ent to object-oriented paradigm could lead to systems

that are hard to maintain and reuse. Design patterns

(Gamma et al., 1995) could be used to partially over-

come these limitations, but this may not be enough.

In this way, even that the system design is recov-

ered in a high abstraction level, giving the Software

Engineer a readable vision of the system functional-

ity, its maintenance, in many cases, is still an ardu-

ous and difﬁcult task. This could interfere with the

evolution of the system in order to keep up with new

hardware and software technologies.

Aspect-Oriented Software Development (AOSD)

(Kiczales et al., 1997) may help to reduce this depen-

dency, by offering a new modular unit (aspect). Func-

tionalities that are necessarily dispersed in object-

oriented systems, such as exception handling and log-

ging, for example, can be grouped into a single as-

pect, increasing the modularity and the reuse level of

the retrieved assets.

This paper presents a approach to help in migrating

from pure object-oriented codes to a mixture of ob-

jects and aspects using reengineering and AOSD tech-

niques, such as aspect mining, refactoring and soft-

ware transformation. The reengineering product has

great reuse potential, due to the beneﬁts of AOSD.

The paper is organized as follows: Section 2

presents the Phoenix Reengineering Approach. Sec-

tion 3 presents the preliminary evaluation based on

the Phoenix approach and revises it based on the iden-

tiﬁed requirements. Related works are presented in

Section 4. Section 5 presents some conclusion and

future works.

2 PHOENIX APPROACH

2.1 Overview

The Phoenix approach aims at migrating object-

oriented systems to aspects. It is based on Aspect-

Oriented reverse engineering techniques and is sup-

ported by two mechanisms: a transformational sys-

tem (called Draco-PUC (Leite et al., 1994)) and

a modeling tool (called MVCASE (Almeida et al.,

2002)). The proposed approach combines differ-

274

Cardoso Garcia V., Lucrédio D., Francisco do Prado A., Santana de Almeida E., Alvaro A. and Romero de Lemos Meira S. (2005).

TOWARDS AN APPROACH FOR ASPECT-ORIENTED SOFTWARE REENGINEERING.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 274-279

DOI: 10.5220/0002520302740279

 SciTePress

ent techniques based on our experience in software

reengineering (Alvaro et al., 2003),(Garcia et al.,

2004b).

Figure 1 shows the approach, according to the

SADT notation (Ross, 1977).

Figure 1: Reverse Engineering

In order to identify and extract crosscutting con-

cerns in legacy systems, tree steps are performed, as

follows.

Crosscutting Concerns Identiﬁcation. Initially,

the software engineer analyzes the legacy system aim-

ing to identify possible crosscutting concerns that are

present. These will serve as input to the aspect min-

ing, which determines where these concerns are lo-

cated inside the system. In our approach, aspect min-

ing is performed using character sequence and regular

expression analysis, and parser-based mining, imple-

mented in the transformational system Draco-PUC.

The idea is to ﬁnd static join points, occurring in the

context of the program, that refer to speciﬁc crosscut-

ting concerns.

The parser-based aspect mining was performed

through software transformations, implemented in

Draco-PUC Transformational System, to identify the

crosscutting concerns. The Figure 2 show the regu-

lar expressions to indicate the presence of exception

handling (1) and database persistence (2) concerns.

In the second stage of the reverse engineering, the

source code will be organized according to Aspect-

Orientation principles, separating the non-functional

requirements in aspects and the functional require-

ments in classes with their respective methods and at-

tributes.

Aspectual Reorganization. After the crosscutting

concerns are identiﬁed, the software engineer uses

refactorings to extract and encapsulate these concerns

into aspects. These refactorings (Garcia et al., 2004c)

consider the interlaced nature of the legacy system

code, and thus the transfer of individual members

from classes to an aspect should not be isolated. In

most cases, they are part of a set of transfers that com-

prise all the implementation elements of the concern

that is being extracted. Such concerns typically in-

Figure 2: Exception handling and database persistence

regular expressions

clude multiple code fragments scattered across multi-

ple modular units (e.g. methods, classes, packages).

Therefore, in many cases, more than one refactoring

should be applied to extract a particular concern.

Aspect-Oriented Design Retrieval. Next, the

software engineer, using software transformations in

the Draco-PUC Transformational System, obtains the

AO design, in UML descriptions. The transforma-

tions map descriptions in a programming language,

corresponding to the reorganized AO code, into de-

scriptions in a modeling language, which can be

loaded into MVCASE tool. Then, the software engi-

neering may edit the retrieved models in MVCASE,

inserting minor corrections and reﬁnements. We cur-

rently use an UML extension that is capable of repre-

senting AOSD concepts, and is implemented in MV-

CASE (Garcia et al., 2004a). More information on

automatic design retrieval using transformations may

be seen in (Alvaro et al., 2003).

Figure 3 shows an example of AO design retrieval

using software transformations. The AO Source code

(1) is analyzed by the transformations (2), which are

responsible for mapping the code into descriptions in

a modeling language (3). These descriptions are then

loaded into MVCASE, becoming available for edition

(4).

In the reading pattern called LHS, in (2), the trans-

former recognizes a aspect declaration, in the domain

of AspectJ language. After identifying the aspect dec-

TOWARDS AN APPROACH FOR ASPECT-ORIENTED SOFTWARE REENGINEERING

275

Figure 3: AO Design Retrieval

laration the control point POST-MATCH is executed.

Following this, the written pattern, called RHS, is ex-

ecuted through a TEMPLATE, that persists the as-

pect in XMI language speciﬁcations. Later, the as-

pect members are also persisted in the XMI language

speciﬁcations.

After that, the Software Engineer, using the CASE

tool, imports the XMI descriptions containing the as-

pects deﬁnition to visualize the design of the legacy

code. This design is represented using a class diagram

with aspects-speciﬁc notation (Garcia et al., 2004a).

The retrieved design and the Aspect-Oriented

source code constitute the knowledge of the legacy

system. Next, this knowledge is encapsulated in

highly modularized, reusable assets, with updated and

consistent documentation. With the aspect-oriented

design obtained from the code, the Software Engineer

goes to the forward engineering, to obtain the new im-

plemented aspect-oriented code.

Using the design obtained in the Reverse Engi-

neering phase that was imported into MVCASE, the

Software Engineer can apply modeling techniques to

modify the existing functional and non-functional re-

quirements, add new features or deﬁne the logical and

physical architecture of the system components.

Once the new aspect-oriented design is ﬁnished, the

Software Engineer may then implement it using an

aspect-oriented language. This task is partially auto-

mated by MVCASE, through a plug-in that was devel-

oped to generate code in the target language, which in

this case is AspectJ.

The generated code can then be tested and exe-

cuted. If any problems are identiﬁed, the user can

go back and correct them directly in the code, or in

the design, since the code can be generated and tested

again. This process continues until the system passes

the tests. A set of unit tests and coverage tests may be

created to help in maintaining the correctness of the

re-constructed system.

3 PARTIAL EVALUATION

In order to obtain a partial evaluation of the Phoenix

approach, a case study was performed.

The pilot project has involved the reverse engineer-

ing of a Bank Teller System, which was developed in

Java. It is composed of 11 classes, where 3 contain

business rules and 8 are related to Graphical User In-

terfaces, through the java.swing package. The system

had approximately 2.5K lines of code.

Like most object-oriented systems, database persis-

tence commands are dispersed through the system’s

classes since the separation of concerns is not always

considered during the development process.

3.1 METHODOLOGY

The systems was obtained in the Internet

. No docu-

mentation was available other than source code com-

ments. The system understanding was performed

through its execution, which generated a document

containing its main functionalities, such as:

http://www.portaljava.com.br

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

276

i. The system allows the customer to register itself,

as well as its accounts. The account information in-

cludes the initial balance, and the account type; and

ii. For the user to access his accounts, it is neces-

sary to inform an user name and a previously stored

password. After this identiﬁcation, the customer in-

forms the account number and the value that he wants

to draw or deposit.

After understanding, the system was analyzed in

order to identify the possible crosscutting concerns,

that were interlaced and spread through the classes. In

this pilot project, two concerns were identiﬁed: data-

base persistence and exception handling.

Figure 4 shows an example of how parser-based

mining may help in the identiﬁcation of the exception

handling crosscutting concern.

Figure 4: Exception Handling Crosscutting Concern

Identiﬁcation

The parser recognizes the “try-catch” syntactic

structure in Java code and the occurrence of a SQLEx-

ception exception type, that indicates the presence

of a non-functional requirement (exception handling).

This information is stored to be later consulted, in or-

der to aid the software engineer to extract and encap-

sulate that crosscutting concern into aspects. How-

ever, it must be stressed that parser-based mining,

as well as character sequence and regular expression

analysis, is just an aid to perform the mining, which

must be carried out manually by the software engi-

neer.

Refactorings were applied to extract these con-

cerns, and the AO Design was retrieved, both activ-

ities through transformations. In order to verify if

the retrieved assets were still in conformance with the

original system requirements, a new implementation

of the system was performed in a forward engineer-

ing step. The new AO system was executed, and its

observation veriﬁed that the functionalities of the OO

system were maintained.

The Figure 5 shows an example of transformation

to refactoring exception handling in source code. The

“try-catch” syntactic structure (1) was recognized by

an LHS reading pattern in the “RefactoringExcep-

tionByTryCatch” transformer (2). After identifying

the “try-catch” declaration, the control point POST-

MATCH is executed. Following this, the written pat-

tern (RHS) creates an aspect responsible to exception

handling (3).

Figure 5: Exception Handling Aspectual Refactoring

Table 1 shows a brief comparison between the OO

and the AO systems.

Table 1: Result Evaluation

OO AO

Classes 11 11

Aspects - 6

Lines of Code (LOC) 2492 2324

The reduced number of lines of code and the in-

creased number of modules (aspects) indicate that the

retrieved assets are smaller and better divided. Since

each aspect groups a single concern, the modules are

also more cohesive. Therefore, we may deduct that

TOWARDS AN APPROACH FOR ASPECT-ORIENTED SOFTWARE REENGINEERING

277

the retrieved assets are more reusable than the origi-

nal ones.

3.2 DISCUSSION

This was only an initial study, to prove the viability of

the proposed approach.

The consequences on identifying and separating

crosscutting concerns are equivalent to those stated

by AOSD:

i. Automation: The use of software transforma-

tions, through Draco-PUC, automates an important

stage in the reengineering: the recovery of the sys-

tem design. The Reverse Engineering activities, such

as the crosscutting concerns identiﬁcation and the as-

pectual reorganization, are also accelerated due to this

automation;

ii. Requirements traceability: After the separa-

tion of concerns, it is easier to trace each module to a

speciﬁc requirement;

iii. Easier Maintenance: Requirement changes,

functionality improvements and code restructuring

are also easier to perform;

iv. Readability: The new code is lighter and

less polluted, because attributes and methods are not

spread through the system; and

v. Reuse: The identiﬁed and extracted aspects can

be implemented in such a way that they can be later

reused. This may even give origin, with the accom-

plishment of different case studies, to a framework of

aspects.

Also, some disadvantages could be observed:

Transformers construction: Since Phoenix uses a

transformational system help the Software Engineer

in some tasks of the process, there must exist trans-

formers to identify crosscutting concerns, to refac-

toring source code and to recover design information

directly from the code. However, these transformers

must be ﬁrst constructed, which requires great effort

and knowledge about the involved languages. The

time spent in the transformers construction is also a

critical factor. However, it must be stressed that this

effort is later reused in any legacy system written in

the same language. The time reduction obtained when

using these transformers in the design recovery, as

discussed earlier, also justiﬁes this effort.

4 RELATED WORK

The ﬁrst relevant work involving the OO technology

and retrieval of knowledge embedded in legacy sys-

tem was presented by Jacobson and Lindstron (Jacob-

son and Lindstrom, 1991), who applied reengineering

in legacy systems that were implemented in proce-

dural languages. The authors state that reengineering

should be accomplished in a gradual way, because it

would be impracticable to substitute an old system for

a completely new one.

Today, on the top of OO techniques, an additional

layer of software development, based on components,

is being established. The goals of “componentware”

are very similar to those of OO: reuse of software is

to be facilitated and thereby increased, software shall

become more reliable and less expensive (Lee et al.,

2003).

Among the ﬁrst research works in this direction,

Caldiera and Basili (Caldiera and Basili, 1991) have

explored the automated extraction of reusable soft-

ware components from existing systems. They pro-

pose a process that is divided in two phases. First,

it chooses, from the existing system, some candi-

dates and packages them for possible independent

use. Next, an engineer with knowledge of the appli-

cation domain analyzes each component to determine

the services it can provide.

Investigations about AOSD in the literature has in-

volved determining the extent that it can be used

to improve software development and maintenance,

along the lines discussed by Bayer in (Bayer, 2000).

The AOSD can be used to reduce code complexity

and tangling; it also increases modularity and reuse,

which are the main problems that are currently faced

by software reengineering. Thus, some works that use

AOSD ideas in reengineering may be found in the re-

cent literature.

In Kendall’s case study (Kendall, 2000), exist-

ing object-oriented designs for role models are used

as the starting point for reengineering with aspect-

oriented techniques. In this work, it did not describe

the reengineering process in full detail. They are

just told the comparative results among the object-

oriented code and the aspect-oriented code, target of

the reengineering. The use of AOSD in this case study

reduced the overall module (30 methods) and lines of

code (146).

Currently, with AOSD technologies being adopted

and extended, new challenges and innovations start

to appear. AOSD languages, such as AspectJ and

AspectS, the contributions of several research groups

and the recent integration with application servers,

such as JBOSS, demonstrate the potential of AOSD

in solving real problems, including those pursued in

reengineering.

5 CONCLUSIONS AND FUTURE

WORK

Many software reengineering approaches have been

proposed to redesign and rebuild legacy systems. The

goal is to develop a global picture on the subject sys-

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

278

tem, which is the ﬁrst major step toward its under-

standing or transformation into a system that better

reﬂects the quality needs of the application domain.

This paper presents a migrating proposal, that inte-

grates different techniques and mechanisms to guide

and help software engineers in redesign and rebuild of

software systems, using transformations from object-

oriented to aspect-oriented paradigm.

This integration has the goal of guiding the user in

the task of retrieving the system design, according to

the aspect-oriented paradigm, willing to get a better

degree of reuse and develop a system that is easier to

maintain. It also helps to improve development pro-

ductivity and support for changes in the requirements.

Additionally, an evaluation was accomplished to

show the reengineering proccess usefulness. By fol-

lowing the Phoenix, it could be veriﬁed that the

AOSD brings several and important beneﬁts to soft-

ware development. The way as the aspects is com-

bined with the system modules allows the inclusion

of additional responsibilities without committing the

clarity of the code, maintainability, reusability, and

providing a greate reliability.

As a future work, the possibility of using the Ob-

ject Management Group (OMG) Model Driven De-

velopment (MDD) in the Phoenix approach is being

studied to enable rapid design, development, modiﬁ-

cation and deployment of the aspect-oriented appli-

cation. The idea is that through MVCASE, the Soft-

ware Engineer could generate complete, working ap-

plications directly from a visual model, in this case an

UML+AO speciﬁcations, and using active synchro-

nization to keep both model and code up to date dur-

ing rapid application changes.

Graphical visualization of the possible crosscutting

concerns source code is also being developed. In this

way, the task of identifying different concerns in the

legacy system should be facilitated.

REFERENCES

Almeida, E., Bianchini, C., Prado, A., and Trevelin, L.

(2002). MVCASE: An integrating technologies tool

for distributed component-based software develop-

ment. In Proceedings of the 6th Asia-Paciﬁc Net-

work Operations and Management Symposium. (AP-

NOMS’2002) Poster Session. IEEE Computer Society

Press.

Alvaro, A., Lucr

edio, D., Garcia, V. C., de Almeida, E. S.,

do Prado, A. F., and Trevelin, L. C. (2003). Orion-RE:

A Component-Based Software Reengineering Envi-

ronment. In Proceedings of the 10th Working Con-

ference on Reverse Engineering (WCRE), pages 248–

257. IEEE Computer Society Press.

Bayer, J. (2000). Towards engineering product lines using

concerns. In Workshop on Multi-Dimensional Sep-

aration of Concerns in Software Engineering (ICSE

2000).

Caldiera, G. and Basili, V. R. (1991). Identifying and quali-

fying reusable software components. IEEE Computer,

24(2):61–71.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns - Elements of Reusable

Object-Oriented Software. Addison Wesley Profes-

sional Computing Series. Addison-Wesley.

Garcia, V. C., Lucr

edio, D., Frota, L., Alvaro, A.,

de Almeida, E. S., and do Prado, A. F. (2004a). A case

tool for aspect-oriented software development (in por-

tuguese). In XI Tools Section - XVIII Brazilian Sym-

posium on Software Engineering (SBES 2004). ISBN

85-7669-004-7.

Garcia, V. C., Lucr

edio, D., do Prado, A. F., de Almeida,

E. S., and Alvaro, A. (2004b). Using aspect min-

ing and refactoring to recover knowlegde embedded in

object-oriented legacy system. In Proceedings of the

IEEE International Conference on Information Reuse

and Integration (IEEE IRI-2004). IEEE Computer So-

ciety Press.

Garcia, V. C., Piveta, E. K., Lucr

edio, D., Alvaro, A.,

de Almeida, E. S., do Prado, A. F., and Zancanella,

L. C. (2004c). Manipulating Crosscutting Concerns.

4th Latin American Conference on Patterns Lan-

guages of Programming (SugarLoafPlop 2004).

Jacobson, I. and Lindstrom, F. (1991). Reengineering of

old systems to an object-oriented architecture. In Pro-

ceedings of the Object-Oriented Programming Sys-

tems, Languages, and Applications (OOPSLA’91),

pages 340–350. ACM Press.

Kendall, E. A. (2000). Reengineering for separation of con-

cerns. In Workshop on Multi-Dimensional Separation

of Concerns in Software Engineering (ICSE 2000).

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C.,

Lopes, C., Loingtier, J.-M., and Irwin, J. (1997).

Aspect-Oriented Programming. In Proceedings of the

11st European Conference Object-Oriented Program-

ming (ECOOP’97), volume 1241 of LNCS, pages

220–242. Springer Verlag.

Lee, E., Lee, B., Shin, W., and Wu, C. (2003). A reengi-

neering process for migrating from an object-oriented

legacy system to a component-based system. In Pro-

ceedings of the 27th Annual International Computer

Software and Applications Conference (COMPSAC),

pages 336–341. IEEE Computer Society Press.

Leite, J. C., Sant’anna, M., and Freitas, F. G. (1994). Draco-

PUC: A Technology Assembly for Domain Oriented

Software Development. In Proceedings of the 3rd In-

ternational Conference on Software Reuse (ICSR’94),

pages 94–100. IEEE Computer Society Press.

Ross, D. T. (1977). Structured analysis (SA): A language

for communicating ideas. IEEE Transactions on Soft-

ware Engineering, 3(1):16–34. Special collection on

Requirement Analysis.

TOWARDS AN APPROACH FOR ASPECT-ORIENTED SOFTWARE REENGINEERING

279