Performing systematic changes by example
Software developers occasionaly needs to perform a "systematic change", i.e. several similar changes in multiple different locations of the source code. In simple cases, a simple "find-replace all" suffices to quickly perform a systematic change. In some cases, such as renaming a method, a refactoring typically already is available to automatically perform the systematic change. In other cases however, developers often resort to performing the systematic change by hand, which is both tedious and error-prone.
Another option would be to use one of the many program transformation tools, such as Ekeko/X, Coccinelle, Stratego/XT, TXL, ... This requires the developer to accurately specify which locations in the source code need to be changed, and what should be added/removed. However, as these tools come with a learning curve, it often takes more time to correctly specify a transformation than it does to perform the change manually.
In this thesis we would like to explore a hybrid approach between using a transformation tool, and manually performing the change. The idea is that a developer first manually performs only one instance of a systematic change in one location, then marks which other locations need to have similar changes applied. Based on this information, a tool could automatically suggest a transformation that performs the systematic change in all locations. (If there are any ambiguities in producing this transformation, the tool could suggest several alternatives.)
To give an example: a developer could upgrade library calls within one method body to a newer API, then mark all the other method bodies (making similar library calls) that need to be upgraded as well. The tool then produces a transformation that performs this upgrade in all method bodies.
The goal of this thesis would be to build an initial prototype of the above idea, using the Ekeko/X transformation tool. Ekeko/X, which is developed here at the Software Languages Lab, is able to perform searches and transformations in Java code. The transformations themselves are specified in terms of code templates, which are essentially code snippets augmented with wildcards, metavariables and special annotations called directives.
To keep the problems to be solved of a manageable size, we will work with the assumption that each instance of a systematic change takes place within a single method declaration. More concretely, the prototype tool would be used as follows: the developer first makes a few modifications within a method body, then selects a set of other methods where similar modifications should be performed as well.
Recording the modifications made by the developer can be done with a change logging or change distilling tool, such as ChangeNodes. Such a tool produces a sequence of changes to AST nodes. We also already have an initial tool that can convert such a sequence of changes into an Ekeko/X transformation. This means the core problem to be solved in this thesis is to take this Ekeko/X transformation, representing one instance of a systematic change, and to adapt it such that it can be applied to the other instances. This involves constructing an algorithm that, given a modification in one method, can figure out where exactly a similar modification should occur in another method, knowing that both modifications must occur in a similar context.
An approach to evaluate the prototype would be to consider a few known systematic changes in the history of existing software projects, to perform these systematic changes once more using the prototype, and determine to what extent the generated transformation produces the correct result.