Changing Programs Correctly: Refactoring with Specifications

Abstract

Abstract. Refactorings change the internal structure of code without changing its external behavior. For non-trivial refactorings, the preservation of external behavior depends on semantic properties of the program that are difficult to check automatically before the refactoring is applied. Therefore, existing refactoring tools either do not support non-trivial refactorings at all or force programmers to rely on (typically incomplete) test suites to check their refactorings. The technique presented in the paper allows one to show the preservation of external behavior even for complex refactorings. For a given refactoring, we prove once and for all that the refactoring is an equivalence transformation, provided that the refactored program satisfies certain semantic correctness conditions. These conditions can be added automatically as assertions to the refactored program and checked at runtime or verified statically. Our technique allows tools to apply even complex refactorings safely, and refactorings automatically improve program documentation by generating assertions.

An abstract interpretation framework for refactoring with application to extract methods with contracts

“…Various formalizations of refactoring have been proposed in the concrete such as [3,25,31]. Refactoring can also be formalized as a special case of semantic program transformation [15].…”

Mechanical verification of refactorings

“…• properties that can be checked statically (they call them "a priori checks" in Bannwart &Müller (2006), and"preconditions" in Bannwart (2006)) • those that can be checked dynamically (called "a posteriori checks" in Bannwart & Müller (2006), and confusingly called "postconditions" in Bannwart (2006)) 3. The refactoring is proved to be behaviour-preserving using the above conditions.…”

“…Only the correctness proof of "Rename a Method" is presented in detail in Bannwart (2006); it would have been useful to see detailed accounts for other refactorings to appreciate the tractability of the method. Bannwart & Müller (2006) study the refactoring "Move Field". This refactoring moves a field declared in one class (let us denote it by S) to a different class (T) and modifying all accesses to that field to reflect this change.…”

“…This refactoring moves a field declared in one class (let us denote it by S) to a different class (T) and modifying all accesses to that field to reflect this change. As specified in Bannwart & Müller (2006), the refactoring works by (i) moving the field, (ii) redirecting access to this field via another field (let us denote it by target) in S that points to T, and (iii) updating statements containing references to the moved field and making them point to the new address (i.e. via target in S).…”

Refactoring Object-Oriented Specifications with Data and Processes

“…While in particular the latter approach is close to ours, both languages are state based formalisms only and do not include dynamic aspects, like CSP-OZ does. A different approach to correctness of refactorings is taken by Bannwart and Müller [BM06]. They show that particular pre-and post-conditions can be derived from a refactoring and used to ensure correctness by inserting them as assertions into programs.…”