Thesis: future work

diff --git a/thesis/master-thesis-erlenkr.tex b/thesis/master-thesis-erlenkr.tex
index 2e87aca10c2a114acbc854f0028a21aaf70a3ce1..abeff44b2186c2d3e7d5bef9a742bd328d7c0d4f 100644 (file)
--- a/thesis/master-thesis-erlenkr.tex
+++ b/thesis/master-thesis-erlenkr.tex
@@ -1480,27 +1480,8 @@ still use it to refactor other code.
 \section{Related work}\label{sec:relatedWork}
 Here we present some work related to automated composition of refactorings.
 
-\subsection{Refactoring safety}\label{sec:saferRefactoring}
-This section presents a couple of approaches to improving the safety of 
-performing refactorings. In these approaches, the problems that are addressed 
-are not compilation problems, but behavior-altering problems that are not easily 
-discovered during static analysis of source code. An example of such a problem 
-is presented in \myref{sec:correctness}.
-
-\subsubsection{Project ``Safer Refactorings''}
-\tit{Safer Refactorings}\citing{stolzSaferRefactorings} is a proposal for a 
-master's thesis. The proposer is my supervisor, Volker Stolz from the University 
-of Oslo.
-
-The proposed solution for making refactorings safer, is to insert assertions 
-into source code when refactoring it. For the example in 
-\myref{lst:correctnessExtractAndMoveResult}, which is the result of a 
-refactoring, it is suggested that we insert an assert statement between lines 9 
-and 10. In this example, the assert statement
-would be \mint{java}|assert c.x == this;| which would discover the aliasing 
-problems of this example.
-
-\subsubsection{``Making Program Refactoring Safer''}
+\subsection{``Making Program Refactoring 
+Safer''}\label{sec:saferRefactoringTests}
 This is the name of an article\citing{soaresSafer2010} about providing a way to 
 improve safety during refactoring. Soares et al. approaches the problem of 
 preserving behavior during refactoring by analyzing a transformation and then 
@@ -5133,14 +5114,26 @@ question: Is it feasible to complete such an analysis? Can this feasibility be
 proven, or disproved?
 
 Another shortcoming of this project is that we have no strategy for assuring 
-safety when refactoring, so the code may end up behaving differently after the 
-refactoring than it behaved before. Approaches toward safer refactorings are 
-mentioned in \myref{sec:saferRefactoring}.
-
-The last important improvement that could be made to this project is to refine 
-the heuristics that is used to find suitable refactoring candidates. This effort 
-should in particular be directed toward making the heuristics choose candidates 
-that do not introduce new dependencies for their destination classes.
+safety when refactoring, so a program may end up behaving differently after a 
+refactoring than it behaved before. One approach towards safer refactorings is
+mentioned in \myref{sec:saferRefactoringTests}, and includes generating tests 
+for the refactored code. Another approach that can be considered for making 
+refactorings safer is part of the original thesis proposal for this thesis, 
+which diverged somewhat from the original proposal. The proposal is about 
+detecting behavioral changes during refactoring, and the work done in this 
+thesis can be used as a basis if one would like to engage in that proposal. The 
+proposed solution for exposing behavioral changes is to insert assertions into 
+source code when refactoring it. For the example in 
+\myref{lst:correctnessExtractAndMoveResult}, which is the result of a 
+refactoring, it is suggested that we insert an assert statement between lines 9 
+and 10. In the example, the assert statement would be 
+\mint{java}|assert c.x == this;| which would discover the aliasing problems of 
+the example.
+
+The final important improvement that I would suggest making to this project is 
+to refine the heuristics that is used to find suitable refactoring candidates.  
+This effort should in particular be directed toward making the heuristics choose 
+candidates that do not introduce new dependencies for their destination classes.
 
 
 \appendix