Deconstructing the Refactoring Process

from a Problem-solving and Decision-making Perspective

Thorsten Haendler

and Josef Frysak

Institute for Information Systems and New Media, WU Vienna, Austria

Institute of Business Informatics - Communications Engineering, JKU Linz, Austria

Keywords:

Software Refactoring, Decision-making Process, Decision Problems, Refactoring Process Model, Managing

Technical Debt.

Abstract:

Refactoring is the process of improving a software system’s internal technical quality by modifying and re-

structuring a system’s source code without changing its external behavior. Manual identiﬁcation and asses-

sment of r efactoring candidates as well as planning and performing the refactoring steps are complex and

tedious tasks, for which several tools and techniques for automation and decision support have been propo-

sed i n recent years. Despite these advances, refactoring is still a neglected part of software engineering in

practice, which is attributed to several barriers that prevent software practitioners from refactoring. In this

paper, we present an approach for deconstructing the refactoring process into decision-problems and corre-

sponding decision-making sub-processes. Within this, we pursue the question of whether and how a theoretical

perspective can contribute to better understand the difﬁculties in the refactoring process (barriers) and to help

improving the refactoring support techniques (enablers). For this purpose, we follow a deductive reasoning

approach by applying concepts from decision-making research to deconstruct the r efactoring process. As a

result, we present a process model, which integrates primary decision problems and corresponding decision-

making sub-processes in refactoring. Based on this process model, software companies can gain a better

understanding of decision-making in the refactoring process. We ﬁnally discuss the applied procedure and

reﬂect on limitations and potential of applying such a theoretical perspective.

1 INTRODUCTION

Refactoring is the process of improving a system’s in-

ternal technical quality by modifying and restructu-

ring a system’s source code without changing its ex-

ternal behavior (Fowler, 2009). Manual identiﬁcation

and assessment of refactoring candidates (e .g., b ad

smells) as well as planning and performing the refac-

toring steps are co mplex and tediou s tasks, for which

several tools and techniques for automatio n and deci-

sion support have been pr oposed in recent years; such

as smell detectors, refactoring-recommen dation tools

and quality-analyzer tools, see, e. g., ( Fontana et al.,

2012; Fernandes et al., 2016; Campbell and Papape-

trou, 2013).

However, despite these advances, refactoring still

seems to be a neglected part of software engineer-

ing. A recent survey (Tempero et al., 2017) conduc te d

with 3,785 software developers in software projects

using objec t-oriented concepts shows that practitio-

ners mostly understand the value of refactoring, but

are often prevented from doing it. The stu dy iden-

tiﬁed seven main factors (called barriers) that affect

the practitioners’ decision o f whethe r or not re factor.

In pa rticular, these barriers to refactoring are catego-

rized into the following seven categor ies: missing re-

sources, the risk to introduce an error, the difﬁculty

to perform the refactoring, an unclear ROI, technical

issues, constraints set by the management, and a lack

of appropria te tools support (Tempero et al., 2017).

The identiﬁed barriers affect decision makers on

different organizational levels: besides decisions o n

the operational level (e.g., the difﬁculty to perform

the refactoring), there are also decisions located on

management level (e.g., ROI); few are on both le-

vels and interrelated (e.g., the allocation of resour-

ces). Due to the manage ment issues addressed by

the ba rriers and due to the relevance of technical debt

for software projects (Kruchten et al., 2012), we sug-

gest a more general problem-solving and decision-

making perspective on software r efactoring. In this

paper, decision-making is understood as a sub-a rea

Haendler, T. and Frysak, J.

Deconstructing the Refactoring Process from a Problem-solving and Decision-making Perspective.

DOI: 10.5220/0006915903630372

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 363-372

ISBN: 978-989-758-320-9

363

of problem-solving , which requires the selection of a

single one of at least two alternatives, that is, mutually

exclusive actions. These actions are designed to solve

a complex problem by achieving one or more goals.

However, an option may be to take no action at all, o r

to postpone the decision and to search for more infor-

mation. In the case of refactoring, however, the latter

alternative measures are likely to increase the techni-

cal debt. On the other sid e, the resource s freed up can

then be used in other areas of software development

and maintenance. Hence, the dilemma, whether or not

to engage in refactor ing, and which refactorings to ap-

ply in order to maximize the beneﬁts arising from the

expenditure of resources, is a key aspect of decision-

making in refactoring.

In this paper, we propose a theory-driven appro-

ach for deconstructing the refactoring process into

decision-making steps and for investigating the cha-

racter of the included decision p roblems. Research

in decision-making provides multiple conce pts that

are very p romising for re-structuring the re factoring

process in or der to better understand the includ e d dif-

ﬁculties. A s a result, we prop ose a ﬁrst version of

a process model for decision-making in software re-

factoring (see Fig. 2) which can help software practi-

tioners in better under standing the de pendencies be-

tween re factoring activities as well as between the

different decision-maker levels. This proc e ss mod el

requires further empirical evaluation, which w ill b e

approa c hed in the next step. However, we illustrate

by example that our process model already can help

in understanding refactoring difﬁculties by allocating

refactoring barriers and suppor t techniques to corre-

sponding affected and addressed process steps.

The remainde r o f this paper is structured as fol-

lows. In Section 2, we apply a deductive methodo-

logy for deconstructing the refactoring process into

process phases and decision problems. In Section 3,

we pre sent as a result our process model for decision-

making in software refactoring, which reﬂects on

three primary decision pro blems and corresponding

sub-processes. Sec tion 4 illustrates the applicability

of the process model by allocating refactoring barriers

and support techniques to process steps. In Section 5,

we discuss the performed procedure, reﬂect shortly on

related research and describe limitations and potential

