ChangeCommander: Recommending Corrective Method Invocation Changes

finished by Jonas Zuberbühler.

A major focus in software evolution research is to learn from the history of a software system to support its ongoing development. Putting the source code change in the center of the investigation has become essential: Guiding source code changes, finding error patterns, or recommending adaptive changes are prominent examples. Their main goal is to support programmers in their daily business.
Consider the following change scenario: You want to insert the method invocation result.add(e.getMessage()), an invocation of the method List.add(..). By exploiting the change history of List.add(..) invocations we intend to 1) distill the difficulty of calling this method, and 2) suggest potential changes that facilitate a correct usage of this method. For instance, we suggest you to add the condition

1. e.getMessage() != null
2. !result.contains(e.getMessage())

before calling the method.

We have already developed an approach to aggregate method invocation changes to provide such suggestions.

The overall objective of this diploma thesis is to build ChangeComander, a recommendation system that suggests method invocation changes when developers add new method invocations. The recommender is to be integrated in Eclipse as part of ChangeDistiller and Evolizer.

The first step is to review the state-of-the-art including:

• Our taxonomy of source code changes and change extraction algorithm.
• Existing approaches on guiding source code changes and recommendation systems.

During the state-of-the-art review, a first prototype of ChangeCommander is to be developed. The prototype shall leverage the existing data that we have already extracted for our explorative study.
The next step is concerned with refining the ChangeCommander prototype with additional change and context information. A possible set can be:

• Including changes of invocations that expect a return value.
• Nested statements that include method invocations.
• Context in which methods are called.

This step further includes the possible refinement of our difficulty ranking scheme and developing a effective confidence value for the suggestions. The confidence value should support the recommender to decide whether a suggestion is adequate. The confidence value should express the relevance of a suggestion for a developer.
Besides the development of JUnit tests (validation) along the development, the emerging ChangeCommander has to be evaluated. For the evaluation we consider the following scenario: The tool collects method invocation changes for the first half of the observation period of a software system. We then replay a sufficient amount of method invocation inserts of the second half of the history. For each of these inserts we check whether the ChangeCommander would suggest the additional changes that were applied during the insertion or in later revisions.

The typical rules of academic work must be followed. "So what is a (Diploma) Thesis" describes guidelines which must be followed. At the end of the thesis, a final report has to be written. The report should clearly be organized, follow the usual academic report structure, and has to be written in English using our s.e.a.l. LaTeX-template.

Since implementing software is also part of this thesis, state-of-the-art design, coding, and documentation standards for the software have to be obeyed.

The diploma thesis has to be concluded with a final presentation for the members of the Software Evolution and Architecture Lab (s.e.a.l.).

Dr. Beat Fluri, Prof. Dr. Harald Gall.

More information on "What is a Diploma Thesis and How to do a Diploma Thesis at IFI" is provided here.