Automating Three Modes of Evolution for Object-Oriented SoftwareArchitectures

Lance Tokuda, Don Batory

Department of Computer ScienceUniversity of Texas at Austin

Austin, TX 78712-1188{unicron, dsb}@cs.utexas.edu

for

nir

ora

w

gs,e:nn-

hatrend

nreds

h.s

hot-

Abstract1

Architectural evolution is a costly yet unavoidableconsequence of a successful application. One methodfor reducing cost is to automate aspects of theevolutionary cycle when possible. Three kinds ofarchitectural evolution in object-oriented systems are:schema transformations, the introduction of designpattern microarchitectures, and the hot-spot-driven-approach. This paper shows that all three can be viewedas transformations applied to an evolving design.Further, the transformations are automatable withrefactorings — behavior-preserving programtransformations. A comprehensive list of refactoringsused to evolve large applications is provided and ananalysis of supported schema transformations, designpatterns, and hot-spot meta patterns is presented.Refactorings enable the evolution of architectures on anif-needed basis reducing unnecessary complexity andinefficiency.

1 IntroductionAll successful software applications evolve [Par79].During the 1970s, evolution and maintenanceaccounted for 35 to 40 percent of the software budgetfor an information systems organization. This numberjumped to 60 percent in the 1980s. It was predicted thatwithout a major change in approach, many companieswill spend close to 80 percent of their software budgeton maintenance [Pre92]. As applications evolve, so dotheir architectures. Architectures evolve for multiplereasons:

• Capability — to support new features or changes

to existing features.

• Reusability — to carve out software artifacts forreuse in other applications.

• Extensibility — to provide for the addition offuture extensions.

• Maintainability — to reduce the cost of softwaremaintenance through restructuring.

We have observed that architectures also evolvehuman reasons:

• Experience. Experienced employees can oftedesign a better architecture based on theknowledge of the current architecture.

• New Perspective.New project members often havenew ideas about how an architecture couldshould be structured. Many organizations usecode ownership model which empowers neemployees with the ability to realize their newdesigns.

While motivations vary, the methods used for evolvinarchitectures appear to follow regular patternparticularly for object-oriented applications. Threkinds of object-oriented architectural evolution areschema transformations, the introduction of desigpattern microarchitectures, and the hot-spot-driveapproach. Schema transformationsare drawn fromobject-oriented database schema transformations tperform edits on a class diagram [Ban87]. Examples arenaming a class, adding new instance variables, amoving a method up the class hierarchy.Designpatterns are recurring sets of relationships betweeclasses, objects, methods, etc. that define prefersolutions to common object-oriented design problem[Gam95]. Thehot-spot-driven-approachis based on theidentification of aspects of a software program whicare likely to change from application to application (i.ehot-spots) [Pre95]. Architectures using abstract classeand template methods are prescribed to keep these

1. We gratefully acknowledge the sponsorship ofMicrosoft Research, the Defense AdvancedResearch Projects Agency (Cooperative AgreementF30602-96-2-0226), and the University of Texas atAustin Applied Research Laboratories.

ganA,ilyle

es,

m,engdetolya

e,

itnm

ns7]rtsee

spots flexible.

Refactorings are behavior-preserving programtransformations which directly aid in theimplementation of new architectures. Primitiverefactorings perform simple edits such as adding newclasses, creating instance variables, and movinginstance variables up the class hierarchy. Compositionsof refactorings can create abstract classes, captureaggregation and components [Opd92], extract templateand hook methods, and even install design patternmicroarchitectures [Tok95]. Although composingrefactorings to achieve a desired result may requiresome planning, this effort is negligible compared to themanual task of identifying all lines of source codeaffected by a change, performing hand-edits, retestingall fixes, and risking the introduction of new errors.

We are pursuing two approaches to promote refactoringresearch. The first is to evaluate refactorings of largeapplications. We believe that we are the first to provideempirical evidence on the usefulness of refactoringswhen applied to non-trivial applications [Tok99]. In oneexample, a major architectural change — the splitting

of a class hierarchy — is automated2. In a secondexample on a large application (~500K LOCS),approximately fourteen thousand lines of code changesbetween two code releases are automated withrefactorings. (See paper for details.)

A second approach to promoting refactoring research isto demonstrate that common forms of architecturalevolution can be automated. This paper catalogs theschema transformations, design pattern restructurings,and hot-spot meta patterns which can be automatedwith refactorings. By demonstrating broad coverage ofcommon modes of evolution, it is argued thatrefactorings will be generally useful in the evolutionarymaintenance cycle.

A summary of the class diagram notation usedthroughout the remainder of this paper is presented inFigure 1. Within the main body of text, we use thefollowing conventions:

