\usepackage{cleveref}
\usepackage[xindy]{glossaries}
-\usepackage[style=alphabetic,backend=biber]{biblatex}
+\usepackage[style=alphabetic,backend=biber,doi=false,isbn=false]{biblatex}
\usepackage{amsthm}
\usepackage{mathtools}
\usepackage{graphicx}
\begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
\title{Automated Composition of Refactorings}
-\subtitle{Implementing and evaluating the search-based Extract and Move Method
+\subtitle{Implementing and evaluating a search-based Extract and Move Method
refactoring}
\author{Erlend Kristiansen}
\DefineBibliographyStrings{english}{%
bibliography = {References},
}
+\newbibmacro{string+doi}[1]{%
+ \iffieldundef{doi}{#1}{\href{http://dx.doi.org/\thefield{doi}}{#1}}}
+\DeclareFieldFormat{title}{\usebibmacro{string+doi}{\mkbibemph{#1}}}
+\DeclareFieldFormat[article]{title}{\usebibmacro{string+doi}{\mkbibquote{#1}}}
% UML comment in TikZ:
% ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
\newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
\newcolumntype{R}[1]{>{\hsize=#1\hsize\raggedleft\arraybackslash}X}%
+
\begin{document}
-\pagenumbering{roman}
+%\pagenumbering{arabic}
+\mainmatter
\ififorside
-\frontmatter{}
+%\frontmatter{}
+%\setcounter{page}{3}
\chapter*{Abstract}
\todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
\tableofcontents{}
\listoffigures{}
\listoftables{}
+\listoflistings{}
-\chapter*{Preface}
+%\mainmatter
+%\setcounter{page}{13}
-The discussions in this report must be seen in the context of object oriented
-programming languages, and Java in particular, since that is the language in
-which most of the examples will be given. All though the techniques discussed
-may be applicable to languages from other paradigms, they will not be the
-subject of this report.
+\chapter{Introduction}
-\mainmatter
+\section{Motivation and structure}
+
+For large software projects, complex program source code is an issue. It impacts
+the cost of maintenance in a negative way. It often stalls the implementation of
+new functionality and other program changes. The code may be difficult to
+understand, the changes may introduce new bugs that are hard to find and its
+complexity can simply keep people from doing code changes in fear of breaking
+some dependent piece of code. All these problems are related, and often lead to
+a vicious circle that slowly degrades the overall quality of a project.
+
+More specifically, and in an object-oriented context, a class may depend on a
+number of other classes. Sometimes these intimate relationships are appropriate,
+and sometimes they are not. Inappropriate \emph{coupling} between classes can
+make it difficult to know whether or not a change that is aimed at fixing a
+specific problem also alters the behavior of another part of a program.
+
+One of the tools that are used to fight complexity and coupling in program
+source code is \emph{refactoring}. The intention for this master's thesis is
+therefore to create an automated composite refactoring that reduces coupling
+between classes. The refactoring shall be able to operate automatically in all
+phases of a refactoring, from performing analysis to executing changes. It is
+also a requirement that it should be able to process large quantities of source
+code in a reasonable amount of time.
-\chapter{What is Refactoring?}
+
+\todoin{Structure. Write later\ldots}
+
+
+\section{What is refactoring?}
This question is best answered by first defining the concept of a
\emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
of programming make people want to refactor their code.
-\section{Defining refactoring}
+\subsection{Defining refactoring}
Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
refactoring like this:
mechanics in terms of other refactorings.
\end{comment}
-\section{The etymology of 'refactoring'}
+\subsection{The etymology of 'refactoring'}
It is a little difficult to pinpoint the exact origin of the word
``refactoring'', as it seems to have evolved as part of a colloquial
terminology, more than a scientific term. There is no authoritative source for a
the \name{Forth} and \name{Smalltalk} communities, but that it emerged
independently in each of the communities.
-\section{Motivation -- Why people refactor}
+\subsection{Reasons for refactoring}
There are many reasons why people want to refactor their programs. They can for
instance do it to remove duplication, break up long methods or to introduce
design patterns into their software systems. The shared trait for all these are
and money should also be able to open the eyes of the many nearsighted managers
that seldom see beyond the next milestone.
-\section{The magical number seven}\label{magic_number_seven}
+\subsection{The magical number seven}\label{magic_number_seven}
The article \tit{The magical number seven, plus or minus two: some limits on our
capacity for processing information}\citing{miller1956} by George A. Miller,
was published in the journal \name{Psychological Review} in 1956. It presents
computer programs that are easier to maintain and have code that is easier (and
better) understood.
-\section{Notable contributions to the refactoring literature}
+\subsection{Notable contributions to the refactoring literature}
\begin{description}
\item[1992] William F. Opdyke submits his doctoral dissertation called
design \see{relationToDesignPatterns}.
\end{description}
-\section{Tool support (for Java)}\label{toolSupport}
+\subsection{Tool support (for Java)}\label{toolSupport}
This section will briefly compare the refactoring support of the three IDEs
\name{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \name{IntelliJ
IDEA}\footnote{The IDE under comparison is the \name{Community Edition},
using the \refa{Extract Class} refactoring in \name{Eclipse}. When it comes to
\name{NetBeans}, it does not even show an attempt on providing this refactoring.
-\section{The relation to design patterns}\label{relationToDesignPatterns}
+\subsection{The relation to design patterns}\label{relationToDesignPatterns}
Refactoring and design patterns have at least one thing in common, they are both
promoted by advocates of \emph{clean code}\citing{cleanCode} as fundamental
decisions that has to be made before proceeding in the process, and that is
going to define a project for all of its unforeseeable future.
-\begin{comment}
-
-\section{Classification of refactorings}
-% only interesting refactorings
-% with 2 detailed examples? One for structured and one for intra-method?
-% Is replacing Bubblesort with Quick Sort considered a refactoring?
-
-\subsection{Structural refactorings}
-
-\subsubsection{Primitive refactorings}
-
-% Composing Methods
-\explanation{Extract Method}{You have a code fragment that can be grouped
-together.}{Turn the fragment into a method whose name explains the purpose of
-the method.}
-
-\explanation{Inline Method}{A method's body is just as clear as its name.}{Put
-the method's body into the body of its callers and remove the method.}
-
-\explanation{Inline Temp}{You have a temp that is assigned to once with a simple
-expression, and the temp is getting in the way of other refactorings.}{Replace
-all references to that temp with the expression}
-
-% Moving Features Between Objects
-\explanation{Move Method}{A method is, or will be, using or used by more
-features of another class than the class on which it is defined.}{Create a new
-method with a similar body in the class it uses most. Either turn the old method
-into a simple delegation, or remove it altogether.}
-
-\explanation{Move Field}{A field is, or will be, used by another class more than
-the class on which it is defined}{Create a new field in the target class, and
-change all its users.}
-
-% Organizing Data
-\explanation{Replace Magic Number with Symbolic Constant}{You have a literal
-number with a particular meaning.}{Create a constant, name it after the meaning,
-and replace the number with it.}
-
-\explanation{Encapsulate Field}{There is a public field.}{Make it private and
-provide accessors.}
-
-\explanation{Replace Type Code with Class}{A class has a numeric type code that
-does not affect its behavior.}{Replace the number with a new class.}
-
-\explanation{Replace Type Code with Subclasses}{You have an immutable type code
-that affects the behavior of a class.}{Replace the type code with subclasses.}
-
-\explanation{Replace Type Code with State/Strategy}{You have a type code that
-affects the behavior of a class, but you cannot use subclassing.}{Replace the
-type code with a state object.}
-
-% Simplifying Conditional Expressions
-\explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
-code is in all branches of a conditional expression.}{Move it outside of the
-expression.}
-
-\explanation{Remove Control Flag}{You have a variable that is acting as a
-control flag fro a series of boolean expressions.}{Use a break or return
-instead.}
-
-\explanation{Replace Nested Conditional with Guard Clauses}{A method has
-conditional behavior that does not make clear the normal path of
-execution.}{Use guard clauses for all special cases.}
-
-\explanation{Introduce Null Object}{You have repeated checks for a null
-value.}{Replace the null value with a null object.}
-
-\explanation{Introduce Assertion}{A section of code assumes something about the
-state of the program.}{Make the assumption explicit with an assertion.}
-
-% Making Method Calls Simpler
-\explanation{Rename Method}{The name of a method does not reveal its
-purpose.}{Change the name of the method}
-
-\explanation{Add Parameter}{A method needs more information from its
-caller.}{Add a parameter for an object that can pass on this information.}
-
-\explanation{Remove Parameter}{A parameter is no longer used by the method
-body.}{Remove it.}
-
-%\explanation{Parameterize Method}{Several methods do similar things but with
-%different values contained in the method.}{Create one method that uses a
-%parameter for the different values.}
-
-\explanation{Preserve Whole Object}{You are getting several values from an
-object and passing these values as parameters in a method call.}{Send the whole
-object instead.}
-
-\explanation{Remove Setting Method}{A field should be set at creation time and
-never altered.}{Remove any setting method for that field.}
-
-\explanation{Hide Method}{A method is not used by any other class.}{Make the
-method private.}
-
-\explanation{Replace Constructor with Factory Method}{You want to do more than
-simple construction when you create an object}{Replace the constructor with a
-factory method.}
-
-% Dealing with Generalization
-\explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
-to the superclass.}
-
-\explanation{Pull Up Method}{You have methods with identical results on
-subclasses.}{Move them to the superclass.}
-
-\explanation{Push Down Method}{Behavior on a superclass is relevant only for
-some of its subclasses.}{Move it to those subclasses.}
-
-\explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
-field to those subclasses}
-
-\explanation{Extract Interface}{Several clients use the same subset of a class's
-interface, or two classes have part of their interfaces in common.}{Extract the
-subset into an interface.}
-
-\explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
-superclasses interface or does not want to inherit data.}{Create a field for the
-superclass, adjust methods to delegate to the superclass, and remove the
-subclassing.}
-
-\explanation{Replace Delegation with Inheritance}{You're using delegation and
-are often writing many simple delegations for the entire interface}{Make the
-delegating class a subclass of the delegate.}
+\subsection{The impact on software quality}
-\subsubsection{Composite refactorings}
-
-% Composing Methods
-% \explanation{Replace Method with Method Object}{}{}
-
-% Moving Features Between Objects
-\explanation{Extract Class}{You have one class doing work that should be done by
-two}{Create a new class and move the relevant fields and methods from the old
-class into the new class.}
-
-\explanation{Inline Class}{A class isn't doing very much.}{Move all its features
-into another class and delete it.}
-
-\explanation{Hide Delegate}{A client is calling a delegate class of an
-object.}{Create Methods on the server to hide the delegate.}
-
-\explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
-the client to call the delegate directly.}
-
-% Organizing Data
-\explanation{Replace Data Value with Object}{You have a data item that needs
-additional data or behavior.}{Turn the data item into an object.}
-
-\explanation{Change Value to Reference}{You have a class with many equal
-instances that you want to replace with a single object.}{Turn the object into a
-reference object.}
-
-\explanation{Encapsulate Collection}{A method returns a collection}{Make it
-return a read-only view and provide add/remove methods.}
-
-% \explanation{Replace Array with Object}{}{}
-
-\explanation{Replace Subclass with Fields}{You have subclasses that vary only in
-methods that return constant data.}{Change the methods to superclass fields and
-eliminate the subclasses.}
-
-% Simplifying Conditional Expressions
-\explanation{Decompose Conditional}{You have a complicated conditional
-(if-then-else) statement.}{Extract methods from the condition, then part, an
-else part.}
-
-\explanation{Consolidate Conditional Expression}{You have a sequence of
-conditional tests with the same result.}{Combine them into a single conditional
-expression and extract it.}
-
-\explanation{Replace Conditional with Polymorphism}{You have a conditional that
-chooses different behavior depending on the type of an object.}{Move each leg
-of the conditional to an overriding method in a subclass. Make the original
-method abstract.}
-
-% Making Method Calls Simpler
-\explanation{Replace Parameter with Method}{An object invokes a method, then
-passes the result as a parameter for a method. The receiver can also invoke this
-method.}{Remove the parameter and let the receiver invoke the method.}
-
-\explanation{Introduce Parameter Object}{You have a group of parameters that
-naturally go together.}{Replace them with an object.}
-
-% Dealing with Generalization
-\explanation{Extract Subclass}{A class has features that are used only in some
-instances.}{Create a subclass for that subset of features.}
-
-\explanation{Extract Superclass}{You have two classes with similar
-features.}{Create a superclass and move the common features to the
-superclass.}
-
-\explanation{Collapse Hierarchy}{A superclass and subclass are not very
-different.}{Merge them together.}
-
-\explanation{Form Template Method}{You have two methods in subclasses that
-perform similar steps in the same order, yet the steps are different.}{Get the
-steps into methods with the same signature, so that the original methods become
-the same. Then you can pull them up.}
-
-
-\subsection{Functional refactorings}
-
-\explanation{Substitute Algorithm}{You want to replace an algorithm with one
-that is clearer.}{Replace the body of the method with the new algorithm.}
-
-\end{comment}
-
-\section{The impact on software quality}
-
-\subsection{What is software quality?}
+\subsubsection{What is software quality?}
The term \emph{software quality} has many meanings. It all depends on the
context we put it in. If we look at it with the eyes of a software developer, it
usually means that the software is easily maintainable and testable, or in other
addition, such things as good documentation could be measured, but this is out
of the scope of this document.)
-\subsection{The impact on performance}
+\subsubsection{The impact on performance}
\begin{quote}
Refactoring certainly will make software go more slowly\footnote{With todays
compiler optimization techniques and performance tuning of e.g. the Java
design, leaving the performance tuning until after \gloss{profiling} the
software and having isolated the actual problem areas.
-\section{Composite refactorings}\label{compositeRefactorings}
+\subsection{Composite refactorings}\label{compositeRefactorings}
Generally, when thinking about refactoring, at the mechanical level, there are
essentially two kinds of refactorings. There are the \emph{primitive}
refactorings, and the \emph{composite} refactorings.
\label{fig:extractSuperclass}
\end{figure}
-\section{Manual vs. automated refactorings}
+\subsection{Manual vs. automated refactorings}
Refactoring is something every programmer does, even if \heshe does not known
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
For even trying to perform one of these complex task manually, one would have to
be very confident on the existing test suite \see{testing}.
-\section{Correctness of refactorings}\label{correctness}
+\subsection{Correctness of refactorings}\label{correctness}
For automated refactorings to be truly useful, they must show a high degree of
behavior preservation. This last sentence might seem obvious, but there are
examples of refactorings in existing tools that break programs. In an ideal
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.
-\section{Refactoring and the importance of testing}\label{testing}
+\subsection{Refactoring and the importance of testing}\label{testing}
\begin{quote}
If you want to refactor, the essential precondition is having solid
tests.\citing{refactoring}
be risk-free to perform refactorings on it. This is why automated tests and
refactoring are such a great match.
-\subsection{Testing the code from correctness section}
+\subsubsection{Testing the code from correctness section}
The worst thing that can happen when refactoring is to introduce changes to the
behavior of a program, as in the example on \myref{correctness}. This example
may be trivial, but the essence is clear. The only problem with the example is
\end{comment}
-\chapter{The Project}
+\section{The Project}
+In this section we look at the work that shall be done for this project, its
+building stones and some of the methodologies used.
-\section{Project description}
+\subsection{Project description}
The aim of this master's project will be to explore the relationship between the
\ExtractMethod and the \MoveMethod refactorings. This will be done by composing
the two into a composite refactoring. The refactoring will be called the
execute the refactoring automatically, I have to make it analyze code to
determine the best selections to extract into new methods.
-\section{The primitive refactorings}
+\subsection{The premises}
+Before we can start manipulating source code and write a tool for doing so, we
+need to decide on a programming language for the code we are going to
+manipulate. Also, since we do not want to start from scratch by implementing
+primitive refactorings ourselves, we need to choose an existing tool that
+provides the needed refactorings. In addition to be able to perform changes, we
+need a framework for analyzing source code for the language we select.
+
+\subsubsection{Choosing the target language}
+Choosing which programming language the code that shall be manipulated shall be
+written in, is not a very difficult task. We choose to limit the possible
+languages to the object-oriented programming languages, since most of the
+terminology and literature regarding refactoring comes from the world of
+object-oriented programming. In addition, the language must have existing tool
+support for refactoring.
+
+The \name{Java} programming language\footnote{\url{https://www.java.com/}} is
+the dominating language when it comes to example code in the literature of
+refactoring, and is thus a natural choice. Java is perhaps, currently the most
+influential programming language in the world, with its \name{Java Virtual
+Machine} that runs on all of the most popular architectures and also supports
+dozens of other programming languages\footnote{They compile to Java bytecode.},
+with \name{Scala}, \name{Clojure} and \name{Groovy} as the most prominent ones.
+Java is currently the language that every other programming language is compared
+against. It is also the primary programming language for the author of this
+thesis.
+
+\subsubsection{Choosing the tools}
+When choosing a tool for manipulating Java, there are certain criteria that
+have to be met. First of all, the tool should have some existing refactoring
+support that this thesis can build upon. Secondly it should provide some kind of
+framework for parsing and analyzing Java source code. Third, it should itself be
+open source. This is both because of the need to be able to browse the code for
+the existing refactorings that is contained in the tool, and also because open
+source projects hold value in them selves. Another important aspect to consider
+is that open source projects of a certain size, usually has large communities of
+people connected to them, that are committed to answering questions regarding the
+use and misuse of the products, that to a large degree is made by the community
+itself.
+
+There is a certain class of tools that meet these criteria, namely the class of
+\emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
+programs that is meant to support the whole production cycle of a computer
+program, and the most popular IDEs that support Java, generally have quite good
+refactoring support.
+
+The main contenders for this thesis is the \name{Eclipse IDE}, with the
+\name{Java development tools} (JDT), the \name{IntelliJ IDEA Community Edition}
+and the \name{NetBeans IDE} \see{toolSupport}. \name{Eclipse} and
+\name{NetBeans} are both free, open source and community driven, while the
+\name{IntelliJ IDEA} has an open sourced community edition that is free of
+charge, but also offer an \name{Ultimate Edition} with an extended set of
+features, at additional cost. All three IDEs supports adding plugins to extend
+their functionality and tools that can be used to parse and analyze Java source
+code. But one of the IDEs stand out as a favorite, and that is the \name{Eclipse
+IDE}. This is the most popular\citing{javaReport2011} among them and seems to be
+de facto standard IDE for Java development regardless of platform.
+
+\subsection{The primitive refactorings}
The refactorings presented here are the primitive refactorings used in this
project. They are the abstract building blocks used by the \ExtractAndMoveMethod
refactoring.
-\subsection{The Extract Method refactoring}
+\paragraph{The Extract Method refactoring}
The \refa{Extract Method} refactoring is used to extract a fragment of code
from its context and into a new method. A call to the new method is inlined
where the fragment was before. It is used to break code into logical units, with
\label{lst:extractMethodRefactoring}
\end{listing}
-\subsection{The Move Method refactoring}
+\paragraph{The Move Method refactoring}
The \refa{Move Method} refactoring is used to move a method from one class to
another. This can be appropriate if the method is using more features of another
class than of the class which it is currently defined.
\label{lst:moveMethodRefactoring}
\end{listing}
-\section{The Extract and Move Method refactoring}
+\subsection{The Extract and Move Method refactoring}
The \ExtractAndMoveMethod refactoring is a composite refactoring composed of the
primitive \ExtractMethod and \MoveMethod refactorings. The effect of this
refactoring on source code is the same as when extracting a method and moving it
-to another class. Conseptually, this is done without an intermediate step. In
+to another class. Conceptually, this is done without an intermediate step. In
practice, as we shall see later, an intermediate step may be necessary.
An example of this composite refactoring is shown in
\label{lst:extractAndMoveMethodRefactoring}
\end{listing}
-\section{Research questions}
+\subsection{Research questions}
The main question that I seek an answer to in this thesis is:
\begin{quote}
And, assuming the refactoring does in fact improve the quality of source code:
\paragraph{How can the automation of the refactoring be helpful?} What is the
-usefullness of the refactoring in a software development setting? In what parts
+usefulness of the refactoring in a software development setting? In what parts
of the development process can the refactoring play a role?
-\section{Choosing the target language}
-Choosing which programming language the code that shall be manipulated shall be
-written in, is not a very difficult task. We choose to limit the possible
-languages to the object-oriented programming languages, since most of the
-terminology and literature regarding refactoring comes from the world of
-object-oriented programming. In addition, the language must have existing tool
-support for refactoring.
+\subsection{Methodology}
-The \name{Java} programming language\footnote{\url{https://www.java.com/}} is
-the dominating language when it comes to example code in the literature of
-refactoring, and is thus a natural choice. Java is perhaps, currently the most
-influential programming language in the world, with its \name{Java Virtual
-Machine} that runs on all of the most popular architectures and also supports
-dozens of other programming languages\footnote{They compile to java bytecode.},
-with \name{Scala}, \name{Clojure} and \name{Groovy} as the most prominent ones.
-Java is currently the language that every other programming language is compared
-against. It is also the primary programming language for the author of this
-thesis.
+\subsubsection{Evolutionary design}
+In the programming work for this project, it have tried to use a design strategy
+called evolutionary design, also known as continuous or incremental
+design\citing{wiki_continuous_2014}. It is a software design strategy
+advocated by the Extreme Programming community. The essence of the strategy is
+that you should let the design of your program evolve naturally as your
+requirements change. This is seen in contrast with up-front design, where
+design decisions are made early in the process.
-\section{Choosing the tools}
-When choosing a tool for manipulating Java, there are certain criteria that
-have to be met. First of all, the tool should have some existing refactoring
-support that this thesis can build upon. Secondly it should provide some kind of
-framework for parsing and analyzing Java source code. Third, it should itself be
-open source. This is both because of the need to be able to browse the code for
-the existing refactorings that is contained in the tool, and also because open
-source projects hold value in them selves. Another important aspect to consider
-is that open source projects of a certain size, usually has large communities of
-people connected to them, that are committed to answering questions regarding the
-use and misuse of the products, that to a large degree is made by the community
-itself.
+The motivation behind evolutionary design is to keep the design of software as
+simple as possible. This means not introducing unneeded functionality into a
+program. You should defer introducing flexibility into your software, until it
+is needed to be able to add functionality in a clean way.
-There is a certain class of tools that meet these criteria, namely the class of
-\emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
-programs that is meant to support the whole production cycle of a computer
-program, and the most popular IDEs that support Java, generally have quite good
-refactoring support.
+Holding up design decisions, implies that the time will eventually come when
+decisions have to be made. The flexibility of the design then relies on the
+programmer's abilities to perform the necessary refactoring, and \his confidence
+in those abilities. From my experience working on this project, I can say that
+this confidence is greatly enhanced by having automated tests to rely on
+\see{tdd}.
+
+The choice of going for evolutionary design developed naturally. As Fowler
+points out in his article \tit{Is Design Dead?}, evolutionary design much
+resembles the ``code and fix'' development strategy\citing{fowler_design_2004}.
+A strategy that most of us have practiced in school. This was also the case when
+I first started this work. I had to learn the inner workings of Eclipse and its
+refactoring-related plugins. That meant a lot of fumbling around with code I did
+not know, in a trial and error fashion. Eventually I started writing tests for
+my code, and my design began to evolve.
+
+\subsubsection{Test-driven development}\label{tdd}
+As mentioned before, the project started out as a classic code and fix
+developmen process. My focus was aimed at getting something to work, rather than
+doing so according to best practice. This resulted in a project that got out of
+its starting blocks, but it was not accompanied by any tests. Hence it was soon
+difficult to make any code changes with the confidence that the program was
+still correct afterwards (assuming it was so before changing it). I always knew
+that I had to introduce some tests at one point, but this experience accelerated
+the process of leading me onto the path of testing.
+
+I then wrote tests for the core functionality of the plugin, and thus gained
+more confidence in the correctness of my code. I could now perform quite drastic
+changes without ``wetting my pants``. After this, nearly all of the semantic
+changes done to the business logic of the project, or the addition of new
+functionality, was made in a test-driven manner. This means that before
+performing any changes, I would define the desired functionality through a set
+of tests. I would then run the tests to check that they were run and that they
+did not pass. Then I would do any code changes necessary to make the tests
+pass. The definition of how the program is supposed to operate is then captured
+by the tests. However, this does not prove the correctness of the analysis
+leading to the test definitions.
+
+\subsubsection{Continuous integration}
+\todoin{???}
+
+\section{Related Work}
+
+\subsection{Safer refactorings}
+\todoin{write}
+
+\subsection{The compositional paradigm of refactoring}
+This paradigm builds upon the observation of Vakilian et
+al.\citing{vakilian2012}, that of the many automated refactorings existing in
+modern IDEs, the simplest ones are dominating the usage statistics. The report
+mainly focuses on \name{Eclipse} as the tool under investigation.
+
+The paradigm is described almost as the opposite of automated composition of
+refactorings \see{compositeRefactorings}. It works by providing the programmer
+with easily accessible primitive refactorings. These refactorings shall be
+accessed via keyboard shortcuts or quick-assist menus\footnote{Think
+quick-assist with Ctrl+1 in \name{Eclipse}} and be promptly executed, opposed to in the
+currently dominating wizard-based refactoring paradigm. They are meant to
+stimulate composing smaller refactorings into more complex changes, rather than
+doing a large upfront configuration of a wizard-based refactoring, before
+previewing and executing it. The compositional paradigm of refactoring is
+supposed to give control back to the programmer, by supporting \himher with an
+option of performing small rapid changes instead of large changes with a lesser
+degree of control. The report authors hope this will lead to fewer unsuccessful
+refactorings. It also could lower the bar for understanding the steps of a
+larger composite refactoring and thus also help in figuring out what goes wrong
+if one should choose to op in on a wizard-based refactoring.
+
+Vakilian and his associates have performed a survey of the effectiveness of the
+compositional paradigm versus the wizard-based one. They claim to have found
+evidence of that the \emph{compositional paradigm} outperforms the
+\emph{wizard-based}. It does so by reducing automation, which seem
+counterintuitive. Therefore they ask the question ``What is an appropriate level
+of automation?'', and thus questions what they feel is a rush toward more
+automation in the software engineering community.
-The main contenders for this thesis is the \name{Eclipse IDE}, with the
-\name{Java development tools} (JDT), the \name{IntelliJ IDEA Community Edition}
-and the \name{NetBeans IDE} \see{toolSupport}. \name{Eclipse} and
-\name{NetBeans} are both free, open source and community driven, while the
-\name{IntelliJ IDEA} has an open sourced community edition that is free of
-charge, but also offer an \name{Ultimate Edition} with an extended set of
-features, at additional cost. All three IDEs supports adding plugins to extend
-their functionality and tools that can be used to parse and analyze Java source
-code. But one of the IDEs stand out as a favorite, and that is the \name{Eclipse
-IDE}. This is the most popular\citing{javaReport2011} among them and seems to be
-de facto standard IDE for Java development regardless of platform.
-\chapter{Semantics}
+\chapter{The search-based Extract and Move Method refactoring}
In this chapter I will delve into the workings of the search-based
\ExtractAndMoveMethod refactoring. We will see the choices it must make along
the way and why it chooses a text selection as a candidate for refactoring or
not.
-After defining som concepts, I will introduce an example that will be used
+After defining some concepts, I will introduce an example that will be used
throughout the chapter to illustrate how the refactoring works in some simple
situations.
\section{The inputs to the refactoring}
For executing an \ExtractAndMoveMethod refactoring, there are two simple
-requirements. The first thing the refactoring need is a text selection, telling
+requirements. The first thing the refactoring needs is a text selection, telling
it what to extract. Its second requirement is a target for the subsequent move
operation.
The extracted method must be called instead of the selection that makes up its
body. Also, the method call has to be performed via a variable, since the method
-is not static. \todo{Explain why static methods are not considered} Therefore,
-the move target must be a variable in the scope of the extracted selection. The
-actual new location for the extracted method will be the class representing the
-type of the move target variable. But, since the method also must be called
-through a variable, it makes sense to define the move target to be either a
-local variable or a field in the scope of the text selection.
+is not static. Therefore, the move target must be a variable in the scope of the
+extracted selection. The actual new location for the extracted method will be
+the class representing the type of the move target variable. But, since the
+method also must be called through a variable, it makes sense to define the move
+target to be either a local variable or a field in the scope of the text
+selection.
\section{Defining a text selection}
A text selection, in our context, is very similar to what you think of when
length of the selection, where the first character is found at the specified
offset.
+\section{Where we look for text selections}
+
+\subsection{Text selections are found in methods}
+The text selections we are interested in are those that surrounds program
+statements. Therefore, the place we look for selections that can form candidates
+for an execution of the \ExtractAndMoveMethod refactoring, is within the body of
+a single method.
+
+\paragraph{On ignoring static methods}
+In this project we are not analyzing static methods for candidates to the
+\ExtractAndMoveMethod refactoring. The reason for this is that in the cases
+where we want to perform the refactoring for a selection within a static method,
+the first step is to extract the selection into a new method. Hence this method
+also become static, since it must be possible to call it from a static context.
+It would then be difficult to move the method to another class, make it
+non-static and calling it through a variable. To avoid these obstacles, we
+simply ignore static methods.
+
\begin{listing}[htb]
\def\charwidth{5.8pt}
\def\indent{2*\charwidth}
\label{lst:grandExample}
\end{listing}
-\section{The possible text selections of a method body}
-The number of possible text selection that can be made from the text in a method
-body, are equal to all the sub-sequences of characters within it. For our
-purposes, analyzing program source code, considering all these is a waste of
-time. Therefore, we must define what it means for a text selection to be valid.
+\subsection{The possible text selections of a method body}
+\todoin{dummy todo}
+The number of possible text selections that can be made from the text in a
+method body, are equal to all the sub-sequences of characters within it. For our
+purposes, analyzing program source code, we must define what it means for a text
+selection to be valid.
\definition{A \emph{valid text selection} is a text selection that contains all
of one or more consecutive program statements.}
For a sequence of statements, the text selections that can be made from it, are
equal to all its sub-sequences. \Myref{lst:textSelectionsExample} show an
example of all the text selections that can be made from the code in
-\myref{lst:grandExample}, lines 16-18. For convenience and the clearity of this
+\myref{lst:grandExample}, lines 16-18. For convenience and the clarity of this
example, the text selections are represented as tuples with the start and end
line of all selections: $\{(16), (17), (18), (16,17), (16,18), (17,18)\}$.
\draw[overlaybox] (2*\charwidth,\mintedtop) rectangle
+(16*\charwidth,\lineheight);
- % Second statement
- \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
- +(16*\charwidth,\lineheight);
+ % Second statement
+ \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
+ +(16*\charwidth,\lineheight);
+
+ % Third statement
+ \draw[overlaybox] (2*\charwidth,\mintedtop+2*\lineheight) rectangle
+ +(16*\charwidth,\lineheight);
+
+ \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
+ +(18*\charwidth,2*\lineheight);
+
+ \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
+ +(14*\charwidth,2*\lineheight);
+
+ % All
+ \draw[overlaybox] (\indent,\mintedtop) rectangle
+ +(12*\charwidth,3*\lineheight);
+\end{tikzpicture}
+% indent should be 5 spaces
+\begin{minted}[linenos,firstnumber=16]{java}
+ b.a.foo();
+ b.a.bar();
+ break;
+\end{minted}
+\caption{Example of how the text selections generator would generate text
+ selections based on a lists of statements. Each highlighted rectangle
+represents a text selection.}
+\label{lst:textSelectionsExample}
+\end{listing}
+
+Each nesting level of a method body can have many such sequences of statements.
+The outermost nesting level has one such sequence, and each branch contains
+their own sequence of statements. \Myref{lst:grandExample} has a version of some
+code where all such sequences of statements are highlighted for a method body.
+
+To complete our example of possible text selections, I will now list all
+possible text selections for the method in \myref{lst:grandExample}, by nesting
+level. There are 23 of them in total.
+
+\begin{description}
+ \item[Level 1 (10 selections)] \hfill \\
+ $\{(5,9), (11), (12), (14,21), (5,11), (5,12), (5,21), (11,12),
+ (11,21), \\(12,21)\}$
+
+ \item[Level 2 (13 selections)] \hfill \\
+ $\{(6), (7), (8), (6,7), (6,8), (7,8), (16), (17), (18), (16,17), (16,18), \\
+ (17,18), (20)\}$
+\end{description}
+
+\subsubsection{The complexity}\label{sec:complexity}
+The complexity of how many text selections that needs to be analyzed for a body
+of in total $n$ statements, is bounded by $O(n^2)$. A body of statements is here
+all the statements in all nesting levels of a sequence of statements. A method
+body (or a block) is a body of statements. To prove that the complexity is
+bounded by $O(n^2)$, I present a couple of theorems and proves them.
+
+\begin{theorem}
+The number of text selections that need to be analyzed for each list of
+statements of length $n$, is exactly
+
+\begin{equation*}
+ \sum_{i=1}^{n} i = \frac{n(n+1)}{2}
+ \label{eq:complexityStatementList}
+\end{equation*}
+\label{thm:numberOfTextSelection}
+\end{theorem}
+
+\begin{proof}
+ For $n=1$ this is trivial: $\frac{1(1+1)}{2} = \frac{2}{2} = 1$. One statement
+ equals one selection.
+
+ For $n=2$, you get one text selection for the first statement, one selection
+ for the second statement, and one selection for the two of them combined.
+ This equals three selections. $\frac{2(2+1)}{2} = \frac{6}{2} = 3$.
+
+ For $n=3$, you get 3 selections for the two first statements, as in the case
+ where $n=2$. In addition you get one selection for the third statement itself,
+ and two more statements for the combinations of it with the two previous
+ statements. This equals six selections. $\frac{3(3+1)}{2} = \frac{12}{2} = 6$.
+
+ Assume that for $n=k$ there exists $\frac{k(k+1)}{2}$ text selections. Then we
+ want to add selections for another statement, following the previous $k$
+ statements. So, for $n=k+1$, we get one additional selection for the statement
+ itself. Then we get one selection for each pair of the new selection and the
+ previous $k$ statements. So the total number of selections will be the number
+ of already generated selections, plus $k$ for every pair, plus one for the
+ statement itself: $\frac{k(k+1)}{2} + k +
+ 1 = \frac{k(k+1)+2k+2}{2} = \frac{k(k+1)+2(k+1)}{2} = \frac{(k+1)(k+2)}{2} =
+ \frac{(k+1)((k+1)+1)}{2} = \sum_{i=1}^{k+1} i$
+\end{proof}
+
+%\definition{A \emph{body of statements} is a sequence of statements where every
+%statement may have sub-statements.}
+
+\begin{theorem}
+ The number of text selections for a body of statements is maximized if all the
+ statements are at the same level.
+ \label{thm:textSelectionsMaximized}
+\end{theorem}
+
+\begin{proof}
+ Assume we have a body of, in total, $k$ statements. Then, the sum of the
+ lengths of all the lists of statements in the body, is also $k$. Let
+ $\{l,\ldots,m,(k-l-\ldots-m)\}$ be the lengths of the lists of statements in
+ the body, with $l+\ldots+m<k \Rightarrow \forall i \in \{l,\ldots,m\} : i < k$.
- % Third statement
- \draw[overlaybox] (2*\charwidth,\mintedtop+2*\lineheight) rectangle
- +(16*\charwidth,\lineheight);
+ Then, the number of text selections that are generated for the $k$ statements
+ is
- \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
- +(18*\charwidth,2*\lineheight);
+ {
+ \small
+ \begin{align*}
+ \frac{l(l+1)}{2} + \ldots + \frac{m(m+1)}{2} +
+ \frac{(k-l-\ldots-m)((k-l-\ldots-m)+ 1)}{2} = \\
+ \frac{l^2+l}{2} + \ldots + \frac{m^2+m}{2} + \frac{k^2 - 2kl - \ldots - 2km +
+ l^2 + \ldots + m^2 + k - l - \ldots - m}{2} = \\
+ \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2}
+ \end{align*}
+ }
- \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
- +(14*\charwidth,2*\lineheight);
+ \noindent It then remains to show that this inequality holds:
- % All
- \draw[overlaybox] (\indent,\mintedtop) rectangle
- +(12*\charwidth,3*\lineheight);
-\end{tikzpicture}
-% indent should be 5 spaces
-\begin{minted}[linenos,firstnumber=16]{java}
- b.a.foo();
- b.a.bar();
- break;
-\end{minted}
-\caption{Example of how the text selections generator would generate text
- selections based on a lists of statements. Each highlighted rectangle
-represents a text selection.}
-\label{lst:textSelectionsExample}
-\end{listing}
+ \begin{align*}
+ \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2} < \frac{k(k+1)}{2} =
+ \frac{k^2 + k}{2}
+ \end{align*}
-Each nesting level of a method body can have many such sequences of statements.
-The outermost nesting level has one such sequence, and each branch contains
-their own sequence of statements. \Myref{lst:grandExample} has a version of some
-code where all such sequences of statements are highlighted for a method body.
+ \noindent By multiplication by $2$ on both sides, and by removing the equal
+ parts, we get
-To complete our example of possible text selections, I will now list all
-possible text selections for the method in \myref{lst:grandExample}, by nesting
-level. There should be 23 of them in total \see{par:complexity}.
+ \begin{align*}
+ 2l^2 - 2kl + \ldots + 2m^2 - 2km < 0
+ \end{align*}
-\begin{description}
- \item[Level 1 (10 selections)] \hfill \\
- $\{(5,9), (11), (12), (14,21), (5,11), (5,12), (5,21), (11,12),
- (11,21), \\(12,21)\}$
+ Since $\forall i \in \{l,\ldots,m\} : i < k$, we have that $\forall i \in
+ \{l,\ldots,m\} : 2ki > 2i^2$, so all the pairs of parts on the form $2i^2-2ki$
+ are negative. In sum, the inequality holds.
- \item[Level 2 (13 selections)] \hfill \\
- $\{(6), (7), (8), (6,7), (6,8), (7,8), (16), (17), (18), (16,17), (16,18), \\
- (17,18), (20)\}$
-\end{description}
+\end{proof}
+
+Therefore, the complexity for the number of selections that needs to be analyzed
+for a body of $n$ statements is $O\bigl(\frac{n(n+1)}{2}\bigr) = O(n^2)$.
\section{Disqualifying a selection}
Certain text selections would lead to broken code if used as input to the
\ExtractAndMoveMethod refactoring. To avoid this, we have to check all text
-selections for such conditions before they are further analyzed. This sections
-is therefore going to present some properties that makes a selection unsuitable
+selections for such conditions before they are further analyzed. This section
+is therefore going to present some properties that make a selection unsuitable
for our refactoring.
\subsection{A call to a protected or package-private method}
selection done to a method in \m{A}. We want to extract and move this selection
to another class. The method \method{foo} is not public, so the \MoveMethod
refactoring must make it public, making the extracted method able to call it
-from the extracted method's new location. The problem is that the, now public,
+from the extracted method's new location. The problem is, that the now public
method \method{foo} is overridden in a subclass, where it has a protected
status. This makes the compiler complain that the subclass \m{B} is trying to
reduce the visibility of a method declared in its superclass \m{A}. This is not
The problem this check helps to avoid, is a little subtle. The problem does not
arise in the class where the change is done, but in a class derived from it.
This shows that classes acting as superclasses are especially fragile to
-introducing errors in the context of automated refactoring. This is also shown
-in bug\ldots \todoin{File Eclipse bug report}
+introducing errors in the context of automated refactoring.
+\begin{comment}
+This is also shown in bug\ldots \todoin{File Eclipse bug report}
+\end{comment}
\subsection{A double class instance creation}
The following is a problem caused solely by the underlying \MoveMethod
Situations like this would lead to code that will not compile. Therefore, we
have to avoid them by not allowing selections to contain such double class
instance creations that also contains references to fields.
+\begin{comment}
\todoin{File Eclipse bug report}
+\end{comment}
\subsection{Instantiation of non-static inner class}
When a non-static inner class is instantiated, this must happen in the scope of
expressions like \code{this == null}, which would not be meaningful, since
\var{this} would never be \var{null}.
-\section{Finding the example selections that has possible targets}
+\section{Finding the example selections that have possible targets}
We now pick up the thread from \myref{sec:disqualifyingExample} where we have a
set of text selections that needs to be analyzed to find out if some of them are
suitable targets for the \ExtractAndMoveMethod refactoring.
\begin{description}
\item[Selections $(6)$, $(8)$ and $(20)$.] \hfill \\
All these selections have a prefix that contains a possible target, namely
- the variable \var{a}. The problem is that the prefixes are ony one segment
- long, and their frequence counts are only 1 as well. None of these
+ the variable \var{a}. The problem is that the prefixes are only one segment
+ long, and their frequency counts are only 1 as well. None of these
selections are therefore considered as suitable candidates for the
refactoring.
is the variable \var{b}. Both the prefixes have frequency 1. We denote this
with the new tuples $((16), \texttt{b.a}, f(1))$ and $((17), \texttt{b.a},
f(1))$. They contain the selection, the prefix with the target and the
- frequence for this prefix.
+ frequency for this prefix.
\end{description}
unfix \var{a}, due to the assignment, and no other possible move targets.
\item[Selection $(16,17)$.] \hfill \\
- This selection is the last un-analyzed selection on nesting level 2. It
- contains only one possible move target, and that is the variable \var{b}. It
- also contains only one prefix \var{b.a}, with frequency count 2. Therefore
- we have a new candidate $((16,17), \texttt{b.a}, f(2))$.
+ This selection is the last selection that is not analyzed on nesting level
+ 2. It contains only one possible move target, and that is the variable
+ \var{b}. It also contains only one prefix \var{b.a}, with frequency count
+ 2. Therefore we have a new candidate $((16,17), \texttt{b.a}, f(2))$.
\end{description}
\begin{description}
\item[Selection $(5,9)$.] \hfill \\
- This selection contains two variable references that must be analyzed to se
+ This selection contains two variable references that must be analyzed to see
if they are possible move candidates. The first one is the variable
\var{bool}. This variable is of type \type{boolean}, that is a primary type
and therefore not possible to make any changes to. The second variable is
only found in one statement, and in a prefix with only one segment, so it is
not considered to be a possible move target. The only variable left is
\var{b}. Just as in the selection $(16,17)$, \var{b} is part of the prefix
- \code{b.a}, that has 2 appearences. We have found a new candidate $((14,21),
+ \code{b.a}, that has 2 appearances. We have found a new candidate $((14,21),
\texttt{b.a}, f(2))$.
\end{description}
-It remains to se if we get any new candidates by analyzing the multi-statement
+It remains to see if we get any new candidates by analyzing the multi-statement
text selections for nesting level 1:
\begin{description}
\item[Selections $(5,11)$ and $(5,12)$.] \hfill \\
- These seelctions are disqualified for the same reason as $(5,9)$. The only
+ These selections are disqualified for the same reason as $(5,9)$. The only
possible move target \var{a} is an unfix.
\item[Selection $(5,21)$.] \hfill \\
\item[Selection $(11,21)$] \hfill \\
This selection contains the selection $(11,12)$ in addition to the switch
statement. The selection has two possible move targets. The first one is
- \var{b}, in a prefix with frequence 2. The second is \var{a}, although it
+ \var{b}, in a prefix with frequency 2. The second is \var{a}, although it
is in a simple prefix, it is referenced 3 times, and is therefore chosen
as the target for the selection. The new candidate is $((11,21),
\texttt{a}, f(3))$.
\item[Selection $(12,21)$.] \hfill \\
This selection is similar to the previous $(11,21)$, only that \var{a} now
- has frequence count 2. This means that the prefixes \code{a} and
+ has frequency count 2. This means that the prefixes \code{a} and
\code{b.a} both have the count 2. Of the two, \code{b.a} is preferred,
since it has more segments than \code{a}. Thus the candidate for this
selection is $((12,21), \texttt{b.a}, f(2))$.
randomly generated suffix. In the refactoring implementation, the extracted
methods follow the pattern \code{generated\_<long>}, where \code{<long>} is a
pseudo-random long value. This is shortened here to make the example readable.
-The result afte the refactoring is shown in \myref{lst:grandExampleResult}.
+The result after the refactoring is shown in \myref{lst:grandExampleResult}.
\begin{listing}[htb]
\begin{multicols}{2}
Shortcomings}\label{ch:jdt_refactorings}
This chapter will deal with some of the design behind refactoring support in
-\name{Eclipse}, and the JDT in specific. After which it will follow a section about
-shortcomings of the refactoring API in terms of composition of refactorings. The
-chapter will be concluded with a section telling some of the ways the
-implementation of refactorings in the JDT could have worked to facilitate
-composition of refactorings.
-\todoin{will it?}
+\name{Eclipse}, and the JDT in specific. After which it will follow a section
+about shortcomings of the refactoring API in terms of composition of
+refactorings.
\section{Design}
The refactoring world of \name{Eclipse} can in general be separated into two parts: The
\todoin{Write about the
ExtractAndMoveMethodCandidateComparator/FavorNoUnfixesCandidateComparator}
-\paragraph{The complexity}\label{par:complexity} of how many text selections
-that needs to be analyzed for a total of $n$ statements is bounded by $O(n^2)$.
-
-\begin{theorem}
-The number of text selections that need to be analyzed for each list of
-statements of length $n$, is exactly
-
-\begin{equation*}
- \sum_{i=1}^{n} i = \frac{n(n+1)}{2}
- \label{eq:complexityStatementList}
-\end{equation*}
-\label{thm:numberOfTextSelection}
-\end{theorem}
-
-\begin{proof}
- For $n=1$ this is trivial: $\frac{1(1+1)}{2} = \frac{2}{2} = 1$. One statement
- equals one selection.
-
- For $n=2$, you get one text selection for the first statement, one selection
- for the second statement, and one selection for the two of them combined.
- This equals three selections. $\frac{2(2+1)}{2} = \frac{6}{2} = 3$.
-
- For $n=3$, you get 3 selections for the two first statements, as in the case
- where $n=2$. In addition you get one selection for the third statement itself,
- and two more statements for the combinations of it with the two previous
- statements. This equals six selections. $\frac{3(3+1)}{2} = \frac{12}{2} = 6$.
-
- Assume that for $n=k$ there exists $\frac{k(k+1)}{2}$ text selections. Then we
- want to add selections for another statement, following the previous $k$
- statements. So, for $n=k+1$, we get one additional selection for the statement
- itself. Then we get one selection for each pair of the new selection and the
- previous $k$ statements. So the total number of selections will be the number
- of already generated selections, plus $k$ for every pair, plus one for the
- statement itself: $\frac{k(k+1)}{2} + k +
- 1 = \frac{k(k+1)+2k+2}{2} = \frac{k(k+1)+2(k+1)}{2} = \frac{(k+1)(k+2)}{2} =
- \frac{(k+1)((k+1)+1)}{2} = \sum_{i=1}^{k+1} i$
-\end{proof}
-
-%\definition{A \emph{body of statements} is a sequence of statements where every
-%statement may have sub-statements.}
-\todoin{Define ``body of statements''?}
-
-\begin{theorem}
- The number of text selections for a body of statements is maximized if all the
- statements are at the same level.
- \label{thm:textSelectionsMaximized}
-\end{theorem}
-
-\begin{proof}
- Assume we have a body of, in total, $k$ statements. Then, the sum of the
- lengths of all the lists of statements in the body, is also $k$. Let
- $\{l,\ldots,m,(k-l-\ldots-m)\}$ be the lengths of the lists of statements in
- the body, with $l+\ldots+m<k \Rightarrow \forall i \in \{l,\ldots,m\} : i < k$.
-
- Then, the number of text selections that are generated for the $k$ statements
- is
-
- {
- \small
- \begin{align*}
- \frac{l(l+1)}{2} + \ldots + \frac{m(m+1)}{2} +
- \frac{(k-l-\ldots-m)((k-l-\ldots-m)+ 1)}{2} = \\
- \frac{l^2+l}{2} + \ldots + \frac{m^2+m}{2} + \frac{k^2 - 2kl - \ldots - 2km +
- l^2 + \ldots + m^2 + k - l - \ldots - m}{2} = \\
- \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2}
- \end{align*}
- }
-
- \noindent It then remains to show that this inequality holds:
-
- \begin{align*}
- \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2} < \frac{k(k+1)}{2} =
- \frac{k^2 + k}{2}
- \end{align*}
-
- \noindent By multiplication by $2$ on both sides, and by removing the equal
- parts, we get
-
- \begin{align*}
- 2l^2 - 2kl + \ldots + 2m^2 - 2km < 0
- \end{align*}
-
- Since $\forall i \in \{l,\ldots,m\} : i < k$, we have that $\forall i \in
- \{l,\ldots,m\} : 2ki > 2i^2$, so all the pairs of parts on the form $2i^2-2ki$
- are negative. In sum, the inequality holds.
-
-\end{proof}
-
-Therefore, the complexity for the number of selections that needs to be analyzed
-for a body of $n$ statements is $O\bigl(\frac{n(n+1)}{2}\bigr) = O(n^2)$.
-
\subsection{The Prefix Class}
This class exists mainly for holding data about a prefix, such as the expression
The checker visits all nodes of type \type{ClassInstanceCreation} within a
selection. For all of these nodes, if its parent also is a class instance
creation, it accepts a visitor that throws a
-\type{IllegalExpressionFoundException} if it enclounters a name that is a field
+\type{IllegalExpressionFoundException} if it encounters a name that is a field
reference.
\subsection{The InstantiationOfNonStaticInnerClassChecker}
If the selection is free from return statements, then the checker validates. So
this is the first thing the checker investigates.
-If the checker proceedes any further, it is because the selection contains one
+If the checker proceeds any further, it is because the selection contains one
or more return statements. The next test is therefore to check if the last
statement of the selection ends in either a return or a throw statement. The
responsibility for checking that the last statement of the selection eventually
\chapter{Case Studies}
In this chapter I am going to present a few case studies. This is done to give
-an impression of how the seaarch-based \ExtractAndMoveMethod refactoring
+an impression of how the search-based \ExtractAndMoveMethod refactoring
performs when giving it a larger project to take on. I will try to answer where
it lacks, in terms of completeness, as well as showing its effect on refactored
source code.
For conducting these experiments, three tools are used. Two of the ``tools''
both uses Eclipse as their platform. The first is our own tool,
written to be able to run the \ExtractAndMoveMethod refactoring as a batch
-prosess, analyzing and refactoring many methods after each other. The second is
+process, analyzing and refactoring many methods after each other. The second is
JUnit, that is used for running the projects own unit tests on the target code
both before and after it is refactored. The last tool that is used is a code
quality management tool, called \name{SonarQube}. It can be used to perform
\section{Case 1: The Eclipse JDT UI project}
This case is the ultimate test for our \ExtractAndMoveMethod refactoring. The
-target sorce code is massive. With its over 300,000 lines of code and over
+target source code is massive. With its over 300,000 lines of code and over
25,000 methods, it is formidable task to perform automated changes on it. There
-should be plenty of situations where things can go wrong, and, as we shall se
+should be plenty of situations where things can go wrong, and, as we shall see
later, they do.
I will start by presenting some statistics from the refactoring execution,
\end{table}
\subsubsection{Execution time}
-I consider the total exection time of approximately 1.5 hours as being
+I consider the total execution time of approximately 1.5 hours as being
acceptable. It clearly makes the batch process unsuitable for doing any
on-demand analysis or changes, but it is good enough for running periodic jobs,
like over-night analysis.
\end{table}
\subsubsection{Diversity in the number of entities analyzed}
-The analysis performed by \name{SonarCube} is reporting fewer methods than found
+The analysis performed by \name{SonarQube} is reporting fewer methods than found
by the pre-refactoring analysis. \name{SonarQube} discriminates between
functions (methods) and accessors, so the 1,296 accessors play a part in this
calculation. \name{SonarQube} also has the same definition as our plugin when
that our assumptions are wrong, and that increasing indirection does not
decrease coupling between classes. The other possibility is that our analysis
and choices of candidate text selections are not good enough. I vote for the
-second possibility. (Voting againts the public opinion may also be a little
+second possibility. (Voting against the public opinion may also be a little
bold.)
What probably happens is, that many of the times the \ExtractAndMoveMethod
It has now been shown that the \ExtractAndMoveMethod refactoring, in its current
state, produces code that does not compile. Had these errors originated from
only one bug, it would not have been much of a problem, but this is not the
-case. By only looking at some random compilation problems in the refactore code,
+case. By only looking at some random compilation problems in the refactored code,
I came up with at least four different bugs \todo{write bug reports?} that
caused those problems. I then stopped looking for more, since some of the bugs
would take more time to fix than I could justify using on them at this point.
The only thing that can be said in my defence, is that all the compilation
errors could have been avoided if the type of situations that causes them was
properly handled by the primitive refactorings, that again are supported by the
-Eclipse JDT UI project. All of the four randomly found bugs that I menitioned
+Eclipse JDT UI project. All of the four randomly found bugs that I mentioned
before, are also weaknesses of the \MoveMethod refactoring. If the primitive
refactorings had detected the up-coming errors
in their precondition checking phase, the refactorings would have been aborted,
\section{Case 2: The \type{no.uio.ifi.refaktor} project}
In this case we will see a form of the ``dogfooding'' methodology used, when
-refaktoring our own \type{no.uio.ifi.refaktor} project with the
+refactoring our own \type{no.uio.ifi.refaktor} project with the
\ExtractAndMoveMethod refactoring.
In this case I will try to point out some differences from case 1, and how they
Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
Branch & master \\
- Test configration & no.uio.ifi.refaktor.tests/ExtractTest.launch \\
+ Test configuration & no.uio.ifi.refaktor.tests/ExtractTest.launch \\
\bottomrule
\end{tabularx}
\end{table}
methods was chosen.
\paragraph{The average number of possible candidate selection.}
-For the methods that are chosen as candidates, the average numer of possible
+For the methods that are chosen as candidates, the average number of possible
candidate selections for these methods differ quite much. For the JDT project,
the number of possible candidate selections for these methods were 14.44
selections per method, while the candidate methods in the refaktor project had
\subsubsection{Execution time}
The differences in complexity, and the different candidate methods to total
-numeber of methods ratios, is shown in the distributions of the execution times.
+number of methods ratios, is shown in the distributions of the execution times.
For the JDT project, 75\% of the total time was used on the actual changes,
while for the refaktor project, this number was only 63\%.
\subsubsection{Executed refactorings}
For the composite \ExtractAndMoveMethod refactoring performed in case 2, 53
successful attempts out of 58 gives a success rate of 91.4\%. This is 5.3
-eprcentage points worse than for case 1.
+percentage points worse than for case 1.
\subsection{\name{SonarQube} analysis}
Results from the \name{SonarQube} analysis is shown in
All of the errors made, originated from the same bug. It is a bug that happens
in situation where a class instance creation is moved from between packages, and
the class for the instance is package-private. The \MoveMethod refactoring does
-not detect that there will be a visibiliy problem, and neither does it promote
+not detect that there will be a visibility problem, and neither does it promote
the package-private class to be public.
Since the errors was easy to fix manually, I corrected them and ran the unit
supported by the informal experiment presented next.
\subsection{An informal experiment}
-To complete the task of ``eating my own dogfood'', I conducted an informal
+To complete the task of ``eating my own dog food'', I conducted an informal
experiment where I used the refactored version of the \type{no.uio.ifi.refaktor}
project, with the corrections, to again refaktor ``itself''.
\type{no.uio.ifi.refaktor} project, clearly influenced the differences in their
execution times. This is mostly because fewer of the methods were chosen to be
refactored for the refaktor project than for the JDT project. What this makes
-difficult, is to know if there are any severe performance penalties accociated
+difficult, is to know if there are any severe performance penalties associated
with refactoring on a large project compared to a small one.
The trends in the \name{SonarQube} analysis are the same for this case as for
\subsection{The no.uio.ifi.refaktor project}
\subsubsection{no.uio.ifi.refaktor.analyze}
-This package, and its subpackages, contains code that is used for analyzing Java
-source code. The most important subpackages are presented below.
+This package, and its sub-packages, contains code that is used for analyzing
+Java source code. The most important sub-packages are presented below.
\begin{description}
\item[no.uio.ifi.refaktor.analyze.analyzers] \hfill \\
\end{description}
\subsubsection{no.uio.ifi.refaktor.change}
-This package, and its subpackages, contains functionality for manipulate source
+This package, and its sub-packages, contains functionality for manipulate source
code.
\begin{description}
and ``Code Coverage Trend'' reported by Jenkins.
-\chapter{Methodology}
-
-\section{Evolutionary design}
-In the programming work for this project, it have tried to use a design strategy
-called evolutionary design, also known as continuous or incremental
-design\citing{wiki_continuous_2014}. It is a software design strategy
-advocated by the Extreme Programming community. The essence of the strategy is
-that you should let the design of your program evolve naturally as your
-requirements change. This is seen in contrast with up-front design, where
-design decisions are made early in the process.
-
-The motivation behind evolutionary design is to keep the design of software as
-simple as possible. This means not introducing unneeded functionality into a
-program. You should defer introducing flexibility into your software, until it
-is needed to be able to add functionality in a clean way.
-
-Holding up design decisions, implies that the time will eventually come when
-decisions have to be made. The flexibility of the design then relies on the
-programmer's abilities to perform the necessary refactoring, and \his confidence
-in those abilities. From my experience working on this project, I can say that
-this confidence is greatly enhanced by having automated tests to rely on
-\see{tdd}.
-The choice of going for evolutionary design developed naturally. As Fowler
-points out in his article \tit{Is Design Dead?}, evolutionary design much
-resembles the ``code and fix'' development strategy\citing{fowler_design_2004}.
-A strategy that most of us have practiced in school. This was also the case when
-I first started this work. I had to learn the inner workings of Eclipse and its
-refactoring-related plugins. That meant a lot of fumbling around with code I did
-not know, in a trial and error fashion. Eventually I started writing tests for
-my code, and my design began to evolve.
+\chapter{Conclusions and Future Work}
+\todoin{Write}
-\section{Test-driven development}\label{tdd}
-As mentioned before, the project started out as a classic code and fix
-developmen process. My focus was aimed at getting something to work, rather than
-doing so according to best practice. This resulted in a project that got out of
-its starting blocks, but it was not accompanied by any tests. Hence it was soon
-difficult to make any code changes with the confidence that the program was
-still correct afterwards (assuming it was so before changing it). I always knew
-that I had to introduce some tests at one point, but this experience accelerated
-the process of leading me onto the path of testing.
+\section{Future work}
-I then wrote tests for the core functionality of the plugin, and thus gained
-more confidence in the correctness of my code. I could now perform quite drastic
-changes without ``wetting my pants``. After this, nearly all of the semantic
-changes done to the business logic of the project, or the addition of new
-functionality, was made in a test-driven manner. This means that before
-performing any changes, I would define the desired functionality through a set
-of tests. I would then run the tests to check that they were run and that they
-did not pass. Then I would do any code changes necessary to make the tests
-pass. The definition of how the program is supposed to operate is then captured
-by the tests. However, this does not prove the correctness of the analysis
-leading to the test definitions.
-\section{Continuous integration}
-\todoin{???}
+\appendix
\chapter{Eclipse Bugs Found}
analysis stage of our \refa{Extract and Move Method} refactoring. So names representing
variables of local types is considered unfixes \see{unfixes}.
\todoin{write more when fixing this in legal statements checker}
-
-\chapter{Conclusions and Future Work}
-\todoin{Write}
-
-\section{Future work}
-
-\chapter{Related Work}
-
-\section{Safer refactorings}
-\todoin{write}
-
-\section{The compositional paradigm of refactoring}
-This paradigm builds upon the observation of Vakilian et
-al.\citing{vakilian2012}, that of the many automated refactorings existing in
-modern IDEs, the simplest ones are dominating the usage statistics. The report
-mainly focuses on \name{Eclipse} as the tool under investigation.
-
-The paradigm is described almost as the opposite of automated composition of
-refactorings \see{compositeRefactorings}. It works by providing the programmer
-with easily accessible primitive refactorings. These refactorings shall be
-accessed via keyboard shortcuts or quick-assist menus\footnote{Think
-quick-assist with Ctrl+1 in \name{Eclipse}} and be promptly executed, opposed to in the
-currently dominating wizard-based refactoring paradigm. They are meant to
-stimulate composing smaller refactorings into more complex changes, rather than
-doing a large upfront configuration of a wizard-based refactoring, before
-previewing and executing it. The compositional paradigm of refactoring is
-supposed to give control back to the programmer, by supporting \himher with an
-option of performing small rapid changes instead of large changes with a lesser
-degree of control. The report authors hope this will lead to fewer unsuccessful
-refactorings. It also could lower the bar for understanding the steps of a
-larger composite refactoring and thus also help in figuring out what goes wrong
-if one should choose to op in on a wizard-based refactoring.
-
-Vakilian and his associates have performed a survey of the effectiveness of the
-compositional paradigm versus the wizard-based one. They claim to have found
-evidence of that the \emph{compositional paradigm} outperforms the
-\emph{wizard-based}. It does so by reducing automation, which seem
-counterintuitive. Therefore they ask the question ``What is an appropriate level
-of automation?'', and thus questions what they feel is a rush toward more
-automation in the software engineering community.
-
-
\backmatter{}
\printglossaries
\printbibliography
git://git.uio.no / ifi-stolz-refaktor.git / blobdiff