of this approach. Section 6 concludes the paper.

2 DECONSTRUCTING

REFACTORING

In this paper, we aim at deconstructing the decision-

making process for refactoring. By deconstruction,

we understand the identiﬁcation of individual steps/-

tasks, characteristics of de c isio n problems, decision-

makers involved as well as the dependencies between

the steps in the refactoring process from the per-

spective of pr oblem solving and decision-making. A

result of this procedur e is an integrated process model

which reﬂects on these aspects and aims at helping

better understand decision-making in refactoring, see

Fig. 2. For this reaso n, we apply deductive reasoning,

also known as top-down logic. The reasoning starts

with stating two or more (often theory-based) linked

premises which lead to a new hypothesis or conclu-

sion (syllogism), see, e.g., (Evans et al., 1993). In our

case, we investigate whether deducing concepts and

classiﬁcation schemes from genera l d e cision-making

research to the refactoring process can help be tter

understanding the difﬁculties in refactoring. Accor-

dingly, the following syllogism was ap plied:

• major premise: decision-making processes can

be structured into ce rta in phases/steps, see, e.g.,

(Simon, 1 977).

• minor premise: refactoring is a decision-making

process including multiple decision problems, see,

e.g., (Lepp¨anen et al., 2015).

Following on these premises, the hypothesis can be

conclud ed that the refa ctoring process can be struc-

tured into the pha ses or steps of a de c isio n-making

process for solving decision problems. In a broa-

der sense, this hypothesis also raises the questions

to which extent refactoring can be understood as a

decision-making process and which decision -making

problems are inc luded? In or der to verify this hypot-

hesis and answer these questions, we will describe in

the following the main con cepts on process models

and decision problems from refactoring on the one

hand and from a decisio n-making perspective on the

other.

2.1 PROCESS MODELS

Process Models for Refactoring. For refactoring

only very few process models are established. Since

refactoring can be understood as a speciﬁc mainte-

nance activity aiming at improving maintainability of

the software system (in terms of a preventive main-

tenance), we also included process models for soft-

ware maintenance, of which several are established,

for instance, (Boehm et al., 1981; Osborne, 1987; Kit-

chenham et al., 1999). Thr oughout all these variants,

the process is driven by the occurrence of a problem

(e.g. triggered by a change reque st or a problem re-

port). Very similarly most mode ls consist of the three

key phases comprehension (or investigation), (c ode)

modiﬁcation and evaluation. In all mentioned mo-

ICSOFT 2018 - 13th International Conference on Software Technologies

364

Problem

recognition

Task

evaluation

Strategy

selection

Situation

analysis

Objective

setting

Search for

alternatives

Evaluation of

alternatives

Making the

decision

Decision review

Problem

recognition

Problem

nition

Design

Choice

Implementation

Evaluation

Change request /

problem report

Modi cation

Evaluation /

quality assessm.

Pain zone

Situation

analysis

Refactoring planning

Implementation

Follow up

Problem

recognition

Beach and Mitchell,

1978

Te'eni and Ginzberg,

1991

Simon, 1997

Kitchenham et al.,

1999

Leppänen et al., 2015

Problem analysis Decision-Making

Implemen-

tation

Evaluation

Generic decision-making

process models

Refactoring

process models

Choice

Information

processing

Strategy

implem.

Simon, 1977

Intelligence

Design

Choice

Decision review

Investigation

Figure 1: Mapping decision-making process models (top) (Simon, 1977; Beach and Mitchell, 1978; Te’eni and G inzberg,

1991; Simon, 1997) to refactoring process models (bottom) (Kitchenham et al., 1999; Lepp¨anen et al., 2015).

dels only very little focus is set on decision-problems

and corre sponding steps of decision-making. In par-

ticular, the mo del in (Kitchenham et al., 1999) des-

cribes that after the investigation phase, the mainte-

nance manager must decide whether or not to per-

form the modiﬁcation. A recen t example for a pro -

cess model explicitly for software refactoring is given

in (Lepp¨anen et al., 2015). The model re presents the

result of a case study with software developers from

three Finnish software companies on their daily re-

factoring pra ctices. The r esulting de c isio n-making

process framework consists of the key phases pain

zone (e.g., triggered by a technical debt, p oor design

or new requirements), situation analysis, refactoring

planning (includin g discussions on requirements and

possible solutions as well as task allocation), imple-

mentation (i.e . the actual co de modiﬁcation), and ﬁ-

nally follow up, which represents the evaluation of the

refactoring in the broadest sense. The process steps of

Kitchenham et al. and Leppnen et al. are de picted in

Fig. 1 (bottom) and are co ntrasted by process models

for decision-making (top in Fig. 1; see below).

Decision-making Process Models in General. The

probably most well known approach to separate

decision-making processes into single phases from

the early days of decision-making research is the four

phases approach o f Simon (Simon, 1977; Pome rol

and Adam, 2004), which in particular comprises the

phases intelligence, design, cho ic e and review. Du-

ring the intelligence phase, the environment is obser-

ved to detect cues indicating problems, which potenti-

ally initiate a decision. Once such cues are identiﬁed,

the underlying problem is then analyzed in more de-

tail by collecting additional information on that pro-

blem. During design phase, alternative solutions for

the previously identiﬁed problem are derived. At

this phase, gathering further information is an inte-

gral part as well. Now, however, information search

aims at su pporting the generation of alternative so-

lutions to the previously identiﬁed prob le m. In the

choice phase, the alternatives a re then evaluated ac-

cording to various criteria. The end of this phase is

usually marked by the selection of one of the alterna-

tives. With the solution selected, deemed most ade-

quate to deal with the detected de c isio n problem, the

solution is ﬁnally implemented and the outcom es ob-

