A Survey of Software Refactoring Tom Mens Tom

  • Slides: 29
Download presentation
A Survey of Software Refactoring Tom Mens, Tom Tourwé IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

A Survey of Software Refactoring Tom Mens, Tom Tourwé IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. XX, NO. Y, MONTH 2004 Presented by: Kishen Maloor 1

Overview l l l l Restructuring, refactoring and associated activities Behavior preservation – Assertions,

Overview l l l l Restructuring, refactoring and associated activities Behavior preservation – Assertions, Formalisms… Types of software artifacts Tool support Qualities of refactoring tools Process support Conclusion 2

Restructuring and refactoring l Restructuring is a transformation from one form of presentation to

Restructuring and refactoring l Restructuring is a transformation from one form of presentation to another l Refactoring is the object-oriented variant of restructuring l The subjects external behavior is preserved l Idea is to make existing code more extensible 3

Refactoring activities l l l Identify where the software should be refactored Determine which

Refactoring activities l l l 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 4

Behavior Preservation refactoring is a parameterized behaviorpreserving program transformation Input 1+1 2 -3 5+3

Behavior Preservation refactoring is a parameterized behaviorpreserving program transformation Input 1+1 2 -3 5+3 4*6 Original System 2 … Refactored System = l. A 2 … l Approaches to behavior preservation may perform checks either statically or dynamically Source: spic. kaist. ac. kr/~selab/html/Study/Lab%20 Seminar/A%20 Survey%20 of%20 Software%20 Refactoring. ppt 5

Behavior Preservation l Static: - Preconditions, graph transformations, (access, update and call) preservations, type

Behavior Preservation l Static: - Preconditions, graph transformations, (access, update and call) preservations, type checking… l 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] 6

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

Behavior Preservation l Ideally, the behavior preservation of refactorings should be proven formally. l But, proving semantic correctness is an undecidable problem [Gupta, 1996] l Therefore, a more conservative, engineering approach is needed l We could do rigorous testing of the code l We could use Assertions and formalisms to check for behavior preservation 7

Assertions l Identify a set of invariants in the program that preserve its behavior

Assertions l Identify a set of invariants in the program that preserve its behavior for refactorings l Create a set of conditions which guarantee that these invariants hold l Pre- and postconditions are therefore formulated and checked before and after refactorings are applied l Are a lightweight and automatic means of verification 8

Example of use of assertions Before refactoring After refactoring Consider the refactoring: Add Class

Example of use of assertions 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 9

Example of use of assertions l Preconditions no class or global variable exists with

Example of use of assertions l Preconditions no class or global variable exists with new name in the same scope ¡ subclasses are all subclasses of all superclasses ¡ l 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 l Invariant: Classes A, B & F are defined before and after the refactoring ¡ 10

Problems with assertions Opdyke proposed a set of seven invariants to preserve behavior for

Problems with assertions Opdyke proposed a set of seven invariants to preserve behavior for refactorings [Opdyke, 1992] l Ex: Distinct class, Type safe assignments, l 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 l Opdyke’s invariants were observed to be insufficient for C++ [Tokuda, 2001] l 11

Problems with assertions l Static checking of preconditions can sometimes be very expensive l

Problems with assertions l Static checking of preconditions can sometimes be very expensive l Preconditions do not consider the size or structure of programs l [Roberts, 1999] suggests a way to augment refactorings with postconditions 12

Formalisms l Graph Transformations - Programs represented as graphs - Refactorings correspond to graph

Formalisms l Graph Transformations - Programs represented as graphs - Refactorings correspond to graph production rules - Application of refactorings correspond to a graph transformation - Assertions specified as application preand postconditions l Provides formal support for refactoring 13

Formalisms l [Mens, 2002] uses graph rewriting to show that certain kinds of program

Formalisms l [Mens, 2002] uses graph rewriting to show that certain kinds of program behavior are preserved using static analysis l Graph transformations can be used to reason about dependence between refactorings Ex. Move method and Rename method l Analysis of sequential dependencies between refactorings can be useful 14

