Automated Software Evolution Towards Design Patterns

Automated Software Evolution Towards Design

Patterns

Advisor Advisor ：： Ku-Yaw ChangKu-Yaw ChangID ID ：： E9406010E9406010InterpreterInterpreter ：： SHIH - CHIEM LIAOSHIH - CHIEM LIAO

Department of Computer Science and Information EngineeringDepartment of Computer Science and Information EngineeringDa-Yeh UniversityDa-Yeh University

AuthorAuthor

Mel Cinneide and Paddy Nixon, "Automated Software EvolutiMel Cinneide and Paddy Nixon, "Automated Software Evolution Towards Design Patterns," Proceedings of the Internatioon Towards Design Patterns," Proceedings of the International Workshop on the Principles of Software Evolution (IWPnal Workshop on the Principles of Software Evolution (IWP

SE), Vienna, September, 2001.SE), Vienna, September, 2001.

Mel ´O Cinn´eideDepartment of Computer ScienceUniversity CollegeDublin Ireland.

[email protected]

Paddy NixonDepartment of Computer ScienceUniversity of Strathclyde Scotand.

[email protected]

Excerpt FromExcerpt From

OutlineOutline• AbstractAbstract• IntroductionIntroduction• Background of methodologyBackground of methodology• methodologymethodology• Precursor of methodologyPrecursor of methodology• Minipattern & Minitransformation of methodologyMinipattern & Minitransformation of methodology• Factory Method transformationFactory Method transformation• Example of methodologyExample of methodology• ResultsResults• ConclusionConclusion• References

ABSTRACT(1)ABSTRACT(1)

• During the evolution of a software systeDuring the evolution of a software system, it may be necessary to m, it may be necessary to refactorrefactor the so the software in order to make it more ftware in order to make it more flexible aflexible and amenablend amenable to new requirements that to new requirements that are being introduced. are being introduced.


• How refactoring A typical to enhance How refactoring A typical to enhance program flexibility ?program flexibility ?

Apply a suitable design pattern Apply a suitable design pattern to the program .to the program .


• Performing such a transformation byPerforming such a transformation by

hand is an error-prone process (X) hand is an error-prone process (X) automated support would be useful (O)automated support would be useful (O)

• We have developed a We have developed a methodologymethodology for for the creation of automated the creation of automated transformations that can apply a design transformations that can apply a design pattern to an existing program. pattern to an existing program.


• In this paper we present a brief In this paper we present a brief description of this methodology, and description of this methodology, and report on the results of using this report on the results of using this methodology to develop program methodology to develop program transformations that can apply the transformations that can apply the Gamma Gamma et al et al design patternsdesign patterns. .


• It is found that in It is found that in almost 75% of casesalmost 75% of cases a a satisfactory transformation is developed satisfactory transformation is developed , and that much of the commonality bet, and that much of the commonality between design patterns can be captured in ween design patterns can be captured in reusable minitransformationsreusable minitransformations..

KeyWordsKeyWords

• Design patternsDesign patterns• RefactoringRefactoring• automated program transformationsautomated program transformations• design qualitydesign quality

Introduction(1)Introduction(1)

• Getting a design right first time is Getting a design right first time is impossible. impossible.

• Software development thinkingSoftware development thinking in the in the past decade. past decade.

process of building a software process of building a software system system

should be an evolutionary.should be an evolutionary.


• Rather than the Rather than the classical waterfall modelclassical waterfall model where analysis is fully completed before where analysis is fully completed before design, anddesign, and

design fully completed before design fully completed before implementation, evolutionary approaches implementation, evolutionary approaches are based on building a simple version of are based on building a simple version of what is required and extending this what is required and extending this iteratively iteratively to build a more complicated to build a more complicated systemsystem. .

Introduction(2) -Introduction(2) -Waterfall Waterfall ModelModel


• Current thinking recommends breaking this Current thinking recommends breaking this process of extending a system into two stages :process of extending a system into two stages :

1. Program Restructuring1. Program Restructuring

2. Actual Updating 2. Actual Updating

Introduction(3) - Introduction(3) - Program RestructuringProgram Restructuring

• This involves changing the design of the This involves changing the design of the program so as to make it more amenable to the program so as to make it more amenable to the new requirement, while not changing the new requirement, while not changing the behavior of the program. behavior of the program.

Introduction(3) -Introduction(3) -Actual UpdatingActual Updating

