Refactoring is a form of program transformation which preserves the semantics of the program. Refactoring frameworks for object-oriented programs were first introduced in 1992 by William Opdyke. Few people apply refactoring in mainstream software development because it is time consuming and error-prone if done by hand. Since then, many refactoring tools have been developed but most of them do not have the capability of analyzing the program code and suggesting which and where refactorings should be applied. Previous work discusses many ways to detect refactoring candidates but such approaches are applied to a separate module. This work proposes an approach to integrate a "code smells'' detector with a refactoring tool.
To the best of our knowledge, no work has established connections between refactoring and finding code smells in terms of program analysis. This work identifies some common analyses required in these two processes. Determining which analyses are used in common allows us to reuse analysis information and avoid unnecessary recomputation which makes the approach more efficient. However, some code smells cannot be detected by using program analysis alone. In such cases, software metrics are adopted to help identify code smells. This work also introduces a novel metric for detecting "feature envy''. It demonstrates that program analysis and software metrics can work well together.
A tool for Java programs called JCodeCanine has been developed using the discussed approach. JCodeCanine detects code smells within a program and proposes a list of refactorings that would help improve the internal software qualities. The programmer has an option whether to apply the suggested refactorings through a "quick fix''. It supports the complete process allowing the programmer to maintain the structure of his software system as it evolves over time.
Our results show that restructuring the program while trying to preserve its behavior is feasible but is not easy to achieve without programmer's declared design intents. Code smells, in general, are hard to detect and false positives could be generated in our approach. Hence, every detected smell must be reviewed by the programmer. This finding confirms that the tool should not be completely automated. An semi-automated tool is best suited for this purpose.
|Advisor:||Boyland, John Tang|
|Commitee:||Munson, Ethan, Webber, Adam Brooks, Zahedi, Fatemeh, Zou, Yi Ming|
|School:||The University of Wisconsin - Milwaukee|
|School Location:||United States -- Wisconsin|
|Source:||DAI-B 74/01(E), Dissertation Abstracts International|
|Keywords:||Code smells, Metrics, Refactoring, Smells, Software quality, Tool support|
Copyright in each Dissertation and Thesis is retained by the author. All Rights Reserved
The supplemental file or files you are about to download were provided to ProQuest by the author as part of a
dissertation or thesis. The supplemental files are provided "AS IS" without warranty. ProQuest is not responsible for the
content, format or impact on the supplemental file(s) on our system. in some cases, the file type may be unknown or
may be a .exe file. We recommend caution as you open such files.
Copyright of the original materials contained in the supplemental file is retained by the author and your access to the
supplemental files is subject to the ProQuest Terms and Conditions of use.
Depending on the size of the file(s) you are downloading, the system may take some time to download them. Please be