• Refactoring — a refactoring.

• AbstractClass — an abstract class name.

• ConcreteClass — a concrete class name.

• Method() — a method or procedure name.

• Instance_variable — an instance variable.

2 RefactoringsA refactoring is a parameterized behavior-preservinprogram transformation that automatically updatesapplication’s design and underlying source code.refactoring is typically a very simple transformationone that has a straightforward (but not necessartrivial) impact on application source code. An exampis inherit [Base, Derived], which establishes asuperclass-subclass relationship between two classBaseandDerived, that were previously unrelated. Fromthe perspective of an object-oriented class diagrainherit merely adds an inheritance relationship betwetheBaseandDerived classes, but it also checks enablinconditions to determine if the change can be masafely and it alters the application’s source codereflect this change. A refactoring is more precisedefined by (a) a purpose, (b) arguments, (c)description, (d) enabling conditions, (e) an initial statand (f) a target state. Such a definition forinherit [Base,Derived] is given in Figure 2. Applying refactorings issuperior to hand-coding similar changes becauseallow a designer to evolve the architecture of aexisting body of code at the level of a class diagraleaving the code-level details to automation.

Banerjee and Kim proposed a set of schema evolutiofor evolving object-oriented database schemas [Ban8and Opdyke proposed a list of primitive refactorings foobject-oriented languages [Opd92]. Roberts implemenmany of these refactorings for the Smalltalk languag[Rob97]. In addition to previous refactorings, we hav

2. The termautomatedin this paper refers to a refactoring’sprogrammed check for enabling conditions and its execu-tion of all source code changes. The choice of whichrefactorings to apply is always made by a human.

ConcreteSubclass1 ConcreteSubclass2

InstanceVariable

AbstractClass

AbstractOperation()

Operation()

ConcreteClass1owns

Implementation

ConcreteClass2

references

Figure 1: Notation

ch.

ases,inaeisg

found that transforming actual applications requires alarger set. We enlarged the set of schema evolutions toinclude, for example,substitute. Substitute changes aclass’ dependency on some classC to a dependency ona superclass ofC [Tok95]. A second new set ofrefactorings is language-specific.Procedure_to_method and structure_to_class areused to convert C artifacts to their C++ equivalents. Athird set supports the addition of design patternmicroarchitectures in evolving programs [Tok95]. Anexample is add_factory_method which creates amethod returning a new object and replaces all C++invocations of "new Object " with a call to themethod. This refactoring is used to add the FactoryMethod design pattern [Gam95].

A list of refactorings used in our research is presentedin Table 1. Refactorings proposed in previous work are

noted. Refactorings first implemented by our researfor object-oriented software evolution appear in italics

3 Automatable Modes of Evolution

3.1 Schema TransformationsThe database schema for an object-oriented databmanagement system (OODBMS) looks like a clasdiagram for an object-oriented application. SimilarlyOODBMS schema transformations have parallelsobject-oriented software evolution. An example schemtransformation is moving the domain of an instancvariable up the inheritance hierarchy Figure 3.1. Thtransformation is supported by the refactorinpull_up_variable which moves an instance variable to

Figure 2: Inherit[Base, Derived] transformation

Derived

Base

vm*()

(a) Initial State (b) Target state

Name:Inherit[ Base, Derived]

Purpose:To establish a public superclass-subclass relationshipbetween two existing classes.

Arguments:Base - superclass nameDerived - subclass name

Description:Inherit[] makesBasea superclass ofDerived. vm*()

represents the unimplemented virtual methodsinherited byBase subclasses.

Enabling Conditions:• Base must not be a subclass ofDerived andDerived

must not have a superclass.

• Subclasses of Base must support methodsvm*() ifobjects of that class are created. Otherwise, there willbe no implementations forvm*().

• Initializer lists must not be used to initializeDerivedobjects. Initializer lists must initialize aggregates andaggregates cannot have superclasses [Ell90].

• Program behavior must not depend on the size ofDerived. Adding a superclass can affect its size.

Derived

Base

vm*()

Schema Refactorings

add_variablecreate_variable_accessorcreate_method_accessorrename_variableremove_variablepush_down_variablepull_up_variablemove_variable_across_

object_boundarycreate_classrename_classremove_classinherituninheritsubstituterename_methodremove_methodpush_down_methodpull_up_method

move_method_across_object_boundary

extract_code_as_methoddeclare_abstract_methodstructure_to_pointer

C++ Refactorings

procedure_to_methodstructure_to_class

Design Pattern Refactorings

add_factory_methodcreate_iteratorcompositedecoratorprocedure_to_commandsingleton

Table 1: Object-oriented refactorings

1. [Ban87]2. [Opd92]3. [Tok95]4. [Rob97]

Base

Derived

Base

iv

instance variables "iv" from

Derived

iv

Figure 3.1: Using pull_up_variable to move

Derived to Base

leeyt-

a superclass.

Banerjee and Kim describe 19 object-oriented databaseschema transformations of which we implement 12 as

automated refactorings3:

Three other useful schema transformations not listed in

[Ban87] are:

Schema transformations perform many of the simpedits encountered when evolving class diagrams. Thcan be used alone or in combination to evolve objecoriented architectures.

Description fromBanerjee and Kim

[Ban87]Refactoring from Table 1

Adding a newinstance variable

add_variable

Drop an existinginstance variable

remove_variable

Change the name ofan instance variable

rename_variable

Change the domainof an instance vari-able

pull_up_variable andpush_down_variable

Drop the compositelink property of an

instance variablea

a. A classA with an instance variable of classB havingthecomposite link property specifies thatA ownsB.B cannot be created independently ofA andB can-not be accessed through a composite link of anotherobject.

structure_to_pointer

Drop an existingmethod

remove_method

Change the name ofa method

rename_method

Make a classS asuperclass of classC

inherit

Remove classS as asuperclass of classC

uninherit

Add a new class create_class

Drop an existingclass

remove_class

Change the name ofa class

rename_class

3. The seven refactorings which are not supported are:changing the value of a class variable, changing thecode of a method, changing the default value of aninstance variable, changing the inheritance parent ofan instance variable, changing the inheritance of amethod, adding a method, and changing the order ofsuperclasses. The first three refactorings are notbehavior-preserving. The next two are not supportedby mainstream object-oriented programming lan-guages. The sixth (adding a method) cannot be auto-mated. The seventh (changing the order ofsuperclasses) is not supported because this researchis currently limited to applications without multipleinheritance.

Description Refactoring

Move a variablethrough a compositelink

move_variable_across_object_boundary (Figure3.2)

Move a methodthrough a compositelink

move_method_across_object_boundary

Change a class’dependency on aclassC to a depen-dency on a superclassS of C

substitute (Figure 3.3)

Object

Point

xy

Point

Object

xy

Figure 3.2: Using move_variable_across_object_bomove instance variables x and y

s

ne].