• Here the program is changed to fulfill Here the program is changed to fulfill the new requirement. the new requirement.

• If the restructuring step has been If the restructuring step has been successful, this step will be successful, this step will be considerably simplified. considerably simplified.

Introduction(4)Introduction(4)• We now consider now what type of We now consider now what type of

restructurings a designer may want restructurings a designer may want to perform in order to make a system to perform in order to make a system more flexible and able to more flexible and able to accommodate a new requirement. accommodate a new requirement.

• Designer wish the program to evolve Designer wish the program to evolve at higher level. at higher level.

for example , simply for example , simply creating a new creating a new classclass or or moving an existing methodmoving an existing method. .

Introduction(5)Introduction(5)• Design patterns typically loosen the Design patterns typically loosen the

coupling between program coupling between program components, thus enabling certain components, thus enabling certain types oftypes of program evolution to occur program evolution to occur with minimal change to the program with minimal change to the program itself.itself.

• For example, the instantiation of a For example, the instantiation of a Product classProduct class within a within a Creator classCreator class could be replaced by an application could be replaced by an application of the of the Factory Method pattern.Factory Method pattern.

Methodology(1)Methodology(1)

• Restructuring of legacy systemsRestructuring of legacy systems To be accustomed to future changeTo be accustomed to future change

Performed either by hand or toolPerformed either by hand or tool•Extract a method from existing codeExtract a method from existing code

•Move a method from one class to anotherMove a method from one class to another

• Main interest of this paperMain interest of this paper Automated support for high level Automated support for high level

program transformationprogram transformation

Methodology(2)Methodology(2)

• Design patternDesign pattern Definition(E. Gamma)Definition(E. Gamma)

• Recurring patterns of relationships between classes, objects, Recurring patterns of relationships between classes, objects, methods, etcmethods, etc

• Define preferred solutions to common OO design problemsDefine preferred solutions to common OO design problems

Loosen the binding between program componentsLoosen the binding between program components• Enables certain types of evolution to occur with minimal Enables certain types of evolution to occur with minimal

changechange

• Automated introduction of design patterns Automated introduction of design patterns The designer decidesThe designer decides

• What design pattern to applyWhat design pattern to apply• Where it is to be appliedWhere it is to be applied

Purely remove the burden of tedious modificationPurely remove the burden of tedious modification

Methodology(3)Methodology(3)- - BackgroundBackground• ““Factory Method” design patternFactory Method” design pattern

Product

ConcreteProduct

Creator

FactoryMethod()AnOperation()

ConcreteCreator

FactoryMethod()

…Product = FactoryMethod()…

return new ConcreteProduct

Methodology(4)-Methodology(4)- OutlineOutlineSelect Design

Pattern

Decide on Precursor for this

pattern

Decomposeinto Minipatterns

DoMinitransformations

Exist?

Define design patternTransformation as

Composition ofminitransformations

yes

Define minitrans-formations

no

Methodology(5)-Methodology(5)- Starting point – existing workStarting point – existing work

• Green field situationGreen field situation When apply design pattern, the target When apply design pattern, the target

component do not have any existing component do not have any existing relationships pertaining to the patternrelationships pertaining to the pattern

• AntipatternAntipattern The designer used some inadequate The designer used some inadequate

design to deal with the situationdesign to deal with the situation

Methodology(6)-Methodology(6)- PrecursorsPrecursors

• Starting pointStarting point in this approach in this approach The basic intent of the pattern existsThe basic intent of the pattern exists

Needed when future change require some Needed when future change require some flexibilityflexibility

If not needed, it is undesirableIf not needed, it is undesirable•Cause unnecessary complexityCause unnecessary complexity

• PrecursorPrecursor A design structure that expresses the intent A design structure that expresses the intent

of a design pattern in a simple wayof a design pattern in a simple way

Methodology(6)-Methodology(6)-Precursors - examplePrecursors - example

Product

ConcreteProduct

Creator

FactoryMethod()AnOperation()

ConcreteCreator

FactoryMethod()

Creator

Product

Precursors

Methodology(7)-Methodology(7)- Minipattern & MinitransformationMinipattern & Minitransformation

• MinipatternMinipatternA design motif that occurs frequentlyA design motif that occurs frequently

Decomposition of design patternDecomposition of design pattern

• MinistransformationMinistransformationA transformation correspond to A transformation correspond to

minipatternminipattern

Methodology(8)-Methodology(8)- MinitransformationMinitransformation

