\chapter{Validation}
\section{Robustness}
This section analyzes the robustness of CSeR. Because CSeR adds features to an
existing editor, we must ensure that the existing features of the editor are not
affected. Eclipse provides many editor features, so the most practical way to
validate compatibility is to use CSeR together with other Eclipse tools. We
performed almost 50 test cases to ensure that existing features were not
affected.

These experiments indicate that the tool works in normal scenarios. However, a
tool is robust only if it can also handle edge cases. To evaluate those cases, we
must analyze different kinds of user edits, as explained in the next section.

\subsection{User Editing}
As explained in the requirements chapter, editing a source file involves both
actions and goals. The same goal can be achieved through different actions. A
tool is more robust when it depends on the goal rather than on the particular
action used to reach that goal. Because CSeR compares code during user edits,
actions still matter in practice. This section therefore considers different
types of user edits. \cite{texteditingbib} contributed significantly to this
classification.

\begin{table}[h]
\caption{\textbf{ Analysis Of User Edits in CSeR}}\vspace{1ex} 
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{l l l l c l }
\hline \hline
No & Type & Goal Description & Action Description & Implemented &  References \\ [0.5ex] \hline
1 & \multirow{6} *{Names}  & Creating a name  & Paste or Type & $ \surd $  & Fig \ref{argumentsfig}  \\
2 &                        & Replacing part  & Paste or Type & $\surd$  & Fig \ref{testworldfig}  \\
3 &                        & Correcting typos & Backspace and Type & $\surd$  & Fig \ref{testworldfig}  \\
4 &                        & Replacing name   & Backspace, Type or Paste& $\surd$  & Fig \ref{expressionstmtcase1}  \\
5 &                        & Removing name    & Backspace, Delete or Type & $\surd$  & Fig \ref{expressionstmtcase3}  \\
6 &                        & Splitting a name & Type in between & $\surd$  & Section \ref{splscenariossec}  \\
7 &                        & Renaming & Using tools & $ \times $  &  \\\cline{3-6}
8 & \multirow{5} *{Lists}  & Creating a new list & Type or Paste & $ \surd $  &  \\
9 &                        & Inserting a new element & Type or Paste & $\surd$  & Fig \ref{argumentsfig}  \\
10 &                        & Removing an element & Delete, Type or Backspace & $\surd$  & Fig \ref{arrayinitfig}  \\
11 &                        & Moving an element  & Cut and Paste or Copy Paste and Delete & $\surd$  & Fig \ref{movechangesfig}  \\
12 &                        & Removing entire list & Backspace or Delete  & $\surd$  & Fig \ref{ifdeletefig1}  \\
13 &                        & Flattening a list inside a list & Backspace or Delete  & $\surd$  & Fig \ref{flattenlistfig}\\\cline{3-6}
14 & \multirow{3} *{Expressions}  & Inserting a new expression & Type or Paste & $ \surd $ & Fig \ref{expressionstmtcase2}   \\
15 &                        & Updating an expression & Type or Paste & $\surd$  & Fig \ref{expressionstmtcase1}  \\
16 &                        & Removing an expression & Delete, Type or Backspace & $\surd$  & Fig \ref{expressionstmtcase3}  \\
17 &                        & Moving an expression  & Cut and Paste or Copy Paste and Delete & $\surd$  &  \\
18 & \multirow{2}*{Comments}& Comment code & Type Line or Block comment & $\surd$  & Fig \ref{commentsfig}  \\
19 &                        & Creating annotations &  & $\times$  &   \\
20 &                        & Inside expressions  & Type  Block comments & $\surd$  & Fig \ref{commentsfig}  \\\cline{3-6}
21 & \multirow{2}*{Keywords}& Insert keyword &  & $\times$  &   \\
22 &                        & Update keyword &  & $\times$  &   \\
23 &                        & modify keyword &  & $\times$  &  \\\cline{3-6}
\hline
\end{tabular}}
\label{texteditingtbl}
\end{table}

Table \ref{texteditingtbl} shows different kinds of user edits and the level of
CSeR support for each. A name refers to anything that is not a Java keyword, such
as a method name, class name, or variable name. Lists correspond to structures
that appear between delimiters, such as \{\} around statement lists and () around
parameter lists. List elements are delimited by characters such as semicolons
between statements and commas between parameters. Actions \ref{actiondef} and
goals \ref{goaldef} are explained in the definitions chapter.

\subsection{Special Scenarios}
\label{splscenariossec}

\paragraph{Type Change Edit}

As a design detail, two important operations occur during every keystroke: AST
comparison and position updating. Position updating keeps the CSeR database
aligned so that every tracked position corresponds to an AST node. The complexity
of AST comparison depends on the size of the AST, while the complexity of
position updating depends on the number of tracked positions. Since the number of
tracked positions can be several hundred, updating a single tracked position must
remain lightweight. Therefore, CSeR does not perform AST parsing during position
updates, which makes position updating AST-unaware. In short, position updating
is AST-unaware, while AST comparison is AST-aware.