served. Reviewing the observed outcomes in relation

to the ones estimated during decision-making then al-

lows to determine the effectiveness and accuracy of

the de c isio n-making strategy fo r the particular case.

Still high in popularity in research community,

this mode l was exp anded by many authors, see, e.g.,

(Asemi et al., 2011; Te’eni and Ginzberg, 1991;

Courtney, 2001; Huber, 1980 ; Mora et al., 20 05), who

added additional ph a ses or broke down the process

into more detail phases. Te’eni and Ginzberg (Te’eni

and Ginzberg, 1991), for instance, while agreeing on

single design and choice phases, split the intelligenc e

phase into a problem recognition and problem de ﬁ-

nition phase, and the review phase into a phase for

implementing the solution and one for evalua ting the

outcomes. In addition, in their model they suggest

that this process is repeated iteratively.

Later, Simon also publishe d an extended version

of his phase framework, see (Asemi et al., 2011 ).

Within this framework, the review phase is still po-

sitioned at the end of the process and the search for

alternatives phase corresponds to the de sign phase in

the small version. The intelligence phase, however,

has been replaced by a phase for situation analysis

and a subsequent phase, in which the decision goals

and criteria are in the focus. Furthermore, instead of

where the choice phase was situated, the process is di-

vided into a phase for evaluating alternatives and the

ﬁnal dec ision-making phase.

From a slightly different perspective, in their

approa c h, Beach and Mitchell (Beach and Mit-

Deconstructing the Refactoring Process from a Problem-solving and Decision-making Perspective

365

chell, 1978) describe ”a typical model of individual

decision-making” to explore how a single decision

maker adapts his co gnitive information processing to

different decision situations. This m odel was added,

as it shows how people identify a problem, evaluate

the problem , and then choose an appropr ia te decision-

making strategy based on that assessment. Once a de-

cision strategy deemed suitable f or the decision pro-

blem has been selected, the information processing

including the search for and evaluation of information

is started in a further step. This step is then followed

by the impleme ntation of the chosen de cision strategy

and ﬁnally the selection of the best solution.

The process of Beach and Mitchel (top) Te’eni and

Ginzberg (seco nd), and the latest version by Simon

(third) are presen te d in parallel in Fig. 1.

Findings. A t the ﬁrst glance, the mapping between

of the generic decision-making m odels and the pro-

cess mode ls for refactoring provides some obvious

similarities, since, at a high level, the refactoring

process (e.g., the one by (Lepp¨anen et al., 20 15))

can b e ﬁtted into the ﬁve phases of which the ﬁrst

two are problem-oriented: problem recognition (pain

zone) and problem analysis (situation analysis); the

third and fourth are dec ision-oriented: the actual

decision-making (refactoring planning) and decision

implementation (performing the refactoring, i.e. the

actual code implementation); and ﬁnally evaluation

(in terms of an optional follow up). On a second

view, we also identify some differences. Comparing

the amount of steps described by generic decision-

making approache s to the ones of refactoring, one

can see that especially the phases of problem ana ly-

sis and decision-makin g are more sophisticated in the

area of generic decision-m a king. Moreover, the gene-

ric approach es presuppose that only on e major deci-

sion problem is in center of the dec isio n-making pro-

cess. For the refactoring process, this would conclude

that refactoring planning addresses the main refacto-

ring decision problem, i.e. for example the identiﬁ-

cation, comparison and selection of refactoring paths.

This obviously contradicts to the barriers observed in

(Te mpero et al., 2017) (see above). The multitude of

barriers a nd the different organizational levels invo l-

ved in the process suggest that there are several deci-

sion problems included in th e refactoring process.

In Section 3, we propose a process model for selected

decision-making aspects in refactoring which also includes

the ﬁndings of 2.2.

2.2 Decision Problems

Table 1: Dimensions for characterizing decision problems;

dimension (1-9) are adapted from (Gr¨unig and K¨uhn, 2013),

dimension (10) from (Gorry and Morton, 1989).

Dimension Characteristics

(1) Complexity Simple Complex

(2) Structuredness Well-structured Ill-structured

(3) Solution space Choice problem Design problem

(4) Fr a ming Threat problem Opportunity problem

(5) Interrelatedness Independent decision

problem

Decision problem in a

decision sequence

(6) Problem level Original decision pro-

blem

Meta-problem (Sub-

problem)

(7) Actor type Individual Collective (Group)

(8) Goals/Criteria Single Multiple

(9) Certainty levels Decisions

under certainty

Decisions under

risk

Decisions un-

der uncertainty

(10) Hierarchy level Operational

(control)

Management

(control)

Strategy (plan-

ning)

Decision Problems in Refactoring. Independent

from the process models discussed in the previ-

ous section, multiple decision problems (and sub-

problems) in refactoring are addressed by research li-

terature, see, e.g., (Fern´andez-S´anchez et al., 2015;

Ribeiro et al., 2016) and Section 4. For the purpose

of this paper, we focus on the following three pro-

blem areas, which can be located in the process-m odel

mapping in Fig. 2.1 and should be answered after the

correspo nding phase:

1. Ma nagement o f Technical Debt (TD) (at manage-

ment level) with the q uestion of Whether (and

when) to refactor?, see

 in Fig. 1 and, e.g. ,

(Kruchten et al., 2012).

2. Detection and assessment of refactoring candida-

tes with the q uestion of What to refactor (ﬁrst)?,

see

 and, e.g., (Fowler, 2009; Ribeiro et al.,

2016).

3. Refactoring planning and pe rfo rming the actual

refactoring steps with th e question of How to re-

factor?, see

 and, e.g., (Fowler, 2009; Suryana-

rayana et al., 2014).

Decision Problems in General. Decision-making