• A set of preconditionsA set of preconditions Program state described by the precursorProgram state described by the precursor Described using predicates over the codeDescribed using predicates over the code

• A sequence of transformation stepsA sequence of transformation steps Defined in terms of low level refactoringsDefined in terms of low level refactorings Use helper functionsUse helper functions

• A set of A set of postconditionspostconditions• An argument demonstrating behavior An argument demonstrating behavior

preservationpreservation

Methodology(8)-Methodology(8)- Minitransformation – Minitransformation – example(1/2)example(1/2)

Name : ABSTRACTIONArguments :String className : name of the class to be abstracted.String infName : name of the new interface to be created.Description : Builds a new interface, infName, to the class className and adds it to the program.Preconditions :No name clashes:Interface i.name != infNameClass c.name != infName (pre1)The class must exist:exists(className) (pre2)Postconditions :The new interface infName precisely refelects the public methodsof className :equalInterface(className, infName)

Methodology(8)-Methodology(8)- Minitransformation – Minitransformation – example(2/2)example(2/2)

Algorithm:(1) Interface inf = abstractClass(className, infName);(2) addInterface(inf);(3) addImplementsLink(className, infName);Behavior Preservation :1: Invokes a helper function and therefore does not update the program. From pre2 we know that the class must exist.2: From pre1 we know that infName does not already exist in the program, so this step adds an unreferenced interface to the program, which cannot affect compilation or behavior3: pre2 ensures that className exists while the postcondition of (2) ensures that infName exists. The postcondition of (1) ensures that className fully implements the interface defined in infName, so all preconditions for (3) are fulfilled.

Methodology(9)-Methodology(9)- Factory method Factory method transformation(1/2)transformation(1/2)Name : APPLY FACTORY METHODArguments :String creator : name of the class that creates product objects.String product : name of the public class.String absP : name of the new interface to the product class.String createP : name of the new factory method itself.Description : Applies the Factory Method design pattern to theprogram.Preconditions :Exists(creator) (pre1)Exists(product) (pre2)!exists(absP) (pre3)!exists(creator, createP) (pre4)Creator.creates(product) (pre5)!product.hasPublicField() (pre6)!product.hasStaticMethod() (pre7)

Methodology(9)-Methodology(9)- Factory method Factory method transformation(2/2)transformation(2/2)

Algorithm :1. ABSTRACTION(product, absP)2. ENCAPSULATE_CONSTRUCTION(creator, product, createP)3. ABSTRACT_ACCESS(creator, product, absP, createP);Behavior Preservation :1: pre2 and pre3 guarantee the preconditions for this step2: pre1, pre2 and pre4 guarantee the preconditions for this step3: pre1, pre2, pre3, pre6, pre7 coupled with the postcondition of (1) guarantee the preconditions for this step

Methodology(10)-Methodology(10)- Tool architectureTool architecture

Design Pattern Transformations

Minitransformations

Helper functions, predicates,refactorings

Abstract Syntax Trees

Methodology(11)-Methodology(11)- Example of application(1/2)Example of application(1/2)

Class Creator { public void doIt() { Product p = new Product(“some text”); Product q = new Product(1234); p.foo(); q.foo(); }}Class Product { public Product(int x) {} public Product(String s) {} public void foo() {}}

Original Code

applyFactoryMethod( “Creator”,”Product”, “absProduct”, “createProduct”)

Applied transformation

Methodology(11)-Methodology(11)- Example of application(2/2)Example of application(2/2)

class Creator { public void doIt() { absProduct p = createProduct(“some text”); absProduct q = createProduct(1234); p.foo(); q.foo(); } public absProduct createProduct(int x) { return new Product(x); } public absProduct createProduct(String s) { return new Product(s); }}

interface absProduct { public void foo();}Class Product implements absProduct { public Product(int x) {} public Product(String s) {} public void foo();}

Changed code

Results(1)Results(1)

• Using the experience gained from this prUsing the experience gained from this process, we ocess, we analysedanalysed the remaining Gam the remaining Gamma ma et al et al patternspatterns with a view to finding a with a view to finding a suitable precursor, assessing if a workabsuitable precursor, assessing if a workable transformation can be built, and deterle transformation can be built, and determining the minitransformations that are mining the minitransformations that are likely to be used. likely to be used.


• In each case we assessed the result In each case we assessed the result we achieved and placed it in one of we achieved and placed it in one of the following categories:the following categories:

