Presentation is loading. Please wait.

Presentation is loading. Please wait.

(On the infeasibility of) Model/Code Co- Refactoring Friedrich Steimann Lehrgebiet Programmiersysteme Fernuniversität in Hagen, Germany.

Similar presentations


Presentation on theme: "(On the infeasibility of) Model/Code Co- Refactoring Friedrich Steimann Lehrgebiet Programmiersysteme Fernuniversität in Hagen, Germany."— Presentation transcript:

1 (On the infeasibility of) Model/Code Co- Refactoring Friedrich Steimann Lehrgebiet Programmiersysteme Fernuniversität in Hagen, Germany

2 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Refactoring Meaning-preserving change of a software artefact with the aim of improving one or more of its non- functional properties. (extended definition)

3 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Problem I 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); b b B B Rename a

4 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Problem II public class A {} public class B extends A { private int x; private int y; public void init() { x = 10; y = 10; } public class C extends A { private int x; … } Pull Up Field x

5 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Problem III = 1= 2 public class A {} public class B extends A { private int x = 1; private int y; public void init() { y = x; } public class C extends A { private int x = 2; … } Pull Up Field y

6 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 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.)

7 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Constraint rules query constraints binds  r, d  r.name  d.name  r  d : constraint variables

8 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Example A a; a = new A(); binds  r, d  r.name  d.name r a.name = d a.name b b  r  d : binds  r a, d a 

9 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Refacola

10 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 language UML kinds Class <: ENTITY { name } Feature <: ENTITY { name, type, owner } Attribute <: Feature Operation <: Feature properties name: Identifier type: ClassDomain owner: ClassDomain domains ClassDomain = [ Class ] queries superclass(c: Class, super: Class) rules uniqueFeatureNames for all F1: FeatureF2: Feature if F1!=F2 then superclass*(F1.owner, F2.owner) -> F1.name != F2.name refactoring renameFeature forced name of Feature allowed name of Feature refactoring pullupFeature forced owner of Feature allowed name of Feature, owner of Feature

11 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 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

12 F Steimann, J von Pilgrim Refactorings without Names ASE language Generation 2.imports Java, UML 3.queries 4.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.rules 9.attributeToFieldNames 10.for all 11.a : UML.Attribute 12.f : Java.Field 13.g, s : Java.Method 14.if 15.attribute2field(a, f) and attribute2getter(a, g) 16. and attribute2setter(a, s) 17.then 18.f.name = a.name 19.f.accessibility = private 20.g.name = "get" + a.name 21.g.accessibility = public 22.s.name = "set" + a.name 23.s.accessibility = public

13 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Model/Code Co-Refactoring Instrumentation

14 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Research Questions 1. 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?

15 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Evaluation 10 open source java programs  3309 classes, 3667 fields, methods reversely engineered class diagrams  1036 classes, 878 attributes, 5975 operations internal representation  elements, facts for model  elements, facts for code  elements, facts for trace

16 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Research Questions 1. 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!

17 F Steimann, J von Pilgrim Refactorings without Names ASE 2012

18 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. 

19 F Steimann, J von Pilgrim Refactorings without Names ASE 2012 Vielen Dank! Fragen?


Download ppt "(On the infeasibility of) Model/Code Co- Refactoring Friedrich Steimann Lehrgebiet Programmiersysteme Fernuniversität in Hagen, Germany."

Similar presentations


Ads by Google