Enabling Refactoring with HTN Planning to Improve the Design Smells Correction Activity

Refactorings are a key technique to software evolution. They can be used to improve the structure and quality of a software system. This paper introduces a proposal for generating refactoring plans with hierarchical task network planning, to improve the automation of the bad smells correction activity. Presented at Benevol 2008 (http://www-set.win.tue.nl/benevol2008).

Transcript

1. Enabling Refactoring with HTN Planning to Improve the Design Smells Correction Activity Javier Pérez jperez@infor.uva.es www.infor.uva.es/∼jperez Universidad de Valladolid BENEVOL 2008 Dec 11-12 2008, Eindhoven Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 1 / 28
2. Design Smell Correction Design Smell Correction Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 2 / 28
3. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
4. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
5. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
6. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
7. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
8. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
9. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
10. Design Smell Correction Object-Oriented Software Design Smells Design Smells Problems encountered in the software’s structure (code or design), that can be detected statically, that do not produce compile or run-time errors, but negatively affect software quality factors. In fact, this negative effect on quality factors could lead to real compile and run-time errors in the future. In the context of software inconsistencies: consistency maintenance (keeping models consistent) inconsistency management (detect and resolve inconsistencies) co-evolution (manage consistency between different artefacts) Design smells are corrected with refactorings Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 3 / 28
11. Design Smell Correction Brief History of Design Smell Management Heuristics for Good OO Design Bad Smells Catalogs Precise Smell Specifications Automated Smell Detection Detection Correction Catalogs Precise Correction Specifications Automated Correction Correction (1996 Riel) "Object-Oriented Design Heurstics" (1999 Fowler) "Refactoring; Improving the ..." (2004 Kerievsky) ``Refactoring to Patterns'' (2006 Lanza, Marinescu) "OO Metrics ...'' (2008 Trifu) Towards Automated Restructuring ..." (2008 Moha) "DECOR: Détection et Correction ..." ??? Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 4 / 28
12. Design Smell Correction Brief History of Design Smell Management Detection Correction Heuristics for Good OO Design (1996 Riel) "Object-Oriented Design Heurstics" Bad Smells Catalogs (1999 Fowler) "Refactoring; Improving the ..." Correction Catalogs (2004 Kerievsky) ``Refactoring to Patterns'' Precise Smell Specifications (2006 Lanza, Marinescu) "OO Metrics ...'' Precise Correction Specifications (2008 Trifu) Towards Automated Restructuring ..." Automated Smell Detection (2008 Moha) "DECOR: Détection et Correction ..." Automated Correction ??? Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 4 / 28
13. Smell Example: Feature Envy Smell Example: Feature Envy Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 5 / 28
14. Smell Example: Feature Envy Feature Envy Feature Envy “. . . a method that seems more interested in a class other than the one it actually is in.” (Fowler et al., 1999) Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 6 / 28
15. Smell Example: Feature Envy Feature Envy Example Document <<create>> Document(name : String,author : String) formatSummary() : String toString() : String _content : String _name : String _author : String _creationDate : Date Printserver Printserver(name : String) Printserver(name : String,nextNode : Node) setLastDocument(lastDocument : Document) : void getLastDocument() : Document formatDocument() : String formatSummary() : String print() : void accept(p : Packet) : void lastDocument : Document formatSummary() uses many attributes from Document and none from its own class. The strategy is to move the method to Document but a method with the same signature already exists. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 7 / 28
16. Smell Example: Feature Envy Feature Envy Example Document <<create>> Document(name : String,author : String) formatSummary() : String toString() : String _content : String _name : String _author : String _creationDate : Date Printserver Printserver(name : String) Printserver(name : String,nextNode : Node) setLastDocument(lastDocument : Document) : void getLastDocument() : Document formatDocument() : String formatSummary() : String print() : void accept(p : Packet) : void lastDocument : Document formatSummary() uses many attributes from Document and none from its own class. The strategy is to move the method to Document but a method with the same signature already exists. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 7 / 28
17. Smell Example: Feature Envy Feature Envy Example Document <<create>> Document(name : String,author : String) formatSummary() : String toString() : String _content : String _name : String _author : String _creationDate : Date Printserver Printserver(name : String) Printserver(name : String,nextNode : Node) setLastDocument(lastDocument : Document) : void getLastDocument() : Document formatDocument() : String formatSummary() : String print() : void accept(p : Packet) : void lastDocument : Document formatSummary() uses many attributes from Document and none from its own class. The strategy is to move the method to Document but a method with the same signature already exists. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 7 / 28
18. Smell Example: Feature Envy Feature Envy Example Document <<create>> Document(name : String,author : String) formatSummary() : String toString() : String _content : String _name : String _author : String _creationDate : Date Printserver Printserver(name : String) Printserver(name : String,nextNode : Node) setLastDocument(lastDocument : Document) : void getLastDocument() : Document formatDocument() : String formatSummary() : String print() : void accept(p : Packet) : void lastDocument : Document formatSummary() uses many attributes from Document and none from its own class. The strategy is to move the method to Document but a method with the same signature already exists. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 7 / 28
19. Smell Example: Feature Envy Feature Envy Example Document <<create>> Document(name : String,author : String) formatSummary() : String toString() : String _content : String _name : String _author : String _creationDate : Date Printserver Printserver(name : String) Printserver(name : String,nextNode : Node) setLastDocument(lastDocument : Document) : void getLastDocument() : Document formatDocument() : String formatSummary() : String print() : void accept(p : Packet) : void lastDocument : Document formatSummary() uses many attributes from Document and none from its own class. The strategy is to move the method to Document but a method with the same signature already exists. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 7 / 28
20. Smell Example: Feature Envy Problems in Automated Correction Which is the strategy to correct a smell? Feature Envy (m) ⇒ move method m close to data, from class s to class t Which is the precise strategy instance to use? Feature Envy (formatSummary) ⇒ move method formatSummary from Printserver to Document How to apply the strategy instance? move method formatSummary from Printserver to Document ⇒ 1 first remove formatSummary in Document or rename formatSummary in Document or rename formatSummary in Printserver 2 then move method formatSummary from Printserver to Document Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 8 / 28
21. Refactoring Planning Refactoring Planning Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 9 / 28
22. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
23. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
24. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
25. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
26. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
27. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
28. Refactoring Planning Refactoring Plans The objective: Instantiate smell correction strategies into a correction plan which could be effectively applied, or at least could guide the developer through the process. Refactoring Plan Specification of a refactoring sequence which matches a system redesign proposal, and that can be immediately executed to modify the system, without changing the system’s behaviour, in order to obtain that desirable system redesign. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 10 / 28
29. Refactoring Planning Refactoring Model Refactoring conflict 0..* 0..* dependency 0..* 0..* Simple Precondition Composed AND OR NOT Definition Transformation 1..* Parameter 1..* 1..* Add Delete Replace Entity Relationship Operation Element 1..* 1..* Refactoring Plan 0..* 1..* Refactoring plans can be computed with automated planning Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 11 / 28
30. Refactoring Planning Refactoring Model Refactoring conflict 0..* 0..* dependency 0..* 0..* Simple Precondition Composed AND OR NOT Definition Transformation 1..* Parameter 1..* 1..* Add Delete Replace Entity Relationship Operation Element 1..* 1..* Refactoring Plan 0..* 1..* Refactoring plans can be computed with automated planning Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 11 / 28
31. Refactoring Planning Automated Planning Definition Automated planning is an artificial intelligence technique to generate sequences of actions that will achieve a certain goal when they are performed. Example: Getting apples and a book. The state of the world: at (grocery) AND not (have (apples)) Actions: buy (apples); moveTo (bookstore) Goals: have (book) AND have (apples) Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 12 / 28
32. Refactoring Planning Plan S0 S1 S2 SG O1 Sn O2 On OG Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 13 / 28
33. Refactoring Planning Classical Planning Operators (STRIPS) World’s state: list of terms Operators: definition: name + arguments precondition effect list (add): terms to add to the state effect list (deletes): terms to remove from the state Problem: initial state goal: list of terms General planning approach: chain operators by matching their effects and preconditions Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 14 / 28
34. Refactoring Planning Some Types of Planners Depending on the planning space: state space planning plan space planning Depending on the search direction: forward searching backwards searching Depending on when the operator ordering is comitted: total-order planning partial-order planning I’m using Hierarchical Task Network (HTN) planning. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 15 / 28
35. Refactoring Planning Some Types of Planners Depending on the planning space: state space planning plan space planning Depending on the search direction: forward searching backwards searching Depending on when the operator ordering is comitted: total-order planning partial-order planning I’m using Hierarchical Task Network (HTN) planning. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 15 / 28
36. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
37. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
38. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
39. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
40. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
41. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Goal Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
42. Refactoring Planning Hierarchical Task Network (HTN) Planning method1 precondition1 task1 task2 task3 ... method2 precondition2 task4 operator1 precondition3 ADD DEL Goal Execute a task Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 16 / 28
43. Refactoring Planning Smell Correction with HTN Planning World’s state: AST represented by first order logic formulas Operators: refactoring substeps Tasks: refactorings strategies smell correction strategies Goals: Execute a smell correction strategy Planning Problem: Execute a particular smell correction strategy over a particular version of a system Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 17 / 28
44. Planning for “Feature Envy” Planning for “Feature Envy” Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 18 / 28
45. Planning for “Feature Envy” HTN for “move method” everything_ok not ( isStatic (m) ) isReachable(target, m) not ( callsSuper (m) ) not ( isNameConflict (m, target) move_method (Class source, Mehod m, Class target) name_conflict move_method_definition (Class source, Mehod m, Class target) update_method_calls (Class source, Mehod m, Class target) not ( isStatic (m) ) isReachable(target, m) not ( callsSuper (m) ) isNameConflict (m, target) move_method (Class source, Mehod m, Class target) solve_name_conflict (Class source, Mehod m, Class target) ... Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 19 / 28
46. Planning for “Feature Envy” HTN for “solve conflict” solve_name_conflict (Class source, Mehod m, Class target) rename_source rename_target remove_target rename_method (Class source, Mehod m) rename_method (Class target, Mehod m) remove_unreferenced_method (Class target, Mehod m) Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 20 / 28
47. Planning for “Feature Envy” HTN for “feature envy” correct_feature_envy (Class c, Method m) Class target = whereToMove (c, m) move_method_close_to_data move_method (Class c, Mehod m, Class target) Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 21 / 28
48. Planning for “Feature Envy” Planning for “feature envy” correct_feature_envy (Printserver, formatSummary) whereToMove (Printserver, formatSummary) -> Document move_method_close_to_data move_method (Printserver, formatSummary, Document) Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 22 / 28
49. Planning for “Feature Envy” Planning for “move method” 1 move_method (Printserver, formatSummary, Document) everything_ok not ( isStatic (formatSummary) ) isReachable(Document,formatSummary) not ( callsSuper (formatSummary) ) not ( isNameConflict (formatSummary, Document) name_conflict move_method (Printserver, formatSummary, Document) solve_name_conflict (Printserver, formatSummary, Document) not ( isStatic (formatSummary) ) isReachable(Document,formatSummary) not ( callsSuper (formatSummary) ) isNameConflict (formatSummary, Document) Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 23 / 28
50. Planning for “Feature Envy” Planning for “move method” 2 move_method (Printserver, formatSummary, Document) solve_name_conflict (Printserver, formatSummary, Document) remove_target remove_unreferenced_method (Document, formatSummary) move_method_definition (Class source, Mehod m, Class target) update_method_calls (Class source, Mehod m, Class target) not ( isStatic (formatSummary) ) isReachable(Document,formatSummary) not ( callsSuper (formatSummary) ) not ( isNameConflict (formatSummary, Document) everything_ok Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 24 / 28
51. Planning for “Feature Envy” Planning for “move method” 2 move_method (Printserver, formatSummary, Document) solve_name_conflict (Printserver, formatSummary, Document) remove_target remove_unreferenced_method (Document, formatSummary) move_method_definition (Class source, Mehod m, Class target) update_method_calls (Class source, Mehod m, Class target) not ( isStatic (formatSummary) ) isReachable(Document,formatSummary) not ( callsSuper (formatSummary) ) not ( isNameConflict (formatSummary, Document) everything_ok Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 24 / 28
52. Conclusions and Future Work Conclusions and Future Work Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 25 / 28
53. Conclusions and Future Work Conclusions Design smell management can keep being improved, working on specification and automation of the correction activity. To do that, correction strategies must be planned ahead for each specific case. This can be done with automated planning and specifically with HTN planning: HT networks can accommodate correction strategies, combining procedural and non-deterministic searching. HTN planning offers good balance between procedural execution and non-determinism. The planner can be incrementally extended, adding new methods and improving the existing ones. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 26 / 28
54. Conclusions and Future Work Conclusions Design smell management can keep being improved, working on specification and automation of the correction activity. To do that, correction strategies must be planned ahead for each specific case. This can be done with automated planning and specifically with HTN planning: HT networks can accommodate correction strategies, combining procedural and non-deterministic searching. HTN planning offers good balance between procedural execution and non-determinism. The planner can be incrementally extended, adding new methods and improving the existing ones. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 26 / 28
55. Conclusions and Future Work Conclusions Design smell management can keep being improved, working on specification and automation of the correction activity. To do that, correction strategies must be planned ahead for each specific case. This can be done with automated planning and specifically with HTN planning: HT networks can accommodate correction strategies, combining procedural and non-deterministic searching. HTN planning offers good balance between procedural execution and non-determinism. The planner can be incrementally extended, adding new methods and improving the existing ones. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 26 / 28
56. Conclusions and Future Work Conclusions Design smell management can keep being improved, working on specification and automation of the correction activity. To do that, correction strategies must be planned ahead for each specific case. This can be done with automated planning and specifically with HTN planning: HT networks can accommodate correction strategies, combining procedural and non-deterministic searching. HTN planning offers good balance between procedural execution and non-determinism. The planner can be incrementally extended, adding new methods and improving the existing ones. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 26 / 28
57. Conclusions and Future Work Conclusions Design smell management can keep being improved, working on specification and automation of the correction activity. To do that, correction strategies must be planned ahead for each specific case. This can be done with automated planning and specifically with HTN planning: HT networks can accommodate correction strategies, combining procedural and non-deterministic searching. HTN planning offers good balance between procedural execution and non-determinism. The planner can be incrementally extended, adding new methods and improving the existing ones. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 26 / 28
58. Conclusions and Future Work Conclusions Design smell management can keep being improved, working on specification and automation of the correction activity. To do that, correction strategies must be planned ahead for each specific case. This can be done with automated planning and specifically with HTN planning: HT networks can accommodate correction strategies, combining procedural and non-deterministic searching. HTN planning offers good balance between procedural execution and non-determinism. The planner can be incrementally extended, adding new methods and improving the existing ones. Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 26 / 28
59. Conclusions and Future Work Future Work Implement refactoring specifications Implement design smell correction strategies Run experiments on real systems Integrate the planer with other tools for: refactoring dependencies computation metrics computation . . . Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 27 / 28
60. Conclusions and Future Work Enabling Refactoring with HTN Planning to Improve the Design Smells Correction Activity Javier Pérez jperez@infor.uva.es www.infor.uva.es/∼jperez Universidad de Valladolid BENEVOL 2008 Dec 11-12 2008, Eindhoven Javier Pérez (UVa) Refactoring Planning 11-12 Dec 2008 28 / 28