1. 1. Excellent Excellent ::

2. 2. Partial Partial : :

3. 3. Impractical Impractical ::

Results(2) - Results(2) - Excellent Excellent ::

• The methodology worked very well. The methodology worked very well. • A plausible precursor was found and a cA plausible precursor was found and a c

ompelling transformation was built, maompelling transformation was built, making use of some of the minitransformatiking use of some of the minitransformations already identified.ons already identified.

Results(2) -Results(2) -Partial Partial : :

• There is some problem with the There is some problem with the result that means a usable result that means a usable transformation can be developed, transformation can be developed, but it is not complete.but it is not complete.

• Typically the designer is left with Typically the designer is left with some work to do by hand in order to some work to do by hand in order to complete the transformation.complete the transformation.

Results(2) -Results(2) -Impractical Impractical :: • There is a serious problem with the There is a serious problem with the

result that makes it impossible to result that makes it impossible to build a transformation, or produces build a transformation, or produces one whose precondition is so one whose precondition is so constrained that it is of no practical constrained that it is of no practical value.value.

• The results are presented in complete The results are presented in complete form in form in table 1table 1 , and in summary form , and in summary form in in table 2table 2. .

• These tables indicate a very These tables indicate a very satisfactory result. satisfactory result.

Results(2) - Results(2) - table 1table 1

Results(2) - Results(2) - Table 2Table 2


• The methodology worked very well for tThe methodology worked very well for the creational patterns , but not so succehe creational patterns , but not so successfully for the ssfully for the structural patternsstructural patterns or or behbehavioural patterns avioural patterns

• It was to be expected that behavioural pIt was to be expected that behavioural patterns would cause problems, but it is satterns would cause problems, but it is surprising that the results for the urprising that the results for the structurstructural patterns were not betteral patterns were not better..


• Other initially surprising results were thOther initially surprising results were those for ose for

Strategy (abehavioural that worked well)Strategy (abehavioural that worked well) Facade (a structural pattern that failed).Facade (a structural pattern that failed).


• In the case of Strategy, we used a In the case of Strategy, we used a precurprecursorsor where the where the behaviouralbehavioural aspects of the aspects of the pattern are already encapsulated within pattern are already encapsulated within methods methods

• The transformation therefore just has to The transformation therefore just has to deal with the structure of this pattern , adeal with the structure of this pattern , and this proved straightforward to handlnd this proved straightforward to handle. e.


• Facade presented the opposite problemFacade presented the opposite problem • Its structure is easy to deal with, but theIts structure is easy to deal with, but the

re is also a behavioural element in how tre is also a behavioural element in how the client classes interact with the subsyshe client classes interact with the subsystem classes that are to be encapsulated,tem classes that are to be encapsulated,and this behavioural element could not and this behavioural element could not be extracted and transformed.be extracted and transformed.

Results(7)-1Results(7)-1

• The following minipatterns were identified durThe following minipatterns were identified during the process of building these transformatiing the process of building these transformations:ons:

1. 1. AbstractionAbstraction adds an interface to a class that adds an interface to a class that reflects how the class is used in some context. reflects how the class is used in some context. This enables another class to take a more This enables another class to take a more abstract view of this class by accessing it via abstract view of this class by accessing it via this interface.this interface.


2. 2. EncapsulateConstructionEncapsulateConstruction is applied wh is applied when en

one class creates instances of another, one class creates instances of another, and it is required to weaken the binding and it is required to weaken the binding between the two classes by packaging between the two classes by packaging the object creation statements into the object creation statements into dedicated methods.dedicated methods.


3. 3. AbstractAccessAbstractAccess is applied when one clas is applied when one class s

uses, or has knowledge of, another class, uses, or has knowledge of, another class, and we want the relationship between thand we want the relationship between th

e e classes to operate in a more abstract classes to operate in a more abstract fashion via an interface.fashion via an interface.


4. 4. PartialAbstractionPartialAbstraction constructs an abstra constructs an abstract ct

class from an existing class and creates class from an existing class and creates an inheritance relationship between the an inheritance relationship between the two classes. two classes.


5. 5. Wrapper Wrapper is applied to “wrap” an existing is applied to “wrap” an existing

receiver class with another class, in such receiver class with another class, in such

a way that all requests to an object of the a way that all requests to an object of the

wrapper class are passed to the receiver wrapper class are passed to the receiver

