RANKING REFACTORING PATTERNS USING THE ANALYTICAL

HIERARCHY PROCESS

Eduardo Piveta

, Ana Moreira

, Marcelo Pimenta

Jo˜ao Ara´ujo

, Pedro Guerreiro

and R. Tom Price

Instituto de Inform´atica, Universidade Federal do Rio Grande do Sul, Porto Alegre, Brazil

Departamento de Inform´atica, Universidade Nova de Lisboa, Caparica, Portugal

Departamento de Engenharia Electr´onica e Inform´atica, Universidade do Algarve, Faro, Portugal

Keywords:

Refactoring, Refactoring Opportunities, Analytical Hierarchy Process.

Abstract:

This paper describes how to rank refactoring patterns to improve a set of quality attributes of a piece of

software. The Analytical Hierarchy Process (AHP) is used to express the relative importance of the quality

attributes and the relative importance of refactoring patterns in regards to those selected quality attributes. This

ranking of refactoring patterns can be used to focus the refactoring effort on the most beneﬁcial patterns to the

software being developed or maintained.

1 INTRODUCTION

Refactoring (Opdyke, 1992; Fowler et al., 1999;

Mens and Tourwe, 2004) is the process of improv-

ing the design of software systems without changing

its externally observable behaviour. Refactoring can

help to incrementally improve the quality attributes

of a software system through the application of be-

havioural preserving transformations called refacto-

ring patterns.

When refactoring a software module, the devel-

oper has to correctly evaluate the trade-offs between

refactoring patterns in terms of the affected quality at-

tributes. As these quality attributes can be conﬂicting

with each other (Boehm and In, 1996), the task of se-

lecting optimal refactoring patterns can be hard. As

the number of possible places to refactor can be very

high (Fowler et al., 1999), the developer has to nar-

row the search for refactoring opportunities to apply

refactoring patterns that bring beneﬁts in terms of the

expected quality attributes.

Current research on the identiﬁcation of refacto-

ring opportunities (Bois and Mens, 2003; Mens et al.,

2005; Bois, 2006) focuses on the improvements of

quality attributes considering each individual appli-

cation of a refactoring pattern, but does not consider

how this search can be narrowed to only those pat-

terns that improve the desired quality attributes of a

software system. Currently, there are no automated

mechanisms to rank refactoring patterns in terms of

quality attributes.

In this paper, we propose an approach to rank

refactoring patterns in terms of a set of quality at-

tributes. The relative importance of quality attributes

over the others and the relative importance of re-

factoring patterns over quality attributes is quantita-

tively expressed using the Analytical Hierarchy Pro-

cess (AHP) multi-criteria decision method (Saaty,

1990; Saaty, 2003).

Using this quantiﬁed information, a ranking of re-

factoring patterns in terms of quality attributes can be

automatically computed. The use of such ranking can

optimise the search for refactoring opportunities, en-

abling the developer to focus on the refactoring pat-

terns that improve the quality attributes most.

The creation of a refactoring patterns ranking is

exempliﬁed using three quality attributes and four re-

factoring patterns. Although the example is based on

refactoring patterns for object-oriented software, the

approach can be used in other paradigms. Moreover,

the approach is general enough to be successfully ap-

plied in software models, source code or other arte-

facts.

This paper is organized as follows. Section 2 de-

tails AHP. Section 3 shows how to rank refactoring

patterns according to a set of quality attributes using

AHP and describes tool support. Section 4 discusses

related work and Section 5 concludes the paper.

195

Piveta E., Moreira A., Pimenta M., Araújo J., Guerreiro P. and Tom Price R. (2008).

RANKING REFACTORING PATTERNS USING THE ANALYTICAL HIERARCHY PROCESS.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 195-200

DOI: 10.5220/0001686001950200

 SciTePress

2 ANALYTICAL HIERARCHY

PROCESS

The Analytical Hierarchy Process (AHP) (Saaty,

1990) is a decision making method for evaluating a

set of different alternative solutions of a given prob-

lem. It focuses on ﬁnding an optimal solution using

qualitative and quantitative decision analysis.

AHP comprises of ﬁve steps: (a) deﬁnition of the

problem and its objective, (b) hierarchical representa-

tion, (c) estimation of priorities, (d) synthesis and (e)

results consistency analysis.

The deﬁnition of the problem and its objective es-

tablishes the context in which the decision making

process will occur. Next, the problem is hierarchi-

cally represented, with the objective having several

associated criteria and each criterion several alterna-

tives.

In the priorities estimation step, the developer de-

ﬁnes the priorities for the criteria and alternatives.

The relative importance of each criterion over the oth-

