Automated Elaboration of Refactoring Plans

This work presents the first exploration to support the automated elaboration of Refactoring Plans. Graph transformations seem to offer good mechanisms to be used as the relying formalism. The refactoring plan problem has been identified as the membership problem in formal languages theory. It seems to be a promising approach, because graph grammars for which the problem has already been solved, can be used. Presented at GTTSE 2005 (http://wiki.di.uminho.pt/twiki/bin/view/Events/GTTSE).

Transcript

1. Automated Elaboration of Refactoring Plans F. Javier Pérez García jperez@infor.uva.es Departamento de Informática Universidad de Valladolid Valladolid, Spain Automated Elaboration of Refactoring Plans – p.1
2. Slides Index • Introduction • Refactoring Plan Issues • Approach • Example • Results and Future Work Automated Elaboration of Refactoring Plans – p.2
3. Introduction Automated Elaboration of Refactoring Plans – p.3
4. Introduction: Refactoring Automation Current approaches to refactoring automation: • automation focus on finding and applying single refactoring opportunities • oriented to improve certain design characteristics In some cases, deeper redesign is needed: • wider architectural changes • starting a framework based product-line from legacy software Other refactoring methodologies are needed. Automated Elaboration of Refactoring Plans – p.4
5. Introduction: Refactoring Plan Start with a desirable system design proposal: • Formal concept Analysis • skilled human designer • metrics Refactoring Plan: chain of refactorings to reach a proposed new design. Automated elaboration of Refactoring Plans: • new design, reachable with a refactoring sequence? • which is the refactoring sequence? Automated Elaboration of Refactoring Plans – p.5
6. Refactoring to a Desirable Design Automated Elaboration of Refactoring Plans – p.6
7. Refactoring Plan Issues Automated Elaboration of Refactoring Plans – p.7
8. A GRS Problem A kind of Formal Language Problem: Finding the transformation steps that turn a state into another. Representing software, specially its structural relationships is straightforward with graphs. Problem Representation: • Software ⇒ Graphs • Software Transformations ⇒ Graph Rewriting Systems Automated elaboration of Refactoring Plans can be represented as a Graph Rewriting/Transformation Problem Automated Elaboration of Refactoring Plans – p.8
9. Finding the refactoring Plan, with GRSs Use a Graph Grammar (GG) where: • Legacy Software System ⇒ Starting State • Refactorings ⇒ Production Rules • Desirable Design ⇒ Final State Validating the desirable design ⇒ membership problem. Obtaining the Refactoring Plan ⇒ Obtaining the derivation sequence. Automated Elaboration of Refactoring Plans – p.9
10. Graph Rewriting Based Approach Automated Elaboration of Refactoring Plans – p.10
11. Formal Representation of OO Software Need to represent: • OO elements (Classes, fields, methods, . . . ) • method’s bodies • structural relationships Mens et al. Formalism: • GRS system based on directed typed graphs • aimed at formalizing refactorings • supports: ◦ Constraints and well formedness rules ◦ Graph transformation rules ◦ behavior preserving invariants ◦ specification of complex context of rules (NAC, node embeddings, path expressions) Automated Elaboration of Refactoring Plans – p.11
12. Finding a Refactoring Plan Write refactoring rules within a GG for which the membership problem is solved. Contextual Layered Graph Grammars (CLGGs): • extension of Layered Graph Grammars (LGGs) • rules are classified in subsets of ordered layers • parsing: ◦ rules are applied by layer order ◦ creation-deletion of single element of same type ◦ each step, graph is reduced ◦ each step, applicable rules are reduced • specification of complex context of rules (NAC, node embeddings, path expressions) Automated Elaboration of Refactoring Plans – p.12
13. Micro-Refactorings Layering Refactoring rules providing graph and rule reduction: • use refactoring rules inspired by CLGGs • refactorings are ordered and assigned different layers • need rules for single element refactorings • each layer aimed at an element type Micro-Refactorings: • based on Opdyke’s low-level refactorings • small behavior preserving operations: ◦ create, delete, move, rename ◦ single elements: classes, methods, . . . • limit the number of times a rule is applicable over an element Automated Elaboration of Refactoring Plans – p.13
14. Example Automated Elaboration of Refactoring Plans – p.14
15. Micro-Refactoring Rules Three simple rules: • Create unreferenced empty Class • Create unreferenced empty Method • Move method to empty method Restrictions to reduce applicable set of rules: • Specific counters for each rule • Rule layering ◦ 0: Create Class ◦ 1: Create Method ◦ 2: Move Method Automated Elaboration of Refactoring Plans – p.15
16. Create unreferenced empty Class Automated Elaboration of Refactoring Plans – p.16
17. Create unreferenced empty Method Automated Elaboration of Refactoring Plans – p.17
18. Move method to empty method Automated Elaboration of Refactoring Plans – p.18
19. Small Example Preferences protocol() printMe() Address connection() printMe() SetUp settings() 1 1 Automated Elaboration of Refactoring Plans – p.19
20. Desirable System Design Preferences protocol() printMe() Address connection() printMe() SetUp settings() protocol(pref:Preferences) Connect connection(addr:Address) 1 1 1 1 Automated Elaboration of Refactoring Plans – p.20
21. Starting System Graph Automated Elaboration of Refactoring Plans – p.21
22. Layer 0: Class created Automated Elaboration of Refactoring Plans – p.22
23. Layer 1: Method created Automated Elaboration of Refactoring Plans – p.23
24. Layer 2: Methods Moved Automated Elaboration of Refactoring Plans – p.24
25. Results and Future Work Automated Elaboration of Refactoring Plans – p.25
26. Results • An initial step of the research has been presented • Requirements for Automated elaboration of Refactoring Plans has been stated • Formalisms to be used have been explored • Mens formalism can fulfill our requirements • CLGGs are OK, but more grammars must been explored Automated Elaboration of Refactoring Plans – p.26
27. Future Work • • Prove that micro-refactorings can be composed into “normal” refactorings • Catalog of micro-refactorings & decomposed refactorings • Extensive validation through tools like AGG, FUJABA or PROGRES • Extensions to formalisms and tools if needed • Improve rules to full automatize the process Automated Elaboration of Refactoring Plans – p.27
28. Automated Elaboration of Refactoring Plans F. Javier Pérez García jperez@infor.uva.es Departamento de Informática Universidad de Valladolid Valladolid, Spain Automated Elaboration of Refactoring Plans – p.28