Automatically generating refactorings to support API evolution

ABSTRACT

When library APIs change, client code should change in response, in order to avoid erroneous behavior, compilation failures, or warnings. Previous research has introduced techniques for generating such client refactorings. This paper improves on the previous work by proposing a novel, lightweight technique that takes advantage of information that programmers can insert in the code rather than forcing them to use a different tool to re-express it. The key idea is to replace calls to deprecated methods by their bodies, where those bodies consist of the appropriate replacement code. This approach has several benefits. It requires no change in library development practice, since programmers already adjust method bodies and/or write example code, and there are no new tools or languages to learn. It does not require distribution of new artifacts, and a tool to apply it can be lightweight. We evaluated the applicability of our approach on a number of libraries and found it to to be applicable in more than 75% of the cases.

REFERENCES

• 1: R. Balzer, J. T. E. Cheatham, and C. Green. Software technology in the 1990's: Using a new paradigm. Computer, 16(11):39--45, Nov. 1983.
• 2: B. W. Boehm. Industrial software metrics top 10 list. IEEE Software, 4(5):84--85, Sept. 1987.
• 3: Borland. Making development a team sport. demo at JavaOne, June 29, 2004.
• 4: Kingsum Chow , David Notkin, Semi-automatic update of applications in response to library changes, Proceedings of the 1996 International Conference on Software Maintenance, p.359, November 04-08, 1996
• 5: Refactoring: improving the design of existing code, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1999
• 6: W. G. Griswold. Program restructuring to aid software maintenance. Technical Report 91-08-04, U. Wash. Dept. of Comp. Sci. & Eng., Seattle, WA, USA, Aug. 1991. PhD dissertation.
• 7: Johannes Henkel , Amer Diwan, CatchUp!: capturing and replaying refactorings to support API evolution, Proceedings of the 27th international conference on Software engineering, May 15-21, 2005, St. Louis, MO, USA [doi>10.1145/1062455.1062512]
• 8: Alex Kalinovsky, Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering, Pearson Higher Education, 2004
• 9: Tom Mens , Tom Tourwé, A Survey of Software Refactoring, IEEE Transactions on Software Engineering, v.30 n.2, p.126-139, February 2004 [doi>10.1109/TSE.2004.1265817]
• 10: W. F. Opdyke. Refactoring: A program restructuring aid in designing object-oriented applications frameworks. Technical Report 1759, University of Illinois at Urbana-Champaign, Dept. of Computer Science, 1992. PhD dissertation.
• 11: T. J. Parr. An overview of SORCERER: A simple tree-parser generator. In Compiler Construction '94, Apr. 1994.
• 12: L. H. Putnam. A general empirical solution to the macro software sizing and estimating problem. IEEE TSE, 4(4):345--361, July 1978.

INDEX TERMS

Primary Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.5 Testing and Debugging

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.2 Design Tools and Techniques
          Subjects: Software libraries
      D.2.7 Distribution, Maintenance, and Enhancement
          Subjects: Restructuring, reverse engineering, and reengineering

General Terms:
Design, Management, Theory, Verification