Concern-based Refactorings Supported by Class Models to

Reengineer Object-Oriented Software into Aspect-Oriented Ones

Paulo Afonso Parreira Júnior

, Matheus Carvalho Viana

, Rafael Serapilha Durelli

Valter Vieira de Camargo

Heitor Augustus Xavier Costa

and Rosângela Aparecida Dellosso Penteado

Departament of Computer Science, Federal University of São Carlos, São Carlos, Brazil

Computer Systems Department, University of São Paulo, São Carlos, Brazil

Departament of Computer Science, Federal University of Lavras, Lavras, Brazil

Keywords: Concern-based Refactorings, Class Models, Aspect-Orientation, Reengineering.

Abstract: Reengineering Object-Oriented Software (OO) into Aspect-Oriented Software (AO) is a challenging task,

mainly when it is done by means of refactorings in the code-level. The reason for it is that direct

transformations from OO code to AO one involve several design decisions due to syntactic and semantic

differences of both paradigms. To make this task more controlled and systematic, we can make use of

concern-based refactorings supported by models. This type of refactorings concentrates on transforming

broader scenarios into a set of context-dependent scenarios, rather than specific ones, as in code-level

refactorings. In this paper we propose a set of concern-based refactorings that allows design decisions to be

made during the reengineering process, improving the quality of the final models. Two of them are

presented in more details in this paper. An example is presented to assess the applicability of the proposed

refactorings. Moreover, we also present a case study, in which AO class models created based on the

refactorings are compared with AO class models obtained without the aid of these refactorings. The data

obtained in this case study indicated to us that the use of the proposed refactorings can improve the efficacy

and productivity of a maintenance group during the process of software reengineering.

1 INTRODUCTION

Aspect-Orientation (AO) can be used in the

revitalization of Object-Oriented (OO) legacy

software. AO allows encapsulating the so-called

“crosscutting concerns” (CCC) - software

requirements whose implementation is tangled and

scattered by functional modules - in new

abstractions such as pointcuts, aspects, advices and

inter-type declarations (Kiczales et al., 1997).

Reengineering from OO to AO in code-level is

not an easy task due to existing differences between

concepts related to both approaches. However, if the

reengineering process was supported by models, it

could facilitate future maintenance. In this paper we

propose the use of concern-based refactorings on

OO class models annotated with information of CCC

to obtain AO models. In the context of this paper,

annotated OO class models are UML OO class

models whose elements (classes, interfaces,

attributes and methods) are annotated with

stereotypes corresponding to the CCC that exist in

the software. The main idea is that concern-based

refactorings can be applied to transform these

models into AO models.

There are many studies in the literature that

present code-based refactorings (Silva et al., 2009;

Monteiro and Fernandes, 2006; Hannemann et al.,

2005; Marin et al., 2004; Iwamoto and Zhao, 2003).

Our main reasons to create and apply concern-

based refactorings supported by models (“model-

based refactorings” in the rest of this paper) are:

i) code-level refactorings can be applied to

transform OO software in AO ones. However,

this transformation is usually done in one step,

which has as input an OO code and as output an

AO one. It makes the reengineering process less

flexible, because the responsibility to generate a

code that follows good design practices of AO is

on the refactorings. The transformation based on

model-based refactorings introduces at least one

Afonso Parreira Júnior P., Carvalho Viana M., Serapilha Durelli R., Vieira de Camargo V., Augustus Xavier Costa H. and Aparecida Dellosso Penteado

R..

Concern-based Refactorings Supported by Class Models to Reengineer Object-Oriented Software into Aspect-Oriented Ones.

DOI: 10.5220/0004442200460057

In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 46-57

ISBN: 978-989-8565-60-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

more step in the process before generating the

final code. Thus, to ease the inflexibility of the

process, in this step the outcome AO model can

be modified by the software engineer according

to the environment and stakeholder

requirements;

ii) generally, the source code is the only available

artifact of the legacy software. Applying model-

based refactorings, both the legacy software and

the generated software will have a new type of

artifact (i.e., UML class models), improving their

documentation; and

iii) unlike the code-based refactorings, model-based

ones are platform independent. Thus, models can

be transformed and good designs can be

produced regardless of programming language.

A set of nine model-based refactorings was

developed. It is subdivided into: i) three generic

refactorings, which are concern-independent

refactorings; and ii) six specific refactorings to the

following concerns: persistence (subdivided into

connection, transaction and synchronization

management), logging and Singleton and Observer

design patterns (Gamma et al., 1995). Due to the

limitation of space, only two of them are discussed

in more details in this paper. The AO class models

presented in this paper are based on AOM (Aspect-

Oriented Modeling) approach proposed by

Evermann (Evermann, 2007).

The remainder of this paper is structured as

follows. Some concepts related to the AOM

approach proposed by Evermann, the annotated OO

class models and the computational support DMAsp

(Costa et al., 2009), used to generate automatically

annotated OO class models, are discussed in Section

2. The generic and specific refactorings are

presented in Section 3. An example that illustrates

the use of these refactorings is shown in Section 4

and an evaluation of them is presented in Section 5.

Some related works are summarized in Section 6.

Finally, conclusions and suggestions for future work

are presented in Section 7.

2 BACKGROUND

ProAJ/UML (UML Profile for AspectJ) is one of the

most used approaches to model AO software

(Evermann, 2007). This approach consists of a set of

stereotypes that can be applied on UML class

models, such as:



<<CrossCuttingConcern>>: it is an extension of

the Package meta-class, in the UML meta-model.

