refactoring-icsm2001 - Automated Support for Program...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
Automated Support for Program Refactoring using Invariants Yoshio Kataoka , Michael D. Ernst , William G. Griswold , David Notkin University of Washington Box 352350, Seattle WA 98195-2350 USA { kataoka,notkin } University of California San Diego, 0114 La Jolla, CA 92093-0114 USA MIT Lab for Computer Science 545 Technology Square Cambridge, MA 02139 USA Abstract Program refactoring — transforming a program to improve readability, structure, performance, abstraction, maintain- ability, or other characteristics — is not applied in practice as much as might be desired. One deterrent is the cost of de- tecting candidates for refactoring and of choosing the appro- priate refactoring transformation. This paper demonstrates the feasibility of automatically finding places in the program that are candidates for specific refactorings. The approach uses program invariants: when particular invariants hold at a program point, a specific refactoring is applicable. Since most programs lack explicit invariants, an invariant detection tool called Daikon is used to infer the required invariants. We developed an invariant pattern matcher for several common refactorings and applied it to an existing Java code base. Nu- merous refactorings were detected, and one of the developers of the code base assessed their efficacy. 1 Introduction Program refactoring is a technique in which a software engi- neer applies well-defined source-level transformations with the goal of improving the code’s structure and thus reducing subsequent costs of software evolution. Initially developed in the early 1990s [OJ90, Gri91, Opd92, GN93], refactoring is increasingly a part of mainstream software development practices [FBB + 99]. As just one example, one of the basic tenets of Extreme Programming [Bec99] is to refactor on a continual basis, as a fundamental part of the software devel- opment process. Refactoring is not applied in practice as frequently as might be beneficial. There are a number of reasons for this, including managerial (such as, “we need to add features to ship the product, and refactoring doesn’t directly contribute to that”) and technical (such as, “refactoring might break a subtle property of the system, which is too dangerous”). There are a number of tools to help overcome some of these problems: most of these automate the process of safely ap- plying a refactoring that an engineer has determined is ap- propriate (see Section 2). Our research shows the feasibility of another kind of tool to support engineers in refactoring software: automatically finding candidate refactorings. The recommended man- ual method of identifying beneficial refactorings is to ob- serve design shortcomings manifested during development and maintenance [GHJV95]. Unfortunately, design prob- lems may be overlooked or ignored by a programmer, partic-
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 02/24/2012 for the course CSE 503 taught by Professor Davidnotikin during the Spring '11 term at University of Washington.

Page1 / 8

refactoring-icsm2001 - Automated Support for Program...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online