Automated Elaboration of Refactoring Plans F. Javier Pérez García [email protected] Departamento de Informática Universidad de Valladolid Valladolid, Spain Automated Elaboration of Refactoring Plans – p.1 

Slides Index • Introduction • Refactoring Plan Issues • Approach • Example • Results and Future Work Automated Elaboration of Refactoring Plans – p.2 

Introduction Automated Elaboration of Refactoring Plans – p.3 

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 

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 

Refactoring to a Desirable Design Automated Elaboration of Refactoring Plans – p.6 

Refactoring Plan Issues Automated Elaboration of Refactoring Plans – p.7 

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 

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 

Graph Rewriting Based Approach Automated Elaboration of Refactoring Plans – p.10 

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 

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 

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 

Example Automated Elaboration of Refactoring Plans – p.14 

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 

Create unreferenced empty Class Automated Elaboration of Refactoring Plans – p.16 

Create unreferenced empty Method Automated Elaboration of Refactoring Plans – p.17 

Move method to empty method Automated Elaboration of Refactoring Plans – p.18 

Small Example Preferences protocol() printMe() Address connection() printMe() SetUp settings() 1 1 Automated Elaboration of Refactoring Plans – p.19 

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 

Starting System Graph Automated Elaboration of Refactoring Plans – p.21 

Layer 0: Class created Automated Elaboration of Refactoring Plans – p.22 

Layer 1: Method created Automated Elaboration of Refactoring Plans – p.23 

Layer 2: Methods Moved Automated Elaboration of Refactoring Plans – p.24 

Results and Future Work Automated Elaboration of Refactoring Plans – p.25 

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 

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 

Automated Elaboration of Refactoring Plans F. Javier Pérez García [email protected] Departamento de Informática Universidad de Valladolid Valladolid, Spain Automated Elaboration of Refactoring Plans – p.28