Its aim is to encapsulate aspects related to the same

crosscutting concern.



<<Aspect>>: it extends the UML Class meta-class.

Its goal is to cluster pointcuts and advices in an

aspect and to allow aspects to extend classes or

aspects and implement interfaces.



<<Advice>>: it is a BehavioralFeature meta-class

extension. Its aim is to associate advices with

aspects.



<<PointCut>>: it is a StructuralFeature meta-class

extension, whose goal is to specify a static

behavior. Its modelling is performed by concrete

subclasses of PointCut, such as CallPointCut and

ExecutionPointCut.

These stereotypes are used in the AO class

models generated with the application of the

refactorings proposed in this work. Furthermore, OO

class models annotated with information of CCC are

used in the proposed refactorings. These annotations

are represented using stereotypes on the left side of

the classes, interfaces, attributes and methods

identifiers. Figure 1 illustrates a class annotated with

indications of persistence CCC. The DMAsp

(Design Model to Aspect) tool (Costa et al., 2009),

developed in a previous work, is used to generate

automatically the annotated OO class models.

Figure 1: An UML Class Annotated with Information

about Persistence CCC.

Based on the concept of annotated OO class models,

the following concepts, proposed by Figueiredo et

al. (2009), were adapted to the context of this work

and are commented in the refactoring descriptions.

 Components affected by a concern are software

elements such as classes, interfaces, attributes and

methods which have indications of this concern.

These elements are annotated with stereotypes of

the concern that affect them.

 Primary concern is the main concern of a

component and it is related to the reason by which

it was created. For example, the

openConnection method (Figure 1) was created

to open database connections. Then “Persistence”

is the primary concern of this method. The primary

concerns are identified by the prefix “Pri_” in the

stereotypes.

 Secondary concern of a component corresponds

to functions that this component plays. However,

Concern-basedRefactoringsSupportedbyClassModelstoReengineerObject-OrientedSoftwareintoAspect-Oriented

Ones

these functions are not directly related to the

reason for which it was created. In Figure 1, the

Account class and its method withdraw were

created to perform the business rules of a

hypothetical banking system. Thus “Persistence” is

a secondary concern in these components. The

secondary concerns are identified by the prefix

“Sec_” in the stereotypes.

 Well-modularized components are software

elements composed only by the primary concern

for which they were created. For example, the

openConnection method (Figure 1) is

considered well-modularized, because the only

type of stereotype of this method is a primary

concern related to “Persistence” concern.

3 MODEL-BASED

REFACTORINGS

Hannemann (2006) proposed the following

classification of AO software refactorings:

i) Conventional OO Refactorings adapted for

AO Software. These refactorings only involve

OO elements. The difference between these

refactorings and the well-known OO refactorings

is they are aware of the existence of AO

elements;

ii) Specific Refactorings for AO Software. These

refactorings involve OO and AO elements and

they are specific to lead to the AO abstractions,

such as aspects, pointcuts, etc; and

iii) Crosscutting Concerns Refactorings. Also

called concern-based refactorings, they should

take all the elements (classes, aspects, interfaces,

etc) that participate in a crosscutting concern and

their relationships into consideration. This

happens, because concerns usually are

manifested in several components.

A set of nine concern-based refactorings is

shown in Table 1, but only two of them are

presented in this paper in more details. The

remaining refactorings were omitted for reasons of

limitation of space and can be found in (Parreira

Júnior, 2011).

The following information of refactorings are

presented: i) Acronym and Name of the Refactoring;

ii) Application Scenario, which defines the situations

the refactoring can be applied; iii) Motivation, which

presents some problems caused by tangling and

scattering of CCC; and iv) ProAJ/UML Mechanism,

which is a set of steps to obtain an AO class model

from an OO one, according to the ProAJ/UML

profile.

Table 1: Model-based refactorings.

Generic Refactorings

Name Description

R-1

Encapsulating a Primary Concern that does not

have Generalization / Specialization

relationships.

R-2

Encapsulating a Primary Concern that has

Generalization / Specialization relationships.

R-3 Extracting a Primary Concern.

Specific Refactorings

Name Description

R-

Connection

Encapsulating the CCC responsible for managing

database connections.

R-

Transaction

Encapsulating the CCC responsible for managing

database transactions.

R-Sync

Encapsulating the CCC responsible for managing

database synchronization.

R-Logging

Encapsulating the CCC responsible for

controlling the application of logging record.

R-Singleton

Encapsulating the CCC corresponding to the

Singleton design pattern.

R-Observer

Encapsulating the CCC corresponding to the

Observer design pattern.

3.1 Generic Refactorings

The generic refactorings are responsible for

transforming an annotated OO class model to a

partial AO class model. The generated model is

named “partial”, because the existing CCC may not

be well-modularized yet. In this case, there still can

exist classes/interfaces, methods and/or attributes

affected by crosscutting concerns. One of the

generic refactorings, R-3, is presented as follows.

R-3. Extracting a Primary Concern.

Application Scenario: when there are classes with

Secondary Concerns, which are Crosscutting

Concerns and these ones are not Primary Concerns

in any classes.

Motivation: some crosscutting concerns can be

scattered in several classes and there are not

specific classes that implement them. One concern

of this type is not a Primary Concern in any class

of the application. This scenario represents a high

level of concern tangling and a low level of

software modularization.

ProAJ/UML Mechanism: 1) Create a

CrossCuttingConcern element called “CCC”, in

which “CCC” represents the concern name that is

being modularized; 2) Inside the element created