In Figure \ref{editscenario1fig}, the user types the method ``doB();'' within
the bounds of ``doA();.'' Because position updating is AST-unaware, it treats the
edit as an update to the method and includes the position of ``doB();'' along
with ``doA();.'' The CSeR database then contains $(x,6)\leftrightarrow(x,12)$,
where x is an offset value. As mentioned earlier, CSeR expects every tracked
position to produce an AST for comparison. In this case, the second position does
not produce a single AST because it contains two AST nodes instead of one. This
is called a type-change edit, because the edit changes one method into two
methods or otherwise changes the type of the AST node.

This issue can be solved by removing the corrupted position from the CSeR
database. There are two places where this can be done. The first is during
position updating. To do this without sacrificing performance, CSeR must find the
position updaters involved in the edit and check whether their positions still
produce AST nodes. If not, the position should be removed from the CSeR database.
The second place is during AST comparison: if a tracked position does not produce
an AST, it should be removed from the database.

In the example above, after the user finishes editing, the tracked position
corresponding to ``doA();'' is removed. When CSeR calculates the deleted and
inserted nodes, it finds two inserted nodes and one deleted node. Since
``doA();'' appears in both places and has identical neighbors, the statements are
considered the same and no marker is added for that node. An insert marker is
added only for ``doB();.''


\begin{figure}[ht]
\centering
\scalebox{0.80}{
\includegraphics{../images/editscenario1.png}}
\caption{Type Change Edit}
\label{editscenario1fig}
\end{figure}

\paragraph{Unexpected Consistent State}
CSeR does not compare until a valid AST exists, but a valid AST can be reached
before the user reaches the intended final state. Consider Figure
\ref{editscenario2}. The user wants to insert ``int j=0'' between the two given
lines. As shown in the figure, a consistent state is reached at step 4, with the
two statements ``int i=0;'' and ``int j=i++.'' On comparison, CSeR finds that the
second statement is new and that the statement ``i++'' was deleted. It therefore
adds a red marker for the deletion and a green marker for the new statement.
Once the user finishes typing, CSeR recalculates the changes and displays the
result shown in step 5.

\begin{figure}[hb]
\centering
\scalebox{0.80}{
\includegraphics{../images/editscenario2.png}}
\caption{Unexpected Consistent State }
\label{editscenario2}
\end{figure}

\section{Comparison with Existing Tools}
This section analyzes existing tools and shows why tools that appear to replace
CSeR cannot completely or accurately address the problem considered here. Most of
the tools analyzed are source-differencing tools. The general distinction is that
CSeR is not simply another tool for finding differences between two source files
at one point in time. Instead, it calculates differences between two files that
were identical at some earlier point, and it calculates those differences
incrementally as edits are made.

\subsection{Text Based Tools- diff, Compare-Editor, Version Editor }
Many text-based tools are available. Most use the diff algorithm, which is based
on solving the LCS (Longest Common Subsequence) problem. Because this approach
was developed for text files, it has clear disadvantages when applied to Java
source code. The algorithm cannot distinguish source code from comments. It also
does not understand that the order of fields and methods does not change the
meaning of a Java class.

Another disadvantage occurs when two methods are interchanged. Suppose the first
method is five lines long and the second is ten lines long. A diff-based tool may
sacrifice the shorter method and show correspondence between the longer methods
in both classes. In short, correspondence between smaller methods or fields can
be lost in move operations.