demand s for choosing a single out of at least two al-

ternative actions. The action is necessary to solve the

problem of achieving one or more obje ctives. In some

cases, like refactoring, it may also be an option to take

no action at all or to postpone ﬁxing the decision and

continue searchin g for more infor mation. To classify

decision-making problems, a variety of characteris-

tics have been identiﬁed. I n (Gr¨unig and K¨uhn, 2013),

nine important dimen sions of characteristics are dis-

tinguished, which are sum marized in Table 1 (1-9):

First, a decision-making problem may be percei-

ved either easy or complex, depending on various fac-

tors such as the nu mber of information cues o r the

familiarity of the decision-m aker with the par ticular

task (Liu and Li, 2012).

ICSOFT 2018 - 13th International Conference on Software Technologies

366

Table 2: Phases of decision-making with relevant process input and output as well as characteristics for three selected key

decision problems in refactoring.

Dimension Whether (and when) to refactor? What to refactor (ﬁrst)? How to refactor?

Problem recognition How to identify/measure technical debt? How to review the system? How to identify op tions?

Problem analysis How to analyze the problem context? How to assess the refactoring candidates? How to compare options?

Decision-making How to plan resource? How to prioritize a refactoring candidate? How to plan refactoring steps?

Decision i mplementation How to allocate resources? How to select a candidate? How to perform the modiﬁcation?

Evaluation How o measure ROI? How to evaluate the effects of refactoring re-

garding softwa re design?

How to evaluate the effects of the refactoring

regarding software behavior?

Process input Software project Resources (time frame, tools, developers

etc.)

Resources (time frame, tools, developers

etc.), refactoring candidates

Process o utput Allocated resources (down) List of candidates (down), Refactored sy-

stem with intended software design (up)

Refactored system with correct behavior

(up)

Information needs Budget, release plan, project context and

state (condensed information)

Rules for candidate identiﬁcation, prioritiza-

tion paradigm (detailed in formation)

Rules for performing refactorings (detailed

information)

(1) Complexity Complex

(2) Structuredness Partly ill-structured, partly well-structured (programmable, see Section 4.2)

(3) Solution space Choice (by having the option to allocate re-

sources or not) Design (by deciding to which

extent ressources shall be allocated)

Design (regarding the identiﬁcation/asses-

sment of candidates)

Choice (by having multiple distinct refacto-

ring options)

(4) Fr a ming Probably mainly perceived as a threat problem, see, e.g., (Tempero et al., 2017).

(5) Interrelatedness to what to refactor? (succeeding) to whether to refactor (preceding)? (prece-

ding) and how to refactor(succeeding)?

to what to refactor? (preceding)

(6) Associated sub-problems Exemplary sub-problems for each decision problem are stated above as phases of decision-making.

(7) Actor type (Project) manager(s) Software architect(s) and developer(s) (in

general: the software design expert)

Software developer(s)

(8) Goals/criteria Multicriteria

(9) Certainty level Decision under uncertainty (Decision under

risk, if probability of increase of technical

debt is measurable or can be estimated)

Decision under uncertainty (Decision under

risk, if p robability of introducing new design

ﬂaws can be measured or estimated)

Decision under uncertainty (Decision under

risk, if chances of refactoring success can

be estimated)

(10) Hierarchy level Management Operational Operational

Second, a decision-making problem can be either

well- or ill-structured. Ill-structured decision-making

problems are usually novel problems for which no

predeﬁned methods are known to handle them and

which often possesses no single, correct solutio n.

Third, the solution space may either consist of a

set of imm utable, predeﬁned alternatives to choose

from, or ma y require the decision ma ker to design the

alternatives within a continuous solution space (Yoon

and H wang, 1995) .

Fourth, depending on the situation and the view

point a dopted by the decision maker, a decision may

either be recognized as a threat of loss or an opportu-

nity to gain an advantage.

Fifth, a decision-making problem ca n appear lar-

gely in dependent o f other decision- making problems

(static), or, as part of a sequence of decisions, can

have depen dencies on other de cisions, as describe d

for dynamic decisions ( A tkins et al., 20 02).

Sixth, the decision-making problem may repre-

sent the originating problem, or may repre sent a meta-

problem, such as how much information to collect for

a decision (Gr¨unig and K¨uhn, 2013).

Seventh, decision-making also heavily depends

on the n umber of stakeholders involved. While

some decision-making p roblems allow decisions to be

made autocratically by one person, in other decision-

making pro blems multiple people contribute to the

decision-making pr ocess, and can thereby inﬂuence

the de c isio n taken.

Eight, in some decision-making problems, the de-

cision maker only needs to focus on a single objective

or goal. However, in practice, a decision-making pro-

blem ofte n r equires to p ursue multip le objectives or

goals, which means that severa l criteria must be con-

sidered at the same time in the decision-making pro-

cess (Yoon and Hwang, 1995).

Last but no t least, decision-making problems can

be distinguishe d depending to the predictiveness of

their outcomes. In d e cisions under certainty, the out-

comes are known and believed to be certa in. For deci-

sions under risk, at least the probability of their occur-

rence is known. In unce rtainty decisions, on the other

hand, there are no ind ic a tions as to whe ther th e se will

occur as predicted .

Moreover, from a business per spective, decision-

making problems can also be classiﬁed by the level

of management activities. According to the fr ame-

work of (Gorry and Morton, 1989), three levels can

be distinguished in this context: operational control,

management control and strategic planning, see (10)

in Tab. 1.

Findings. Based on the characteristics of decision

problems in general (stated in Table 1) and the proce -

dural aspects from Sect. 2.1, we cha racterize in the

following the three selected problem areas in refac-

toring. Table 2 su mmarizes the ﬁndings for the exa-