previously, add an Aspect element called

“CCCAspect”; and 3) Move each well-modularized

attribute and method from the classes affected by

the concern to the “CCCAspect” element.

Looking at the application scenario of R-3

refactoring, we understand that: “no matter what

concern we are dealing, the scenario described

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

above represent a low level of modularization”.

Thus, we already can apply a modularization

strategy to this concern, whatever it is, putting all the

well-modularized elements (attributes and methods)

related to this concern in a specific module, in this

case, an aspect. Only well-modularized elements are

moved to the aspect, avoiding problems related to

the dependence of other concerns.

3.2 Specific Refactorings

The specific refactorings are responsible for

transforming partial AO class models in final ones.

These refactorings are named “specific”, because

they only can be applied to a specific type of

concern. For example, there is a specific refactoring

to the transaction management concern that

generates an AO class model with the

modularization of this concern using aspects. Six

specific refactorings were developed, as presented in

Table 1.

These refactorings were created based on the

most common strategies for implementing these

types of crosscutting concerns. For example, the

database connection concern is usually implemented

with a class responsible for creating connections and

each persistent method must open the connection at

the beginning of its execution and close it at the end.

In another example, the singleton pattern is

generally implemented as follows (Gamma et al.,

1995): i) create an attribute of the same type of the

Singleton class; ii) become private the constructor of

the Singleton class; and ii) create a method

responsible for keeping only one instance of the

Singleton class. Therefore, it is possible to define

some steps for modularization of this type of

concern, based on the most common strategies for

implementing them.

The specific refactorings are applied on the

models generated by the generic refactorings. Thus,

in ProAJ/UML Mechanism description, aspects

created previously are mentioned. To illustrate this

case the refactoring R-Singleton is presented.

Unlike the generic refactorings, in this case, we can

use some more specific steps to modularize the

CCC, because Singleton pattern is a commonly

known concern. Thus the aspect created by a generic

refactoring has been transformed into an abstract one

and for each class affected by the Singleton concern

one aspect has been created. This strategy follows a

good practice for AO design suggested by Piveta et

al. (2007). Furthermore, it is similar to Hanneman

and Kiczales’ (2002) solution and was adapted to the

context of annotated OO class models.

R-Singleton. Encapsulating the CCC

corresponding to the Singleton design pattern.

Application Scenario: when there are classes

dedicated to implementation of Singleton pattern.

Motivation: the Singleton pattern can cause

problems of tangling and scattering of concerns in

OO application. The modularization using AO is

one alternative to solve these problems

(Hannemann and Kiczales, 2002).

ProAJ/UML Mechanism: 1) Identify the

“CCCAspect” aspect related to implementation of

the singleton concern and verify if this aspect is

abstract. If not, transform it into abstract one; 3)

Create, inside the element “CCC” related to the

singleton concern, an empty interface called

Singleton; 4) Define an execution pointcut

called instance that intercepts the calls to

constructor of the classes that realize the

Singleton interface and add it to the

“CCCAspect”; 5) Identify the set of classes, “S”,

that implement the Singleton pattern, i. e., the

classes whose instance must be unique in the

application. If the constructor of these classes be

private, transform it into public; 6) For each class

“N” ϵ “S”, create an aspect “CCCAspectN”, where

“N” corresponds to the class name and create

inheritance relationships from the aspects

“CCCAspectN” to the aspect “CCCAspect”; 7)

Each aspect “CCCAspectN” created previously

must declare an interface realization relationship

between the class “N”, represented by this aspect,

and the interface Singleton; and 8) Create an

around advice that returns a Singleton object.

This advice implements the logic of the Singleton

pattern: if there exists an instance, return it;

otherwise, create one instance and return it.

Associate the around advice to the instance

pointcut.

3.3 Considerations about

the Refactorings

Some of the main reasons to apply generic

refactorings are: i) the application of generic

refactorings can facilitate the achievement of a

better AO model: wrong decisions made by

software engineers, due to their inexperience, can

prejudice the AO model quality. Thus, an initial

modularization strategy offered by these refactorings

can minimize this problem; and ii) generic

refactorings can be applied to any type of

concern, even to those concerns that are not

widely known as crosscutting concerns: it is not

easy to identify whether a particular concern is or

Concern-basedRefactoringsSupportedbyClassModelstoReengineerObject-OrientedSoftwareintoAspect-Oriented

Ones

not a crosscutting concern. Thus, with the help of

generic refactorings, we can identify scenarios that

demonstrate or provide evidence of the existence of

crosscutting concerns in software. For example, the

application scenario for the refactoring R-3 states a

configuration that can evidence the existence of a

crosscutting concern (many classes of software

related to a secondary concern in these classes).

There is not a specific sequence to apply generic

refactorings proposed in this work. The steps created

for refactoring are applied when a specific element

is well-modularized, i.e., when there is no

interference of other concerns in this element.

Moreover, some modularization strategies described

in the steps of the refactoring were considered to

avoid interference in the order of execution of the

refactoring. Similarly to what happens with the

generic refactorings, the order in which the specific

refactorings are applied does not interfere in the

final AO class model. It happens because each

refactoring acts only on a particular concern at a

time, not compromising elements related to other

concerns.

The manual execution of the steps described in

the refactoring presented on class models of

software for medium and large scale can be hard and

error-prone. Thus, an Eclipse plug-in called MoBRe

(Model-Based Refactorings) was developed to

perform tasks related to refactoring of crosscutting

concerns in a semi-automatic way. MoBRe (Parreira

Júnior et al., 2011) allows transforming an annotated

