1

A Survey of Software Refactoring Tom Mens, Tom Tourwé IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. XX, NO. Y, MONTH 2004

Presented by: Kishen Maloor

2

Overview

Restructuring, refactoring and associated activities

Behavior preservation – Assertions, Formalisms…

Types of software artifacts Tool support Qualities of refactoring tools Process support Conclusion

3

Restructuring and refactoring

Restructuring is a transformation from one form of presentation to another

Refactoring is the object-oriented variant of restructuring

The subjects external behavior is preserved

Idea is to make existing code more extensible

4

Refactoring activities

Identify where the software should be refactored Determine which refactoring(s) should be

applied to the identified places Guarantee that the applied refactoring preserves

behaviour Apply the refactoring Assess the effect of the refactoring on quality

characteristics of the software Maintain the consistency between the refactored

program code and other software artifacts

5

Behavior Preservation

A refactoring is a parameterized behavior-preserving program transformation

Approaches to behavior preservation may perform checks either statically or dynamically

OriginalSystem

RefactoredSystem

1+12-35+34*6

Input

2…

2…

=Source: spic.kaist.ac.kr/~selab/html/Study/Lab%20Seminar/A%20Survey%20of%20Software%20Refactoring.ppt

6

Behavior Preservation

Static: - Preconditions, graph transformations, (access, update and call) preservations, type checking…

Dynamic: - Take dynamic information into account - Checks more aspects of the program behavior - WSL comes along with a tool that preserves dynamic behavior of programs [Bennett, 1995]

7

Behavior Preservation

Ideally, the behavior preservation of refactorings should be proven formally.

But, proving semantic correctness is an undecidable problem [Gupta, 1996]

Therefore, a more conservative, engineering approach is needed

We could do rigorous testing of the codeWe could use Assertions and formalisms

to check for behavior preservation

8

Assertions

Identify a set of invariants in the program that preserve its behavior for refactorings

Create a set of conditions which guarantee that these invariants hold

Pre- and postconditions are therefore formulated and checked before and after refactorings are applied

Are a lightweight and automatic means of verification

9

Example of use of assertions

B

C D FN

A B

C D

F

A

Before refactoring After refactoring

Consider the refactoring:

Add Class (new name, package, superclasses,

subclasses)Source: https://www.iam.unibe.ch/scg/svn_repos/Talks/OORP/Store/Refactoring-Lecture.ppt

10

Example of use of assertions

Preconditions no class or global variable exists with new name in

the same scope subclasses are all subclasses of all superclasses

Postconditions new class is added into the hierarchy with

superclasses as superclasses and subclasses as subclasses

new class has name new name subclasses inherit from new class and not anymore

from superclasses Invariant: Classes A, B & F are defined before and

after the refactoring

11

Problems with assertions

Opdyke proposed a set of seven invariants to preserve behavior for refactorings [Opdyke, 1992]

Ex: Distinct class, Type safe assignments, Compatible signatures in member function definition, Inherited member variables not defined, Distinct member names, Distinct class names etc.

A more complex language may need more preconditions

Opdyke’s invariants were observed to be insufficient for C++ [Tokuda, 2001]

12

Problems with assertions

Static checking of preconditions can sometimes be very expensive

Preconditions do not consider the size or structure of programs

[Roberts, 1999] suggests a way to augment refactorings with postconditions

13

Formalisms

Graph Transformations- Programs represented as graphs- Refactorings correspond to graph production rules- Application of refactorings correspond to a graph transformation- Assertions specified as application pre- and postconditions

Provides formal support for refactoring

14

Formalisms

[Mens, 2002] uses graph rewriting to show that certain kinds of program behavior are preserved using static analysis

Graph transformations can be used to reason about dependence between refactorings Ex. Move method and Rename method

Analysis of sequential dependencies between refactorings can be useful

15

Other useful techniques

Program SlicingFormal concept analysisSoftware metricsSoftware visualizationDynamic program analysis

16

Types of software artifacts

Program source code- Supported by a variety of programming paradigms (Imperative, OO, Functional, AOP)- Formal support (WSL)

Non-OO languages are as such more difficult to restructure

More complex the language, harder it is to automate the refactoring process

17

Types of software artifacts

Refactoring of designs, a recent research trend

Independent of the underlying programming language

Refactoring of UML diagrams [Boger, 2002]

Refactoring pre- and post-conditions can be expressed using OCL

18

Types of software artifacts

Design patterns describe program structure at a higher level

Refactorings are used to introduce new design pattern instances into software

19

Types of software artifacts

Restructuring software architectures- based on graphical representation of the architecture [Philipps, 1997] - Behavior specified by casual relationship between two components is preserved

Software requirements- [Russo, 1998] restructure natural language requirements

20

Tool support

Semiautomatic approach

MoveMethod

AddClass

Refactoring

? ?

?

Refactored System

Op1 Op2 Opn

Refactoringoperations

Source: spic.kaist.ac.kr/~selab/html/Study/Lab%20Seminar/A%20Survey%20of%20Software%20Refactoring.ppt

21

Tool support

In the semiautomatic approach, thedeveloper:- Identifies the part of the software to be refactored and selects an appropriate refactoring to apply

Application of the refactoring is automaticFully automated refactoring has been

demonstrated to be feasible [Moore, 1996]

22

Tool support

Fully automatic approach: - Refactorings can be easily undone - Can make the code difficult to understand

Semiautomatic approach: - For large software, needs lots of human interaction; time consuming! - More useful-most knowledge required to perform refactoring cannot be extracted from software

23

Qualities of refactoring tools

Reliability- Is it possible to check if the provided refactorings are truly behavior preserving?

Tools check preconditions before applying them and perform tests afterwards

Tools provide an undo mechanism to make undesired changes undone

Coverage specifies the number of refactoring activities supported by the tool

24

Qualities of refactoring tools

Configurability- Modifying bad smell specifications- Changing the links between bad smells and refactorings

[Leitao, 2002] specifies a pattern language to express refactorings

[Munoz, 2003] provides configurable threshold values to specify conditions for a bad smell

25

Qualities of refactoring tools

Scalability- Combine frequently used primitive refactorings into composite refactorings - Better capture intent of software change - Performance gain - Weaken behavior preservation requirements for primitive refactorings- Support for cascaded refactorings [Tourwe, 2003]

26

Qualities of refactoring tools

Language Independence- Applicability to different languages- Provide hooks to add language specific behavior

[Lammel, 2002] proposes generic program refactoring – a language parametric framework, can be used with Java, XML…

[Mens, 2002] Meta-model based approachUse of an intermediate formal language

[Bennett, 1995]

27

Process Support

An important activity in the software development process

Software Reengineering- To restructure legacy software to implement a new solution- To assist a MDA tool

28

Process Support

Agile Software Development (XP)- Develops and refactor software in small

iterationsFramework-Based or Product Line

Development

29

Conclusion

Provided an overview of refactoring; spoke about the different refactoring activities, prevalent problems and open issues, tool support for refactoring

Spoke about how refactoring fits into the software engineering process

Cited several relevant publications