Thesis: a few changes, PDF included

diff --git a/thesis/master-thesis-erlenkr.pdf b/thesis/master-thesis-erlenkr.pdf
index 966d941ebb949dc2878d183c77a99827baaaac5c..063dd5389d62b8c53cfaf02e8875b0e20aa2942b 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 a2600bcd96f4369460acde6924d390eafe707769..13bc003fc01fccaadb3450d297b3f2b4ba88fc93 100644 (file)
--- a/thesis/master-thesis-erlenkr.tex
+++ b/thesis/master-thesis-erlenkr.tex
@@ -1477,16 +1477,15 @@ leading to the test definitions.
 
 \subsection{Refactoring safety}
 This section presents a couple of approaches to improving the safety of 
 
 \subsection{Refactoring safety}
 This section presents a couple of approaches to improving the safety of 

-performing refactorings. The problems these projects address 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}.
+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''}
 
 \subsubsection{Project ``Safer Refactorings''}

-This project is a project that is not realized, but exists only as a proposal 
-for a master's thesis\citing{stolzSaferRefactorings}.  The proposer is my 
-supervisor, Volker Stolz of the ``Precise Modelling and Analysis'' research 
-group at the University of Oslo.
+\title{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 
 
 The proposed solution for making refactorings safer, is to insert assertions 
 into source code when refactoring it. For the example in 


@@ -1499,9 +1498,9 @@ problems of this example.
 \subsubsection{``Making Program Refactoring Safer''}
 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 
 \subsubsection{``Making Program Refactoring Safer''}
 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 the transformation and then 
-generates a test suite for it, using static analysis. These tests are run for 
-both the before- and after-code, and is then compared to assure that they are 
+preserving behavior during refactoring by analyzing a transformation and then 
+generate a test suite for it, using static analysis. These tests are then run 
+for both the before- and after-code, and is compared to assure that they are 

 consistent.
 
 \subsection{Search-based refactoring}
 consistent.
 
 \subsection{Search-based refactoring}


@@ -1514,11 +1513,12 @@ The common approach for all these algorithms is to generate a set of changes to
 a program for then to use a ``fitness function'' to evaluate if they improve its
 design or not.  The fitness function consists of a weighted sum of different 
 object-oriented metrics.
 a program for then to use a ``fitness function'' to evaluate if they improve its
 design or not.  The fitness function consists of a weighted sum of different 
 object-oriented metrics.

-\todoin{finish}
-
-
-

 
 

+Among other things, the authors conclude that even with small input programs, 
+their solution representation is memory-intensive, at least for some algorithms.  
+The programs they refactor on have in average 4,000 lines of code, spread over 
+57 classes. I.e. considerably smaller than one of the programs that will be 
+   subject to refactoring in this project.

 
 
 \subsection{The compositional paradigm of refactoring}
 
 
 \subsection{The compositional paradigm of refactoring}


@@ -4161,12 +4161,13 @@ quality profile. The values that are set for these rules are listed in
     measures how many other classes a class depends upon. It does not count the 
     dependencies of nested classes. It is meant to promote the Single 
     Responsibility Principle. The metric for the rule resembles the CBO metric 
     measures how many other classes a class depends upon. It does not count the 
     dependencies of nested classes. It is meant to promote the Single 
     Responsibility Principle. The metric for the rule resembles the CBO metric 

-    that is described in \myref{sec:CBO}. The max value for the rule is chosen 
-    on the background of an empirical study by Raed Shatnawi, that concludes 
-    that the number 9 is the most useful threshold for the CBO 
-    metric\citing{shatnawiQuantitative2010}. This study is also performed on 
-    Eclipse source code, so this threshold value should be particularly well 
-    suited for the Eclipse JDT UI case in this chapter.
+    that is described in \myref{sec:CBO}, but is only considering outgoing 
+    dependencies. The max value for the rule is chosen on the background of an 
+    empirical study by Raed Shatnawi, that concludes that the number 9 is the 
+    most useful threshold for the CBO metric\citing{shatnawiQuantitative2010}.  
+    This study is also performed on Eclipse source code, so this threshold value 
+    should be particularly well suited for the Eclipse JDT UI case in this 
+    chapter.

 
   \item[Control flow statements \ldots{} should not be nested too deeply] is 
     a rule that is meant to counter ``Spaghetti code''. It measures the nesting 
 
   \item[Control flow statements \ldots{} should not be nested too deeply] is 
     a rule that is meant to counter ``Spaghetti code''. It measures the nesting