class model into a partial AO class model, when the

generic and specific refactorings are applied. The

AO class models generated can be visualized within

the Eclipse.

4 EXAMPLE OF USE

To verify the applicability of the proposed

refactorings, an example, using the Health Watcher

software (Soares et al., 2002), is presented. This

software registers complaints in the health area and

it was chosen because it: i) has an OO and an AO

version; and ii) was modularized by expert software

engineers by using best practices of AO design.

Figure 2: A UML Class Stereotyped with CCC Indications.

Figure 3: Health Watcher AO Class Model obtained through R-3 Refactoring.

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

Figure 4: Health Watcher AO Class Model obtained through R-Singleton Refactoring.

The crosscutting concern modularized in this

example is the Singleton pattern, represented by the

“Singleton” stereotype. Other crosscutting concerns

affect this application, such as connection and

transaction management, represented by the “Conn”

and “Trans” stereotypes, but the modularization of

them is not performed in this paper because of

limitations of space.

One part of Health Watcher OO class model,

responsible for the maintenance of the patient

complaints, is presented in Figure 2. This model is

annotated by using stereotypes of the concerns that

affect the software classes, according to the

information provided by Soares et al. (2002).

The

HealthWatcherFacade class provides

methods necessary for execution of the business

logic of the application, as complaints registration,

diseases, and symptoms. The

singletonHW and

singletonPS attributes and the getInstanceHW

and getInstancePS methods have “Singleton” as

Primary Concern, because they were created

specifically for implementing the Singleton pattern.

The same way, “Conn” and “Trans” are Primary

Concerns of the

IPersistenceMechanism

interface and the

PersistenceMechanism class,

because they were created for implementing these

concerns. The

HealthWatcherFacade class has

“Trans” and “Singleton” as Secondary Concerns,

because this class was not created for implementing

these concerns, but it is affected by them. This

information about what concerns are primary or

secondary one was provided by the Health Watcher

developers.

According to the scenario of tangling/scattering

of the model presented in Figure 2, the singleton

concern can be initially refactored by the R-3

refactoring. This happens because “Singleton” is a

Secondary Concern in some classes of this model

and it is not a Primary Concern in none other

classes.

After applying the R-3 refactoring to the

“Singleton” concern, the partial AO class model

presented in Figure 3 was obtained. The changes

made were: i) the

SingletonAspect aspect was

created; and ii) the

singletonHW and

singletonPS attributes and the getInstanceHW

and

getInstancePS methods were moved to the

SingletonAspect aspect. It is because these

elements are well-modularized in the

Health-

WatcherFacade and PersistentMechanism

classes.

Concern-basedRefactoringsSupportedbyClassModelstoReengineerObject-OrientedSoftwareintoAspect-Oriented

Ones

The pmInit method of the Health-

WatcherFacade

class continues being affected to

the “Singleton” concern. To eliminate this influence,

the R-Singleton refactoring has been used on the

model in Figure 3 and the resulting model is

presented in Figure 4.

The changes were:

 An interface called

Singleton was created; The

SingletonAspect aspect became abstract and a

pointcut called

instance was added to it. This

pointcut intercepts the calls to constructor of the

classes whose instances must be unique;

 Two new aspects that extend

Singleton-Aspect

were created:

SingletonAspect-

HealthWatcherFacade and Singleton-

AspectPersistenceMechanism;

 For each aspect created: i) attributes and methods

corresponding to each Singleton class were moved

to it; ii) advices responsible for returning an

instance of the Singleton class when the pointcut

instance is reached were created; and iii) declare

parents structures were created to associate each

class related to Singleton concern with

Singleton interface; and

 The modifiers of the constructors of the

HealthWatcherFacade and Persistence-

Mechanism classes were changed from private

public. It was done so that the instance of a

Singleton class is obtained using its constructor

and not by

getInstance method.

5 EVALUATION

The crosscutting concern modularization may be

performed with or without the assistance of

refactorings. In the second case, the process of

modularization is extremely dependent on the

expertise of the software engineer. He/She must

have knowledge about the crosscutting concerns to

be modularized and best practices and strategies for

the modularization of these concerns. Refactorings

minimize this dependence, making the final product

(modularized software) more standardized and

improving its quality.

The question we want to answer with this case

study is: how much can the refactorings affect the

efficacy of the modularization process and the

productivity of the maintenance group? In this

context, productivity is defined as the time that a

group takes to modularize the crosscutting concerns

of a software product. Besides, efficacy consists in

verifying whether all crosscutting concerns were

suitably modularized or not. Thus, the case study

was carried out and it is shown in the next

subsections.

5.1 Case Study Definition

The efficacy and productivity evaluation of the

refactorings was performed in two ways:

i) comparing the generated AO class models with

another version of them, obtained from a reverse

engineering using the AO code found in the

literature (in this study, we use the JSpider AO

code available in (JSpider, 2013)). To do this, a

set of seven Metrics for Modularization were

used to compare both versions of the application

AO class model (Table 2). All of them, except

MQ and AVG(MQ), accept the following values:

1.0 – Completely Compliant; 0.5 - Partially

Compliant; and 0.0 – Not Compliant. These

values are assigned to the metrics for

modularization by specialists after comparing the

models created by the participants of this

experiment to the models obtained from the

literature. The metrics MQ and AVG(MQ)

accepts values between [0.0; 5.0] and the higher

the value of them, the better is the

modularization of a concern; and

ii) comparing the time spent by each participant to

