CSC/ECE 517 Fall 2009/wiki1a 9 pp: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
Research in refactoring tools | *Research in refactoring tools* | ||
Refactoring is a very practical subject. A lot of the work in refactoring environments has been done on an ad hoc basis, by practicing programmers. This article briefly summarizes various initiatives that have been taken to improve the current generation of refactoring tools. Refactoring analysis requires serious research. All though the refactoring tools have been used presently for an automated refactoring, the refactoring itself is being performed informally from many years. The automatic refactoring is a result of academic researches being performed in this area since many years. This article will later summarizes the academic underpinning for some popular refactoring methods. | |||
*1. Introduction* | |||
While the integration of refactoring tools into many development environments has increased, the usability of these tools has remained stagnant. Specifically, when refactoring fail, tools communicate the failure to the programmer poorly, causing the programmer to restructure slowly, conservatively, and without preserving behavior. This article summarizes various techniques developed for refactoring correctness, speed, and user satisfaction and improving the usability of refactoring tools. In the long run, better usability will aid in the adoption and utilization of refactoring tools. | While the integration of refactoring tools into many development environments has increased, the usability of these tools has remained stagnant. Specifically, when refactoring fail, tools communicate the failure to the programmer poorly, causing the programmer to restructure slowly, conservatively, and without preserving behavior. This article summarizes various techniques developed for refactoring correctness, speed, and user satisfaction and improving the usability of refactoring tools. In the long run, better usability will aid in the adoption and utilization of refactoring tools. | ||
* | Refactoring is a process of restructuring code without changing the way it behaves. Refactoring can be semi-automated with the help of tools, such as those that are integrated into the Eclipse environment. If these tools help programmers refactor with fewer errors, in less time, and with greater overall satisfaction than refactoring by hand, then programmers are likely to adopt such tools.\\\\** | ||
*2. Improvements in the Refactoring Tools* | |||
There are two main difficulties encountered by programmers while trying to refactor. First, on many occasions programmers are unable to select a list of statements, due to very long statements and inconsistent formatting. Second, is that the programmers have trouble understanding and interpreting error messages produced by the tools, such as “Ambiguous return value: selected block contains more than one assignment to local variable.” These error messages are generally caused by violated refactoring preconditions. | There are two main difficulties encountered by programmers while trying to refactor. First, on many occasions programmers are unable to select a list of statements, due to very long statements and inconsistent formatting. Second, is that the programmers have trouble understanding and interpreting error messages produced by the tools, such as “Ambiguous return value: selected block contains more than one assignment to local variable.” These error messages are generally caused by violated refactoring preconditions. | ||
In order to make the tools user friendly there are several researches being performed. Murphy-Hill [5] proposed add-ons to Eclipse such as SelectionAssist where when the cursor is placed in the whitespace in front of a statement, a green highlight appears over the text range of that statement. Another suggestion was using Refactoring Annotations which tell the programmer that one parameter must be passed in to the extracted method, and that two values must be returned, violating an Extract Method precondition. Refactoring Annotations can also inform the programmer about precondition violations involving control flow. | In order to make the tools user friendly there are several researches being performed. Murphy-Hill [5] proposed add-ons to Eclipse such as SelectionAssist where when the cursor is placed in the whitespace in front of a statement, a green highlight appears over the text range of that statement. Another suggestion was using Refactoring Annotations which tell the programmer that one parameter must be passed in to the extracted method, and that two values must be returned, violating an Extract Method precondition. Refactoring Annotations can also inform the programmer about precondition violations involving control flow. With experimental validations Murphy-Hill [1] found that the usability of refactoring tools increases significantly with these changes this increasing programmers’ speed and correctness. | ||
*3. Academic underpinnings* | |||
* | |||
Refactoring techniques have been used informally since many years and the recent automation is a result on serious academic research that is being performed for many years. Below section describes some popularly used refactoring methods and underlying academic research being performed in the related areas. | Refactoring techniques have been used informally since many years and the recent automation is a result on serious academic research that is being performed for many years. Below section describes some popularly used refactoring methods and underlying academic research being performed in the related areas. | ||
Line 19: | Line 21: | ||
Refactoring Annotations as discussed above could be applied to other software engineering tools, such as compilers. For example, type error messages are notoriously hard for beginners to understand and for experts to track down. | Refactoring Annotations as discussed above could be applied to other software engineering tools, such as compilers. For example, type error messages are notoriously hard for beginners to understand and for experts to track down. | ||
Extract Method has been recognized as one of the most important refactorings, since it decomposes large methods and can be used in combination with other refactorings for fixing a variety of design problems. However, existing tools and methodologies support extraction of methods based on a set of statements selected by the user in the original method. There are researches being performed in order to provide suggestions about Extract Method opportunities. Chatzigeorgiou [12] have already proposed methodology to automatically identify Extract Method refactoring opportunities and present them as suggestions to the designer of an object oriented system. Such techniques require making uses of Program Slicing [2] techniques. | Extract Method has been recognized as one of the most important refactorings, since it decomposes large methods and can be used in combination with other refactorings for fixing a variety of design problems. However, existing tools and methodologies support extraction of methods based on a set of statements selected by the user in the original method. There are researches being performed in order to provide suggestions about Extract Method opportunities. Chatzigeorgiou [12] have already proposed methodology to automatically identify Extract Method refactoring opportunities and present them as suggestions to the designer of an object oriented system. Such techniques require making uses of Program Slicing [2] techniques. According to Weiser [3], a slice consists of all the statements in a program that may affect the value of a variable x at a specific point of interest p. The pair (p, x) is referred to as slicing criterion. In general, slices are computed by finding sets of directly or indirectly relevant statements based on control and data dependencies. There are vast majority of the papers found in the literature of method extraction are based on the concept of program slicing. | ||
When a section of code is duplicated in more than one location among a collection of source files, that section of code and all of its duplicates are considered code clones. Clones are typically generated because a programmer copies a section of code and pastes it into other parts of the same program. Such clones can produce maintenance nightmares. In particular, if a section of code representing a clone is updated, then other sections of code representing clones from the same group may also need to be updated. This scenario creates a challenge for the maintainer to realize the existence of the clones and uniformly update all relevant sections of code. One approach to improve the maintainability of clones is the use of refactoring to eliminate the duplicate code through abstraction and improved modularity. In this case, the maintainability is improved because an update to the section of code is only required in one location. In order to determine clones that have potential for being refactored, analysis of the clones is required. | |||
Clone refactoring analysis requires a significant amount of academicals research foundation. Information Retrieval-Based Analysis technique can be utilized to determine relationships between the groups of clones or clone classes that have been detected by a clone detection tool. | |||
*4. References* | |||
[1] Emerson Murphy-Hill, Improving usability of refactoring tools. | [1] Emerson Murphy-Hill, Improving usability of refactoring tools. | ||
Line 33: | Line 33: | ||
October 2006, ACM | October 2006, ACM | ||
[2] [http://en.wikipedia.org/wiki/Program_slicing] | [2] [Program Slicing|http://en.wikipedia.org/wiki/Program_slicing] | ||
[3] M. Weiser, "Program Slicing," IEEE Transactions on Software Engineering, vol. 10, no. 4, pp. 352-357, 1984. |
Revision as of 19:23, 7 September 2009
- Research in refactoring tools*
Refactoring is a very practical subject. A lot of the work in refactoring environments has been done on an ad hoc basis, by practicing programmers. This article briefly summarizes various initiatives that have been taken to improve the current generation of refactoring tools. Refactoring analysis requires serious research. All though the refactoring tools have been used presently for an automated refactoring, the refactoring itself is being performed informally from many years. The automatic refactoring is a result of academic researches being performed in this area since many years. This article will later summarizes the academic underpinning for some popular refactoring methods.
- 1. Introduction*
While the integration of refactoring tools into many development environments has increased, the usability of these tools has remained stagnant. Specifically, when refactoring fail, tools communicate the failure to the programmer poorly, causing the programmer to restructure slowly, conservatively, and without preserving behavior. This article summarizes various techniques developed for refactoring correctness, speed, and user satisfaction and improving the usability of refactoring tools. In the long run, better usability will aid in the adoption and utilization of refactoring tools.
Refactoring is a process of restructuring code without changing the way it behaves. Refactoring can be semi-automated with the help of tools, such as those that are integrated into the Eclipse environment. If these tools help programmers refactor with fewer errors, in less time, and with greater overall satisfaction than refactoring by hand, then programmers are likely to adopt such tools.\\\\**
- 2. Improvements in the Refactoring Tools*
There are two main difficulties encountered by programmers while trying to refactor. First, on many occasions programmers are unable to select a list of statements, due to very long statements and inconsistent formatting. Second, is that the programmers have trouble understanding and interpreting error messages produced by the tools, such as “Ambiguous return value: selected block contains more than one assignment to local variable.” These error messages are generally caused by violated refactoring preconditions.
In order to make the tools user friendly there are several researches being performed. Murphy-Hill [5] proposed add-ons to Eclipse such as SelectionAssist where when the cursor is placed in the whitespace in front of a statement, a green highlight appears over the text range of that statement. Another suggestion was using Refactoring Annotations which tell the programmer that one parameter must be passed in to the extracted method, and that two values must be returned, violating an Extract Method precondition. Refactoring Annotations can also inform the programmer about precondition violations involving control flow. With experimental validations Murphy-Hill [1] found that the usability of refactoring tools increases significantly with these changes this increasing programmers’ speed and correctness.
- 3. Academic underpinnings*
Refactoring techniques have been used informally since many years and the recent automation is a result on serious academic research that is being performed for many years. Below section describes some popularly used refactoring methods and underlying academic research being performed in the related areas.
Refactoring Annotations as discussed above could be applied to other software engineering tools, such as compilers. For example, type error messages are notoriously hard for beginners to understand and for experts to track down.
Extract Method has been recognized as one of the most important refactorings, since it decomposes large methods and can be used in combination with other refactorings for fixing a variety of design problems. However, existing tools and methodologies support extraction of methods based on a set of statements selected by the user in the original method. There are researches being performed in order to provide suggestions about Extract Method opportunities. Chatzigeorgiou [12] have already proposed methodology to automatically identify Extract Method refactoring opportunities and present them as suggestions to the designer of an object oriented system. Such techniques require making uses of Program Slicing [2] techniques. According to Weiser [3], a slice consists of all the statements in a program that may affect the value of a variable x at a specific point of interest p. The pair (p, x) is referred to as slicing criterion. In general, slices are computed by finding sets of directly or indirectly relevant statements based on control and data dependencies. There are vast majority of the papers found in the literature of method extraction are based on the concept of program slicing.
When a section of code is duplicated in more than one location among a collection of source files, that section of code and all of its duplicates are considered code clones. Clones are typically generated because a programmer copies a section of code and pastes it into other parts of the same program. Such clones can produce maintenance nightmares. In particular, if a section of code representing a clone is updated, then other sections of code representing clones from the same group may also need to be updated. This scenario creates a challenge for the maintainer to realize the existence of the clones and uniformly update all relevant sections of code. One approach to improve the maintainability of clones is the use of refactoring to eliminate the duplicate code through abstraction and improved modularity. In this case, the maintainability is improved because an update to the section of code is only required in one location. In order to determine clones that have potential for being refactored, analysis of the clones is required.
Clone refactoring analysis requires a significant amount of academicals research foundation. Information Retrieval-Based Analysis technique can be utilized to determine relationships between the groups of clones or clone classes that have been detected by a clone detection tool.
- 4. References*
[1] Emerson Murphy-Hill, Improving usability of refactoring tools.
October 2006, ACM
[2] [Program Slicing|http://en.wikipedia.org/wiki/Program_slicing]
[3] M. Weiser, "Program Slicing," IEEE Transactions on Software Engineering, vol. 10, no. 4, pp. 352-357, 1984.