ennts.ftedan

.

i-

3.2 Design Pattern MicroarchitecturesDesign patterns capture expert solutions to manycommon object-oriented design problems: creation ofcompatible components, adapting a class to a differentinterface, subclassing versus subtyping, isolating thirdparty interfaces, etc. Patterns have been discovered in awide variety of applications and toolkits includingSmalltalk Collections [Gol84], ET++ [Wei88], MacApp[App89], and InterViews [Lin92]. As with databaseschema transformations, refactorings have been shownto directly implement certain design patterns:

We directly support three additional patterns arefactorings:

While design patterns are useful when included in ainitial software design, they are often applied in thmaintenance phase of the software lifecycle [Gam93For example, the original designer may have beunaware of a pattern or additional system requirememay arise that require unanticipated flexibilityAlternatively, patterns may lead to extra levels oindirection and complexity inappropriate for the firssoftware release. A number of patterns can be viewas automatable program transformations applied toevolving design. Examples for the following twopatterns have been documented:

Pattern Description Example

Command Command encapsulates arequest as an object,thereby letting youparameterize clients withdifferent requests, queueor log requests, and sup-port undoable opera-tions. Theprocedure_to_command refactorings converts aprocedure to a commandclass.

[Tok99]

FactoryMethod

Factory Method definesan interface for creatingan object, but lets sub-classes decide whichclass to instantiate. Theadd_factory_methodrefactoring adds a fac-tory method to a class.

[Tok95]

Letter

Filer Document

Letter

Filer Document

Figure 3.3: Using substitute to changeFiler ’sreference to a Letter to a reference to aDocument

Singleton Singleton ensures a classwill have only oneinstance and provides aglobal point of access toit. Thesingletonrefactor-ing converts an emptyclass into a singleton.

[Tok99]

Pattern Description

Composite Composite composes objects into treestructures to represent part-whole hier-archies. Thecomposite refactoringconverts a class into a composite class

Decorator Decorator attaches additional responsbilities to an object dynamically. Thedecorator refactoring converts a classinto a decorator class.

Iterator Iterator provides a way to access theelements of an aggregate objectsequentially without exposing itsunderlying representation. Thecreate_iterator refactoring generatesan iterator class.

Pattern Description Example

AbstractFactory

Abstract Factory provides aninterface for creating fami-lies of related or dependentobjects without specifyingtheir concrete class.

[Tok95]

Pattern Description Example

At least five additional patterns from [Gam95] can beviewed as a program transformations:

In all cases, we can apply refactorings to simple designsto create the designs used as prototypical examples in[Gam95]. The following sections show how the firsttwo patterns can be automated.

3.2.1 Adapter

Adapter lets classes work together that couldn’totherwise because of incompatible interfaces. In theobject adapter example from [Gam95] (Figure 3.4), theTextShape class adaptsTextView’s GetExtent()

method to implementBoundingBox() . The adaptercan be constructed from the originalTextView class(Figure 3.5) in five steps:

1. Create the classesTextShape andShape usingcreate_class.

2. MakeTextShapea subclass ofShapeusing inherit(Figure 3.6).

3. Add thetext instance variable toTextShapeusingadd_variable (Figure 3.7).

4. Create theBoundingBox() method which callstext->GetExtent() usingcreate_method_accessor.Create_accessor_methodcreates a method whichreplaces calls of the forminstance_variable-

>method() .

5. Declare BoundingBox() in Shape usingdeclare_virtual_method (Figure 3.4).

Visitor Visitor lets you define a newoperation without changingthe classes of the elementson which it operates.

[Rob97]

Pattern Description

Adapter Adapter lets classes work together thatcouldn’t otherwise because of incom-patible interfaces.

Bridge Bridge decouples an abstraction from itsimplementation so that the two can varyindependently.

Builder Builder separates the construction of acomplex object from its representationso that the same construction processcan create different representations.

Strategy Strategy lets algorithms vary indepen-dently from the clients that use them.

TemplateMethod

Template Method lets subclasses rede-fine certain steps of an algorithm with-out changing the algorithm structure.

Pattern Description Example

Shape

BoundingBox()

text TextView

text->GetExtent();

TextShape

BoundingBox() GetExtent()

Figure 3.4: TextShape adapts TextView’sinterface

TextView

GetExtent()

Figure 3.5: Unadapted TextView class

Shape

TextViewTextShape

GetExtent()

Figure 3.6: Adapter class created

Figure 3.7: Adaptee instance variable addedto adapter

Shape

text TextViewTextShape

GetExtent()

en

3.2.2 Bridge

Bridge decouples an abstraction from itsimplementation so that the two can vary independently.In the example from [Gam95] (Figure 3.8), theWindowabstraction andWindowImp implementation are placedin separate hierarchies. All operations onWindowsubclasses are implemented in terms of abstractoperations from theWindowImp interface. Only theWindowImp hierarchy needs to be extended to supportanother windowing system. We refer to the relationshipbetweenWindow andWindowImp as a bridge because itbridges the abstraction and its implementation, allowingthem to vary independently.

Refactorings can be used to install a bridge designpattern given a simple design committed to a singlewindow system. Figure 3.9 depicts a system designedfor X-Windows. This system can be evolved with

refactorings to use the bridge design pattern in sevsteps:

1. Create classesXWindow andWindowImp usingcreate_class.

2. Make WindowImp a superclass ofXWindow withinherit (Figure 3.10).

3. Add instance variableimp to the Window classusingadd_variable (Figure 3.11).

4. Move methodsDrawLine() and DrawText() tothe XWindow class using the refactoringmove_method_across_object_boundary. Thesemethods are accessed through theimp instancevariable (Figure 3.12 ).

5. Declare methodDrawLine() andDrawText() inWindowImp with declare_abstract_method.

impWindow

DrawRect()DrawText()

imp->DrawLine();

imp->DrawLine();imp->DrawLine();imp->DrawLine();

XWindow

DrawLine()

DrawText()

WindowImp

DrawLine()

DrawText()

XDrawLine();

bridge

Figure 3.8: Bridge design pattern example

Window

DrawRect()DrawText()

DrawLine();

DrawLine();DrawLine();DrawLine();

XDrawLine();DrawLine()

Figure 3.9: Design for a single window system

Window

DrawRect()DrawText()DrawLine()

XWindow

WindowImp

DrawLine();

DrawLine();DrawLine();DrawLine();

XDrawLine();

Figure 3.10: Implementor classes created

Window

DrawRect()DrawText()DrawLine()

impXWindow

WindowImp

DrawLine();

DrawLine();DrawLine();DrawLine();

XDrawLine();

Figure 3.11: Implementor instance variableadded toWindow

alln,se.

s

4on

nd

nse,

toe

husrerya

en

6. Change the type of instance variableimp fromXWindow to WindowImp using substitute (Figure0.13).

7. Add aDrawText() method toWindow which callsDrawText() in WindowImp usingcreate_method_accessor (Figure 3.8).

The Bridge architecture uses object composition toprovide needed flexibility. Object composition is alsopresent in the Builder and Strategy design patterns. Thetrade-offs between use of inheritance and objectcomposition are discussed in [Gam95, pp. 18-20].Refactorings allow a designer to safely migrate fromstatically checkable designs using inheritance todynamically defined designs using object-composition.

3.2.3 Role of Refactorings for Design Pat-terns

Gamma et. al. note that a common design pattern pitfis overenthusiasm: "Patterns have costs (indirectiocomplexity) therefore [one should] design to be aflexible as needed, not as flexible as possible." Thexample from [Gam96] is displayed in Figure 3.14Instead of creating a simpleCircle class, anoverenthusiastic designer adds aCircle factory withstrategies for each method, a bridge to aCircleimplementation, and aCircle decorator. The design islikely to be more complex and inefficient that what iactually required. The migration from a singleCircleclass to the complex microarchitecture in Figure 3.1can be viewed as a transformation. This transformati

is in fact automatable with refactorings4. Thus, insteadof overdesigning, one can start with a simpleCircleclass and add the Factory Method, Strategy, Bridge, aDecorator design patterns as needed.

Refactorings can restructure existing implementatioto make them more flexible, dynamic, and reusablhowever, their ability to affect algorithms is limited.Patterns such as Chain of Responsibility and Memenrequire that algorithms be designed with knowledgabout the patterns employed. These patterns are tconsidered fundamental to a software architectubecause there is no refactoring enabled evolutionapath which leads to their use. Refactorings allowdesigner to focus on fundamental patterns wh

Figure 3.12: Window system specific methodsmoved toXWindow class

impWindow

DrawRect()

imp->DrawLine();

imp->DrawLine();imp->DrawLine();imp->DrawLine();

XWindow

DrawLine()

WindowImp

DrawText()

XDrawLine();

impWindow

DrawRect()

imp->DrawLine();

imp->DrawLine();imp->DrawLine();imp->DrawLine();

XWindow

DrawLine()

DrawText()

WindowImp

DrawLine()

DrawText()

XDrawLine();

Figure 3.13: Virtual methods declared so that"imp" can be generalized toclassWindowImp

4. A Circle factory is created [Tok95]. Strategies areadded (Section 3.2). The Bridge pattern is applied(Section 3.2.2). Finally, a decorator is added (Sec-tion 3.2).

Figure 3.14: Overenthusiastic use of designpatterns

Circle

draw()

radius

createCircle()

CircleFactory

bounds()

Circle

draw()bounds()

CircleDecorator

CircleImp

bounds()

BoundsStrategy

draw()

DrawStrategy

creating a new software architecture. Patterns supportedthrough refactorings can be added on an if-needed basisto the current or future architecture at minimal cost.

3.3 Hot-Spot AnalysisThe hot-spot-driven-approach[Pre94] identifies whichaspects of a framework are likely to differ fromapplication to application. These aspects are calledhot-spots. When a data hot-spot is identified, abstractclasses are introduced. When a functional hot-spot isidentified, extra methods and classes are introduced.

3.3.1 Data Hot-Spots

When the instance variables between applications arelikely to differ, Pree prescribed the creation of abstractclasses. Refactorings have repeatedly demonstrated theability to create abstract classes [Opd93, Tok95,Rob97]. As an example, Pree and Sikora provide aMailing System case study [Pre95]. Figure 3.15displays the initial state of its software architecture. Inthis system, Folder cannot be nested, and onlyTextDocument can be mailed. Their suggestedarchitecture is displayed in Figure 3.16. Under theimproved architecture,Folders can be nested and anysubclass ofDesktopItemcan be mailed. Refactorings canautomate these changes in five steps:

1. Create aDesktopItem class usingcreate_class(Figure 3.17).

2. Make DesktopItem a superclass ofTextDocumentusinginherit (Figure 3.18).

3. Generalize the link betweenMailer andTextDocument to a link between Mailer andDesktopItem using substitute (Figure 3.19).Subclasses ofDesktopItem can now be mailed.

4. Generalize the link between Folder and

Mailer

Folder

Mailbox

TextDocument

Figure 3.15: Initial state of mailing system

Mailer

Folder

Mailbox

DesktopItem

TextDocument

Figure 3.16: Final state of mailing system

Mailer

Folder

Mailbox

TextDocument

DesktopItem

Figure 3.17: EmptyTextDocument classcreated

Mailer

Folder

Mailbox

DesktopItem

TextDocument

Figure 3.18:TextDocument inherits fromDesktopItem

ds:

:1

tased

rt

drey).nrns