complete the modularization of a given OO class

model. For this, we used the metric Productivity

(Pr), given to the Formula (1). The higher the

value of Pr, the better is the productivity of a

participant.

5.2 Case Study Planning

a) Selection of Context and Formulation of

Hypothesis. The study was carried out with

graduate students at the Federal University of São

Carlos. The system used as object of study was

JSpider (2013), a highly configurable and

customizable Web Spider engine. The participants

had to modularize the Logging and Singleton

crosscutting concerns and generate an AO class

model from the OO model classes of the JSpider

application.

Four hypotheses were elaborated (Table 3), two

of which refer to the efficacy and two ones refer to

the productivity. Besides, the metrics MQ and Pr

were used for formulating the hypotheses.

b) Selection of Variables and Participants.

Independent variables are those manipulated and

controlled during the experiment. In this context,

they are the way how the participants performed the

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

modularization: with or without the use of the

refactorings.

Dependent variables are those under analysis,

whose variations must be observed. In this

experiment, they are the efficacy and productivity.

The participants were selected through a convenient

non-probabilistic sampling.

Table 2: Metrics for Modularization.

Metric Metric Description

CC_As

Correctly Created Aspects: specifies if all needed

aspects were correctly created.

CM_AM

Correctly Modularized Attributes and Methods:

specifies if all attributes and methods affected by a

concern were correctly modularized.

CC_PA

Correctly Created Pointcut and Advices specifies if all

needed pointcuts and advices were correctly created.

CC_GSR

Correctly Created Generalization and Specialization

Relationships: specifies if all needed relationships

were correctly created.

CS_PC

Correctly Specified Profile Concepts: specifies if all

ProAJ/UML concepts were correctly used.

Modularization Quality: CC_As + CM_AM + CC_PA

+ CC_GSR + CS_PC.

AVG(MQ)

Average of the Metric MQ.

Pr = AVG(MQ) / T,

where AVG(MQ) is the average of the metric

Modularization Quality and T is the time (in

hours) spent by a participant to modularize

the crosscutting concerns.

(1)

Table 3: Hypotheses of the case study.

Hypotheses for Efficacy

0Ef

There is no difference of using refactorings or not using them,

regarding the efficacy. H

0Ef

: MQ

= MQ

WOR

1Ef

There is difference of using refactorings or not using them,

regarding the efficacy. H

1Ef

: MQ

≠ MQ

WOR

Hypotheses for Productivity

0Pr

There is no difference of using refactorings or not using them,

regarding the productivity. H

: Pr

= Pr

WOR

1Pr

There is no difference of using refactorings or not using them,

regarding the productivity. H

: Pr

≠ Pr

WOR

Legends:

 X

, where X is a metric, means: the value of X obtained by a

specific participant using the refactorings proposed in this paper

(WR = With Refactorings).

 X

WOR

, where X is a metric, means: the value of X obtained by a

specific participant that did not use the refactorings proposed in this

paper (WOR = Without Refactorings).

c) Design of the Experiment. The distribution of

the participants in groups was done by using a

profile characterization questionnaire. The questions

were about their level of experience in OO and AO,

modularization and UML profile to modelling AO

software. All questions had the possible answers: 1 -

None; 2 - Basic; 3 - Medium; 4 - Advanced; 5 -

Expert. The obtained values are plotted in the graph

shown in Figure 5.

The groups were created as follows: Group A –

participants P1 to P5; Group B – participants P6 to

P10. The average of expertise of Group A is

approximately 1.86 and Group B, 1.80, representing

that the groups were balanced. To separate the

experts and novices we have defined the value 1.75

(horizontal line in Figure 5). This value was defined

according to our experience with the required

knowledge to perform the modularization of CCCs.

Above this value the participants were considered

experts (P1, P2, P6 and P9) and below novices (P3,

P4, P5, P7, P8 and P10). It is important to notice that

both groups have the same number of expert and

novice participants.

Figure 5: Participants Expertise.

The documents used in this experiment were: i) a

registry form to be filled out with information

related to the execution of the study; ii) a script of

execution with the steps to be followed to perform

the experiment; and iii) the description of the

proposed refactorings. The registry form contained

the participant name, the application to be

modularized, the starting time and the observations

and/or problems noticed by the participant. The

script of execution contained a list of tasks that the

participants should carry out and had the goal of

assisting them and minimizing the possibility of

failures during the execution. The description of the

proposed refactorings presents the refactoring

according the template used in Section 3.

Table 4 shows the experimental design. The

experiment was divided in three phases. In the first

phase (Training), we conducted a training aimed at

homogenizing the knowledge of the participants on

the modularization of crosscutting concerns using

hypothetical applications.

In the second phase (Pilot) all participants had to

discover how to modularize the persistence concern

that crosscuts pieces of the HealthWatcher

application manually and using the proposed

refactorings. The goal of the pilot was to minimize

the difficulties of following the steps described in

Concern-basedRefactoringsSupportedbyClassModelstoReengineerObject-OrientedSoftwareintoAspect-Oriented

Ones

the refactorings. Besides, the pilot also was intended

to avoid that problems related to the filling out of the

forms could interfere in the results of the

experiment.

Table 4: Design of the case study.

Phases

Software

Used

With Refactorings

Without

Refactorings

. Phase

(Training)

Toy

Applications

All participants All participants

. Phase

(Pilot)

Health

Watcher

All participants All participants

. Phase

(Execution)

JSpider Group A Group B

In the third phase (Execution) the goal was to

modularize the Logging and Singleton concerns in

