Pro-active Support to Detect and Correct Design Violations (EngIME group meeting, 20/04/2017)

Refactoring is a key process to improve program comprehension and maintainability, and it is currently automated in many standard IDEs. To bring this automated support to the next level, we propose to put code transformations into a more elaborated flow of actions, e.g., move more classes after a Move Class refactoring is performed. Our approach recommends additional transformations that, if accepted by the developer, are applied automatically. The recommendations used as examples in this paper were identified by inspecting sequences of transformations performed by developers in two real-life use cases. On these real cases, our approach automated about a third of transformations that were otherwise performed manually for some refactoring such as Move Class and Extract Method.

Transcript

1. Pro-active Support to Detect and Correct Design Violations Gustavo SANTOS Advisor: Fabio KON, IME-USP, Brazil
2. / 16 Software Evolution In software development, change is the only constant Code transformations on a daily basis Manual code edition, or Eventual automated support, e.g., refactoring tools 2
3. / 16 Problem Motivated by adaptive and perfective maintenance Code might undergo an undesirable state Design violations might be introduced Tests might fail, etc. 3
4. / 16 Overall Solution Recommend additional transformations after the developer performs a specific transformation “Move additional classes after one class is moved” Repetitive flow of actions (transform-then-fix) A.k.a. post-refactoring [Zarras et al., 2015] Based on the occurrence of known design smells 4
5. / 16 Recorder Transformation Tool Quality Rule: “a subclass must be in the same package as its superclass” e.g., Epicea, Mylyn e.g., Refactoring, Eclipse new MoveClass( WindowActivated, “Morphic-Windows”); Dependent on the recorded transformation event: ClassWasMoved ——————————-———— + class: WindowAnnouncement + srcPackage: “Morphic-Base” + tgtPackage: “Morphic-Window” Recommending Additional Transformations 5
6. / 16 Recording Transformations Epicea [Dias et al., 2015] 6 IDEEvent AutomatedRefactoring CodeTransformation ... + 12 events PackageTransformation MethodTransformation TempVariableTransformation ClassTransformation AttributeTransformation InheritanceChange ProtocolChange AssignmentTransformation ReturnTransformation MessageSendTransformation PragmaTransformation Model::Main
7. / 16 Identifying Transformation Opportunities QualityAssistant [Tymchuk, 2015] Executed independently Associated to a specific transformation Local checking 7
8. / 16 Transformation Opportunity I Related classes should be in the same package Scattered Functionality [Garcia et al., 2009]
 Broken Modularization [Suryanarayana et al., 2014]
 Misplaced Class [Fowler et al., 1999] Scenario for Move Class refactoring:
 “If subclasses of a moved class are in the former package, recommend to move them as well” 8
9. / 16 Transformation Opportunity II Hierarchy must separate common behavior Code clone [Fowler et al., 1999]
 Unfactored Hierarchy [Suryanarayana et al., 2014]
 Sibling Duplication [InFusion, 2016]
 Repeated Functionality [Arévalo, 2005] Scenario for Extract Method refactoring:
 “If the extracted method’s code is repeated along the subclasses, mark them invoke the method instead.” 9
10. / 16 Recommending Transformations 10 DSL to instantiate and execute transformations Declared in the quality rule Scenario for Move Class refactoring:
 buildTransformationsFor: aClass ^ RBCompositeTransformation with: ((self filteredSubclassesFor: aClass) collect: [ :subclass | RBMoveClassTransformation move: subclass name to: aClass package name ])
11. / 16 Evaluation Extract specific transformations from code repository Replay these transformations using our approach Collect the recommendations Check whether the recommended transformation was performed 11
12. / 16 Evaluation Metrics 1. Precision
 - Recommendations that are correct (accuracy) 2. Recall
 - Recommendations that were manually performed by developers (automation) 12
13. / 16 Project PolyMorph 132 Move Class transformations 79 recommendations 62 correct recommendations 78% precision 32% recall Preliminary Results - Case Study I 13 19 recommendations validated by the developers
14. / 16 Preliminary Results - Case Study II 14 Pharo’s icon management 19 Extract Method + 389 Code Replacement transformations 352 recommendations 336 correct recommendations 95% precision 71% recall 58 recommendations validated by the developers
15. / 16 Current Work Identify rules that developers fix the most (collaboration) More post-mortem analysis Possibility to integrate in a default Pharo image 15
16. Pro-active Support to Detect and Correct Design Violations Gustavo SANTOS gustavojss.github.io Thank you!