The Eclipse Compare Editor uses an objectified version of
diff\footnote{http://en.wikipedia.org/wiki/Diff}. Even though it can identify
Java tokens and show token-level differences, it still inherits limitations from
its text-based algorithm. Moved methods and fields may not be identified
correctly, and the tool may show correspondence between two methods even when a
better correspondence exists elsewhere.

For example, consider JavaContext and JavaDocContext. Analysis of the two classes
shows that some correspondences are wrong. The method ``evaluate'' on the right
has a corresponding method ``evaluate'' on the left, but the Compare Editor
treats it as a deleted method. Meanwhile, ``getCharacterBeforeStart'' is removed
from JavaContext and has no correspondence on the other side. Figure
\ref{compareeditorfig} shows the incorrect correspondence produced by the
Compare Editor. This happens because the ``evaluate'' method is moved in the
second class.

Version-Editor~\cite{versioneditor} provides tight integration between revision
history and the editor. It makes version data available in context, showing
changes made so far, newly added lines, creation time, change status, and other
details. The changes are calculated against versions in the repository. However,
the comparison is line-based, so the limitations of text-based tools still
apply.


\begin{figure}[hb]
\centering
\includegraphics{../images/compareeditor.png}
\caption{Wrong Correspondence in Eclipse Compare Editor }
\label{compareeditorfig}
\end{figure}

\subsection{AST Based Tools- Breakaway and ChangeDistiller}
Breakaway~\cite{breakaway} supports generalization tasks. It identifies detailed
structural correspondence between classes and prints the calculated
correspondence to the console. ChangeDistiller~\cite{changedistiller} is intended
to find changes between multiple versions of code. It compares trees using a
change-detection algorithm for hierarchically structured information, producing
an edit script that can convert the original version of a tree into the modified
one.

Both tools compare the ASTs of two source files. However, neither tool exactly
addresses the problem considered here. ChangeDistiller is designed to compare
different versions of a single source file, so it expects a higher level of
similarity, such as the same class name. It is therefore less useful for
comparing two different classes. Breakaway, on the other hand, is used for
generalization and expects classes to be similar. Both tools differ from ordinary
source-comparison tools because their comparison is AST-based.

``Level mismatch''~\cite{breakaway} is a common error in tree-comparison
algorithms. It occurs when a statement node is not found to correspond to another
statement even though the statements exist at different AST levels. For example,
one statement may be directly inside a method declaration while the other is
inside an if condition within a method declaration. Figures
\ref{expressionstmtcase2} and \ref{expressionstmtcase3} show how CSeR handles
such cases. CSeR can keep the correspondence between statements even when their
AST levels change.

Compared with both tools, CSeR has an advantage because it begins tracking
changes when the classes are identical and then tracks changes continuously. The
changes are tracked based on the user edit and the AST being edited. For example,
if the parameters in a method declaration are reordered or modified so that the
signatures no longer correspond, ChangeDistiller may fail to find the
correspondence because it does not consider the statements inside the method when
finding correspondence between methods. This can produce poor results.

Breakaway may fail to consider neighbors. For example, when two classes each have
two fields of the same type, Breakaway may show incorrect correspondence because
it does not consider the order or neighbors of each field. Breakaway may also
fail to consider statements inside a method when comparing method declarations.
CSeR, by contrast, considers neighbors when comparing statements. In CSeR, a
statement in the current file whose correspondence is undefined is considered the
same as a statement in the original file only if the statements match and have
matching neighbors.

Breakaway applies a greedy algorithm and takes the first corresponding element
whose similarity is greater than its threshold value. Conceptual disconnect
errors, described in Section 5.1.2 of~\cite{breakaway}, occur when common
elements such as String, =, and ``'' provide enough similarity to exceed the
threshold. Because Breakaway does not search for the best match, it can produce
``Unordered mismatch'' and ``Ordered mismatch'' errors~\cite{breakaway}. These
errors are not relevant to CSeR because of its incremental design.

ChangeDistiller extends the algorithm by Chawathe et al.~\cite{chawathe} for
extracting changes in hierarchically structured data. It is limited in finding an
appropriate number of move operations, particularly for parameter-ordering and
statement-ordering changes. As noted in the limitations section
of~\cite{changedistiller}, parameter changes can affect the ability to find
overall class correspondence. Figure \ref{argumentsfig} shows how CSeR handles
these changes. Parameter changes are calculated when the user edits inside the
parameters, while statement changes are calculated when the user edits inside a
method, so these two kinds of changes are independent.

\subsection{Clone Detectors}
A small experiment was conducted to study clones reported by clone detectors. The
clone detector used in the study was CCFinder\footnote{www.ccfinder.net}, with
its default configuration. All files used in the examples are relevant because
they are later used in the CSeR experiment described in Section
\ref{cserexperimentlbl}. The results are shown in Table \ref{clonedetectorstbl}.
Here we consider five clone groups. LOC refers to lines of code. Missed LOC
refers to lines that should have correspondence but were missed by CCFinder.
\#Clones is the number of clones detected by CCFinder. Missed LOC does not
include lines that appear in only one file, nor does it include spaces or
comments; it counts corresponding lines missed by CCFinder.

\begin{figure}[h]
\centering
\resizebox{\textwidth}{!}{
\includegraphics{../images/ccfinder.png}}
\caption{Calculation of Missed LOC}
\label{ccfinderfig}
\end{figure}

The calculation of ``Missed LOC'' is shown in Figure \ref{ccfinderfig}. The
figure is taken from the CCFinder view. For the file SetFilterWizardPage, the
clones are from ExclusionInclusionDialog. Lines marked ``S'' are treated as
skipped lines, while lines marked ``C'' are corresponding lines calculated by
CCFinder. The other lines exist only in one of the files. In the figure,
comparison is performed with respect to the first file on each row.

The ideal result for the experiment would be a clone detector finding a single
clone without any missed lines. We did not observe that result in the experiment,
which involved five clone groups and 14 files. In most cases, CCFinder found
clones for only part of the class, as shown by the \#Clones value in Table
\ref{clonedetectorstbl}. Even when only one clone was found, as in clone group 5,
there were skipped lines, showing that the clone did not include the entire
class.

In short, clone detectors fail to provide a complete high-level picture. Even the
correspondence provided for code blocks is incomplete or inaccurate. Some
correspondences are left out by clone detectors. This small experiment shows that
class correspondence can become worse when method declarations and fields move,
which is not an uncommon situation.

\begin{table}[h]
\caption{\textbf{ Analysis Of Clones Using CCFinder}}\vspace{1ex} 
\centering
\begin{tabular}{l l l c c }
\hline \hline
No & File Name & LOC & Missed LOC & \#Clones \\ [0.5ex] \hline
1 & \textbf{SetFilterWizardPage} & 340 &  &  \\
 & ExclusionInclusionDialog & 327 & 54 & 5  \\\cline{2-5}
2 &\textbf{NewClassWizardPage} & 292 &  &   \\
 & NewAnnotationWizardPage & 142 & 24 &  2  \\
 & NewEnumWizardPage & 146 & 5 & 2 \\
 & NewInterfaceWizardPage & 133 & 5 & 2  \\\cline{2-5}
3 & \textbf{NewClassCreationWizard} & 96 &  &  \\
 & NewAnnotationCreationWizard & 96 & 0 & 2  \\
 & NewEnumCreationWizard & 96 & 6 & 2  \\
 & NewInterfaceCreationWizard & 96 & 6 & 2   \\\cline{2-5}
4 & \textbf{CleanUpPreferencePage} & 60 &  &   \\
 & CodeFormatterPreferencePage & 62 & 0 & 1  \\\cline{2-5}
5 & \textbf{CodeStylePreferencePage} & 129 &  &   \\
 & CodeAssistPreferencePage & 98 & 6 & 1  \\\cline{2-5}
\hline
\end{tabular}
\label{clonedetectorstbl}
\end{table}

\section{Demonstration of Usefulness}
The usefulness of a tool is measured by the difference it makes in practice. In
the context of CSeR, we claim that the tool can serve as a useful source-code
documentation aid and as a guide for similar activities in the future. The
previous sections discussed problems with existing tools and showed why those
tools cannot correctly or completely address the issue. This section shows how
CSeR addresses the issue, how it manages clones, how the information is
presented, and how programmers can benefit from it. We identified test cases and
applied CSeR to them. These test cases also demonstrate the robustness of the
tool in real-world scenarios.



\subsection{Experiment Setup}
\label{cserexperimentlbl}
First, we identify classes or code that may have been created by copy and paste.
Then we recreate the scenario with CSeR. Identifying appropriate candidates is
not easy. Our approach uses the clone detector CCFinder
\footnote{http://www.ccfinder.net}~\cite{ccfinder} as a starting point, followed
by manual inspection of classes in the same package or related packages. If two
classes appear similar, we screen them further to determine whether they may have
been created by copy and paste. To do this, we compare the positions and spacing
of statements and comments, first at the class level, then at the method level,
and finally at the statement level.

One case from the JLCP \footnote{http://sourceforge.net/projects/gotjava}
project illustrates the issue. A class file had two authors, and the programmer
who copied the file from another file with a different author forgot to remove
the old comments. Once similar files are identified, they must be paired. It is
sometimes difficult to identify which file was copied from which, or which file
should be treated as the original and which as the current file. Because CSeR
supports two-way correspondence, this decision does not affect the experiment.

The current CSeR implementation supports only pairwise comparison, so related
classes must be split into pairs. CSeR always shows changes with respect to
another file. If three classes are similar, we split them into two pairs. For
example, if Class A and Class B are similar, we copy Class A and try to construct
Class B from the copied version. The changes shown by CSeR are tracked and
analyzed in Section \ref{resultssec}.

\textbf{In short, we are trying to recreate the situation the programmer went
through while modifying the clones.}

The test cases were collected from three sources. The first source was the
Eclipse project, specifically the JDT UI, JDT Core, and SWT projects. Eclipse is
a well-known open-source project and provides a good source of carefully written
Java code. The second source was Java Lobby Community Platform (JLCP), a
web-based business project that provides another practical test case. The final
source was clone examples from the literature. Literature clones often include
extreme cases, diverse domains, common cases, or generalized cases. A tool that
passes these cases is more likely to help programmers in practice.

To give a clearer picture of the experiments, two case studies are explained in
detail.

\subsection{Case Study 1 SetFilterWizardPage And ExclusionInclusionDialog}
ExclusionInclusionDialog and SetFilterWizardPage are an interesting case because
they belong to different type hierarchies, yet they are very similar. The parent
class of ExclusionDialog is StatusDialog, while the parent class of
SetFilterWizardPage is NewElementWizardPage. Details of the changes are shown in
Tables \ref{resultstbl} and \ref{resultstblpart2}, and part of the code is shown
in Figure \ref{setfilterfig}. As a rule of thumb, a red marker indicates a
delete operation, a green marker indicates an insert operation, and a yellow
marker indicates an update operation.

\begin{figure}[h]
\centering
\resizebox{\textwidth}{!}{
\includegraphics{../images/setfilter2.png}}
\caption{CSeR Showing SetFilterWizardPage from ExclusionInclusionDialog}
\label{setfilterfig}
\end{figure}

In Figure \ref{setfilterfig}, the differences start with the parent class.
SetFilterWizardPage is a child of NewElementWizardPage, while
ExclusionInclusionDialog is a child of StatusDialog. This change is marked ``1''
and categorized as ``other'' in the update-change type in Table
\ref{resultstblpart2}. Changes ``2'' and ``3'' show the deletion of three fields
from the class. The deleted fields can be seen by hovering near the marker; the
figure shows this for change ``2.''

Similarly, change ``7'' corresponds to the deletion of two statements. As
mentioned earlier, when a delete occurs, CSeR always looks for a place to attach
the marker for the delete operation. In this case, two statements after
``super(parent)'' are deleted, so CSeR places a marker after that statement.
Change ``8'' corresponds to a move operation: the
``fCurrElement=entryToEdit'' statement is moved one statement earlier.

Changes ``4,'' ``5,'' and ``6'' correspond to parameter changes. Change ``5''
indicates the deletion of two parameters, ``ArrayList existingEntries'' and
``IPath outputLocation,'' while ``4'' and ``6'' are marked in green to show newly
inserted parameters. The inner class in the figure does not show any changes
because it has no change from the original file other than position, and the
position of an inner class declaration does not change the meaning of the class.


\subsection{Case Study 2 NewClassCreationWizard And Clones}

A quick comparison of the wizards used to create classes, interfaces, enums, and
annotations shows that they share a substantial amount of code. This case study
includes NewClassCreationWizard, NewEnumCreationWizard,
NewAnnotationCreationWizard, and NewInterfaceCreationWizard. Changes for part of
the code in the editor are shown in Figure \ref{newannotationfig}. The changes
are analyzed in Table \ref{resultstblpart2}.

The figure is shown with respect to NewAnnotationCreationWizard. There are only
five changes. Changes ``1,'' ``2,'' and ``5'' are variable-type changes, while
``3'' and ``4'' are variable-name changes. Every update change carries a message
showing the original node, and this message is shown with change ``5.''

The same kind of change occurs for both NewInterfaceCreationWizard and
NewEnumCreationWizard. NewEnumWizardPage and NewInterfaceWizardPage replace
NewAnnotationWizardPage, respectively, and the variable names are changed in a
similar fashion. This supports the argument that programmers often copy and paste
templates rather than code that will remain identical.

\begin{figure}
\centering
\resizebox{\textwidth}{!}{
\includegraphics{../images/newannotation.png}}
\caption{CSeR Showing NewAnnotationCreationWizard from NewClassCreationWizard}
\label{newannotationfig}
\end{figure}

\subsection{Result Analysis}
\label{resultssec}
The results of the experiments are summarized in Tables \ref{resultstbl},
\ref{resultstblpart2}, \ref{litresultstbl}, and \ref{summaryresultstbl}. One
change excluded from the analysis in all cases is the class-file name. For
example, when NewClassCreationWizard is copied and pasted as
NewAnnotationCreationWizard, the second class goes through Eclipse refactoring,
which changes occurrences of NewClassCreationWizard to NewAnnotationCreationWizard.
Because this is an obvious change, it is not highlighted in the code and is not
included in the data below. After analyzing the changes in different classes, we
created categories for each change type. These categories are explained below.

\paragraph{Division of Changes}
The division of changes is a study of changes observed with CSeR; it is not
directly tied to the design of CSeR. In general, we do not consider overlapping
changes. If there is a new method, we count only one change: the inserted method
declaration. Even though the statements inside the method are also new, they are
not counted separately. The same rule applies to statements: if a statement is
new, the expressions inside it are not counted separately.

The categories are based on experience gained while analyzing the changes. For
example, a broad category such as expression update could include variable-name
changes, literal changes, and method-invocation name changes. Because we observed
many variable-name changes and other specific cases, we treated them separately.
Similarly, literal changes could be split into string, number, and character
literal changes, but the test cases motivated treating them together.

\paragraph{Update Changes }
As shown in Table \ref{summaryresultstbl}, most of the changes were updates. The
largest portions of update changes were variable-name and type updates (V and T).
An update is categorized this way when the variable name or type is changed
partially or completely. For example, if the statement ``Expression statement =
null'' is changed to ``Expression expression=null,'' it is considered a variable
name change (V). If it is changed to ``Body statement =null,'' it is considered a
type change (T). Changing the return type of a method is also considered a type
change.

L stands for literal, and includes string, number, and character literal changes.
Method changes can occur either in a method definition or in a method invocation.
In some cases, such as Case Study 1, a method must be renamed. When that happens,
the places where the method is called inside the class must also change. Both the
declaration and invocation changes are considered method changes.

\begin{figure}[ht]
\centering
\resizebox{\textwidth}{!}{
\includegraphics{../images/others.png}}
\caption{Statement Update change}
\label{stmtupdatefig}
\end{figure}

Special cases in V include ``return null $\rightarrow$ return variableName'' and
``variableName $\rightarrow$ methodName.'' In a case such as Figure
\ref{stmtupdatefig}, it is better to consider the change a statement update
rather than several simple-name updates. Statement updates are explained below.
Other updates include cases where only an ``else block'' or ``else if'' is
deleted while the rest of the statement is maintained. These cases are included
in the other (O) category.

\paragraph{Statement Updates}
From Figure \ref{stmtupdatefig}, it may not initially be obvious that the
statement should be considered an update. After considering the context, however,
there is sufficient reason to treat it that way. If we counted individual changes
in the example, there would be more than six updates involving changes in names,
types, and method names. Instead, we treat these changes as a single statement
update.


\paragraph{Insert \& Delete Changes}
S (Statement), M (Method Declaration), and F (Field Declaration) are
self-explanatory categories. A statement can be an if statement or a method
invocation. C (Class Declaration) includes anonymous inner classes and other
inner classes. P refers to parameters in a method declaration. E (Expression) has
a broader scope: it includes adding new members to an array initializer, adding
only an ``if'' condition, adding new arguments to a method invocation, or adding
a new expression to an existing expression. Delete applies to all the same cases.

\paragraph{Move Changes}
S (Statement), M (Method Declaration), and C (Class Declaration) are defined the
same way as above, except that the operation is a move.





\begin{table}[h]
\caption{\textbf{Inserts \& Deletes In Clones Collected From Projects}}\vspace{1ex} 
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{l l |c|c|c|c|c|c ||c|c|c|c|c|c|}
\hline \hline
\multirow{2}*{No} & \multirow{2}*{File (LOC)} & \multicolumn{6}{c}{Insert} & \multicolumn{6}{c}{Delete} \\\cline{3-14}
 &           & S & E & P & M & F & C & S & E & P & M & F & C  \\ [0.5ex] \hline
 \multicolumn{14}{c}{Eclipse}\\ \hline 
 & \textbf{CodeAssistPreferencePage} (100)		 &&&&&& &&&&&& \\\cline{3-14}
1 & CodeStylePreferencePage (122) 		 &&&1&2&2& &&&&&& \\\cline{2-14}  
 & \textbf{CodeFormatterPreferencePage} (61)		 &&&&&& &&&&&& \\\cline{3-14}
2 & CleanUpPreferencePage (60)		 &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{FoldingPreferencePage} (60) 		 &&&&&& &&&&&& \\\cline{3-14}
3 & MarkOccurrencesPreferencePage (6)		 &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{JavaContext} (767)				 &&&&&& &&&&&& \\\cline{3-14}
4 & JavaDocContext (223)			 &5&&&&3&1 &1&&&25&5& \\\cline{2-14}
 & \textbf{SetFilterWizardPage} (340)			 &&&&&& &&&&&& \\\cline{3-14}
5 & ExclusionInclusionDialog (326)		 &6&&2&1&&&9&&2&1&3&1 \\\cline{2-14}
 & \textbf{NewClassWizardPage} (296)			 &&&&&& &&&&&& \\\cline{3-14}
6 & NewAnnotationWizardPage (145)		 &&&&1&& &13&2&&6&4& \\\cline{3-14}
7 & NewEnumWizardPage (147)			 &&&&1&& &11&1&&6&4& \\\cline{3-14}
8 & NewInterfaceWizardPage (146)		 &&&&&& &11&1&&6&4& \\\cline{2-14}
 & \textbf{NewClassCreationWizard} (95)		 &&&&&& &&&&&& \\\cline{3-14}
9 & NewAnnotationCreationWizard (95)		 &&&1&&& &&&&&& \\ \cline{3-14}
10 & NewEnumCreationWizard (94)		 &&&1&&& &&&&&& \\ \cline{3-14}
11 & NewInterfaceCreationWizard(94)		 &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{PrefixExpression} (337)			 &&&&&& &&&&&& \\\cline{3-14}
12 & PostfixExpression (320)			 &&&&&& &&4&&&4& \\\cline{3-14}
13 & ParenthesizedExpression (189)		 &&&&&& &2&&&3&2&1 \\\cline{2-14}
 & \textbf{ForStatement} (361)			 &&&&&& &&&&&& \\\cline{3-14}
14 & LabeledStatement (275)			 &&&&&& &6&2&&2&4& \\\cline{3-14}
15 & AssertStatement (261)			 &&&&&& &6&2&&2&4& \\\cline{2-14}
 & \textbf{HistoryListAction(C\footnote{callhierarchy package})} (185)	 &&&&&& &&&&&& \\\cline{3-14}
16 & HistoryListAction(T\footnote{typehierarchy package}) (207)	 &&&&&& &&&&&&1 \\\cline{2-14}
 & \textbf{HistoryDropDownAction (C)} (109) &&&&&& &&&&&& \\\cline{3-14}
17 & HistoryDropDownAction (T) (109) &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{CallHeirarchyImageDescriptor} (180)	 &&&&&& &&&&&& \\\cline{3-14}
18 & JavaElementImageDescriptor (300)		 &6&&&5&13& &5&&&&2& \\\cline{2-14}
 & \textbf{TableEditor} (260)			 &&&&&& &&&&&& \\\cline{3-14}
19 & TreeEditor (285)				 &4&&&&2&1 &1&&1&&1& \\\hline
 \multicolumn{14}{c}{JLCP}  \\\hline
 & \textbf{FileDescriptionTag} (75)			 &&&&&& &&&&&& \\\cline{3-14}
20 & FileCreationDateTag (75)			 &&&&&& &&&&&& \\\cline{3-14}
21 & FileTitleTag (75) 			 &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{PanelsDAOFactory} (67) 			 &&&&&& &&&&&& \\\cline{3-14}
22 & LinksDAOFactory (50) 			 &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{UserDAOFactory} (110)			 &&&&&& &&&&&& \\\cline{3-14}
23 & MessagingDAOFactory (122)		 &&&&&& &&&&&& \\\cline{3-14}
24 & GroupDAOFactory (102)			 &&&&&& &&&&&& \\\cline{3-14}
25 & BuddyDAOFactory (121) 			 &&&&&& &&&&&& \\\cline{2-14}
 & \textbf{AddFileCategoryAction} (105) 	         &&&&&& &&&&&& \\\cline{3-14}
26 & AddLicenseAction (111) 			 &3&1&&&1& &2&1&&&& \\\cline{2-14}
 & \textbf{ExpirePollAction} (74) 			 &&&&&& &&&&&& \\\cline{3-14}
27 & DeletePollAction (72)			 &&&&&& &&&&&& \\
\hline
\end{tabular}}
\label{resultstbl}
\end{table}

\begin{table}[h]
\caption{\textbf{ Updates \& Moves In Clones Collected From Projects}}\vspace{1ex} 
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{l l |c|c|c|c|c||c|c|c|}
\hline \hline
\multirow{2}*{No} & \multirow{2}*{File (LOC)} & \multicolumn{5}{c}{Update} & \multicolumn{3}{c}{Move} \\\cline{3-10}
 &           & V & T & L & M & O & S & M & C  \\ [0.5ex] \hline
 \multicolumn{10}{c}{Eclipse}\\ \hline 
 & \textbf{CodeAssistPreferencePage} (100)		 &&&&& &&& \\\cline{3-10}
1 & CodeStylePreferencePage (122) 		 &1&2&&&3 &&& \\\cline{2-10}  
 & \textbf{CodeFormatterPreferencePage} (61)		 &&&&& &&& \\\cline{3-10}
2 & CleanUpPreferencePage (60)		 &2&1&2&& &&& \\\cline{2-10}
 & \textbf{FoldingPreferencePage} (60) 		 &&&&& &&& \\\cline{3-10}
3 & MarkOccurrencesPreferencePage (6)		 &1&1&&& &&& \\\cline{2-10}
 & \textbf{JavaContext} (767)				 &&&&& &&& \\\cline{3-10}
4 & JavaDocContext (223)			 &&&&1& &1&2& \\\cline{2-10}
 & \textbf{SetFilterWizardPage} (340)			 &&&&& &&& \\\cline{3-10}
5 & ExclusionInclusionDialog (326)		 &&&&2&1 &1&1&1 \\\cline{2-10}
 & \textbf{NewClassWizardPage} (296)			 &&&&& &&& \\\cline{3-10}
6 & NewAnnotationWizardPage (145)		 &3&&1&& &&& \\\cline{3-10}
7 & NewEnumWizardPage (147)			 &3&&1&& &&& \\\cline{3-10}
8 & NewInterfaceWizardPage (146)		 &3&&1&& &&& \\\cline{2-10}
 & \textbf{NewClassCreationWizard} (95)		 &&&&& &&& \\\cline{3-10}
9 & NewAnnotationCreationWizard (95)		 &2&3&&& &&& \\ \cline{3-10}
10 & NewEnumCreationWizard (94)		 &2&3&&& &&& \\ \cline{3-10}
11 & NewInterfaceCreationWizard(94)		 &2&3&&& &&& \\\cline{2-10}
 & \textbf{PrefixExpression} (337)			 &&&&& &&& \\\cline{3-10}
12 & PostfixExpression (320)			 &2&&&& &1&& \\\cline{3-10}
13 & ParenthesizedExpression (189)		 &13&&3&8& &&& \\\cline{2-10}
 & \textbf{ForStatement} (361)			 &&&&& &&& \\\cline{3-10}
14 & LabeledStatement (275)			 &14&5&3&6& &&& \\\cline{3-10}
15 & AssertStatement (261)			 &13&6&3&6& &&& \\\cline{2-10}
 & \textbf{HistoryListAction} (callhierarchy) (185)	 &&&&& &&& \\\cline{3-10}
16 & HistoryListAction(typehierarchy) (207)	 &&11&&3& &1&1& \\\cline{2-10}
 & \textbf{HistoryDropDownAction} (callhierarchy) (109) &&&&& &&& \\\cline{3-10}
17 & HistoryDropDownAction (typehierarchy) (109) &12&9&&2& &&2& \\\cline{2-10}
 & \textbf{CallHeirarchyImageDescriptor} (180)	 &&&&& &&& \\\cline{3-10}
18 & JavaElementImageDescriptor (300)		 &&3&&& &&& \\\cline{2-10}
 & \textbf{TableEditor} (260)			 &&&&& &&& \\\cline{3-10}
19 & TreeEditor (285)				 &21&6&&1& &&1& \\\hline
 \multicolumn{10}{c}{JLCP}  \\\hline
 & \textbf{FileDescription} (75)			 &&&&& &&& \\\cline{3-10}
20 & FileCreationDateTag (75)			 &&&1&& &&& \\\cline{3-10}
21 & FileTitleTag (75) 			 &&&1&& &&& \\\cline{2-10}
 & \textbf{PanelsDAOFactory} (67) 			 &&&&& &&& \\\cline{3-10}
22 & LinksDAOFactory (50) 			 &1&2&2&& &&& \\\cline{2-10}
 & \textbf{UserDAOFactory} (110)			 &&&&& &&& \\\cline{3-10}
23 & MessagingDAOFactory (122)		 &9&4&1&2& &&& \\\cline{3-10}
24 & GroupDAOFactory (102)			 &9&4&1&2& &&& \\\cline{3-10}
25 & BuddyDAOFactory (121) 			 &9&4&1&2& &&& \\\cline{2-10}
 & \textbf{fAddFileCategoryAction} (105) 	         &&&&& &&& \\\cline{3-10}
26 & AddLicenseAction (111) 			 &3&&1&&1 &&& \\\cline{2-10}
 & \textbf{ExpirePollAction} (74) 			 &&&&& &&& \\\cline{3-10}
27 & DeletePollAction (72)			 &&&1&& &&& \\\hline
\end{tabular}}
\label{resultstblpart2}
\end{table}



\begin{table}[h]
\caption{\textbf{Clones Collected From Literature}}\vspace{1ex} 
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{l l |c|c|c|c|c|c ||c|c|c|c|c|c||c|c|c|c|c||c|c|c|}
\hline \hline
\multirow{2}*{No} & \multirow{2}*{Desc (LOC)} & \multicolumn{6}{c}{Insert} & \multicolumn{6}{c}{Delete} 
& \multicolumn{5}{c}{Update} & \multicolumn{3}{c}{Move}\\\cline{3-22}
 &           & S & E & P & M & F & C & S & E & P & M & F & C & V & T & L & M & O & S & M & C   \\ [0.5ex] \hline
 & Fig 6 (23) 				 &&&&&& &&&&&& &&&&& &&& \\\cline{3-22}
1\cite{ethnography} & Fig 7 (22)   &4&&&&& &2&&&&& &1&1&&&1 &&& \\\cline{2-22}  
 & Scenario 1 (10) &&&&&& &&&&&& &&&&& &&& 	 \\\cline{3-22}
2\cite{kimprogramelement} & Scenario 1 (12) 	&&1&&&& &&&&&& &&&&& &1&&   \\\cline{2-22}  
 & Scenario 2 (2)  &&&&&& &&&&&& &&&&& &&&  \\\cline{3-22}
3\cite{kimprogramelement} & Scenario 2 (3)   &&&&1&& &&&&&& &&&&1& &&& \\\cline{2-22}  
 & Fig 3a (4)  &&&&&& &&&&&& &&&&& &&&  \\\cline{3-22}
4\cite{changedistiller} & Fig 3b (4)  &&&&&& &&&&&& &&&&1& &&&  \\\cline{2-22}  
 & Fig 8a (4)  &&&&&& &&&&&& &&&&& &&&  \\\cline{3-22}
5\cite{changedistiller} & Fig 8b (5)  &1&&&&& &&&&&& &&&&& &&&  \\\cline{2-22}  
 & Fig 11a (5) &&&&&& &&&&&& &&&&& &&&   \\\cline{3-22}
6\cite{changedistiller} & Fig 11b (10)&1&&&&& &&&&&& &&&&& &&&    \\\cline{2-22}  
 & Fig 12 (1)  &&&&&& &&&&&& &&&&& &&&  \\\cline{3-22}
7\cite{changedistiller} & \ref{argumentsfig} &&&3&&& &&&&&& &&&&& &&&       \\\cline{2-22}  
 &Fig 3 code1       &&&&&& &&&&&& &&&&& &&&    \\\cline{3-22}
8\cite{clonerelated} & Fig 3 code2    &4&&&&& &&&&&& &&&&& &&&   \\\cline{2-22}  
 & Fig 5 code1 &&&&&& &&&&&& &&&&& &&&   \\\cline{3-22}
9\cite{clonerelated} & Fig 5 code2   &3&&&&& &&&&&& &&&&& &&& \\\cline{2-22}  
 & Fig 1 (9)  &&&&&& &&&&&& &&&&1& &&& \\\cline{3-22}
10\cite{scalablebib} & Fig 2 (17)   &1&&&&& &1&&&&& &&&&& &&& \\\cline{2-22}  
\end{tabular}}
\label{litresultstbl}
\end{table}



