Towards a Framework for Software Design Defects Correction with Refactoring Plans

Presented at the seminar "Fundamental Aspects of Software Evolution" of the FNRS Contact Group on Fundamental Computer, Science May 22nd 2008, University of Namur (https://www.info.fundp.ac.be/fnrs-fcs)

Transcript

1. Towards a Framework for Software Design Defects Correction with Refactoring Plans Javier Pérez jperez@infor.uva.es Universidad de Valladolid Université de Mons-Hainaut Fundamental Aspects of Software Evolution FNRS Contact Group on Fundamental Computer Science May 22nd 2008, University of Namur Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 1 / 31
2. Introduction Introduction Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 2 / 31
3. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
4. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
5. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
6. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
7. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
8. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
9. Introduction Software Design Defects Definition Design defects are “bad” solutions to recurring design problems in object-oriented systems. Design defects are problems resulting from bad design practices. They include problems ranging from high-level and design problems, such as antipatterns, to low-level or local problems, such as code smells. (Moha, 2008) Why is important to deal with design defects? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 3 / 31
10. Introduction Motivation Software evolution “happens”. Software design decays: changes are applied hastily “design debt” appears (Kerievsky, Refactoring To Patterns) Design decay can manifest through design defects, which affect software quality factors: maintainability reusability comprehensibility . . . Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 4 / 31
11. Introduction Motivation Software evolution “happens”. Software design decays: changes are applied hastily “design debt” appears (Kerievsky, Refactoring To Patterns) Design decay can manifest through design defects, which affect software quality factors: maintainability reusability comprehensibility . . . Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 4 / 31
12. Introduction Motivation Software evolution “happens”. Software design decays: changes are applied hastily “design debt” appears (Kerievsky, Refactoring To Patterns) Design decay can manifest through design defects, which affect software quality factors: maintainability reusability comprehensibility . . . Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 4 / 31
13. Introduction Software Design Defect Management The ideal is to prevent design defects, but . . . design defects appear, so systematic ways to detect and correct design defects are needed. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 5 / 31
14. Introduction Software Design Defect Management The ideal is to prevent design defects, but . . . design defects appear, so systematic ways to detect and correct design defects are needed. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 5 / 31
15. Introduction Software Design Defect Management The ideal is to prevent design defects, but . . . design defects appear, so systematic ways to detect and correct design defects are needed. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 5 / 31
16. Introduction Software Design Defect Management Techniques to detect design defects and to suggest design changes are maturing: Structural patterns to find defects (Moha, DECOR project) Metrics to detect “bad smells” (Marinescu, 2006; Crespo et al., 2005). Formal/Relational Concept Analysis to propose reorganisation of OO entities (Moha et al., 2006; Prieto et al., 2003). Software inconsistency management (Mens, 2006) The change suggestions given: are not directly applicable over a system, are usually given in terms of refactorings. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 6 / 31
17. Introduction Software Design Defect Management Techniques to detect design defects and to suggest design changes are maturing: Structural patterns to find defects (Moha, DECOR project) Metrics to detect “bad smells” (Marinescu, 2006; Crespo et al., 2005). Formal/Relational Concept Analysis to propose reorganisation of OO entities (Moha et al., 2006; Prieto et al., 2003). Software inconsistency management (Mens, 2006) The change suggestions given: are not directly applicable over a system, are usually given in terms of refactorings. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 6 / 31
18. Introduction Refactorings to Correct Design Defects Refactorings are structural transformations that can be applied to a software system to perform design changes without modifying its behaviour. Current approaches to improve a system design with refactorings focus in: Individual refactoring steps. Detecting refactoring opportunities. Assisting the developer in executing the refactoring Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 7 / 31
19. Introduction Refactorings to Correct Design Defects Refactorings are structural transformations that can be applied to a software system to perform design changes without modifying its behaviour. Current approaches to improve a system design with refactorings focus in: Individual refactoring steps. Detecting refactoring opportunities. Assisting the developer in executing the refactoring Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 7 / 31
20. Introduction Goals Objective of a Defect Correction Framework 1 Instantiate defect removing suggestions into a correction plan which could be effectively applied. through refactorings, because systems’ behaviour should be preserved. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 8 / 31
21. Introduction Goals Objective of a Defect Correction Framework 1 Instantiate defect removing suggestions into a correction plan which could be effectively applied. through refactorings, because systems’ behaviour should be preserved. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 8 / 31
22. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
23. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
24. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
25. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
26. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
27. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
28. Introduction Goals Refactoring Plans We pretend to introduce a new concept: Refactoring Plans Definition A Refactoring Plan will be a specification of a refactoring sequence which matches a system redesign proposal, so that it can be automatically executed to modify the system in order to obtain that desirable system redesign without changing the system’s behaviour. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 9 / 31
29. Introduction Goals Goals of a Framework for Refactoring Plans 1 Support to automatic or assisted generation of refactoring plans 2 To provide very high level (big) refactorings for design improvement, using refactoring plan generation altogether with the defect detection techniques that suggest redesign proposals. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 10 / 31
30. Introduction Goals Goals of a Framework for Refactoring Plans 1 Support to automatic or assisted generation of refactoring plans 2 To provide very high level (big) refactorings for design improvement, using refactoring plan generation altogether with the defect detection techniques that suggest redesign proposals. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 10 / 31
31. Design Defect Correction Design Defect Correction Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 11 / 31
32. Design Defect Correction General Defect Correction Process Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 12 / 31
33. Design Defect Correction Goals of a Framework for Refactoring Plans 1 Support to automatic or assisted generation of refactoring plans 2 To provide very high level (big) refactorings for design improvement, using refactoring plan generation altogether with the defect detection techniques that suggest redesign proposals. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 13 / 31
34. Design Defect Correction Goals of a Framework for Refactoring Plans 1 Support to automatic or assisted generation of refactoring plans 2 To provide very high level (big) refactorings for design improvement, using refactoring plan generation altogether with the defect detection techniques that suggest redesign proposals. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 13 / 31
35. Design Defect Correction A Framework sketch Software System Software Entity 1 1..* Design Defect Definition 1..* 1 Defect Symptom 1..* 1..* Metric Symptom Lexical/Semantic Smptom Structural Symptom 0..* 1..* Defect Correction Strategy Behaviour-Preserving Change Non Behaviour-Preserving Refactoring Suggestion Refactoring Plan 1..* 0..* Automated Refactorings 0..* 1..* Non-Automated Refactorings Class Interface Instance Methods Instance Variables Detected Defect 1..* 1..* Change 0..* 0..* 1..* 1..* Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 14 / 31
36. Generating Refactoring Plans Generating Refactoring Plans Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 15 / 31
37. Generating Refactoring Plans Problem description Refactoring Plan Questions Given a software system as the source of the transformation, a redesign proposal, and a set of refactorings that can be used as transformation operations: 1 Does a refactoring plan, which transforms the source, according to the redesign proposal, using the provided refactorings, exist? additional non-refactoring transformations could be needed 2 When a refactoring plan exists, can it be generated and executed automatically? How to deal with a semi-automated solution, with additional user input? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 16 / 31
38. Generating Refactoring Plans Problem description Refactoring Plan Questions Given a software system as the source of the transformation, a redesign proposal, and a set of refactorings that can be used as transformation operations: 1 Does a refactoring plan, which transforms the source, according to the redesign proposal, using the provided refactorings, exist? additional non-refactoring transformations could be needed 2 When a refactoring plan exists, can it be generated and executed automatically? How to deal with a semi-automated solution, with additional user input? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 16 / 31
39. Generating Refactoring Plans Problem description Refactoring Plan Questions Given a software system as the source of the transformation, a redesign proposal, and a set of refactorings that can be used as transformation operations: 1 Does a refactoring plan, which transforms the source, according to the redesign proposal, using the provided refactorings, exist? additional non-refactoring transformations could be needed 2 When a refactoring plan exists, can it be generated and executed automatically? How to deal with a semi-automated solution, with additional user input? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 16 / 31
40. Generating Refactoring Plans Problem description Subproblems We have divided the problem of automatic generation of refactoring plans in: Definition and formalization of the “Refactoring Plan” concept Representation of Software Formalization of Refactorings Elaboration of techniques to obtain refactoring plans Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 17 / 31
41. Generating Refactoring Plans Refactoring Representation Formalising Refactorings Any refactoring formalization method must allow: to deal with system structure. to check behaviour preserving conditions. We will use Graph Transformations because: Representing and managing structural information is straightforward with graphs. This approach has already been validated (Mens et al., 2005). With Graph Transformation: Software is represented as graphs. Refactorings are represented as graph transformation rules. Other refactoring formalization approaches: First Order Logic (Kniessel, Köch, 2002). Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 18 / 31
42. Generating Refactoring Plans Refactoring Representation Example of a Graph Transformation Rule C P 2 4 M 1 p t I 3 i* C P 2 4 M 1 p t I 3 i* Left Hand Side Right Hand Side Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 19 / 31
43. Generating Refactoring Plans Software Representation Software Representation: Program Graphs A graph representation for Object-Oriented Software is needed. We must represent: elements of OO paradigm (classes, fields, methods, ...) structural relationships method bodies We have chosen the software representation part from the refactoring formalization of (Mens et al., 2005). This representation: uses directed type graphs. is language independent, lacking specific language constructions. has been simplified to be as flexible as possible. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 20 / 31
44. Generating Refactoring Plans Software Representation Software Representation: Program Graphs A graph representation for Object-Oriented Software is needed. We must represent: elements of OO paradigm (classes, fields, methods, ...) structural relationships method bodies We have chosen the software representation part from the refactoring formalization of (Mens et al., 2005). This representation: uses directed type graphs. is language independent, lacking specific language constructions. has been simplified to be as flexible as possible. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 20 / 31
45. Generating Refactoring Plans Software Representation Software Representation: Java Program Graphs C M MD E P V VD t p u a e c 1 1 p t i m l l m u a e Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 21 / 31
46. Generating Refactoring Plans Software Representation Software Representation: Java Program Graphs For real systems, it is necessary to extend the graph format, adding: elements for specific languages more detailed representation of method bodies We have extended program graphs for Java: Java Program Graphs. Our graph representation format adds: Java concepts such as visibility, interfaces, packages, . . . More detailed representation of method bodies, with new node types, attributes and relationships. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 22 / 31
47. Generating Refactoring Plans Software Representation Software Representation: Java Program Graphs For real systems, it is necessary to extend the graph format, adding: elements for specific languages more detailed representation of method bodies We have extended program graphs for Java: Java Program Graphs. Our graph representation format adds: Java concepts such as visibility, interfaces, packages, . . . More detailed representation of method bodies, with new node types, attributes and relationships. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 22 / 31
48. Generating Refactoring Plans Software Representation Software Representation: Java Program Graphs For real systems, it is necessary to extend the graph format, adding: elements for specific languages more detailed representation of method bodies We have extended program graphs for Java: Java Program Graphs. Our graph representation format adds: Java concepts such as visibility, interfaces, packages, . . . More detailed representation of method bodies, with new node types, attributes and relationships. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 22 / 31
49. Generating Refactoring Plans Software Representation Software Representation: Java Program Graphs Package name : String Class isFinal : boolean Interface implements 0..* 0..* Variable name : String visibility : String isAbstract : boolean isStatic : boolean isFinal : boolean Operation name : String visibility : String isAbstract : boolean isStatic : boolean isFinal : boolean Parameter MethodBody binding 0..* 1 belongsTo 0..* 0..1 belongsTo 1 0..* belongsTo 0..* 1 belongsTo 0..* 0..1 Literal value : String type 0..* 1 Expression belongsTo 0..* 0..1 expression 0..* {ordered} 0..* Access this : boolean Call this : boolean super : boolean Operator name : String Update this : boolean Instantiation {incomplete} Return Block belongsTo 1 1 ActualParameters expression 1 0..1 Classifier name : String visibility : String isAbstract : boolean belongsTo 1 1..* imports 0..* 0..* extends 0..* 0..* type 0..* 1 type 0..1 0..* type 1 0..* parameter 1 0..* {ordered} link 0..1 0..* link 0..* 0..1 link 0..* 0..1 link 0..* 0..1 link 0..* 0..1 belongsTo 0..1 0..* link 1 0..1 {ordered} expression 1 1..* {ordered} Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 23 / 31
50. Generating Refactoring Plans Software Representation Possible Approaches to Obtain Refactoring Plans We are exploring two aproaches: Searching forwards Searching backwards Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 24 / 31
51. Generating Refactoring Plans Software Representation Searching forwards approach Suggested changes are turned into a simplified version of the sstem’s desirable design. Available refactorings are applied in a state space search way. Refactoring pre and postconditions guide the search. Advantages Every possible path is being explored Relatively easy to implement Problems Size of the state space Possible infinite process Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 25 / 31
52. Generating Refactoring Plans Software Representation Searching Backwards approach Dependencies between refactorings are computed Iteratively, refactorings which enable the application of the desired change are added to the plan. Advantages More efficient than searching backwards Problems More difficult to implement with current Graph Transformation tools Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 26 / 31
53. Generating Refactoring Plans Software Representation Open questions Can complex refactorings be represented and analysed with current GT tools? Can searching be reduced to finite process? Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 27 / 31
54. Conclusions and Future Work Conclusions and Future Work Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 28 / 31
55. Conclusions and Future Work Conclusions Automatic generation of refactoring plans will provide very high level refactorings to improve the design of existing code. The Main subproblems and the research strategy have been introduced. Graph transformation can be used as the underlying formalism, specifically the programmed graph rewriting approach. Representing Java programs with Java Program Graphs. The graph transformation formalism could provide support to refactorings formal analysis, enabling searching for refactoring plans. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 29 / 31
56. Conclusions and Future Work Conclusions Automatic generation of refactoring plans will provide very high level refactorings to improve the design of existing code. The Main subproblems and the research strategy have been introduced. Graph transformation can be used as the underlying formalism, specifically the programmed graph rewriting approach. Representing Java programs with Java Program Graphs. The graph transformation formalism could provide support to refactorings formal analysis, enabling searching for refactoring plans. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 29 / 31
57. Conclusions and Future Work Conclusions Automatic generation of refactoring plans will provide very high level refactorings to improve the design of existing code. The Main subproblems and the research strategy have been introduced. Graph transformation can be used as the underlying formalism, specifically the programmed graph rewriting approach. Representing Java programs with Java Program Graphs. The graph transformation formalism could provide support to refactorings formal analysis, enabling searching for refactoring plans. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 29 / 31
58. Conclusions and Future Work Future Work Main future tasks will be directed to: Further definition of the “Refactoring Plan” concept. Explore the expressivenss of GT tools Analyse termination and correctness conditions of the searching approaches. Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 30 / 31
59. Conclusions and Future Work Towards a Framework for Software Design Defects Correction with Refactoring Plans Javier Pérez jperez@infor.uva.es Universidad de Valladolid Université de Mons-Hainaut Fundamental Aspects of Software Evolution FNRS Contact Group on Fundamental Computer Science May 22nd 2008, University of Namur Javier Pérez (UVa, UMH) A Framework for Refactoring Plans May 2008 31 / 31