DIAGNOSING REFACTORING DANGERS: FUNNELING LONGLISTED RISKS INTO A NARROW VERDICT

Abstract

As the real world changes, software that works in that world has to adapt. Initially, a program is developed with a specific design in mind, but new requirements later introduced to the software do not always match that existing design. Therefore, adaptions have to be made to make the new requirements fit, but these can lead to lower software quality. To improve the quality of the software, the internal structure of the program has to be revised while the behavior of the program stays the same. This activity is called refactoring. We pay special attention to how it can be guaranteed that a program exhibits the same behavior after a refactoring has been performed. This is known as behavior preservation.
Behaviour preservation analyses are often incomplete, little or no insight is given into the reasons why a refactoring is rejected, and no solutions are given for each of the reasons for rejection. However, programmers prefer that a refactoring engine does not only reject the application of a refactoring. Instead, they prefer insight into the reasons for rejection and possible solutions to satisfy the failed preconditions. And to teach students to refactor, it is important that they understand the complexities of refactoring and learn how to deal with these complexities. Therefore, it is important that, for example before starting a
refactoring task, an overview is given of the dangers that may arise.
Our goal is to design and implement a system for the automatic identification of refactoring dangers that supplies information to generate an advice from. This design should be implemented in a reference implementation (prototype) which can later be extended. Specifically, we focus on how our current knowledge can be implemented and extended, how a modular system can be developed, and how false positive results can be eliminated.
In this thesis, we present a new model to detect refactoring dangers and a first implementation in the form of an Eclipse plugin called ReFD. The model detects dangers by splitting a refactoring up into microsteps that have associated potential risks. A detector examines the code context to determine if the potential risk is present in the code, thus becoming an actual risk. The resulting actual risks are evaluated by a verdict mechanism to remove false positives.
The Eclipse plugin has been shown to be able to detect dangers in a refactoring by closely implementing the aforementioned model. It supports two refactorings, Pull Up Method and Combine Methods into Class, that are based on Fowler’s descriptions and the results of a case study that was performed. In this case study, we reviewed the problems students and experts encounter while performing the Pull Up Method refactoring on a code example.
Streams were developed to chain subdetectors to query the codebase. These streams of program locations can be processed by chaining subdetectors as operations on the stream, much like how Java streams can form a chain of operations. Subdetectors query the codebase by querying a graph representation of it. For this, we use an existing tool called Atlas.
Finally, ReFD was validated against the earlier described case study code example. Both implemented refactorings were tested on multiple inputs and yielded the expected results.

Date of Award	15 Dec 2023
Original language	English
Supervisor	Harrie Passier (Examiner) & Lex Bijlsma (Co-assessor)