TextDocument to a link between Folder andDesktopItemusing substitute (Figure 3.20).Foldercan now contain anyDesktopItem.

5. Make Folder a subclass ofDesktopItem usinginherit (Figure 3.16). AFolder which can contain aDesktopItem can now contain anotherFolder.

With the improved architecture, aFolder can be nestedwithin another Folder and DesktopItem provides asuperclass for adding other types of media to be mailed.These changes which would normally be implementedand tested by hand can be automated with refactorings.

3.3.2 Functional Hot-Spots

For the case of differing functionality, solutions basedon templateandhook methodsare prescribed to providethe needed behavior. A template method provides theskeleton for a behavior. A hook method is called by thetemplate method and can be tailored to providedifferent behaviors. Figure 3.21 is an example of atemplate method and hook method defined in the sameclass. Different subclasses ofT can override hook

methodM2() which leads to differing functionality intemplate methodM1(). (Figure 3.22). Pree identifiesseven meta patterns for template and hook methounification, 1:1 connection, 1:N connection, 1:1recursive connection, 1:N recursive connection, 1recursive unification, and 1:N recursive unification[Pre94]. Refactorings automate the introduction of mepatterns into evolving architectures. The transitionbetween patterns enabled by refactorings are display

in Figure 3.235. As examples, we demonstrate suppofor the first two transitions.