\begin{table}[h]
\caption{\textbf{Summary Of 533 Changes From Collected Clones}}\vspace{1ex} 
\centering
\begin{tabular}{l l l c }
\hline \hline
No & Change Distribution  & Description & Internal Distribution  \\ [0.5ex] \hline
 & \multirow{5}{*}{Update (49 \%, 261)} &  &  \\
1 & & Variable Name (V) &  49 \%   \\\cline{3-4}
2 & & Variable Type (T) &  26 \%   \\\cline{3-4}
3 & & Method (M) & 15 \%   \\\cline{3-4}
4 & & Literal (L) &  8 \%  \\\cline{3-4}
5 & & Other (O) & $<$2 \%   \\\cline{2-4}
& \multirow{6}{*}{Delete (33 \%, 177)} & &  \\
6 & & Statement (S) & 40 \%   \\\cline{3-4}
7 & & Method Declaration (M) & 28 \%    \\\cline{3-4}
8 & & Field Declaration (F) &  21 \%  \\\cline{3-4}
9 & & Expression (E) &  8 \%  \\\cline{3-4}
10 & & Parameter (P) &  $<1$ \%  \\\cline{3-4}
11 & & Class Declaration (C) & $<1$ \%   \\\cline{2-4}
& \multirow{6}{*}{Insert (16 \%, 82)} & &  \\
12 & & Statement (S) & 46 \%   \\\cline{3-4}
16 & & Field Declaration (F) & 26 \%    \\\cline{3-4}
15 & & Method Declaration (M) & 14 \%  \\\cline{3-4}
13 & & Parameter (P) &   10 \% \\\cline{3-4}
14 & & Expression (E) &  2 \%  \\\cline{3-4}
17 & & Class Declaration (C) &  2 \%    \\\cline{2-4}
& \multirow{6}{*}{Move (2 \%, 13)} & &   \\
18 & & Method Declaration (M) & 54 \%   \\\cline{3-4}
19 & & Statement (S) &   39 \% \ \\\cline{3-4}
20 & & Class Declaration (C) & 7 \%   \\\cline{2-4}
\hline
\end{tabular}
\label{summaryresultstbl}
\end{table}