the JSpider application. Different types of concern

between Execution and Pilot phases were used to

avoid that the knowledge on the persistence concern

obtained in the previous phase (pilot) to influence

the results.

d) Collected Data. Table 5 and 6 show the data

obtained in third phase of the experiment

(Execution) by the Groups A and B, respectively

(AoE means Average of the Experts and AoN means

Average of the Novices).

The participants, assigned by "P#", and the titles

of the table columns are presented in first line. The

time used by the participants for performing the

modularization is presented in lines from 2 to 3. The

concern names are presented in lines 3 and 10 and

the values of the metrics described in Table 2 are

presented in lines from 5 to 10 (for the Singleton

concern) and from 12 to 17 (for the Logging

concern). The average of the metric MQ and the

value of the metric Pr are presented in lines 19 and

20. The columns that contain the data of participants

classified as experts were highlighted in gray color.

e) Data Analysis. Regarding the Efficacy and

Productivity, Tables 5 and 6 show that most of

participants that used the proposed refactorings got

better results than those ones that do not used them.

Regarding the Productivity, just one of the

participants that used the proposed refactorings was

less productive. Although there was an extra task to

be carried out (to follow the steps described in the

refactorings), the developer will need to modify the

models during the process of refactoring less times,

thus minimizing the final time to perform the

activity.

As it can be observed in Figure 6, the average of

metric MQ, when the participants had the aid of the

refactorings was higher than the one when they did

not have this aid. According to this chart, the value

of the metric MQ was 206% higher, in average, for

all participants, and 344% higher, in average, for

participants classified as experts and 150% higher,

in average, for participants classified as novices).

Figure 6: Average of the Metric MQ.

Table 5: Execution of the case study – Group A (with

refactorings).

Data P1 P2 P3 P4 P5 Average AoE AoN

Time (min) 35 47 60 60 60 52 41 60

Time (hours) 0,58 0,78 1,0 1,0 1,0 0,87 0,68 1,0

Singleton Pattern

CC_As 1,0 1,0 1,0 1,0 1,0

CM_AM 1,0 1,0 1,0 1,0 1,0

CC_PA 1,0 1,0 0,5 1,0 0,5

CC_GSR 1,0 1,0 1,0 1,0 1,0

CS_PC 1,0 1,0 1,0 1,0 1,0

MQ 5,0 5,0 4,5 5,0 4,5 4,8 5,0 4,7

Logging

CC_As 1,0 1,0 1,0 1,0 1,0

CM_AM 1,0 1,0 1,0 1,0 1,0

CC_PA 1,0 1,0 0,5 0,5 0,5

CC_GSR 1,0 1,0 1,0 1,0 1,0

CS_PC 1,0 1,0 1,0 1,0 1,0

MQ 5,0 5,0 4,5 4,5 4,5 4,7 5,0 4,5

Results

AVG(MQ) 5,0 5,0 4,5 4,8 4,5 4,8 5,0 4,6

Pr 8,57 6,38 4,5 4,8 4,5 5,75 7,48 4,6

Analogously, in Figure 7, the average of metric Pr

also was better when the participants used the

refactorings. This chart presents productivity 124%

higher, in average, for all participants, and 115%

higher, in average, for participants classified as

experts and 134% higher, in average, for participants

classified as novices).

It is also possible to notice in Figure 6 and 7 that

the refactorings helped more expert participants than

non-expert ones. It happened maybe because the

description of the proposed refactorings was not well

detailed enough to guide non-expert participants to

modularize the concerns correctly.

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

Table 5: Execution of the case study – Group B (without

refactorings).

Data P6 P7 P8 P9 P10 Average AoE AoN

Time (min) 38 45 60 60 30 46 49 45

Time (hours) 0,63 0,75 1,0 1,0 0,5 0,78 0,69 0,83

Singleton Pattern

CC_As 1,0 1,0 0,0 0,0 1,0

CM_AM 1,0 1,0 0,0 0,0 1,0

CC_PA 0,0 0,0 0,0 0,0 0,0

CC_GSR 0,0 0,0 0,0 0,0 0,0

CS_PC 0,0 0,0 0,0 0,0 1,0

MQ 2,0 2,0 0,0 0,0 3,0 1,4 1,0 1,7

Logging

CC_As 1,0 1,0 0,5 0,0 1,0

CM_AM 1,0 1,0 0,0 0,0 0,5

CC_PA 0,5 1,0 0,0 0,0 0,0

CC_GSR 0,0 0,0 0,0 0,0 0,0

CS_PC 0,0 0,0 0,0 0,0 1,0

MQ 2,5 3,0 0,5 0,0 2,5 1,7 1,3 2,0

Results

AVG(MQ) 2,3 2,5 0,3 0,0 2,8 1,6 1,1 1,8

Pr 3,63 3,33 0,3 0,0 5,6 2,57 3,48 1,97

Figure 7: Average of the Metric Pr.

f) Hypothesis Testing. After outlier analysis, it was

noticed that none outlier was identified and the

hypotheses tests were performed. The verification of

the normality of the distribution sample data was

made using the non-parametric test called Shapiro-

Wilk (Montgomery, 2000).

The aim of the hypothesis test is to verify if the

null hypothesis (H

0Ef

and H

0EPr

) can be rejected, with

some significance degree, in favor of an alternative

hypotheses (H

1Ef

or H

1Pr

) based in the set of data

obtained.

The t-test test was applied to the set of sample

data in two stages, because of the existence of two

dependent variables, Efficacy and Productivity were