mined decision pr oblems regarding the identiﬁed sub-

process phases, sub-process in- and output as well as

the problem characteristics.

Deconstructing the Refactoring Process from a Problem-solving and Decision-making Perspective

367

Problem recognition

Problem analysis

Decision-making

Implementation

Evaluation

Monitor software

project

Management level

Operational level

Plan resources

Candidates

Whether (and when) to refactor?

What to refactor (ﬁrst)?

How to refactor?

Allocate resources

Review system for

design problems

(smell candidates)

Select candidates

Identify refactoring

options for

candidate

Compare options, e.g.,

regarding eﬀort and

site eﬀects

Perform actual code

modi

cation

(refactoring steps)

Evaluate eﬀects in

terms of system

behavior

Evaluate eﬀects in

terms of software

design

[available]

[else]

[candidates

identi

ed]

[else]

[true positives

exist]

prioritized

candidates

refactoring options

refactoring option

refactoring steps

modi ed source code

paradigm

assessed

candidates

assessed

candidates

resources

Software project

[feasible]

[refactoring steps too di

cult]

project context

project state

availability of

resources

ressources

refactored system

with correct

behavior

refactored system with

intended sw. design

ROI

[else]

[feasible]

prioritized

candidates

Software project

Software design

& source code

Source code

[unintended eﬀects]

[more candidates]

Refactored system with correct behavior

Refactored system with intended sw. design

ROI

step addressed by refactoring decision support

not inlcuding a refactoring barrier

step including a refactoring barrier

not addressed by refactoring decision support

step addressed by refactoring decision support

including a refactoring barrier

step neither addr. by refactoring decision support

nor including a refactoring barrier

control ow

information feedback

[else]

[ongoing project monitoring]

[else]

[unintended eﬀects or search for more design problems]

[else]

[more candidates]

Resources

[else]

Select option and plan

refactoring steps

Resources

Assess the candidates

(and discard false

positives)

Analyze project

context

[slow development progress

or critical technical debt i.a.]

re ROI

(and controlling)

Prioritize candidates

according paradigm

Figure 2: Proposed refactoring process model as result of the applied analysis. The model integrates the decision-making

sub-processes for primary decision problems in refactoring: whether (and when) t o refactor? (t op), what to refactor (ﬁrst)?

(center), and How to refactor? (bottom). Each sub-process is ordered by key phases (horizontal) and by the organizational

level of decision makers and context (vertical), for details on the model, see Section 3; for details on the allocation of barriers

and support techniques to process steps, see Section 4.

3 A PROCESS MODEL FOR

DECISION-MAKING IN

REFACTORING

Fig. 2 depicts the proposed process model resulting

from deconstructing the refactoring pr ocess and from

analyzing th e characteristics of the selected de c isio n

problems (see Table 2). It represents an integrated

perspective on three interrelated sub-processes, each

focusing on one decision problem. Each decision-

making process is structured by the ﬁve key ph ases

of problem recognition, problem analysis, de c isio n-

making, (decision) implementation, and (decision)

evaluation (as identiﬁed in Section 2.1) and sp eciﬁed

in terms of a UML2 activity diagram (O bject Ma na-

gement Group, 2015).

Organizational Levels and Communication Flows.

The sub-processes are located on different organi-

zational levels (i.e., management, operational) and

focus on different aspects of the software project

(i.e., project man a gement, software de sign/architec-

ture, and source code; as depicted le ft-hand of the

sub-processes). The inte rrelations between the levels

are expressed via different kinds of ﬂows:

• The control ﬂow from management to o rganizati-

onal level is represented by inputs for the lower le-

vels in terms of sourc e s (e.g., time frame, people,

tools; top-down) and (refactoring) candidates.

• Vice versa, the information feedback ﬂow is repre-

sented by reporting the results of the evaluation to

the speciﬁc higher level (bottom-up).

This communication between the three levels cor re-

sponds to the (aggregated) information needs of e a ch

level described by (Gorry and Morton, 1989).

Refactoring Starting Points. Indic a te d by the

three start nodes in Fig. 2, the process can be started

at each of the three levels, be it on the Management

level or at both Operational levels.

• Following a top-down approa ch, the process may

be triggered by a management decision e.g ., dri-

ven by noticing a slow development progress

(whether to refactor?).

• Through allocation of corresponding resour-

ces, the manager triggers the underlying sub-

process(es). The seco nd sub-process, located at

the center of Fig. 2, may also be started directly

by a software architect or a developer who detects

design ﬂaws while reviewing th e system’s soft-

ICSOFT 2018 - 13th International Conference on Software Technologies

368

ware desig n (inside-out, what to refactor (ﬁrst)?;

provided that the nec essary resources have been

former ly alloca ted).

• Also th e bottom sub-process how to refa ctor? can

be started based on a previously collected list of

candidates. This way a software developer who

is actually developing can process a list of refac-

toring candidates that has been collected befor e,

e.g., via an issue tracker such as Jira.

This ﬂexibility in triggering the refactoring process

correspo nds to (Fowler, 2009) who states that causes

and starting p oints for refacto ring source code can be

very diverse. Moreover, all sub-proce sses are cyclic

and can repeat, e.g. for multiple candidates or in case

the evaluations indicate an error. From a practical per-

spective, these steps may no t all be performe d con s-

ciously. For example, they may be skipped intenti-

onally or may be done intuitively, see, e.g., (Kahne-

man, 2011).

An overview of existing support techniques for

software developers to address the process steps is i.a.

given in the next section.

4 BARRIERS AND ENABLERS IN

THE PROCESS MODEL

To illustrate the app licability of our process model in

Fig. 2 for supporting software practitioners in under-

