(On the infeasibility of) Model/Code Co- Refactoring Friedrich Steimann Lehrgebiet...

(On the infeasibility of) Model/Code Co-Refactoring

Friedrich SteimannLehrgebiet ProgrammiersystemeFernuniversität in Hagen, Germany

ProgrammiersystemeProgrammiersysteme

F Steimann, J von Pilgrim Refactorings without Names ASE 2012

Refactoring

Meaning-preserving change of Meaning-preserving change of a software artefact with the a software artefact with the aim of improving one or more aim of improving one or more of its non-functional of its non-functional properties.properties.

(extended definition)



Problem I

A

a class A {private A a;public void setA(A a) { … }public A getA() { … }}

class AImpl extends A {private Object b;public void setB(Object b) { … }}

AImpl aImpl = new AImpl(); aImpl.setB(aImpl);

bb

B

B

Rename a



Problem II

A

B C

x : inty : int

x : int

Pull Up Field x



Problem III

A

B C

x : inty : int

x : int= 1 = 2

Pull Up Field y



Constraint-based refactoring

proven successful for programs one of the few developed theories of

refactoring encodes refactoring invariants as CSPs originally applied to type refactorings (like

Extract Superclass) recently generalized to other programming

constructs (names, accessibilities, etc.)



Constraint rules

query

constraints

bindsr, d r.name d.name

r d :

constraint variables



Example

A a;a = new A();

bindsr, d r.name d.name

ra.name = da.name

b

b

r d :

bindsra, da



Refacola

refactoring definitionsrefactoring definitions

Eclipse

refactoring definitions

Xtext / Xpand / Xtend

Refacola Compiler

programs to be refactoredprograms to be refactored

ConstraintSolver

Generated RefactoringTools

programs to be refactored

programqueries

AST

writingback

constraint generator

Refacola Framework

IDE

= component dependencies



language UMLkinds

Class <: ENTITY { name }Feature <: ENTITY { name, type, owner }Attribute <: FeatureOperation <: Feature

propertiesname: Identifiertype: ClassDomainowner: ClassDomain

domainsClassDomain = [ Class ]

queriessuperclass(c: Class, super: Class)

rulesuniqueFeatureNamesfor allF1: Feature F2: Featureif F1!=F2then superclass*(F1.owner, F2.owner) -> F1.name != F2.name

refactoring renameFeature forced name of Feature allowed name of Featurerefactoring pullupFeature forced owner of Feature

allowed name of Feature, owner of Feature



From refactoring to co-refactoring record transformation traces as facts

transformation of attribute to field + getter + setter:

attribute2field(a, f) attribute2getter(a, g) attribute2setter(a, s)

generate constraints from trace facts



1. language Generation2. imports Java, UML3. queries4. class2class(cU : UML.Class, cJ : Java.Class)5. attribute2field(a : UML.Attribute, f : Java.Field)6. attribute2getter(a : UML.Attribute, g : Java.Method)7. attribute2setter(a : UML.Attribute, s : Java.Method)8. rules9. attributeToFieldNames10. for all11. a : UML.Attribute12. f : Java.Field13. g, s : Java.Method14. if15. attribute2field(a, f) and attribute2getter(a, g) 16. and attribute2setter(a, s)17. then18. f.name = a.name19. f.accessibility = private20. g.name = "get" + a.name21. g.accessibility = public22. s.name = "set" + a.name23. s.accessibility = public



Model/Code Co-RefactoringInstrumentation

UML

model

transformation language

transformationmodel & rules

transformationtrace

Java

code

M3

M2

M1 modelconstraints

traceconstraints

codeconstraints

UMLrefactorings

tracerules

Javarefactorings

Refacola Refacola Refacola

CSP

query engine

instance of data flow

factbase

Code Generation RefactoringMOF Layer



Research Questions1. How often is an intended model refactoring inhibited by implied

changes of the code which would break its well-formedness or change its meaning and hence cannot be performed?

2. For the model refactorings implying code changes that can be performed: How many changes are implied in the code?

3. How often do implied changes performed in the code propagate back as necessary changes of the model?

4. For the necessary changes propagated back to the model: How often do they inhibit the refactoring?

5. If they do not inhibit the refactoring: How many are they?



Evaluation

10 open source java programs 3309 classes, 3667 fields, 13196 methods

reversely engineered class diagrams 1036 classes, 878 attributes, 5975 operations

internal representation 30627 elements, 143287 facts for model 360694 elements, 534239 facts for code 14579 elements, 26006 facts for trace



Research Questions1. How often is an intended model refactoring inhibited by implied

changes of the code? In 50% of all cases!

2. For the model refactorings implying code changes that can be performed: How many changes are implied in the code? 8.5 changes per refactoring!

3. How often do implied changes performed in the code propagate back as necessary changes of the model? In 46% of these cases!

4. For the necessary changes propagated back to the model: How often do they inhibit the refactoring? 14%

5. If they do not inhibit the refactoring: How many are they? 5.6 on average!





Chaotic transformations

Transformations may react to very small changes

by generating largely different code. Even if meaning-preserving, we have no means of synchronizing

extensions. Co-refactoring is a dead-end road.



Vielen Dank!Fragen?

Date post:	31-Mar-2015
Category:	Documents
Upload:	clarence-sheehan
View:	212 times
Download:	0 times

(On the infeasibility of) Model/Code Co- Refactoring Friedrich Steimann Lehrgebiet...

Documents