Automated Software Evolution Towards Design Patterns

1. Automated Software Evolution Towards Design Patterns Advisor ：Ku-Yaw Chang ID ：E9406010 Interpreter：SHIH - CHIEM LIAO Department of Computer Science and Information Engineering Da-Yeh University

2. Mel Cinneide and Paddy Nixon, "Automated Software Evolution Towards Design Patterns," Proceedings of the International Workshop on the Principles of Software Evolution (IWPSE), Vienna, September, 2001. Author Mel ´O Cinn´eide Department of Computer Science University CollegeDublin Ireland. mel.ocinneide@ucd.ie Paddy Nixon Department of Computer Science University of Strathclyde Scotand. paddy@cs.strath.ac.uk Excerpt From

3. Outline • Abstract • Introduction • Background of methodology • methodology • Precursor of methodology • Minipattern & Minitransformation of methodology • Factory Method transformation • Example of methodology • Results • Conclusion • References

4. ABSTRACT(1) • During the evolution of a software system, it may be necessary to refactor the software in order to make it more flexible and amenable to new requirements that are being introduced.

5. ABSTRACT(2) • How refactoring A typical to enhance program flexibility ? Apply a suitable design pattern to the program .

6. ABSTRACT(3) • Performing such a transformation by hand is an error-prone process (X) automated support would be useful (O) • We have developed a methodology for the creation of automated transformations that can apply a design pattern to an existing program.

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

8. ABSTRACT(5) • It is found that in almost 75% of cases a satisfactory transformation is developed , and that much of the commonality between design patterns can be captured in reusable minitransformations.

9. KeyWords • Design patterns • Refactoring • automated program transformations • design quality

10. Introduction(1) • Getting a design right first time is impossible. • Software development thinking in the past decade. process of building a software system should be an evolutionary.

11. Introduction(2) • Rather than the classical waterfall model where analysis is fully completed before design, and design fully completed before implementation, evolutionary approaches are based on building a simple version of what is required and extending this iteratively to build a more complicated system.

12. Introduction(2) -Waterfall Model

13. Introduction(3) • Current thinking recommends breaking this process of extending a system into two stages : 1. Program Restructuring 2. Actual Updating

14. Introduction(3) - Program Restructuring • This involves changing the design of the program so as to make it more amenable to the new requirement, while not changing the behavior of the program.

15. Introduction(3) -Actual Updating • Here the program is changed to fulfill the new requirement. • If the restructuring step has been successful, this step will be considerably simplified.

16. Introduction(4) • We now consider now what type of restructurings a designer may want to perform in order to make a system more flexible and able to accommodate a new requirement. • Designer wish the program to evolve at higher level. for example , simply creating a new class or moving an existing method.

17. Introduction(5) • Design patterns typically loosen the coupling between program components, thus enabling certain types ofprogram evolution to occur with minimal change to the program itself. • For example, the instantiation of a Product class within a Creator class could be replaced by an application of the Factory Method pattern.

18. Methodology(1) • Restructuring of legacy systems To be accustomed to future change Performed either by hand or tool • Extract a method from existing code • Move a method from one class to another • Main interest of this paper Automated support for high level program transformation

19. Methodology(2) • Design pattern Definition(E. Gamma) • Recurring patterns of relationships between classes, objects, methods, etc • Define preferred solutions to common OO design problems Loosen the binding between program components • Enables certain types of evolution to occur with minimal change • Automated introduction of design patterns The designer decides • What design pattern to apply • Where it is to be applied Purely remove the burden of tedious modification

20. Methodology(3)- Background • “Factory Method” design pattern Creator Product FactoryMethod() AnOperation() … Product = FactoryMethod() … ConcreteProduct ConcreteCreator return new ConcreteProduct FactoryMethod()

21. Decide on Precursor for this pattern Decompose into Minipatterns Define design pattern Transformation as Composition of minitransformations Do Minitransformations Exist? yes Define minitrans- formations no Methodology(4)-Outline Select Design Pattern

22. Methodology(5)-Starting point – existing work • Green field situation When apply design pattern, the target component do not have any existing relationships pertaining to the pattern • Antipattern The designer used some inadequate design to deal with the situation

23. Methodology(6)-Precursors • Starting point in this approach The basic intent of the pattern exists Needed when future change require some flexibility If not needed, it is undesirable • Cause unnecessary complexity • Precursor A design structure that expresses the intent of a design pattern in a simple way

24. Methodology(6)-Precursors - example Precursors Creator Creator Product FactoryMethod() AnOperation() Product ConcreteProduct ConcreteCreator FactoryMethod()

25. Methodology(7)-Minipattern & Minitransformation • Minipattern A design motif that occurs frequently Decomposition of design pattern • Ministransformation A transformation correspond to minipattern

