Specifying and implementing refactorings.
ABSTRACT Modern IDEs for object-oriented languages like Java provide support for a basic set of simple automated refactorings whose behaviour is easy to describe intuitively. It is, however, surprisingly difficult to specify their behaviour in detail. In particular, the popular precondition-based approach tends to produce somewhat unwieldy descriptions if advanced features of the object language are taken into account. This has resulted in refactoring implementations that are complex, hard to understand, and even harder to maintain, yet these implementations themselves are the only precise "specification" of many refactorings. We have in past work advocated a different approach based on several complementary notions of dependencies that guide the implementation, and on the concept of microrefactorings that structure it. We show in this work that these concepts are powerful enough to provide high-level specifications of many of the refactorings implemented in Eclipse. These specifications are precise enough to serve as the basis of a clean-room reimplementation of these refactorings that is very compact, yet matches Eclipse's for features and outperforms it in terms of correctness.
- [Show abstract] [Hide abstract]
ABSTRACT: Some approaches have been used to investigate evidence on how developers refactor their code, whether refactorings activities may decrease the number of bugs, or improve developers’ productivity. However, there are some contradicting evidence in previous studies. For instance, some investigations found evidence that if the number of refactoring changes increases in the preceding time period the number of defects decreases, different from other studies. They have used different approaches to evaluate refactoring activities. Some of them identify committed behavior-preserving transformations in software repositories by using manual analysis, commit messages, or dynamic analysis. Others focus on identifying which refactorings are applied between two programs by using manual inspection or static analysis. In this work, we compare three different approaches based on manual analysis, commit message (Ratzinger's approach) and dynamic analysis (SafeRefactor's approach) to detect whether a pair of versions determines a refactoring, in terms of behavioral preservation. Additionally, we compare two approaches (manual analysis and Ref-Finder) to identify which refactorings are performed in each pair of versions. We perform both comparisons by evaluating their accuracy, precision, and recall in a randomly selected sample of 40 pairs of versions of JHotDraw, and 20 pairs of versions of Apache Common Collections. While the manual analysis presents the best results in both comparisons, it is not as scalable as the automated approaches. Ratzinger's approach is simple and fast, but presents a low recall; differently, SafeRefactor is able to detect most applied refactorings, although limitations in its test generation backend results for some kinds of subjects in low precision values. Ref-Finder presented a low precision and recall in our evaluation.Journal of Systems and Software 04/2013; 86(4):1006–1022. · 1.14 Impact Factor
Conference Paper: Recommending Move Method Refactorings Using Dependency Sets20th Working Conference on Reverse Engineering (WCRE); 01/2013
Conference Paper: Implementing refactorings for FOP: lessons learned and challenges ahead[Show abstract] [Hide abstract]
ABSTRACT: Software product lines (SPL) gain momentum as a mean for developing and managing a set of related software systems under one umbrella. While intensive research on design and implementation of SPLs exist, the consequences of continuous evolution over time such as a decay of design or implementation have been neglected so far. In this context, refactoring has been shown to be an appropriate mean for improving the structure of source code. In this paper, we provide support for fine-grained program refactoring of feature-oriented SPLs. Particularly, we extend existing, object-oriented refactorings by taking the additional dimension of variability into account. To this end, we present the tool VAmPiRE as a basic framework for such refactorings and explain our considerations during implementation, which has been mainly guided by the idea of decomposing refactorings for ease and understandability. Additionally, we provide a detailed discussion about problems and limitations we faced during the implementation and come up with future challenges that have to be tackled for reliable and automated refactoring of software product lines.Proceedings of the 5th International Workshop on Feature-Oriented Software Development; 10/2013