\chapter{Conclusion \& Future Work}
Developers must manage clones efficiently within software projects. Significant
work has been done in clone detection, but relatively little work has focused on
tracking ``copy and paste'' (CnP) operations, even though those operations play
an important role in clone formation. This thesis demonstrated the advantages of
tracking CnP operations directly.

We presented an approach for clone management based on tracking CnP operations.
Using this approach, detailed differences between clones are available directly
inside the editor. Changes are visualized in different colors to make them easier
to understand. The comparison is context-sensitive and AST-based, which makes the
approach distinctive. We also discussed CSeR (Code Segment Reuse), a
proof-of-concept implementation, and described its design.

We conducted a small experiment involving nine pairs of classes to verify CSeR's
advantages over clone detectors. These test cases were selected from an
industrial project. We also demonstrated CSeR's usefulness and robustness using
37 test cases selected from industrial projects and research publications. The
533 changes identified by CSeR were carefully analyzed and divided into 20
different categories.

\paragraph{Clone groups}
CSeR currently considers clones in pairs. Clone groups occur when more than two
clones are related. For example, when a class is pasted twice, there are three
related clones and therefore a clone group. The current CSeR implementation
represents this situation as two clone pairs: the first and second clones, and
the first and third clones. Although the second and third clones are related, the
current implementation does not identify that relationship.

A better design would connect all related clones as a group. This would allow a
developer to view the differences between any two clones in the group. For
example, when NewAnnotationCreationWizard and NewEnumCreationWizard are both
created from NewClassCreationWizard, a developer should be able to see the
difference between NewEnumCreationWizard and NewAnnotationCreationWizard.

\paragraph{Tracking Code and Identifying Templates}

Consider a scenario in which a developer is working on a large file and suddenly
something stops working. The developer may not know which changes caused the
problem. CSeR could be extended to track changes in code across two editing time
frames. It could also provide a capability to return to the state before an edit.

CSeR already calculates editing regions in clones. Because these edits are based
on the AST, CSeR could be integrated with the Eclipse template feature. As a
rough idea, when a developer pastes a few lines of code, the developer could
activate a CSeR template option. CSeR would calculate the editing regions, pass
that information to the template model, and create a keyed template that could be
used later.

\paragraph{Version Control Integration and Side-by-Side View}
While calculating changes, CSeR saves information related to a class file in a
text file with the same name, and this file is read whenever someone opens the
class file. This mechanism could be extended to version control. If such
integration were available, changes could be shared among users. Comparisons
could also be performed against earlier versions on the local machine or in the
version-control system.

CSeR does not currently have a side-by-side view. It would be useful to integrate
CSeR data with the Eclipse Compare Editor so that users could view comparisons in
a familiar interface while retaining CSeR's more accurate comparison data.