In the unification composition, both the template anhook methods are located in the same class (Figu3.21). The behavior of the template is changed boverriding the hook method in a subclass (Figure 3.22An architecture with no template or hook methods cabe transformed to use the unification meta patte(transition 1 from Figure 3.23). Consider the clas

Mailer

Folder

Mailbox

DesktopItem

TextDocument

Figure 3.19:Mailer dependency changed fromTextDocument to DesktopItem

Mailer

Folder

Mailbox

DesktopItem

TextDocument

Figure 3.20:Folder can contain anyDesktopItem

5. We consider the 1:N connection composition to befundamental to an architecture. For this pattern, atemplate object is linked to a collection of hookobjects. This implies that the template method hasknowledge about how to use multiple hook methodsand thus cannot be derived from the 1:1 connectioncomposition in which the template method is codedfor a single hook method.

T

M1()M2()

while (...)M2();

do ...

do special behavior

Figure 3.21: Template and hook methods insame class

T

M1()M2()

while (...)

do special behavior

M2()do ...

H

M2()

Figure 3.22: Hook method M2() overriddenin classH

m

cheedtbern

s

diagram in Figure 3.24 with classT having methodM1()

which calls some special behavior. A hook method canbe added with refactorings in one step:

1. Create a hook methodM2() which executes thespecial behavior usingextract_code_as_method(Figure 3.21).Extract_code_as_methodreplaces ablock of code with a call to a newly created methodwhich executes the block.

In the new microarchitecture, general behavior iscontained in template methodM1() while specialbehavior is captured by hook methodM2() . To extendthe architecture, subclasses ofT override M2() toprovide alternative behaviors forM1() . The extendedstructure can be added in four steps:

1. Create classH usingcreate_class.

2. Make T a superclass ofH using inherit (Figure3.25).

3. MakeM2() overridable by the subclasses ofT usingdeclare_abstract_method.

4. Move the implementation ofM2() into H usingpush_down_method (Figure 3.22).

As a second example, we support the transition frounification to 1:1 connection (transition 2 from Figure3.23). Consider the 1:1 connection meta pattern whistores the hook method in an object owned by thtemplate class (Figure 3.26). Behavior can be changat run-time by assigning a hook object with a differenbehavior to the template class. 1:1 connection canautomated in three steps using the unification patte(Figure 3.21) as a starting point.

1. Create classH usingcreate_class.

2. Add an instance variableref to T withadd_variable (Figure 3.27).

3. Move M2() to class H usingmove_method_across_object_boundary (Figure3.26).

The behavior of template methodM1() can now bealtered dynamically by pointing to different hook clas

Figure 3.23: Hot-spot meta pattern transitionsenabled by refactorings

No meta pattern

1:1 connection

Unification 1:1 recursive unification

1:1 recursive connection

1:N recursive unification

1:N recursive connection

1

2

3

4

5

6

T

M1()while (...)

do special behaviordo ...

Figure 3.24: Method M1() calls a special behaviorwhich differs for each application

T

M1()M2()

while (...)

do special behavior

M2()do ...

H

Figure 3.25: Hook class created

T

M1()

H

M2()

while (...)

do special behaviorref->M2()do ...

ref

Figure 3.26: 1:1 connection

T

M1()

H

M2()

while (...)do special behavior

ref->M2()do ...

ref

Figure 3.27: Connection to H objectcreated

ato

7].g

