CSC/ECE 517 Fall 2009/wiki1a 9 pp
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.
1. Introduction Refactoring is a process of restructuring code without changing the way it behaves [1]. 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. Problems with Current Tools With an experimental study using Extract Method refactoring Murphy-Hill [5] observed two main difficulties encountered by subjects while trying to refactor. First, on many occasions programmers were unable to select a list of statements, due to very long statements and inconsistent formatting. Second, observation was that 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.
3. New Refactoring Tools With this observation Murphy-Hill [5] proposed few tools for Eclipse. First one of it was SelectionAssist which provides the programmer with a visual cue to the extent of a statement, to assist in accurate statement selection. When the cursor is placed in the whitespace in front of a statement, a green highlight appears over the text range of that statement (Figure 1).
Second suggestion was BoxView. BoxView is as a series of nested boxes adjacent to the program code (Figure 2). When a rectangle is clicked, the corresponding statement is selected. When a statement is selected, the corresponding rectangle is shown in cyan.
Another suggestion was using Refactoring Annotations which tell the programmer why a code segment cannot be extracted by overlaying program code with representations of violated refactoring preconditions. In Figure 3, the programmer has selected and wishes to extract two statements. Refactoring Annotations 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 [5] found that the usability of refactoring tools increases significantly with these changes this increasing programmers’ speed and correctness.
4. 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 can be extended to other refactoring. The research is being conducted to investigate how Refactoring Annotations techniques apply 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. Can annotations help improve understanding of type errors?
Extract Method 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. Chatzigeorgiou [12] proposed methodology to automatically identify Extract Method refactoring opportunities and present them as suggestions to the designer of an objectoriented system. The suggested refactorings adhere to three principles: the extracted code should contain the complete computation of a given variable declared in the original method, the behavior of the program should be preserved after the application of the refactoring, and the extracted code should not be excessively duplicated in the original method. The approach proposed by Chatzigeorgiou [12] is based on the union of static slices that result from the application of a block-based slicing technique. However this technique is developed on top of the vast majority of the papers found in the literature of method extraction based on the concept of program slicing. According to Weiser [13], 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. After the original definition by Weiser, several notions of slicing have been proposed. Concerning the employment of runtime information, static slicing uses only statically available information to compute slices, while dynamic slicing [15] uses as input the values of variables for a specific execution of a program in order to provide more accurate slices. Concerning flow direction, in backward slicing a slice contains all statements and control predicates that may affect a variable at a given point, while in forward slicing [14] a slice contains all statements and control predicates that may be affected by a variable at a given point. Concerning syntax preservation, syntax-preserving slicing simplifies a program only by deleting statements and predicates that do not affect a computation of interest, while amorphous slicing [17] employs a range of syntactic transformations in order to simplify the resulting code. Concerning slicing scope, intraprocedural slicing computes slices within a single procedure, while interprocedural slicing [16] generates slices that cross the boundaries of procedure calls. Program slicing has several applications in various software engineering domains such as debugging, program comprehension, testing, cohesion measurement, maintenance and reverse engineering. Static slicing of object-oriented programs has drawn considerable research interest. A direct application of program slicing in the field of refactorings is slice extraction which is defined as the extraction of the computation of a set of variables V from a program S as a reusable program entity, and the update of the original program S to reuse the extracted slice.
Clone Refactoring [4, 8]: 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. Research has shown that a considerable percentage of code. 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 academic 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.
Balazinska et al. provide categorizations of clones using both difference analysis and context analysis [11]. The former provides difference information based on method signatures or types of parameters and local variables that are used inside the methods. The latter provides information on the context of attributes, methods, and classes of a group of clones to allow measurements of, for example, the coupling strength of the clones. Both analyses seek to provide more information about clones to assist the maintainer in determining the potential for a refactoring opportunity. Komondoor [10] looks for clones that can be refactored through procedural extraction and ARIES [9] uses customized metrics to determine clones that could be combined into a single new method (e.g., using the “Extract Method” and “Pull Up Method” refactoring).
[1] Fowler, M., Beck, K., Brant, J., Opdyke, W. and Roberts, D. Refactoring: Improving the Design of Existing Code.
Addison-Wesley Professional, 1999.
[2] Fowler, M. Crossing Refactoring's Rubicon.
http://www.martinfowler.com/articles/refactoringRubicon.html, 2001.
[3] Emerson Murphy-Hill, Chris Parnin, Andrew P. Black, How we refactor, and how we know it.
IEEE, May 2009
[4] Robert Tairas, Clone detection and refactoring.
ACM, Oct 2006
[5] Emerson Murphy-Hill, Improving usability of refactoring tools.
October 2006, ACM
[6] Steve Berzcuk, Michael Feathers, Steven Fraser, Dennis Mancl, Bill Opdyke, Living with legacy: love it or leave it?
October 2005, ACM
[7] Danny Dig, Robert M. Fuhrer, Ralph Johnson , The 2nd workshop on refactoring tools (WRT'08).
October 2008, ACM
[8] Robert Tairas, Clone maintenance through analysis and refactoring.
October 2008, ACM
[9] Higo, Y., Kamiya, T., Kusumoto, S., and Inoue, K. ARIES: Refactoring Support Environment Based on Code Clone Analysis.
In Proceedings of the 8th IASTED International Conference on Software Engineering and Applications, Cambridge, MA, November 2004, pp. 222-229.
[10] Komondoor, R. V. Automated Duplicated-Code Detection and Procedure Extraction. Ph.D. Thesis, University of Wisconsin-Madison, Madison, WI,
2003.
[11] Balazinska, M., Merlo, E., Dagenais, M., Lague, B., and Kontogiannis, K. Advanced Clone-Analysis to Support
Object-Oriented System Refactoring. In Proceedings of the Working Conference on Reverse Engineering, Brisbane,
Australia, November 2000, pp. 98-107.
[12] Tsantalis, N.; Chatzigeorgiou, A., Identification of Extract Method Refactoring Opportunities
Software Maintenance and Reengineering, 2009. CSMR '09. 13th European Conference on
IEEE, 24-27 March 2009 Page(s):119 – 128
[13] M. Weiser, "Program Slicing," IEEE Transactions on Software Engineering, vol. 10, no. 4, pp. 352-357, 1984. [14] J.-F. Bergeretti, and B.A. Carré, "Information-flow and data-flow analysis of while-programs,"
ACM Transactions on Programming Languages and Systems, vol. 7, no. 1, pp. 37-61, 1985.
[15] B. Korel, and J. Laski, "Dynamic program slicing,"
Information Processing Letters, vol. 29, no. 3, pp. 155-163, 1988.
[16] S. Horwitz, T. W. Reps, and D. Binkley, "Interprocedural Slicing Using Dependence Graphs,"
ACM Transactions on Programming Languages and Systems, vol. 12, no. 1, pp. 26-60, 1990.
[17] M. Harman, D. Binkley, and S. Danicic, "Amorphous Program Slicing,"
Journal of Systems and Software, vol. 68, no. 1, pp. 45-64, 2003.