Other useful techniques l Program Slicing l Formal concept analysis l Software metrics l

Other useful techniques l Program Slicing l Formal concept analysis l Software metrics l Software visualization l Dynamic program analysis 15

Types of software artifacts l Program source code - Supported by a variety of

Types of software artifacts l Program source code - Supported by a variety of programming paradigms (Imperative, OO, Functional, AOP) - Formal support (WSL) l Non-OO languages are as such more difficult to restructure l More complex the language, harder it is to automate the refactoring process 16

Types of software artifacts l Refactoring of designs, a recent research trend l Independent

Types of software artifacts l Refactoring of designs, a recent research trend l Independent of the underlying programming language l Refactoring of UML diagrams [Boger, 2002] l Refactoring pre- and post-conditions can be expressed using OCL 17

Types of software artifacts l Design patterns describe program structure at a higher level

Types of software artifacts l Design patterns describe program structure at a higher level l Refactorings are used to introduce new design pattern instances into software 18

Types of software artifacts l Restructuring software architectures - based on graphical representation of

Types of software artifacts l Restructuring software architectures - based on graphical representation of the architecture [Philipps, 1997] - Behavior specified by casual relationship between two components is preserved l Software requirements - [Russo, 1998] restructure natural language requirements 19

Tool support l Semiautomatic approach Refactoring Move Method Add Class Op 1 Op 2

Tool support l Semiautomatic approach Refactoring Move Method Add Class Op 1 Op 2 ? ? Opn Refactored System ? Refactoring operations Source: spic. kaist. ac. kr/~selab/html/Study/Lab%20 Seminar/A%20 Survey%20 of%20 Software%20 Refactoring. ppt 20

Tool support l In the semiautomatic approach, the developer: - Identifies the part of

Tool support l In the semiautomatic approach, the developer: - Identifies the part of the software to be refactored and selects an appropriate refactoring to apply l Application of the refactoring is automatic l Fully automated refactoring has been demonstrated to be feasible [Moore, 1996] 21

Tool support l Fully automatic approach: - Refactorings can be easily undone - Can

Tool support l Fully automatic approach: - Refactorings can be easily undone - Can make the code difficult to understand l 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 22

Qualities of refactoring tools l Reliability - Is it possible to check if the

Qualities of refactoring tools l Reliability - Is it possible to check if the provided refactorings are truly behavior preserving? l Tools check preconditions before applying them and perform tests afterwards l Tools provide an undo mechanism to make undesired changes undone l Coverage specifies the number of refactoring activities supported by the tool 23

Qualities of refactoring tools l Configurability - Modifying bad smell specifications - Changing the

Qualities of refactoring tools l Configurability - Modifying bad smell specifications - Changing the links between bad smells and refactorings [Leitao, 2002] specifies a pattern language to express refactorings l [Munoz, 2003] provides configurable threshold values to specify conditions for a bad smell l 24

Qualities of refactoring tools l Scalability - Combine frequently used primitive refactorings into composite

Qualities of refactoring tools l 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] 25

Qualities of refactoring tools l Language Independence - Applicability to different languages - Provide

Qualities of refactoring tools l Language Independence - Applicability to different languages - Provide hooks to add language specific behavior l [Lammel, 2002] proposes generic program refactoring – a language parametric framework, can be used with Java, XML… l [Mens, 2002] Meta-model based approach l Use of an intermediate formal language [Bennett, 1995] 26

Process Support l An important activity in the software development process l Software Reengineering

Process Support l An important activity in the software development process l Software Reengineering - To restructure legacy software to implement a new solution - To assist a MDA tool 27

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

Process Support l Agile Software Development (XP) - Develops and refactor software in small iterations l Framework-Based or Product Line Development 28

Conclusion Provided an overview of refactoring; spoke about the different refactoring activities, prevalent problems

Conclusion Provided an overview of refactoring; spoke about the different refactoring activities, prevalent problems and open issues, tool support for refactoring l Spoke about how refactoring fits into the software engineering process l Cited several relevant publications l 29