observed. In first stage, the sample relative to the

values of the metric Pr was compared. In second

one, the comparison was made using samples

referring to the values of MQ metric. For the

purpose of this study, the minor degree of

significance α was used in both stages to reject the

null hypothesis and the maximum degree of

significance equal to 5% was considered.

First stage. Based in two independent samples

(Pr

and Pr

WOR

) with averages equals to 5.75 and

2.57, respectively in Tables 5 and 6, the null

hypothesis (H

0Pr

) could be rejected with 0.0151% of

significance. In others words, it is possible to assure

with 99.9% of accuracy that the average of the

values of the productivity obtained by the

participants that used the refactorings is different.

Second stage. Based in two independent samples

(MQ

and MQ

WOR

) with averages equals to 4.8 and

1.6, respectively, the null hypothesis (H

0Ef

) could be

rejected with 0.0007% of significance. In others

words, it is possible to assurance with 99.9% of

accuracy that the average of the values of the

efficacy obtained using the refactorings is different

as compared to not using the refactorings.

With the rejection of H

, it can be stated that the

observed differences in the average of efficacy and

productivity of the participants who used the

refactorings and participants who have not use them,

have statistical significance. Thus, the change in

efficacy and productivity of the groups was due to

the strategies for software modularization adopted in

the experiment, i.e., with or without refactorings.

As presented in Figures 6 and 7, the average

value of the metric MQ of the participants who used

the refactorings was higher than that of the

participants who have not used (MQ

> MQ

WOR

These data show that the use of refactorings for

modularization of crosscutting concerns is generally

more effective than when such refactoring are not

used.

Analogously, with respect to productivity, it was

expected that the systematic description of the steps

of refactorings becomes more agile the execution of

the participants’ tasks. Based on the data and

hypothesis test, there are evidences that the use of

refactorings can increase the productivity of a group.

The analysis of the data was accomplished using

a statistical plug-in to the Excel called Analyse-it

(2013).

g) Threats to the Validity of the Study.

Concluding Validity: the t-test was adopted because

our study was a project with one factor with two

treatments. This is the most suitable test for projects

with this configuration, which the aim is to compare

the obtained averages from two distinct treatments.

The t-test usually requires normally distributed data.

So, the Shapiro-Wilk test was applied and the result

Concern-basedRefactoringsSupportedbyClassModelstoReengineerObject-OrientedSoftwareintoAspect-Oriented

Ones

was positive for our study.

Internal Validity: a point that may have

influenced the results of the experiment is the use of

graduate students as participants. However, they

were not influenced by the conductors of this study

and we did not show any expectation in favor or

against the refactorings proposed in this paper.

Besides, the students were properly grouped

according to their experience levels in order to have

homogeneous groups. This was done to avoid that a

group could finish the tasks much earlier than other

group. The participants did not receive any grade for

the participation.

External Validity: an important bias is the choice

of the concerns to be modularized in the experiment.

Different types of concern were used to avoid that

the knowledge on a specific concern obtained in the

training phase to influence the results in other phases

of the experiment. Another bias in this case study is

that the proposed refactorings have been applied in

software of fairly small size that cannot reflect the

real scenario of a company that develops/maintains

software. It is intended to replicate such experiment

with different participants, concerns and

applications, in order to isolate the obtained results

from these possible influences.

6 RELATED WORKS

Many works have been proposed for refactoring of

OO software to AO ones and the refactorings are

only applied at source-code level, from OO to AO

(Silva et al., 2009); (Monteiro and Fernandes, 2006);

(Hannemann et al., 2005); (Marin et al., 2005);

(Iwamoto and Zhao, 2003). Moreover, it was noted a

lack of related works related to model-based

refactorings.

Borger et al. (2001) developed a plug-in for the

CASE tool ArgoUML that support UML model-

based refactorings. The refactoring of class, states

and activities is possible, allowing the user to apply

refactorings that are not simple to apply at source-

code level. Van Gorp et al. (2003) proposed a UML

profile to express pre and post-conditions of source-

code refactorings using Object Constraint Language

(OCL) constraints. The proposed profile allows that

a CASE tool: i) verify pre and post-conditions for

the composition of sequences of refactorings; and ii)

use the OCL consulting mechanism to detect bad

smells.

The differential of this work in relation to others

is the proposal to construct an AO model

considering OO class models annotated with

stereotypes representing crosscutting concerns.

From the conducted case study was performed an

evaluation of the obtained results with the support of

AO metrics. It was realized that the use of proposed

refactorings allows to obtain high quality AO

models because: i) it provided a step by step guide to

modularization of certain CCC; and ii) the proposed

refactorings were elaborated considering good

design AO practices. Therefore, the use of these

refactorings can lead to build high quality AO

models, because it prevents software engineers to

choose inappropriate strategies for modularization of

crosscutting concerns. The limitations of this study

is considered: i) lack of a more quantitative

evaluation of the computational support and the

proposed refactorings; ii) the need for new metrics

to improve the evaluation process of the

refactorings; iii) lack of studies about the security

semantics of legacy software after the application of

refactorings; and iv) a little amount of refactorings

for CCC.

7 FINAL CONSIDERATIONS

AND FUTURE WORKS

The idea of using annotated OO class models to

build AO models was adopted because they can

bring the following benefits: i) it helps to visualizing

possibilities for modularization without using AO;

ii) provides higher level of abstraction by helping

the software understanding; iii) the generated

models serves as documentation for the AO software

and legacy ones and are independent of

programming language.

