1. Automated Support for Program Refactoring Using Invariants
Yoshio Kataoka (Toshiba)
Michael Ernst (MIT)
William Griswold (UCSD)
David Notkin (UW)
[Be excited! Have a twinkle in my eye! This is good research; it is exciting; share the fun I had and enthusiasm I feel.]
[Smile when I make a joke -- don’t be too dry, don’t sound mean.]
[Don’t go too fast through first part of talk.]
[Make eye contact.]
This is a technique for helping programmers to cope with inadequately documented programs.
Invite questions and comments.
Daikon: an Asian radish (not the Asian radish)
Perhaps don’t say this, but this is but a summary: I can’t talk about every aspect of this research, but welcome questions either now or in individual meetings.
Goal:
Automatically identify refactoring candidates

2. Refactoring (Local) program restructuring
Enhance readability, performance, abstraction, maintainability, flexibility, ...
Beloved of Extreme Programming
Example: Extract Method
find repeated code
replace each occurrence by call to a new method

3. Refactoring steps Select a refactoring Apply the refactoring
Typically done by hand or via lexical analysis
Apply the refactoring
Some tool support exists
A semantic analysis would be better.
Also need to validate the refactoring, either before or after application.

4. Identifying refactoring opportunities
Pattern of invariants  refactoring is applicable
An invariant is a program property (as in asserts or specifications)
x > abs(y)
x = 16*y + 4*z + 3
array a contains no duplicates
for each node n, n = n.child.parent
graph g is acyclic
if ptr  null then *ptr > i
Invariants are rarely present in practice
Here and subsequently, avoid conflating "invariant" and "specification".
Segue: this works assuming you have a set of invariants -- essentially, a specification. What if you do not?

5. Tool architecture Original program Invariant Detector (Daikon)
Test suite
Invariants
patterns
Refactoring
Candidate
candidates
Implemented invariant pattern matcher
Given invariants, suggests refactorings
User decides which refactorings to apply
Segue: this works assuming you have a set of invariants -- essentially, a specification. What if you do not?

6. Dynamic invariant detection
Goal: recover invariants from programs
Technique: run the program, examine values
postulate potential invariants
check for each set of variable values
Results are likely invariants
If you were at the dissertation forum yesterday, you already heard about this.
It's generate-and-check.
It's efficient.

7. Dynamic invariant detection
Implementation: Daikon
Experiments indicate accuracy and usefulness
Recover/prove formal specs, aid programmers
Dynamically detected invariants may identify more refactoring opportunities
Static analysis fails for pointers
For this application, we only needed the simplest equality invariants.
Previous approaches primarily lexical, non-semantic.

8. Refactorings examined
Remove Parameter
Eliminate Return Value
Separate Query from Modifier
Encapsulate Downcast
Replace Temporary Variable by Query
Refactoring catalogs [Opdyke 92, Fowler 99] focus on simple lexical transformations

9. Remove Parameter Applicable when parameter is constant or unused
param = constant, or
param = f(a, b, ...), where a, b, ... are in scope
Examples:
height = width for all icons
isAutomaticAspect = true in Aspect constructor
SetFirstItemFlag called with constant argument
GO SLOW! Give people time to read and understand the slides.
Say where the examples come from.

10. Eliminate Return Value
Applicable if return value is constant or unused
return = constant, or
return = f(a, b, ...), where a, b, ... are in scope
Example:
return = true in MakeObjectObey

11. Separate Query from Modifier
Applicable when a method returns a value and has a side effect
return  constant, and
a  orig(a) for some a in scope
Example:
mCurrentIndex = orig(mCurrentIndex) +1 in CursorHistory.GetNextItem
Explain the orig() notation.

12. Encapsulate Downcast
Applicable when return value needs to be downcasted by the caller
LUB(return.class)  declaredtype(return)
Approximation:
return.class = constant, and
return.class  declaredtype(return)
Example:
comboBoxItems.class = AspectTraverseListItem[] in AspectTraverseComboBox

13. Replace Temp. Var. by Query
Applicable when a temporary variable holds the value of an expression
temp = orig(temp), and
a = orig(a) for all vars a in initializer of temp
Examples found after adding wrapper functions

14. Case study: Nebulous A component of Aspect Browser [Griswold 01]
Visualizes cross-cutting aspects of a program
Manages changes to such aspects
Uses pattern matching and the map metaphor
78 files, 7000 non-comment non-blank lines
The geographic map metaphor.

15. Case study methodology
Wrote a Perl script to identify invariant patterns in Daikon output
Ran Daikon over Nebulous executions
Ran script to identify refactoring opportunities
Nebulous programmer evaluated the recommendations

16. Programmer assessment
yes
maybe no
total
Remove Parameter 6 4 5 15
Eliminate Return Value 1 2 7
Sep. Query from Modifier
Encapsulate Downcast
Total 8 9 26
Remove Parameter: singletons, flags (another refactoring)
Eliminate Return Value: test suite, convenience
Separate Query from Modifier: style
Encapsulate Downcast: static count

17. Evaluation
Tool suggestions revealed architectural flaws, prompted redesign and code simplification
Easy to filter out poor suggestions
No set of rules is right for all users and tasks
Some are a matter of degree or of style
Maintainer had not previously identified these refactoring opportunities
Suggestions orthogonal to clone detection tool

18. Future work Add patterns for more refactorings
Perform more case studies
Combine with static analysis
Static analysis better for "large method", "variable never used"
Refactorings requiring static and dynamic info
Compare dynamic and static counts
Combine with tool for applying refactorings
First point requires inventing new refactorings relying on dynamic properties rather than adding patterns for more from the books.
Give a good example of refactoring requiring both static and dynamic info

19. Conclusions
Program invariants effectively identify refactoring candidates
Automatic technique
Justified in terms of run-time properties
Programmer assessment demonstrates utility and ease of use
Aid code improvement.
Dynamically detected invariants used as tool input
Automatic computation of invariants and identification of refactoring candidates
Say: this is further evidence of the accuracy and usefulness of program invariants in general and dynamic invariant detection in particular.

20. Questions?
The point of this slide is to separate my extra slides from the main part of the talk.