The slides from my presentation at the International Conference on Software Reuse (ICSR'22). The paper: https://link.springer.com/chapter/10.1007/978-3-031-08129-3_2 Free preprint: https://hal.archives-ouvertes.fr/hal-03647706/

1. DepMiner: Automatic Recommendation of
Transformation Rules for Method Deprecation
1Arolla, Paris
2Inria, Univ. Lille, CNRS, Centrale Lille, UMR 9189 - CRIStAL
Oleksandr ZAITSEV1,2, Stéphane DUCASSE 2, Nicolas ANQUETIL2, Arnaud THIEFAINE1
The 20th International Conference on Software and Systems Reuse
oleksandr.zaitsev@arolla.fr

3. The problem of
library update
Part 1:

4. 4
Library Update Problem
Client
System
Library
v1.0
Client
Developer
Library
Developer
depends

5. 5
Library Update Problem
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Library Evolution

6. 6
Library Update Problem
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Library Evolution
! 500 errors

7. 7
Library Update Problem
Updated
Client
System
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Library Evolution
Library Update

8. 8
Library Update Problem
If a client system depends on version N of a given
library, what must be changed in the client code
to use version N+K of that same library?

9. 9
Tools for Client Developers
Client
Developer
Library
Developer
Support?
Objective: Help client developers
update their system
Tools
01
10
Code
Analysis
Commit
History
(knows the client
system and what
parts of API it uses)

10. 10
Client
Developer
Library
Developer
Support
Objective: Help library developers
to better support their clients.
Tools for Library Developers
Tools
01
10
Code
Analysis
Commit
History
(knows the library
and what was
changed in the new
version)

11. 11
Support from Library Developers
Deprecation
Documentation (release notes, change logs, etc.)
Communication (forums, chats, mailing lists)
A
B
D
C Automation (update script, rewriting rules)
How can library developers support their clients:
Client
Developer
Library
Developer
Support

12. Documentation (release notes, change logs, etc.)
Communication (forums, chats, mailing lists)
A
D
How can library developers support their clients:
12
The Scope of Our Work
B Deprecation
C Automation (update script, rewriting rules)
Client
Developer
Library
Developer
Support
Tools
Commit
History
Mine frequent
method call
replacements from
the commit history.
Generate
deprecations with
rules that can
fi
x
client code.

13. Rewriting
Deprecations in
Pharo
Part 2:

14. 14
Pharo Programming Language
Pharo is a pure object-oriented
programming language designed
in tradition of Smalltalk. It is also an
IDE developed entirely in itself.
We focus on Pharo because:
1. We have access to its
core developers
2. Pharo is convenient for
manipulating source code

15. 15
isSpecial
self deprecated: ‘Renamed to #needsFullDefinition’.
^ self needsFullDefinition
Method Deprecation in Pharo

16. 16
isSpecial
self deprecated: ‘Renamed to #needsFullDefinition’.
^ self needsFullDefinition
Deprecation
Deprecation message
Method signature
Method body
Method Deprecation in Pharo

17. 17
isSpecial
self
deprecated: ‘Renamed to #needsFullDefinition’
transformWith:
‘`@receiver isSpecial’ -> ’`@receiver needsFullDefinition’.
^ self needsFullDefinition
Rewriting Deprecation

18. 18
isSpecial
self
deprecated: ‘Renamed to #needsFullDefinition’
transformWith:
‘`@receiver isSpecial’ -> ’`@receiver needsFullDefinition’.
^ self needsFullDefinition
Method signature
Method body
Deprecation
Deprecation message
Transformation rule
Rewriting Deprecation

19. 19
isSpecial
self
deprecated: ‘Renamed to #needsFullDefinition’
transformWith:
‘`@receiver isSpecial’ -> ’`@receiver needsFullDefinition’
^ self needsFullDefinition
Antecedent
(left hand side)
matches the method calls
that should be replaced
Consequent
(right hand side)
de
fi
nes the replacement
Transformation Rule

20. Why do we need to
support library
developers?
Part 3:

21. 21
Java
33 %
67 %
Deprecations with helpful
replacement messages
Deprecations without helpful
replacement messages
Replacement Messages
C#
22 %
78 %
JS
33 %
67 %
[Brito et al., 2018] [Brito et al., 2018] [Nascimento et al., 2020]

22. 22
367
41 %
59 %
Rewriting deprecations
(contain a transformation rule)
Non-rewriting deprecations
(no transformation rule)
Analysis of Deprecations in Pharo 8

23. 23
367
9 %
32 %
59 %
Analysis of Deprecations in Pharo 8
Rewriting deprecations
(contain a transformation rule)
Non-rewriting deprecations
(no transformation rule)
Missed opportunity

24. 24
-4
-13
-52
-43
-5
-7
-1
-24
5
28
2
1
3
179
Rename method
Split method
Complex replacement
Remove argument(-s)
Add argument(-s)
Change receiver
Delete method
Deprecate class
Push down
Analysis of Deprecations in Pharo 8
Rewriting deprecations
(contain a transformation rule)
Non-rewriting deprecations
(no transformation rule)

25. 25
-4
-13
-52
-43
-5
-7
-1
-24
5
28
2
1
3
179
Rename method
Split method
Complex replacement
Remove argument(-s)
Add argument(-s)
Change receiver
Delete method
Deprecate class
Push down
Analysis of Deprecations in Pharo 8
Rewriting deprecations
(contain a transformation rule)
Non-rewriting deprecations
(no transformation rule)
Missed opportunity

26. 26
Challenge 1:
Challenge 2:
Absence of method visibility.
Absence of static type information.
There are no public/private keywords in Pharo.
Every method is public but not every method is meant to be used.
Pharo is a dynamically-typed language. Just by looking at source
code, we do not know the class from which the function is called, the
return type, or the argument types.

27. DepMiner:
Mining frequent
method call
replacements
Part 4:

28. 28
{
Id: ef4fdd35fb05e74aa12aad4d22a37e17a8d87b5b,
Removed methods: […],
Added methods: […],
Modified methods: [
{
Old source code: …,
New source code: …,
Removed method calls: [smartDescription],
Added method calls: [description],
}],
Added classes: […],
Removed classes: […],
…
}
Line-based diffs High-level commits
Which lines of code were added or removed? Which methods, classes, or packages
were added, removed, or modified?
Q:
Q:
Step 1. Collecting the Data

29. 29
public static LinkedList insert(LinkedList list, int data)
{
Node new_node = new Node(data);
- new_node.setNext(null);
+ new_node.setNextNode(null);
if (list.head() == null) {
list.setHead(new_node);
}
else {
Node last = list.head;
- while (last.next() != null) {
- last = last.next();
+ while (last.nextNode() != null) {
+ last = last.nextNode();
}
last.next = new_node;
}
return list;
}
Method Change
Method change —
one method modified
by one commit

30. 30
public static LinkedList insert(LinkedList list, int data)
{
Node new_node = new Node(data);
- new_node.setNext(null);
+ new_node.setNextNode(null);
if (list.head() == null) {
list.setHead(new_node);
}
else {
Node last = list.head;
- while (last.next() != null) {
- last = last.next();
+ while (last.nextNode() != null) {
+ last = last.nextNode();
}
last.next = new_node;
}
return list;
}
{
remove(setNext),
add(setNextNode),
remove(next),
remove(next),
add(nextNode),
add(nextNode)
}
Method Change as Transaction
Transaction — set of
added and removed
method calls in a
method change:

31. 31
Missing methods — public methods that were present in the old version
and no longer exist in the new version.
Step 2. Detecting Breaking Changes
new API
old API

32. 32
Missing methods — public methods that were present in the old version
and no longer exist in the new version.
Step 2. Detecting Breaking Changes
new API
old API
Challenge 1:
Which methods are “public”?
We address this challenge by de
fi
ning
language-speci
fi
c heuristics.
For example, in Pharo, test, example,
baseline methods, etc. can be considered “private”.
The complete list of heuristics and the tool to deduce
method visibility in Pharo can be found in our repository:
https://github.com/olekscode/VisibilityDeductor

33. 33
Customer 1:
Customer 2:
Customer 3:
{ bread, butter, avocado }
{ bread, butter, bananas }
{ bread, butter, milk, cereal }
Customer 4: { bread, milk, cereal }
Customer 5: { butter, milk, cereal }
Transactions: Q1: What are the products that are
frequently purchased together?
Q2: What can we recommend to
people who buy bread?
(frequent itemsets)
(association rules)
Step 3. Market Basket Analysis

34. 34
Customer 1:
Customer 2:
Customer 3:
{ bread, butter, avocado }
{ bread, butter, bananas }
{ bread, butter, milk, cereal }
Customer 4: { bread, milk, cereal }
Customer 5: { butter, milk, cereal }
Transactions: Q1: What are the products that are
frequently purchased together?
Q2: What can we recommend to
people who buy bread?
{ bread } { butter }
Con
fi
dence: 75%
{ bread, butter }
{ milk, cereal }
Support: 60%
Support: 60%
Step 3. Market Basket Analysis

35. 35
Q1: What are the operations that frequently appear together in
method changes?
Q2: What can we recommend as a replacement for next() ?
{ next } { nextNode }
Con
fi
dence: 75%
{ remove(next), add(nextNode) }
Support: 60%
Frequent Method Call Replacements

36. 36
Step 4. Generating Deprecations
Node >> next
self
deprecated: ‘Use #nextNode instead.’
transformWith:
‘`@receiver next’ ->
’`@receiver nextNode’.
^ self needsFullDefinition
Generated Deprecation
Missing Method
Node >> next
Association Rule
{next}
{nextNode}
Support: 60%
Confidence: 75%

37. 37
Step 4. Generating Deprecations
Node >> next
self
deprecated: ‘Use #nextNode instead.’
transformWith:
‘`@receiver next’ ->
’`@receiver nextNode’.
^ self needsFullDefinition
Generated Deprecation
Missing Method
Node >> next
Association Rule
{next}
{nextNode}
Support: 60%
Confidence: 75%
Challenge 2:
Is “nextNode” called from the same class as “next”?
To address this challenge, retain only those association
rules, where methods in antecedent and consequent of
the rule are de
fi
ned in the same class.
(i.e. new version Node must de
fi
ne nextNode method,
otherwise the association rule is discarded).
This is also the limitation of our approach.

38. 38
commit
history
old
API
new
API
high-level
changes
diff
Removed
public methods
Step 1: Collect data Step 2: Detect breaking changes
Step 3: Mine frequent method call replacements
Software Library
v1.0
v2.0
method 2
method 3
method 4
method 5
method 1
for
each
pull
requests
A-Priori
missing
method
association
rules Library
Developer
history
oldMethod
self
deprecated: ‘Use newMethod’
transformWith:‘`@rec oldMethod’
->‘`@rec newMethod’.
^ self newMethod
Step 4: Generate deprecations

39. Evaluation
on 5 open-source
projects
Part 5:

40. 40
Prototype Tool for Pharo

41. 41
Selecting Projects
Famix
6,538
Moose
1,670
Pillar
5,848
Pharo
116,212
DataFrame
661
Tool
Library
SDK
Project type:
N Size
(num. methods)
Reviewers

42. 42
Recommended Deprecations
113
56
5
52
33
1
32
87
28
40
19
1
1
11
4
7
Pharo Famix DataFrame
Accepted recommendations
Rewriting
Non-rewriting
Rejected recommendations
Moose Pillar

43. 43
Limitations & Future Work
Unused / untested
methods
Our approach detects the changes in how the library uses
its own API. It is ineffective for methods that are not tested
and only called by clients
Unordered set of
method calls
Our approach ignores the order of method calls as well as
the distance between method calls in the source code.
Search entire
commit history
When a method is removed, it is more likely that the effect
caused by it happen in the same commit or in several next
commits. We search the whole history.
Reflective
operations
Methods that are invoked programmatically (through the
reflective operations) will not be detected.

44. oleksandr.zaitsev@arolla.fr
Summary
Get in touch:
‣ We proposed an approach to help library developers by generating
deprecations with transformation rules.
‣ Those deprecations can be used to rewrite client code.
‣ Our approach is based on frequent method call replacement from
the commit history.
‣ We implemented our approach as a prototype tool for Pharo and
evaluated it on 5 open-source projects.
‣ 134 deprecations generated by our tool were accepted and
merged into the projects.