As future works we intend: i) to determine if, by

means of a controlled experiment, the AO project

model generated with the use of refactorings has

better benefits than an AO project only obtained

with code refactorings; ii) to develop new specific

refactorings for other types of concerns such as

security, exception handling, among others; iii) to

create a module for detecting the impacts that can

cause a refactoring on a particular software before

being applied; and iv) to proposed strategies for

guarantee the behavior-preservation of OO and AO

models after using the refactorings;

ACKNOWLEDGEMENTS

The authors would like to thank CNPq for the

financial support (Proc. No. 133140/2009-1 and

560241/2010-0).

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

REFERENCES

Analyse-it. Statistical analysis software for researchers in

environmental & life sciences, engineering,

manufacturing and education. Available in:

http://www.analyse-it.com/. Accessed on: Jan/2013.

Boger, Marko and Sturm, Thorsten. “Tools-support for

Model-Driven Software Engineering”, In Proceedings

of Practical UML-Based Rigorous Development

Methods. (2001).

Costa, H. A. X. ; Parreira Júnior, P. A. ; Camargo, V. V. ;

Penteado, R. A. D. . “Recovering Class Models

Stereotyped With Crosscutting Concerns”. In: Session

Tool of XVI Working Conference on Reverse

Engineering (WCRE), Lille, França. (2009).

Evermann, J. “A MetaLevel Specification and Profile for

AspectJ in UML”. Victoria University Wellington,

Wellington, New Zealand. AOSD - Aspect Oriented

Software Development. (2007).

Figueiredo E., Sant'Anna C., Garcia A., and Lucena C.

Applying and Evaluating Concern-Sensitive Design

Heuristics. In Proceedings of the 23rd Brazilian

Symposium on Software Engineering Fortaleza, 2009.

Gamma, E., Helm, R., Johnsn, R., Vlisside, J. “Design

Patterns: Elements of Reusable Object-Oriented

Software”. Addison-Wesley, (1995).

Hannemann, J., and Kiczales, G. Design Pattern

Implementation in Java and AspectJ. In Proceedings of

the ACM SIGPLAN Conference on Object-Oriented

Programming Systems, Languages and Applications

(OOPSLA 2002) SIGPLAN Notices, Vol. 37, N°11,

ACM 161–173 (2002).

Hannemann, J.; Murphy, G. C.; Kiczales, G. Role-Based

Refactoring Of Crosscutting Concerns. In Procedings

of the Aspect-Oriented Software Development, New

York, Usa. P.135–146. (2005).

Hannemann, J. “Aspect-Oriented Refactoring:

classification and challenges”. In Procedings of the

International Workshop On Linking Aspect

Technology And Evolution, Bonn, Germany. p. 1-5

(2006).

Iwamoto, M.; Zhao, J. Refactoring Aspect-Oriented

Programs. In Procedings of the International

Workshop On Aspect-Oriented Modeling With UML,

Boston, USA P. 1-7 (2003).

JSpider. The Open Source Web Robot. Available in: j-

spider.sourceforge.net/. Accessed at: Jan. 2013.

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

Lopes, C., Loingtier, J., Irwin, J. “Aspect-Oriented

Programming”. 11th European Conference on Object-

Oriented Programming. v. 241 de LNCS, p. 220-242.

Springer-Verlag (1997).

Marin, M.; Moonen, L.; Van Deursen, A. An Approach To

Aspect Refactoring Based On Crosscutting Concern

Types. Sigsoft Software Engineering Notes, V.30, N.4,

P.1–5. (2005).

Monteiro, M. P.; Fernandes, J. M. L. Towards A

Catalogue Of Refactorings And Code Smells For

Aspectj. Transactions On Aspect Oriented Software

Development (Taosd) - Lecture Notes In Computer

Science, N.3880, P.214–258 (2006).

Montgomery, D. C., Design and Analysis of Experiments,

5 ed., Wiley, 2000.

Parreira Júnior, P. A. “Recovering Aspect-Oriented Class

Models from Object-Oriented Systems by Model-

based Refactorings”. Master Dissertation. UFSCar.

São Carlos. Brazil. 2011 (available only in

portuguese).

Parreira Júnior, P. A.; Penteado, R. A. D.; Camargo, V.

V.; Costa, H. A. X. “Mobre: Refactoring from

Annotated OO Class Models to AO Class Models”. In:

CBSoft Tools Session, 2011, São Paulo/SP. II

Brazilian Conference on Software: Theory and

Practice (CBSoft), 2011 (to be publish in portuguese).

Piveta, E. K. et al. “Avoiding Bad Smells In Aspect-

Oriented Software”. In: International Conference On

Software Engineering And Knowledge Engineering -

Seke, Boston, Usa, 2007. Proceedings... Boston: Seke

2007. P.81–87.

Silva, B. et al. Refactoring Of Crosscutting Concerns With

Metaphor-Based Heuristics. Electronic Notes In

Theoretical Computer Science (Entcs), Vol. 233, P.

105-125. (2009).

Soares, S., Laureano, E., and Borba, P. “Implementing

distribution and persistence aspects with AspectJ”. In

Procedings of the 17th ACM Conference OOPSLA’02,

174 –190. (2002).

Van Gorp, P. Stenten, H. Mens, T. and Demeyer, S.,

“Towards Automating Source Consistent UML

Refactorings,” Proc. Unified Modeling Language

Conf. (2003).

Concern-basedRefactoringsSupportedbyClassModelstoReengineerObject-OrientedSoftwareintoAspect-Oriented

Ones