Abstract1Refactorings are behavior-preserving program transfor-mations that automate design level changes in object-ori-ented applications. Our previous research established thatmany schema transformations, design patterns, and hot-spot meta-patterns are automatable. This research evalu-ates whether refactoring technology can be transferred tothe mainstream by restructuring non-trivial C++ applica-tions. The applications that we examine were evolved man-ually by software engineers. We show that an equivalentevolution could be reproduced significantly faster andcheaper by applying a handful of general-purpose refactor-ings. In one application, over 14K lines of code were trans-formed automatically that otherwise would have beencoded by hand. Our experiments identify benefits, limita-tions, and topics of further research related to the transferof refactoring technology to a production environment.1. IntroductionBefore the invention of graphical user interface (GUI)editors, the process of evolving a GUI was to design, code,test, evaluate, and redesign again. With the introduction ofeditors, GUI design has become an interactive processallowing users to design, evaluate, and redesign an interfaceon-screen and to output compilable source code that reflectsthe latest design.We believe that a similar advance needs to occur for edit-ing object-oriented class diagrams. Editing a class diagramcan be as simple as adding a line between classes to repre-sent an inheritance relationship or moving a variable from asubclass to a superclass. However, such changes must nowbe accompanied by painstakingly identifying lines ofaffected source code, manually updating the source, testingthe changes, fixing bugs, and retesting the application untilthe risk of new errors is sufficiently low.Just as GUI editors revolutionized GUI design, webelieve that class diagram editors (where changes to anapplication’s diagram automatically trigger correspondingchanges to its underlying source code) will revolutionizethe evolution of software design. The technology to powersuch a tool is refactorings — behavior-preserving programtransformations that automate many design level2changes.The term automate refers to a refactoring’s programmedcheck for enabling conditions and its execution of all sourcecode changes. The choice of which design to implementand which refactorings need to be applied is always madeby a human. Refactorings preserve behavior thereby reduc-ing costly and tedious debugging and testing that wouldotherwise have to be performed.2. RefactoringsA refactoring is a parameterized behavior-preservingprogram transformation that updates an application’s designand underlying source code. A refactoring is typically asimple transformation that has a straightforward (but notnecessarily trivial) impact on application source. An exam-ple is inherit[Base, Derived], which establishes a super-class-subclass relationship between two classes, Base andDerived, that were previously unrelated. From the perspec-tive of an object-oriented class diagram, the inherit refac-toring merely adds an inheritance relationship between theBase and Derived classes, but also it alters the application’ssource code to reflect this change.A summary of the class diagram notation used through-out this paper is presented in Figure 2.1.2.1. Enabling ConditionsPrograms are restructured by applying a series of refac-torings. Because individual refactorings preserve behavior,a series of refactorings also preserves behavior. To preservebehavior, we adopt the method proposed by Banerjee andKim for database schema evolutions [2] and employed by1. We gratefully acknowledge the sponsorship of the Defense AdvancedResearch Projects Agency (Cooperative Agreement F30602-96-2-0226)and the University of Texas at Austin Applied Research Laboratories.2. We use a limited definition of the term design referring to the aspect ofdesign reflected in the extended class diagram notation from Gamma [1].Evolving Object-Oriented Designs with RefactoringsLance Tokuda and Don BatoryDepartment of Computer ScienceUniversity of Texas at Austin{unicron, batory}@cs.utexas.eduTo appear in Automated Software Engineering 1999Opdyke for refactorings [3]. Opdyke claimed to identify aset of seven invariants which, if preserved, guaranteed thattwo Smalltalk or C++ programs would run identically. Forexample, his first invariant is that each class must have aunique superclass and its superclass must not also be one ofits subclasses. When a refactoring runs the risk of violatingan invariant, enabling conditions are added to guarantee thatthe invariant is preserved. Enabling conditions for theinherit refactoring are listed in Figure 2.2. Inherit’s firstenabling condition preserves Opdyke’s first invariant.2.2. Design Evolution and RefactoringsThree kinds of object-oriented design evolution are:schema transformations, design pattern microarchitectures,and hot-spots. Schema transformations are drawn fromobject-oriented database schema transformations that per-form edits on a class diagram [2]. Examples are adding newinstance variables and moving methods up the class hierar-chy. Design patterns are recurring sets of relationshipsbetween classes, objects, methods, etc. that define preferredsolutions to common object-oriented design problems [1].Hot-spots are aspects of a program which are likely tochange from application to application [4]. Designs usingabstract classes and template methods are prescribed tokeep these hot-spots flexible.In previous work, we identified a list of schema transfor-mations, design pattern microarchitectures, and hot-spotmeta patterns that were automatable with refactorings [5].Refactorings to enable these changes includes those pro-posed by Banerjee and Kim for evolving object-orienteddatabase schemas [2] and by Opdyke for restructuringobject-oriented programs [3]. We found that transformingactual C++ programs required additional refactorings. Weenlarged the set of schema evolutions to include, for exam-ple, inherit (from the example above) and substitute. Sub-stitute changes a class’s dependency on a class C1 to adependency on a superclass of C1 [6]. Other refactoringsare language-specific; procedure_to_method andstructure_to_class convert C artifacts to their C++ equiva-lents. Yet another set of refactorings supports the additionof design pattern microarchitectures in evolving programs[5, 6]. Examples include add_factory_method, singleton,and
View Full Document
Unlocking...