standing the refactoring process, we allocate refac-

toring barriers and refactoring support techniques to

correspo nding affected or addressed process steps.

4.1 Refactoring Barriers

(Te mpero et al., 2017) identiﬁed seven categories of

refactoring barrie rs which can be alloc a te d to process

steps as follows.

• missing resources (such as the time frame, group

size, or tools and technologies); a s result of step

) in Fig. 2 with effects on all steps in both un -

derlying sub-processes.

• the risk of in troducing an error; relevant at multi-

ple levels, especially in step

 in Fig. 2 and for

evaluating whether an error has been introduced

(see step

).

• the difﬁculty to perform the refactoring which is

relevant for step

in Fig. 2 as well as the prece-

ding steps which focus on identifying (step

),

comparing (step

), and selecting refactoring

option (step

).

• unclear ROI, on ma nagement levels in steps



and

 in Fig. 2, but also on operational levels,

e.g. step

.

• technical issues, e.g., as a lack of technologies

or tools (relevant in many steps, e.g., step

 in

Fig. 2).

• constraints set by the management which are

again result of steps

 and

 via attributed re-

sources; but also in terms of corresponding cont-

rol and information ﬂows.

• lack of appropriate too ls (in multip le steps, see be-

low, can also be partially seen as a result of step

).

This allocation shows that some barriers cross the

steps and are loc a lized on multiple organization al le-

vels which makes them even harder to handle.

4.2 Refactoring Support

In recen t year s, several techniques and tools have

been proposed for decision-support in refactoring.

For an overview, see, e.g., (Simmonds and Mens,

2002; Mens and Tourw´e, 2004; Mealy and Strooper,

2006; Fontana et al., 2012; Fontana et al., 2015; Fer-

nandes et al., 2016) . For the purposes of this paper,

the tools and techniques are roughly divided into the

following categories. For each gro up, the addressed

process steps in Fig. 2 are stated.

• Smell-detection & refactoring recommendation

tools (such as JDeodorant (Tsantalis, 2017) or

Decor (Ptidej, 2017)) support in (sem i-) au tomati-

cally identifying smell and refactoring candidate s

via symptoms by ana lyzing the source code. For

this purp ose, rules are used which apply metrics

and thr esholds. Smell detectors address step



in Fig. 2, refactoring recomme ndation tools also

,

 and

).

• Code-Quality and D esign-Critique Tools (such as

JArchitect (Co derGears, 2017) or NDepend (ZEN

PROGRAM, 2017)) assist so ftware engineers in

reviewin g the source code or in investigating a sy-

stem’s design and a rchitecture. Mo st o f them pr o-

vide several visualization tec hniques (e.g. matri-

ces, graphs) fo r reﬂecting static dependencies be-

tween system units (e.g., for assessing the as-is

software design, addressing step

).

• Refactoring Tools (such as I DEs like RCP Eclipse

or ( Ro berts et al., 199 7)) provide the automa tic or

guided/interactive execution of refactoring step s

(addressing step

 in Fig. 2).

• Technical Debt Management and Analysis Tools

(such as SonarQube (Campbe ll a nd Papapetrou ,

2013), Sonargraph (hello2morrow, 2017)) mea-

sure and quantif y a system’s technical d ebt in

terms of a concrete score, mostly in terms of

person-hours necessary to ﬁx the d e bt. For this,

they apply metr ic s and thresho lds based on sta-

Deconstructing the Refactoring Process from a Problem-solving and Decision-making Perspective

369