object it wraps, and similarly any results object it wraps, and similarly any results

of such requests are passed back by the of such requests are passed back by the

wrapper object.wrapper object.


6. 6. DelegationDelegation moves part of an moves part of an existing existing

class to a component class, and sets class to a component class, and sets up a up a

delegation relationship from the delegation relationship from the existing existing

class to its component.class to its component.


• Reuse of minipatterns is an important isReuse of minipatterns is an important issue to consider .sue to consider .

• We hoped that the minipatterns uncoverWe hoped that the minipatterns uncovered during the development of the earlier ed during the development of the earlier design pattern transformations would pdesign pattern transformations would prove useful in later developments.rove useful in later developments.

• In In table 3table 3 we depict the reuse of minipat we depict the reuse of minipatterns across the design pattern transforterns across the design pattern transformations. mations.

Results(9)Results(9)• It is clear from this table that we have achiIt is clear from this table that we have achi

eved considerable reuse of the set of six mieved considerable reuse of the set of six minitransformations that were uncovered dunitransformations that were uncovered during the development of these design pattering the development of these design pattern transformations.rn transformations.

• The actual reuse achieved is even stronger, The actual reuse achieved is even stronger, as this table 3 only depicts minitransformaas this table 3 only depicts minitransformation reuse and ignores the reuse of primitivtion reuse and ignores the reuse of primitive refactorings. e refactorings.

Results(2) - Results(2) - Table 3Table 3

ConclusionConclusion(1)(1)

• We have developed a methodology for tWe have developed a methodology for the creation of he creation of behaviour-preservingbehaviour-preserving desi design pattern transformations, and applied gn pattern transformations, and applied this methodology to the Gamma this methodology to the Gamma et al et al dedesign patterns. sign patterns.


• Our results were promising Our results were promising in thatin that for m for most patterns a workable solution could bost patterns a workable solution could be found, and there proved to be extensive found, and there proved to be extensive reuse of the minitransformations that e reuse of the minitransformations that were developed during this work.were developed during this work.


• Compilers, debuggersCompilers, debuggers and and profilersprofilers all fit all fit into this category.into this category.

• As design patterns become more As design patterns become more establiestablishedshed, we can expect programmers to be, we can expect programmers to become more comfortable with the notion come more comfortable with the notion of of automated design pattern transformaautomated design pattern transformationstions..

References(1)• [1] K. Beck. Extreme Programming Explained. Addison Wesley Longman, Reading, Massachusetts, first edition, 2000.• [2] K. Bennett and V. Rajlich. Software maintenance and evolution: A roadmap. In A. Finkelstein, editor, The Future of Software Engineering, New York, 2000. ACM Press.• [3] G. Booch. Object-oriented analysis and design with applications. Benjamin/Cummings, Redwood City, California, second edition, 1994.

References(2)• [4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. A System of Patterns: Pattern-Oriented Software Architecture. John Wiley & Sons, Chicester, first edition, 1996.• [5] B. Foote and W. Opdyke. Lifecycle and refactoring patterns that support evolution and reuse. In J. Coplien and D. Schmidt, editors, Pattern Languages of Programming, Monticello, Illinois, 1995.• [6] M. Fowler. Refactoring: improving the design of existing code. Object Technology Series. Addison-Wesley Longman, Reading, Massachusetts, first edition, 1999.

References(3)• [7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley, Reading, Massachusetts, first edition, 1995.• [8] M. ’O Cinn’eide. Automated Application of Design Patterns: a Refactoring Approach. PhD dissertation, University of Dublin, Trinity College, Department of Computer Science, 2000. Available from: http://www.cs.ucd.ie/staff/meloc/home/papers/ thesis/thesis.htm.

http://www.cs.ucd.ie/staff/meloc/home/papers/

References(4)• [9] M. ’O Cinn’eide and P. Nixon. A methodology for th

e automated introduction of design patterns. In H. Yang and L. White, editors, Proceedings of the International Conference on Software Maintenance, pages 463–472,Oxford, Sept. 1999. IEEE Press.• [10] D. Roberts and J. Brant. “Good enough” analysis f

or refactoring. In S. Ducasse and J. Weisbrod, editors, ECOOP Workshop on Experiences in Object-Oriented Re-Engineering, Brussels, July 1998. FZI Karlsruhe report.

Thanks !

Automated Software Evolution Towards Design Patterns

Documents

Transcript of Automated Software Evolution Towards Design Patterns