ers and each alternative over the others is ascertained

using pairwise comparisons. The scale in Table 1 is

used to numerically express the relative importance

between the criteria and the alternatives.

Table 1: The numerical values of each relative importance

(Saaty, 1990).

Value Relative Importance

1 Same importance

2 Slightly more important

3 Weakly more important

4 Weakly to moderately more important

5 Moderately more important

6 Moderately to strongly more important

7 Strongly more important

8 Greatly more important

9 Absolutely more important

In this process, a pairwise matrix can be created,

containing the relative importance of the criteria over

the others. Consider, for example, a set of crite-

ria C = {c

,...,c

} and a matrix M representing

the relative importance of one criterion over another

W = {w

,...,w

}. The pairwise matrix in this

case, is constructed as follows:

M =







1 w

··· w

1/w

1 ··· w

1/w

··· 1







(1)

For example, consider three criteria c

, c

where c

is weakly more important than c

, c

slightly more important than c

and c

is weakly to

moderately more important than c

. A pairwise ma-

trix M containing the importance of each criterion

over another can be created as follows:

M =

z }| {





1 1/2 3

2 1 4

1/3 1/4 1





(2)

The same process is done to the alternatives. For

each criterion, a set of pairwise comparisons are cre-

ated between the alternatives and a pairwise matrix is

created to represent these comparisons.

The next step of AHP, named synthesis, computes

a vector containing the relative weights of all the cri-

teria in the matrix and a vector for each alternative

matrix. To compute each vector, the respective ma-

trix is squared successively. In each iteration, the row

sums are calculated and normalized. The computa-

tion stops when the differences of these sums in two

consecutive calculations are smaller than a prescribed

value. Usually two to four iterations are sufﬁcient.

For the example matrix M , the ranking of prior-

ities can be derived from the weights vector of the

matrix. To compute this vector, the matrix is squared,

the sum of the row values is computed and the values

are normalized:

squared matrix

z }| {





3.00 1.75 8.00

5.33 3.00 14.00

1.17 0.67 3.00





sum of rows

z }| {





12.7500

22.3332

4.8333





Total 39.9165

Eigenvector =

normalized

z }| {





0.3194

0.5595

0.1211





Norm. Total 1.0000

Iterating the process again, the computed vector

is:

′

= h0.3196 0.5584 0.1220i

Additional iterations do not change these values

(using four digits precision). This normalized vector

is called the principal eigenvector (Saaty, 2003) of the

matrix. To compute the overall ranking of alterna-

tives in terms of the selected criteria, a matrix whose

columns are the alternativeseigenvectorsis multiplied

by the criteria eigenvector. The resulting vector is the

overall ranking.

The last step of AHP, results consistency analy-

sis, evaluates the consistency level of the pairwise

comparison matrix. More details on how to com-

pute a consistencyratio are described by Saaty (Saaty,

1990).

ICEIS 2008 - International Conference on Enterprise Information Systems

196

3 RANKING REFACTORING

PATTERNS

This section describes the main steps for ranking

refactoring patterns according to a set of preferred

quality attributes and exempliﬁes each step using

three quality attributes and four refactoring patterns,

showing how AHP can be used to create a ranking of

refactoring patterns in terms of quality attributes.

3.1 Overview

Starting with a set of candidate refactoring patterns

and a set of selected quality attributes, the developer

performs the following steps to generate a ranking

of refactoring patterns according the preferred qual-

ity attributes:

1. Create pairwise comparisons for quality at-

tributes: The ﬁrst step is to create pairwise com-

parisons between the selected quality attributes.

This is the developer’s main task in this approach,

as the relationship of quality attributes is usually

speciﬁc to a project.

2. Create pairwise comparisons for refactoring pat-

terns: A tool provider can make available a

knowledge base containing pairwise comparisons

for typical refactoring patterns and quality at-

tributes. The developer can then retrieve the pair-

wise comparisons from this base or add new ones

to the knowledge base (if there are no pairwise

comparisons available for a particular refactoring

pattern or quality attribute).

3. Compute the quality attributes ranking: In this

task, a pairwise matrix is created to express the

relationship between the quality attributes. The

quality attributes ranking is the eigenvector of the

quality attributes pairwise matrix. This step and

the next ones can be automated.

4. Compute the refactoring patterns rankings: For

each quality attribute, a pairwise matrix is created

to quantitatively express the relationship of the re-

factoring patterns vs. the quality attribute. The

ranking of refactoring patterns considering each

quality attribute in isolation is the eigenvector of

the respective pairwise matrix.

5. Compute the overall ranking: A ranking of the se-

lected refactoring patterns is computed using the

quality attributes eigenvector and the alternatives

(refactoring patterns) eigenvectors. To compute

the ranking of the refactoring patterns given the

set of quality attributes, a matrix is created with

the criteria (the quality attributes) and the alter-

natives (the refactoring patterns). This matrix is

multiplied by the eigenvector of the quality at-

tributes pairwise matrix.

This overall ranking can be used to focus the

search for refactoring opportunities for the best

ranked refactoring patterns, instead of looking for re-

factoring opportunities for refactoring patterns that

contribute little to the overall software quality (i.e. are

low ranked). Once a knowledge base containing the

relationship between the refactoring patterns and the

quality attributes is created, the developer has only

to provide pairwise comparisons for the quality at-

tributes, as the matrix manipulation activities can be

automated.

3.2 Creating the Quality Attributes

Pairwise Comparisons

The importance of the selected quality attributes de-

pends on the values of the development team, the pro-

cess, the project and the organisation. Each project

can have different sets and ordering of quality at-

tributes.

In this example, the following quality attributes

are considered: reusability, simplicity and compre-

hensibility. The following possible judgments for the

selected quality attributes are expressed as pairwise

comparisons:

• Simplicity is moderately more important than reu-

sability and slightly more important than compre-

hensibility;

• Comprehensibility is slightly more important than

reusability.

Note that these pairwise comparisons are hypo-

thetical. Each project can have different needs in

terms of quality attributes and can have different

weights for each quality attribute. The responsibility

for creating these comparisons can be delegated to a

quality analyst, made by the project leader or by other

means.

3.3 Creating the Refactoring Patterns

Pairwise Comparisons

For the example being developed, four different re-

factoring patterns were chosen, because they manipu-

late classes, methods and interfaces: Pull Up Method

(pm), Rename Class (rc), Inline Method (im), and Ex-

tract Interface (ei). They are compared and ranked in

terms of the selected quality attributes.

The ﬁrst step is evaluating each refactoring pattern

in terms of each quality attribute, considering how

much one refactoring pattern improves each quality

RANKING REFACTORING PATTERNS USING THE ANALYTICAL HIERARCHY PROCESS

197

attribute compared to the others. Let us suppose that

the developer created a set of pairwise comparisons

of the refactoring patterns in terms of the ﬁrst quality

attribute (simplicity), as follows:

• Pull Up Method is strongly more important than

Rename Class, weakly more important than Inline

Method and strongly more important than Extract

Interface

• Inline Method is slightly more important than Re-

name Class and strongly more important than Ex-

tract Interface

• Rename Class is weakly more important than Ex-

tract Interface

The second quality attribute is reusability, for

which the following judgments are made to exemplify

the process:

• Pull Up Method is absolutely more important than

Rename Class, moderately to strongly more im-

portant than Inline Method and slightly more im-

portant than Extract Interface

• Inline Method has the same importance than Re-

name Class

• Extract Interface is strongly more important than

Rename Class and Inline Method

The third quality attribute is comprehensibility.

For this quality attribute the following judgments are

made using pairwise comparisons:

• Extract Interface is slightly more important than

Pull Up Method and Rename Class and it is abso-

lutely more important than Inline Method;

• Rename Class is slightly more important than Pull

Up Method and strongly more important than In-

line Method;

• Pull Up Method is moderately more important

than Inline Method

These pairwise comparisons can be inserted in a

knowledge base to enable future reuse of the relations

between refactoring patterns and quality attributes.

3.4 Computing the Quality Attributes

Ranking

Using the pairwise comparisons deﬁned in the pre-

vious section and the numerical values on Table 1,

the quality attributes pairwise matrix Q is straight-

forwardly created from the deﬁned pairwise compar-

isons:

Q =

simp. reus. comp.

z }| {





1.00 5.00 2.00

0.20 1.00 0.50

0.50 2.00 1.00





simp.

reus.

comp.

This pairwise matrix is used to compute the

weight of each quality attribute. In this matrix, the

computed eigenvector E

is:





0.5954

0.1283

0.2764





simp.

reus.

comp.

The E

vector shows that the most important qual-

ity attribute in this setting is simplicity, then compre-

hensibility and last reusability. This setting can vary

from project to project. The computed weights for

each quality attribute deﬁne which are the preferred

refactoring patterns for the selected quality attributes.

In this case, the consistency ratio of the Q matrix is

0.48% (the matrix is consistent).

3.5 Computing the Refactoring Patterns

Ranking

The ranking of refactoring patterns for each quality

attribute and the ranking of quality attributes can be

automatically created as follows.

The Simplicity Ranking. First, the pairwise com-

parisons for the simplicity quality attribute are trans-

lated to their numerical equivalents and a pairwise

matrix S is computed as follows:

S =

pm im rc ei

z }| {







1.00 3.00 7.00 7.00

0.33 1.00 2.00 7.00

0.14 0.50 1.00 3.00

0.14 0.14 0.33 1.00







Here is the computed eigenvector of S , named E







0,593

0,245

0,113

0,050







In this case, Pull Up Method is the preferred re-

factoring pattern to be used, in terms of simplicity,

when compared with the other three refactoring pat-

terns (in order): Inline Method, Rename Class and

Extract Interface. The consistency ratio is 5.83% and

the pairwise matrix is consistent. Note that the differ-

ence between them is high. The developer can focus

on those patterns with high values of relative impor-

tance for the quality attribute.

The Reusability Ranking. The reusability pair-

wise matrix R , after translating the pairwise compar-

ICEIS 2008 - International Conference on Enterprise Information Systems

198

isons to their numerical equivalents, is:

R =

pm im rc ei

z }| {







1.00 6.00 9.00 2.00

0.17 1.00 1.00 0.14

0.11 1.00 1.00 0.14

0.50 7.00 7.00 1.00







The computed eigenvector E

is:







0.522

0.063

0.056

0.358







Considering the ranking of refactoring patterns for

reusability, the preferred refactoring pattern is Pull Up

Method, followed by Extract Interface. The Inline

Method and Rename Class refactoring patterns do not

have much impact on this quality attribute. The con-

sistency ratio is 2.52% and the pairwise matrix is con-

sidered consistent.

The Comprehensibility Ranking. The pairwise

matrix C for comprehensibility is also created:

C =

pm im rc ei

z }| {







1.00 5.00 0.50 0.50

0.20 1.00 0.14 0.11

2.00 7.00 1.00 0.50

2.00 9.00 2.00 1.00







And the computed eigenvector E

is:







0.196

0.044

0.304

0.457







Considering only comprehensibility, the best

ranked refactoring pattern is Extract Interface, fol-

lowed by Rename Class and Pull Up Method. The

Inline Method refactoring pattern does not have much

impact in terms of comprehensibility compared to the

other ones selected. The consistency ratio is 1.9% (the

pairwise matrix is consistent). Note that the order of

the refactoring patterns is different, depending on the

quality attribute.

3.6 Computing the Overall Ranking

For the example used in this paper the ranking is com-

puted by:

O =

simp. reus. compre.

z }| {







0.593 0.522 0.196

0.245 0.063 0.044

0.113 0.056 0.304

0.050 0.358 0.457







∗

criteria

z }| {





0.5954

0.1283

0.2764





Considering the initial quality attributes, the pair-

wise comparisons between them and the judgments

for the alternatives, the ranking O of refactoring pat-

terns is:

O =







0.4743

0.1658

0.1583

0.2018







The overall ranking shows that, considering the

selected quality attributes, the selected refactoring

patterns and the pairwise comparisons made, the best

ranked refactoring pattern is Pull Up Method, fol-

lowed by Extract Interface, Inline Method and Re-

name Class.

After the ranking is created, the developer can de-

ﬁne a threshold to reduce the initial set of refacto-

ring patterns to only those that have a ranking value

higher than this threshold. He can decrease the thresh-

old value to add more refactoring patterns to the

search for refactoring opportunities or increase it if

the search for low ranked refactoring patterns is not

being fruitful. The use of a threshold narrows the

search for refactoring opportunities, focusing on the

best ranked refactoring patterns.

3.7 Tool Support

A proof-of-concept tool was developed to assess the

practical use of the proposed approach. It (i) converts

pairwise matrices expressing the relative importance

of each quality attribute over the others and of each

refactoring pattern over the others (for each quality at-

tribute) to the equivalent AHP numerical representa-

tion, (ii) creates the pairwise matrices, (iii) computes

the eigenvectors, (iv) elaborates the quality attributes

ranking and (vi) computes the rankings of refactoring

patterns regarding each quality attribute.

These rankings are used to automatically compute

the overall ranking. If the refactoring patterns matri-

ces are created by a tool provider, for example, the

user has only to provide the pairwise comparisons be-

tween the quality attributes.

Note that the ranking does not need to be up-

dated frequently. Once the matrices relating refac-

toring patterns to quality attributes are created (by a

tool provider, for example), the developer only has to

inform the pairwise comparisons for the relative im-

portance of each quality attribute over the others.

The ranking must be recalculated if one of the

change scenarios occur: changes in the pairwise com-

parisons; addition of a refactoring pattern; addition of

a quality attribute. The tool can recalculate the rank-

ing automatically.

RANKING REFACTORING PATTERNS USING THE ANALYTICAL HIERARCHY PROCESS

199

4 RELATED WORK

Du Bois and Mens (Bois and Mens, 2003), (Bois,

2006) suggest the evaluation of refactoring patterns

by identifying conditions in which their application

minimize coupling and maximize cohesion. Their

formal analysis can be used together with our ap-

proach to provide additional information for the de-

veloper to express the relative importance of refacto-

ring patterns over the quality attributes using pairwise

comparisons.

Tourwe and Mens (Tourwe and Mens, 2003) use

logic meta programming to identify refactoring op-

portunities in a software design and propose the ap-

plication of refactoring patterns. Their approach can

be used together with ours to improve the results by

focusing on the refactoring patterns that improve most

the set of quality attributes selected by the developers.

Mens et al. (Mens et al., 2003) state that an open

problem is to assess the effects of a refactoring pattern

on the software quality, as some refactoring patterns

remove redundancy, raise abstraction or modularity

level and others have negative impact on reusability,

for example. By classifying refactoring patterns in

terms of the quality attributes they affect, the effect

of a refactoring on the software quality can be esti-

mated. In this paper, we provide a quantitative ap-

proach to rank a set of refactoring patterns according

to the quality attributes that the developers are con-

cerned about.

5 CONCLUSIONS

Usually, there is room for improvements in existing

software projects. However, resources are ﬁnite and

must be directed to those activities that bring more

beneﬁts to the project. Considering refactoring activ-

ities, the developers should focus on the search for re-

factoring opportunities for those refactoring patterns

that are more likely to improve the software being de-

veloped or maintained.

AHP can help the developers to express the re-

lationship between quality attributes and refactoring

patterns and quality attributes between themselves.

These relations are used to compute a ranking of re-

factoring patterns (according to the selected quality

attributes), which can be used to focus the effort of

searching for refactoring opportunities for those re-

factoring patterns that can have more impact in the

software quality.

Without focusing in a restricted set of refactoring

patterns, the developers can be losing time with re-

factoring opportunities that bring little or nothing to

the software quality. The approach described in this

paper is adaptable: the quality attributes, the refacto-

ring patterns and the weights can be changed and a

new ranking computed automatically.

ACKNOWLEDGEMENTS

This work has been partially supported by CNPq un-

der grant No. 140046/2006-2 for Eduardo Piveta,

by Capes-Grices grant No. 166/06 and by PRO-

SUL No. 490478/2006-9 - Latin-America Research

Network on Aspect-Oriented Software Development

(Latin- AOSD).

REFERENCES

Boehm, B. W. and In, H. (1996). Identifying quality-

requirement conﬂicts. IEEE Software, 13(2):25–35.

Bois, B. D. (2006). A Study of Quality Improvements by

Refactoring. PhD thesis, Universiteit Antwerpen.

Bois, B. D. and Mens, T. (2003). Describing the impact of

refactorings on internal program quality. In 1st Work-

shop on Evolution of Large-scale Industrial Software

Applications - ELISA’03. Amsterdam, Netherlands.

Fowler, M., Beck, K., Brant, J., Opdyke, W. F., and Roberts,

D. (1999). Refactoring: Improving the Design of Ex-

isting Code. Addison-Wesley.

Mens, T., Demeyer, S., Bois, B. D., Stenten, H., and van

Gorp, P. (2003). Refactoring: Current research and

future trends. ENTCS - Elsevier, 82(3):483 – 499.

Mens, T., Taentzer, G., and Runge, O. (2005). Detecting

structural refactoring conﬂicts using critical pair anal-

ysis. ENTCS - Elsevier, 127(3):113 – 128.

Mens, T. and Tourwe, T. (2004). A survey of software

refactoring. IEEE Trans. on Software Engineering,

30(2):126 – 139.

Opdyke, W. F. (1992). Refactoring Object-Oriented Frame-

works. PhD thesis, University of Illinois.

Saaty, T. L. (1990). How to make a decision: The analytic

hierarchy process. European Journal of Operational

Research - Elsevier, 48(1):9 – 26.

Saaty, T. L. (2003). Decision-making with the ahp: Why is

the principal eigenvector necessary? European Jour-

nal of Operational Research - Elsevier, 145(1):85 –

91.

Tourwe, T. and Mens, T. (2003). Identifying refactoring op-

portunities using logic meta programming. In 7th Eu-

ropean Conf. on Software Maintenance and Reengi-

neering - CSMR’03. Benevento, Italy., pages 91 – 100.

ICEIS 2008 - International Conference on Enterprise Information Systems

200