1 / 19

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

(On the infeasibility of) Model/Code Co-Refactoring. Friedrich Steimann Lehrgebiet Programmiersysteme Fernuniversität in Hagen, Germany. Refactoring. Meaning-preserving change of a software artefact with the aim of improving one or more of its non-functional properties. (extended definition).

erling
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Refactoring Meaning-preserving change of a software artefact with the aim of improving one or more of its non-functional properties. (extended definition)

  3. Problem I b class A { private A a; publicvoid setA(A a) { … } public A getA() { … } } b B B class AImpl extends A { private Object b; publicvoid setB(Object b) { … } } AImpl aImpl = new AImpl(); aImpl.setB(aImpl); Rename a

  4. Problem II public class A {} public class B extends A { private int x; private int y; … @not_generated public voidinit() { x = 10; y = 10; } } public class C extends A { privateint x; … } Pull Up Field x

  5. Problem III public class A {} public class B extends A { private int x = 1; private int y; … @not_generated public voidinit() { y = x; } } public class C extends A { privateint x = 2; … } = 1 = 2 Pull Up Field y

  6. 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. Constraint rules r d : constraint variables

  8. Example b A a; a = new A(); bindsra, da b r d : ra.name = da.name

  9. Refacola

  10. 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: Feature F2: 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. 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. language Generation • imports Java, UML • queries • class2class(cU : UML.Class, cJ : Java.Class) • attribute2field(a : UML.Attribute, f : Java.Field) • attribute2getter(a : UML.Attribute, g : Java.Method) • attribute2setter(a : UML.Attribute, s : Java.Method) • rules • attributeToFieldNames • for all • a : UML.Attribute • f : Java.Field • g, s : Java.Method • if • attribute2field(a, f) and attribute2getter(a, g) • and attribute2setter(a, s) • then • f.name = a.name • f.accessibility = private • g.name = "get" + a.name • g.accessibility = public • s.name = "set" + a.name • s.accessibility = public

  13. Model/Code Co-RefactoringInstrumentation

  14. Research Questions 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? For the model refactorings implying code changes that can be performed: How many changes are implied in the code? How often do implied changes performed in the code propagate back as necessary changes of the model? For the necessary changes propagated back to the model: How often do they inhibit the refactoring? If they do not inhibit the refactoring: How many are they?

  15. 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

  16. Research Questions How often is an intended model refactoring inhibited by implied changes of the code? In 50% of all cases! For the model refactorings implying code changes that can be performed: How many changes are implied in the code? 8.5 changes per refactoring! How often do implied changes performed in the code propagate back as necessary changes of the model? In 46% of these cases! For the necessary changes propagated back to the model: How often do they inhibit the refactoring? 14% If they do not inhibit the refactoring: How many are they? 5.6 on average!

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

  18. Vielen Dank! Fragen?

More Related