edsofe

h

toaretot-n

icittKns

ert.ingrsirsis

eodedbyfhedyns

dngt a

cets.tel

objects with different implementations ofM2() . Othertransitions in Figure 3.23 are similarly supported.

3.3.3 Role of Refactorings for Hot-SpotAnalysis

The hot-spot-driven-approach provide a comprehensivemethod for evolving designs to manage change in bothdata and functionality. Pree notes that "the sevencomposition meta patterns repeatedly occur inframeworks." Thus, we expect an ongoing need to addmeta patterns to evolving architectures. The addition ofmeta patterns is currently a manual process. Conditionsare checked to ensure that a pattern can be added safely,lines of affected source code are identified, changes arecoded, the system is tested to check for errors, anyerrors are fixed and the system is retested. Retestingcontinues until the expected likelihood of an error issufficiently low.

This section demonstrates that most meta patterns canbe viewed as transformations from a simpler design.Refactorings automate the transition between designsgranting designers the freedom to create simpleframeworks and add patterns as needed when hot-spotsare identified.

4 Related WorkGriswold developed behavior-preservingtransformations for structured programs written inScheme [Gri91]. The goal of this system was to assistin the restructuring of functionally decomposedsoftware. Software architectures developed using theclassic structured software design methodology[You79] are difficult to restructure because nodes of thestructure chart which define the program pass both dataand control information. The presence of controlinformation makes it difficult to relocate subtrees of thestructure chart. As a result, most transformations arelimited to the level of a function or a block of code.