tic analysis techniques. (addre ssing steps

 and

, and partially

 in Fig. 2 (r egar ding the esti-

mation of person-hours needed).

• Automated Regression Testing Fra meworks

(such as XJunit test frameworks) help to ensure

that the system still behaves as intended, i.e. that

no errors have been introduced by the code modi-

ﬁcations (addressing step

).

• Documented Knowledge on Refactoring Rules

Multiple catalogs exist which document rules

for performing re facto ring-related tasks, such as

for symptom-based candidate identiﬁcation or

for performing refactoring steps. Some of this

decision-making knowledge has already bee n im-

plemented into corresponding support systems

(see above). In particular, there is documented

knowledge for instance available for:

– detecting smell c andidates via sympto ms (see

e.g. ( Fowler, 2009; Suryanarayana et al., 2014),

addressing step

 in Fig. 2),

– identifying smell false positives, see, e.g., (Fon-

tana et al., 2016) (addressing

),

– paradigms for prioritizing can didates, see, e.g.,

(Ribeiro et al., 2016) (ad dressing step

),

– comparing and performing refactoring steps

(also see e.g. (Fowler, 2009; Suryanarayana

et al., 2014 ), addressing step

).

Some tools also combine certain functionalities, such

as for instance SonarGraph (hello2morrow, 2017),

JArchitect (CoderGears, 2017) or NDepend (ZEN

PROGRAM, 2017).

Table 3 shows the process steps of Fig. 2 with

exemplary barriers (included in step) and support

techniques (addressing the step). This confrontation

illustrates on the one hand that multiple steps ar e ad-

dressed by support techniques which have not been

identiﬁed as barriers ( e .g.,

,

). On the oth er

hand it becomes evident that some steps are no t co-

vered sufﬁciently by co rresponding refactoring sup -

port techniq ues (see, e.g.,

). In the following the

barriers and sup port te c hniques are described in more

detail.

5 DISCUSSION

Motivated by the aim to better understand the difﬁ-

culties in the refactorin g process, we applied in this

paper a theoretical perspective on decision p roblems

in the refactoring process. For this reason, we used

concepts of decision-making for deconstructing the

refactoring process. The result of this an alysis is a

process model for decision-making in software refac-

toring (see Fig. 2) w hich comprises the sub-processes

Table 3: Exemplary allocation of barriers identiﬁed by

(Tempero et al., 2017) and of several refactoring decision-

support techniques to steps in the process model in Fig.2.

No Step Barriers Support

A1 Monitor software

project

unclear ROI TD management and ana-

lysis tools

A2 Analyze project con-

text

– –

A3 Plan resources missing resour-

ces, management

dependencies

(TD management and

analysis tools)

A4 Allocate resources – –

A5 Measure ROI unclear ROI TD management and ana-

lysis tools

B1 Review system – smell-detection tools, do-

cumented knowledge on

smell detection

B2 Assess candidates lack of tool sup-

port

documented knowledge

on smell false positives

B3 Prioritize candidates lack of tool sup-

port

documented knowledge

on prioritization para-

digms

B4 Select candidates – –

B5 Evaluate effects in

(software design)

– design-critique tools

C1 Identify refacto-

ring options for

candidate

– refactoring recommenda-

tion tools

C2 Compare options – refactoring recommenda-

tion tools

C3 Select option and

plan refactoring

steps

difﬁculty of refac-

toring, lack of tool

support

refactoring recommenda-

tion tools

C4 Perform code modi-

ﬁcation

difﬁculty of re-

factoring, risk

of introducing

unintended ef-

fects, lack of tool

support

refactoring tools

C5 Evaluate effects (sy-

stem behavior)

risk of i n trodu-

cing unintended

effects

automated regression tes-

ting frameworks

of the three interrela te d decision problems expressed

by the questions whether, what, and how to refactor?

Due to many sub - and meta-problems which are part

of every cognitive pr ocess, not all pro bable decision

problems in refactoring could have been covered. So,

for each sub- or meta-problem, probably a sep arate

decision-making pr ocess could be speciﬁed.

So far only very few p rocess models f or refacto-

ring are available. To the best of our knowledge, the

framework proposed by (Lepp¨anen et al., 2015) repre-

sents the only process model for refactoring that ex-

plicitly includes decision problems. It is b ased on an

empirical study with three software companies (and

expressed in terms of a state chart, see Section 2.1).

Or approach compleme nts the state-of-the-art of re-

factoring research by providing a th eory-based pro-

cess description in terms of a process model that in-

tegrates three key decision problems and correspon-

ding decision-making processes for refactoring. Ac-

cording to applied concepts of decision-m aking re-

search, the activities are structu red into certain pha-

ses of decision-making and alo ng hierarchical levels

with corresponding communication ﬂows. Thus, the

process model requires an empirical evaluation which

will be approached in the next step.

For Section 4, only barriers were presented that

ICSOFT 2018 - 13th International Conference on Software Technologies

370

have been identiﬁed by (Tempero et al., 2017). In

addition, we here only in c luded tools and techni-

ques from the software engineering domain. Probably

more related tools and techniques from other dom-

ains are available such as from project management,

resources management, management information sy-

stems or decision support systems.

6 CONCLUSION

In this paper, we applied a deductive approach for

deconstructing the refactoring process into distin-

guished phases, decision problems and correspon-

ding decision-making sub-processes. As a result, we

have developed a process model including decision-

making steps for three selec te d major de cision-

problems in the refactoring process as well as re-

ﬂecting the characteristics of the decision-making

sub-processes o n different o rganizational levels.

We have also shown by example that our model

allows for allocating refactoring enablers (i.e. refac-

toring tec hniques and tools) and barriers to process

steps, w hich may help software practitioners in un-

derstandin g the difﬁculties in the refactoring process

and the relationship between enablers and barriers.

For future work, we plan a survey with software

developers and managers to evaluate and reﬁn e the

proposed process model. Within this, we also seek

to investigate the role o f su pport tec hniques and bar-

riers for eac h step. Furthermore, we intend to inves-

tigate how the dec ision-support techniques in refac-

toring and othe r related domains, such as project and

resource management, can be combined, especially

in order to support information and control ﬂows be-

tween d ifferent organizational levels (also in terms of

an integrating project cockpit).

REFERENCES

Asemi, A., Safari, A ., and Asemi Zavareh, A. (2011). The

Role of Management Information System (MIS) and

Decision Support System (DSS) for Managers Deci-

sion Making Process. I nternational Journal of Busi-

ness and Management, 6(7):164.

Atkins, P. W. B., Wood, R. E. , and Rutgers, P. J. (2002).

The Effects of Feedback Format on Dynamic Deci-

sion Making. Organizational Behavior and Human

Decision Processes, 88(2):587–604.

Beach, L. R. and Mitchell, T. R. (1978). A Contingency

Model for the Selection of Decision Strategies. The

Academy of Management Review, 3(3):439–449.

Boehm, B. W. et al. (1981). Software engineering eco-

nomics, volume 197. Prentice-hall Englewood Cliffs

(NJ).

Campbell, G. and Papapetrou, P. P. (2013). SonarQube in

action. Manning Publications Co.

CoderGears (2017). JArchitect. [last access: June 8, 2018].

Courtney, J. F. (2001). Decision making and knowledge

management in inquiring organizations: toward a new

decision-making paradigm for DSS. Decision Support

Systems, 31(1):17–38.

Evans, J. S. B., Newstead, S. E., and Byrne, R. M. ( 1993).

Human reasoning: The psychology of deduction. Psy-

chology Pr ess.

Fernandes, E., Oliveira, J., Vale, G., Paiva, T., and Figuei-

redo, E . (2016). A review-based comparative study

of bad smell detection tools. In P roceedings of the

20th International Conference on Evaluation and As-

sessment in Software Engineering, page 18. ACM.

Fern´andez-S´anchez, C., Garbajosa, J., and Yag¨ue, A.

(2015). A framework to aid i n decision making for

technical debt management. In Managing Technical

Debt (MTD), 2015 IEEE 7th International Workshop

on, pages 69–76. IEEE.

Fontana, F. A., Braione, P., and Zanoni, M. (2012). Auto-

matic detection of bad smells in code: An experimen-

tal assessment. J. Object Technology, 11(2):5–1.

Fontana, F. A., Dietrich, J., Walter, B., Yamashita, A., and

Zanoni, M. (2016). Antipattern and code smell false

positives: Preliminary conceptualization and classiﬁ-

cation. In Software Analysis, Evolution, and Reengi-

neering (SANER), 2016 IEEE 23rd International Con-

ference on, volume 1, pages 609–613. IEEE.

Fontana, F. A., Mangiacavalli, M., Pochiero, D., and Za-

noni, M. (2015). On experimenting refactoring tools

to remove code smells. In Scientiﬁc Workshop Pro-

ceedings of the XP2015, page 7. ACM.

Fowler, M. (2009). Refactoring: improving the design of

existing code. Pearson Education India.

Gorry, G. A. and Morton, M. S. (1989). A framework

for management information systems. Sloan Mana-

gement Review, 30(3):49–61.

Gr¨unig, R. and K¨uhn, R. (2013). Successful Decision-

Making. Springer Berlin Heidelberg, B erlin, Heidel-

berg.

hello2morrow (2017). Sonargraph. [last access: June 8,

2018].

Huber, G. P. (1980). Organizational science contributions

to the design of decision support systems. Decision

support systems: issues and challenges, pages 237–

275.

Kahneman, D. (2011). Thinking, fast and slow. Macmillan.

Kitchenham, B. A., Travassos, G. H., Von Mayrhauser, A.,

Niessink, F., Schneidewind, N. F., Singer, J., Takada,

S., Vehvilainen, R., and Yang, H. (1999). Towards an

ontology of software maintenance. Journal of Soft-

ware Maintenance, 11(6):365–389.

Kruchten, P., Nord, R. L., and Ozkaya, I . (2012). Techni-

cal debt: From metaphor to theory and practice. Ieee

software, 29(6):18–21.

Lepp¨anen, M., L ahtinen, S., Kuusinen, K., M¨akinen, S.,

M¨annist¨o, T., Itkonen, J., Yli-Huumo, J., and Lehto-

nen, T. (2015). Decision-making framework for re-

factoring. In Managing Technical Debt ( MTD), 2015

Deconstructing the Refactoring Process from a Problem-solving and Decision-making Perspective

371

IEEE 7th International Workshop on, pages 61–68.

IEEE.

Liu, P. and Li, Z. (2012). Task complexity: A review and

conceptualization framework. International Journal

of Industrial Ergonomics, 42(6):553–568.

Mealy, E. and Strooper, P. (2006). Evaluating software re-

factoring tool support. In Software Engineering Con-

ference, 2006. Australian, pages 10–pp. IEEE.

Mens, T. and Tourw´e, T. (2004). A survey of software refac-

toring. IEEE Transactions on software engineering,

30(2):126–139.

Mora, M., Forgionne, G., Cervantes, F., Garrido, L., Gupta,

J. N., and Gelman, O. (2005). Toward a Compre-

hensive Framework for t he Design and E valuation

of Intelli gent Decision-making Support Systems (i-

DMSS). Journal of Decision Systems, 14(3):321–344.

Object Management Group (2015). Uniﬁed Modeling Lan-

guage (UML), Superstructure, Version 2.5.0. [last

access: June 8, 2018].

Osborne, W. M. (1987). Building and sustaining software

maintainability. In Proceedings of the International

Conference on Software Maintenance, pages 13–23.

Pomerol, J.-C. and Adam, F. (2004). Practical decision

making–from the legacy of herbert simon to decision

support systems. In Actes de la Conf´erence Internati-

onale IFIP TC8/WG8, volume 3.

Ptidej (2017). DECOR. [last access: June 8, 2018].

Ribeiro, L. F., de Freitas Farias, M. A., Mendonc¸a, M. G.,

and S p´ınola, R. O. (2016). Decision criteria for the

payment of technical debt in software projects: A sys-

tematic mapping study. In ICEIS (1), pages 572–579.

Roberts, D., Brant, J., and Johnson, R . (1997). A refactoring

tool f or smalltal k. Urbana, 51:61801.

Simmonds, J. and Mens, T. (2002). A comparison of soft-

ware refactoring tools. Programming Technology Lab.

Simon, H. (1997). The poliheuristic theory of foreign policy

decision-making. Decision making on war and peace:

The cognitive-rational debate, 1:81.

Simon, H. A . (1977). The New Science of Management De-

cision. Prentice Hall PTR, Englewood Cliffs, NJ.

Suryanarayana, G., Samarthyam, G., and Sharma, T.

(2014). Refactoring for software design smells: Ma-

naging technical debt. Morgan Kaufmann.

Te’eni, D. and Ginzberg, M. J. (1991). Human-computer

decision systems: The multiple roles of dss. European

journal of operational research, 50(2):127–139.

Tempero, E., Gorschek, T., and Angelis, L. (2017). Bar-

riers to refactoring. Communications of the ACM,

60(10):54–61.

Tsantalis, N. (2017). JDeodorant. [last access: June 8,

2018].

Yoon, K. P. and Hwang, C.-L. (1995). Multiple Attribute

Decision Making: An Introduction. Sage Publications,

Incorporated, Thousand Oaks, CA, new. edition.

ZEN PROGRAM (2017). NDepend. [l ast access: June 8,

2018].

ICSOFT 2018 - 13th International Conference on Software Technologies

372