26. Methodology(8)-Minitransformation • A set of preconditions Program state described by the precursor Described using predicates over the code • A sequence of transformation steps Defined in terms of low level refactorings Use helper functions • A set of postconditions • An argument demonstrating behavior preservation

27. Methodology(8)-Minitransformation – example(1/2) Name: ABSTRACTION Arguments: 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 != infName Class c.name != infName (pre1) The class must exist: exists(className) (pre2) Postconditions : The new interface infName precisely refelects the public methods of className : equalInterface(className, infName)

28. Methodology(8)-Minitransformation – example(2/2) • Algorithm: • Interface inf = abstractClass(className, infName); • addInterface(inf); • 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 behavior • 3: 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.

29. Methodology(9)-Factory method transformation(1/2) Name : APPLY FACTORY METHOD Arguments : 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 the program. Preconditions : Exists(creator) (pre1) Exists(product) (pre2) !exists(absP) (pre3) !exists(creator, createP) (pre4) Creator.creates(product) (pre5) !product.hasPublicField() (pre6) !product.hasStaticMethod() (pre7)

30. Methodology(9)-Factory method transformation(2/2) • Algorithm: • ABSTRACTION(product, absP) • ENCAPSULATE_CONSTRUCTION(creator, product, createP) • ABSTRACT_ACCESS(creator, product, absP, createP); • Behavior Preservation : • 1: pre2 and pre3 guarantee the preconditions for this step • 2: pre1, pre2 and pre4 guarantee the preconditions for this step • 3: pre1, pre2, pre3, pre6, pre7 coupled with the postcondition of (1) • guarantee the preconditions for this step

31. Methodology(10)-Tool architecture Design Pattern Transformations Minitransformations Helper functions, predicates, refactorings Abstract Syntax Trees

32. Methodology(11)-Example of application(1/2) Original Code Applied transformation 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() {} } applyFactoryMethod( “Creator”,”Product”, “absProduct”, “createProduct”)

33. Methodology(11)-Example of application(2/2) Changed code 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(); }

34. Results(1) • Using the experience gained from this process, we analysed the remaining Gamma et al patternswith a view to finding a suitable precursor, assessing if a workable transformation can be built, and determining the minitransformations that are likely to be used.

35. Results(2) • In each case we assessed the result we achieved and placed it in one of the following categories: 1. Excellent : 2. Partial : 3. Impractical :

36. Results(2) - Excellent : • The methodology worked very well. • A plausible precursor was found and a compelling transformation was built, making use of some of the minitransformations already identified.

37. Results(2) -Partial : • There is some problem with the result that means a usable transformation can be developed, but it is not complete. • Typically the designer is left with some work to do by hand in order to complete the transformation.

38. Results(2) -Impractical : • There is a serious problem with the result that makes it impossible to build a transformation, or produces one whose precondition is so constrained that it is of no practical value. • The results are presented in complete form in table 1 , and in summary form in table 2. • These tables indicate a very satisfactory result.

39. Results(2) - table 1

40. Results(2) - Table 2

41. Results(3) • The methodology worked very well for the creational patterns , but not so successfully for the structural patterns or behavioural patterns • It was to be expected that behavioural patterns would cause problems, but it is surprising that the results for the structural patterns were not better.

42. Results(4) • Other initially surprising results were those for Strategy (abehavioural that worked well) Facade (a structural pattern that failed).

43. Results(5) • In the case of Strategy, we used a precursor where the behavioural aspects of the pattern are already encapsulated within methods • The transformation therefore just has to deal with the structure of this pattern , and this proved straightforward to handle.

44. Results(6) • Facade presented the opposite problem • Its structure is easy to deal with, but there is also a behavioural element in how the client classes interact with the subsystem classes that are to be encapsulated,and this behavioural element could not be extracted and transformed.

45. Results(7)-1 • The following minipatterns were identified during the process of building these transformations: 1. Abstraction adds an interface to a class that reflects how the class is used in some context. This enables another class to take a more abstract view of this class by accessing it via this interface.

46. Results(7)-2 2. EncapsulateConstruction is applied when one class creates instances of another, and it is required to weaken the binding between the two classes by packaging the object creation statements into dedicated methods.

47. Results(7)-3 3. AbstractAccess is applied when one class uses, or has knowledge of, another class, and we want the relationship between the classes to operate in a more abstract fashion via an interface.

48. Results(7)-4 4. PartialAbstraction constructs an abstract class from an existing class and creates an inheritance relationship between the two classes.

49. Results(7)-5 5. Wrapper is applied to “wrap” an existing receiver class with another class, in such a way that all requests to an object of the wrapper class are passed to the receiver object it wraps, and similarly any results of such requests are passed back by the wrapper object.

50. Results(7)-6 6. Delegation moves part of an existing class to a component class, and sets up a delegation relationship from the existing class to its component.