Object-oriented software architectures offer greaterpossibilities for restructuring. Bergstein defined a smallset of object-preserving class transformations which canbe applied to class diagrams [Ber91]. Lieberherrimplemented these transformations in the Demeterobject-oriented software environment [Lie91]. Exampletransformations are deleting useless subclasses andmoving instance variables between a superclass and asubclass. Bergstein’s transformations are objectpreserving so they cannot add, delete, or move methodsor instance variables exported by a class.

Banerjee and Kim identified a set of schemtransformations which accounted for many changesevolving object-oriented database schema [Ban8Opdyke defined a parallel set of behavior-preservintransformations for object-oriented applications bason the work by Banerjee and Kim, the design principleof Johnson and Foote [Joh88], and the design historythe UIUC Choices software system [May89]. Thestransformations were termedrefactorings. Robertsdeveloped the Smalltalk Refactory Browser whicimplements many of these refactorings [Rob97].

Tokuda and Batory proposed additional refactoringssupport design patterns as targets states for softwrestructuring efforts [Tok95]. Refactorings are shownsupport the addition of design patterns to objecoriented applications [Tok95, Rob97, Sch98]. Winseused refactorings to make design patterns more expl[Win96]. Tokuda and Batory demonstrated tharefactorings can automate significant (greater than 10lines of code) changes when applied to real applicatio[Tok99].

A number of tools instantiate a design pattern and insit into existing source code [Bud96, Kim96, Flo97]Instantiations are not necessarily refactorings, so testof any changes may be required. Florijn and Meijecheck invariants governing a pattern and repaviolations when possible. Refactorings do not have thpattern-level knowledge.

5 SummaryArchitectural evolution is a costly yet unavoidablconsequence of a successful application. One methfor reducing cost is to automate aspects of thevolutionary cycle when possible. For object-orienteapplications in particular, there are regular patternswhich architectures evolve. Three modes oarchitectural evolution are: schema transformations, tintroduction of design pattern microarchitectures, anthe hot-spot-driven-approach. Many evolutionarchanges can be viewed as program transformatiowhich are automatable with object-orienterefactorings. Refactorings are superior to hand-codibecause they check enabling conditions to ensure thachange can be made safely, identify all lines of sourcode affected by a change, and perform all ediRefactorings allow architectural evolution to occur athe level of a class diagram and leave the code-levdetails to automation.

Architectures should evolve on an if-needed basis:

ble

rt,

ty,

n

g

of

red

dd

• "Complex systems that work evolved from simplesystems that worked." — Booch

• "Start stupid and evolve." — Beck

Refactorings directly address the need to evolve fromsimple to complex designs by automating manycommon design transitions. We believe that themajority of all object-oriented applications undergoessome form of automatable evolution. The broad scopeof supported changes indicates that refactorings canhave a significant impact when applied to evolvingdesigns. This claim is validated with real applications in[Tok99] where many hand-coded changes between twomajor releases of two software systems are automated.

The limiting factor barring the widespread acceptanceof refactoring technology appears to be the availabilityof production quality refactorings for the two mostpopular object-oriented languages: C++ and Java. Ourcurrent research identifies implementation issues forC++ [Tok99].

References[Ban87] J. Banerjee and W. Kim. Semantics andImplementation of Schema Evolution in Object-Oriented Databases. InProceedings of the ACMSIGMOD Conference, 1987.

[Ber91] P. Bergstein. Object-Preserving ClassTransformations. InProceedings of OOPSLA ’91,1991.

[Bud96] F. J. Budinsky et.al., Automatic CodeGeneration from Design Patterns. InIBM SystemsJournal, Volume 35, No. 2, 1996.

[Ell90] M. Ellis and B. Stroustrup.The Annotated C++Reference Manual. Addison-Wesley, Reading,Massachusetts, 1990.

[Gam93] E. Gamma et. al. Design Patterns: Abstractionand Reuse of Object-Oriented Design. InProceedings,ECOOP ’93, pages 406-421, Springer-Verlag, 1993.

[Gam95] E. Gamma et.al.Design Patterns Elements ofReusable Object-Oriented Software. Addison-Wesley,Reading, Massachusetts, 1995.

[Gam96] E. Gamma et. al.TUTORIAL 29: DesignPatterns Applied.OOPSLA ’96 Tutorial, 1996.

[Gol84] A. Goldberg. Smalltalk-80: The InteractiveProgramming Environment. Addison-Wesley, Reading,

Massachusetts, 1984.

[Gri91] W. Griswold.Program Restructuring as an Aidto Software Maintenance. Ph.D. thesis. University ofWashington. August 1991.

[Joh88] R. Johnson and B. Foote. Designing ReusaClasses. InJournal of Object-Oriented Programming,pages 22-35, June/July 1988.

[Kim96] J. Kim and K. Benner. An Experience UsingDesign Patterns: Lessons Learned and Tool SuppoTheory and Practice of Object Systems, Volume 2, No.1, pages 61-74, 1996.

[Lie91] K. Lieberherr, W. Hursch, and C. Xiao.Object-Extending Class Transformations.Technical report,College of Computer Science, Northeastern Universi360 Huntington Ave., Boston, Massachusetts, 1991.

[Flo97] G. Florijn, M. Meijers, and P. van Winsen.Tool Support for Object-Oriented Patterns. IProceedings, ECOOP ’97, pages 472-495, Springer-Verlag, 1997.

[Opd92] W. F. Opdyke.Refactoring Object-OrientedFrameworks. Ph.D. thesis, University of Illinois, 1992.

[Opd93] W. F. Opdyke and R. E. Johnson. CreatinAbstract Superclasses by Refactoring. InACM 1993Computer Science Conference. February 1993.

[Par79] D. L. Parnas. Designing Software for EaseExtension and Contraction.IEEE Transactions onSoftware Engineering, 5(2):128-138, March 1979.

[Pre94] W. Pree. Meta Patterns — A Means foCapturing the Essentials of Reusable Object-OrientDesign. InProceedings, ECOOP ’94, Springer-Verlag,1994.

[Pre95] W. Pree and H. Sikora.Application of DesignPatterns in Commercial Domains. OOPSLA ’95Tutorial 11, Austin, Texas, October 1995.

[Pre92] R. Pressman.Software Engineering APractitioner's Approach, McGraw Hill, 1992.

[Rob97] D. Roberts, J. Brant, R. Johnson. ARefactoring Tool for Smalltalk. InTheory and Practiceof Object Systems, Vol. 3 Number 4, 1997.

[Sch98] B. Schulz et. al. On the Computer AideIntroduction of Design Patterns into Object-Oriente

Systems. In Proceedings of the 27th TOOLSConference, IEEE CS Press, 1998.

[Tok95] L. Tokuda and D. Batory. Automated SoftwareEvolution via Design Pattern Transformations. InProceedings of the 3rd International Symposium onApplied Corporate Computing, Monterrey, Mexico,October 1995.

[Tok99] L. Tokuda and D. Batory.Evolving Object-Oriented Designs with Refactorings. University ofTexas, Department of Computer Science, TechnicalReport TR99-09, March 1999.

[Wei88] A. Weinand, E. Gamma, and R. Marty. ET++ -- An Object-Oriented Application Framework in C++.In Object-Oriented Programming Systems, Languages,and Applications Conference, pages 46-57, San Diego,California, September 1988.

[Win96] Pieter van Winsen.(Re)engineering withObject-Oriented Design Patterns. Master’s Thesis,Utrecht University, INF-SCR-96-43, November, 1996.

[You79] E. Yourdon and L. Constantine.StructuredDesign. Prentice Hall, 1979.