Thesis: future work first draft

diff --git a/thesis/master-thesis-erlenkr.tex b/thesis/master-thesis-erlenkr.tex
index 2a1f78f4861226b5d97e122a51499cd9d85f3d10..2aa53f960b648826c7638f757f0b819f6a7ba743 100644 (file)
--- a/thesis/master-thesis-erlenkr.tex
+++ b/thesis/master-thesis-erlenkr.tex
@@ -676,9 +676,7 @@ with this as a common version:
 
 \begin{quote}
   Software entities (classes, modules, functions, etc.) should be open for 
-  extension, but closed for modification.\footnote{See 
-    \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or  
-    \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
+  extension, but closed for modification.
 \end{quote} 
 
 Maintainability is often thought of as the ability to be able to introduce new 
@@ -937,10 +935,9 @@ public class X {
 \end{listing}
 
 The bug introduced in the previous example is of such a nature\footnote{Caused 
-  by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}} 
-  that it is very difficult to spot if the refactored code is not covered by 
-  tests.  It does not generate compilation errors, and will thus only result in 
-  a runtime error or corrupted data, which might be hard to detect.
+by aliasing.} that it is very difficult to spot if the refactored code is not 
+covered by tests.  It does not generate compilation errors, and will thus only 
+result in a runtime error or corrupted data, which might be hard to detect.
 
 \subsection{Refactoring and the importance of testing}\label{testing}
 \begin{quote}
@@ -1482,7 +1479,7 @@ 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}
+\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 
@@ -3226,14 +3223,12 @@ meaningful, is called a parser. A parser is fed tokens from the scanner and
 performs an analysis of the structure of a program. It verifies that the syntax 
 is correct according to the grammar rules of a language, that are usually 
 specified in a context-free grammar, and often in a variant of the 
-\name{Backus--Naur 
-Form}\footnote{\url{https://en.wikipedia.org/wiki/Backus-Naur\_Form}}.  The 
-result coming from the parser is in the form of an \emph{Abstract Syntax Tree}, 
-AST for short. It is called \emph{abstract}, because the structure does not 
-contain all of the tokens produced by the scanner. It only contains logical 
-constructs, and because it forms a tree, all kinds of parentheses and brackets 
-are implicit in the structure. It is this AST that is used when performing the 
-semantic analysis of the code.
+\name{Backus--Naur Form}. The result coming from the parser is in the form of an 
+\emph{Abstract Syntax Tree}, AST for short. It is called \emph{abstract}, 
+because the structure does not contain all of the tokens produced by the 
+scanner. It only contains logical constructs, and because it forms a tree, all 
+kinds of parentheses and brackets are implicit in the structure. It is this AST 
+that is used when performing the semantic analysis of the code.
 
 As an example we can think of the expression \code{(5 + 7) * 2}. The root of 
 this tree would in \name{Eclipse} be an \type{InfixExpression} with the operator
@@ -5128,10 +5123,24 @@ Then the results could be made available, and an administrator could be set to
 review them and choose whether or not they should be performed.
 
 \section{Future work}
-\todoin{Find out if a complete analysis is feasible}
-\todoin{Complete the analysis}
-\todoin{Make refactorings safer (behavior)}
-\todoin{Improve heuristics/introduce metrics}
+An important part that is missing for making the search-based 
+\ExtractAndMoveMethod refactoring more usable, is to complete the 
+pre-refactoring analysis of the source code, to make sure that the refactoring 
+does not introduce compilation errors when it is performed.
+
+The first point of making the static analysis complete brings up the next 
+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.
 
 
 \appendix