Thesis

diff --git a/thesis/master-thesis-erlenkr.pdf b/thesis/master-thesis-erlenkr.pdf
index 5baeea825bfea8ee49a7787bbbdf26377ab1d495..09f3ba5f6f6e4244696651e5da5c23da5d4314d1 100644 (file)
Binary files a/thesis/master-thesis-erlenkr.pdf and b/thesis/master-thesis-erlenkr.pdf differ

diff --git a/thesis/master-thesis-erlenkr.tex b/thesis/master-thesis-erlenkr.tex
index f27d98c3c2915b4666fde1300b3f2bc22188183e..c3f8df23e7d922f0454e5d372cdd03d3e247cdb3 100644 (file)
--- a/thesis/master-thesis-erlenkr.tex
+++ b/thesis/master-thesis-erlenkr.tex
@@ -185,7 +185,7 @@ algorithms and enhances the \emph{understandability} of the program
 \see{magic_number_seven}. This makes simple refactoring an excellent method for 
 exploring unknown program code, or code that you had forgotten that you wrote!
 
-The word \emph{simple} came up in the last section. In fact, most basic 
+The word \emph{simple} came up in the last section. In fact, most primitive 
 refactorings are simple. The true power of them are revealed first when they are 
 combined into larger --- higher level --- refactorings, called \emph{composite 
 refactorings} \see{intro_composite}. Often the goal of such a series of 
@@ -322,7 +322,7 @@ better) understood.
 
 \subsection{Structural refactorings}
 
-\subsubsection{Basic refactorings}
+\subsubsection{Primitive refactorings}
 
 % Composing Methods
 \explanation{Extract Method}{You have a code fragment that can be grouped 
@@ -566,25 +566,28 @@ leaving the performance tuning until after profiling\footnote{For and example of
 
 
 
-\section{Correctness of refactorings}
-\todo{Volker's example?}
-
 \section{Composite refactorings} \label{intro_composite}
 \todo{motivation, examples, manual vs automated?, what about refactoring in a 
 very large code base?}
 Generally, when thinking about refactoring, at the mechanical level, there are 
-essentially two kinds of refactorings. There are the \emph{basic} refactorings, 
-and there are the \emph{composite} refactorings. The basic refactorings are 
-those that cannot be expressed in terms of other refactorings. Examples are the 
-\emph{Pull Up Field} and \emph{Pull Up Method} refactorings~\cite{refactoring}, 
-that moves members up in their class hierarchies. Composite refactorings could 
+essentially two kinds of refactorings. There are the \emph{primitive} 
+refactorings, and the \emph{composite} refactorings. A primitive refactoring can 
 be defined like this:
 
+\definition{A primitive refactoring is a refactoring that cannot be expressed in 
+terms of other refactorings.}
+
+Examples are the \emph{Pull Up Field} and \emph{Pull Up Method} 
+refactorings~\cite{refactoring}, that moves members up in their class 
+hierarchies. A composite refactoring is more complex, and can be defined like 
+this:
+
 \definition{A composite refactoring is a refactoring that can be expressed in 
-terms of two or more basic refactorings.}
+terms of two or more primitive refactorings.}
+
 An example of a composite refactoring is the \emph{Extract Superclass} 
 refactoring~\cite{refactoring}. In its simplest form, it is composed of the 
-previously described basic refactorings, in addition to the \emph{Pull Up 
+previously described primitive refactorings, in addition to the \emph{Pull Up 
 Constructor Body} refactoring~\cite{refactoring}. It works by creating an 
 abstract superclass that the target class(es) inherits from, then by applying 
 \emph{Pull Up Field}, \emph{Pull Up Method} and \emph{Pull Up Constructor Body} 
@@ -594,13 +597,30 @@ on the members that are to be members of the new superclass.
 
 \section{Manual vs. automated refactorings}
 Refactoring is something every programmer does, even if he or she does not known 
-the term \emph{refactoring}. For small refactorings, such as \emph{Extract 
-Method}, executing it manually is a manageable task, but it is still prone to 
-errors, and getting it right the first time is still not easy, considering the 
-signature and all the other aspects of the refactoring that has to be in place.
+the term \emph{refactoring}. Every refinement of source code that does not alter 
+the program's behavior is a refactoring. For small refactorings, such as 
+\emph{Extract Method}, executing it manually is a manageable task, but is still 
+prone to errors. Getting it right the first time is not easy, considering the 
+signature and all the other aspects of the refactoring that has to be in place.  
+
+Take for instance the renaming of classes, methods and fields. For complex 
+programs these refactorings are almost impossible to get right.  Attacking them 
+with textual search and replace, or even regular expressions, will fall short on 
+these tasks. Then it is crucial to have proper tool support that can perform 
+them automatically. Tools that can parse source code and thus has semantic 
+knowledge about which occurrences of which names that belongs to what construct 
+in the program. For even trying to perform one of these complex task manually, 
+one would have to be very confident on the existing test suite \see{tdd}.
 
-\section{Software metrics}
+\section{Correctness of refactorings}
+\todo{Volker's example?}
+For automated refactorings to be truly useful, they must show a high degree of 
+behavior preservation. This might seem obvious, but there are examples of 
+refactorings in existing tools that break programs. This is one of them:
 
+\section{Test Driven Development}\label{tdd}
+
+\section{Software metrics}
 
 %\part{The project}
 %\chapter{Planning the project}