This document discusses improving the process of analyzing code differences during legacy code migration projects. It proposes using control flow graphs to provide a higher-level view of where code has changed. It also proposes constructing finite state automata from migration logs to represent the migration process and help explain why code changes were made. Initial results using log differencing show promise in succinctly expressing changes between versions. The overall goal is to help migration companies like Raincode more efficiently explain code changes to clients.

1. Advanced Differencing of Legacy
Code and Migration Logs
Céline Deknop, Johan Fabry,
Kim Mens and Vadim Zaytsev
13th Seminar Series on Advanced Techniques & Tools for Software Evolution
Online, 01/02 July 2020 1

2. Code differencing today
Original algorithm by Hunt and McIlroy in
1976
J. W. Hunt and M. D. McIlroy. An Algorithm for Differential File Comparison. CSTR #41, Bell Telephone
Laboratories, 197
2

3. Code differencing today
Original algorithm by Hunt and McIlroy in
1976
Hasn’t changed much since
J. W. Hunt and M. D. McIlroy. An Algorithm for Differential File Comparison. CSTR #41, Bell Telephone
Laboratories, 197
3

4. Code differencing today
Original algorithm by Hunt and McIlroy in
1976
Hasn’t changed much since
Isn’t always easy to interpret
➔ Can get very long
➔ Structured by file
➔ No use of the semantics
J. W. Hunt and M. D. McIlroy. An Algorithm for Differential File Comparison. CSTR #41, Bell Telephone
Laboratories, 197
4

5. Code differencing today
Original algorithm by Hunt and McIlroy in
1976
Hasn’t changed much since
Isn’t always easy to interpret
➔ Can get very long
➔ Structured by file
➔ No use of the semantics
This makes the process of analysing diffs very
tedious.
J. W. Hunt and M. D. McIlroy. An Algorithm for Differential File Comparison. CSTR #41, Bell Telephone
Laboratories, 197
5

6. Case study
Raincode Labs works in modernisation of legacy software.
Many projects of that sort, the one we are interested in being PACBASE
migration.
6

7. Case study
Raincode Labs works in modernisation of legacy software.
Many projects of that sort, the one we are interested in being PACBASE
migration.
Refactors generated COBOL it to make it more maintainable.
7

8. Case study: step 1
Decide of the rules to apply
8

9. Case study: step 2
Run the migration on a few programs
9

10. Case study: step 2
Run the migration on a few programs
Test the output
10

11. Case study (concretely)
11

12. Case study: manual processes
Identify where manual work is being done in migration projects
12

13. Case study: manual processes
Identify where manual work is being done in migration projects
➔ In the redelivery process
13

14. Case study: redelivery process
14

15. Case study: redelivery process
15

16. Case study: redelivery process
16

17. Case study: redelivery process
17

18. Case study: redelivery process
18

19. Case study: manual processes
The client now has question on the new version : it hasn’t been tested !
19

20. Case study: manual processes
The client now has question on the new version : it hasn’t been tested !
➔ Is it safe for production ?
20

21. Case study: manual processes
The client now has question on the new version : it hasn’t been tested !
➔ Is it safe for production ?
➔ What changed ?
21

22. Case study: manual processes
The client now has question on the new version : it hasn’t been tested !
➔ Is it safe for production ?
➔ What changed ?
➔ Why did it change ?
22

23. Case study: manual processes
The client now has question on the new version : it hasn’t been tested !
➔ Is it safe for production ?
➔ What changed ?
➔ Why did it change ?
Raincode perform a manual analysis to try to answer.
23

24. Case study: manual processes
The client now has question on the new version : it hasn’t been tested !
➔ Is it safe for production ?
➔ What changed ?
➔ Why did it change ?
Raincode perform a manual analysis to try to answer.
➔ Using diffs and logs of the migration process
24

25. Needs to be time-efficient!
25

26. Communication problem
Leads engineers to do it “quick and dirty”.
Analysis is done based on instinct and previous experience.
26

27. Communication problem
Leads engineers to do it “quick and dirty”.
Analysis is done based on instinct and previous experience.
➔ Clients do not receive full, detailed explanation
➔ Sometimes leads to more time loss
27

28. Our goal
Create tools to help Raincode explain to their clients
➔ Where the code has or hasn’t changed
➔ How it has changed
➔ Why it has changed
28

29. Our goal
Create tools to help Raincode explain to their clients
➔ Where the code has or hasn’t changed
➔ How it has changed
➔ Why it has changed
In an easy to understand format
29

30. Give a more global vue using reduced-flow graphs.
We plan to use the two migrated versions.
How and where the code has changed
30

31. How and where the code has changed
Give a more global vue using reduced-flow graphs.
We plan to use the two migrated versions.
J. W. Laski and W. Szermer. Identification of Program Modifications and Its Applications in Software Maintenance. InICSM, pages 282–290. IEEE, 1992
31

32. Points precisely at where things changed
How and where the code has changed
J. W. Laski and W. Szermer. Identification of Program Modifications and Its Applications in Software Maintenance. InICSM, pages 282–290. IEEE, 1992
32

33. We plan to use the two migration logs.
Why it changed
33
Intermediate version
Loop initialisation
Removing labels
Removing NOP instructions
Recognizing loop-like patterns
Dead code removal
Write only var
Removed If inside loop
Intermediate version
Remove Thru in Performs
Perform to perform
Ruptures Simplification
IF factorisation
IF conjunction
consecutive IFs into IF THEN ELSIF
PERFORM VARYING

34. We plan to use the two migration logs.
Why it changed
34
Intermediate version
Loop initialisation
Removing labels
Removing NOP instructions
Recognizing loop-like patterns
Dead code removal
Write only var
Removed If inside loop
Intermediate version
Remove Thru in Performs
Perform to perform
Ruptures Simplification
IF factorisation
IF conjunction
consecutive IFs into IF THEN ELSIF
PERFORM VARYING

35. We plan to use the two migration logs.
Why it changed
35
Intermediate version
Loop initialisation
Removing labels
Removing NOP instructions
Recognizing loop-like patterns
Dead code removal
Write only var
Removed If inside loop
Intermediate version
Remove Thru in Performs
Perform to perform
Ruptures Simplification
IF factorisation
IF conjunction
consecutive IFs into IF THEN ELSIF
PERFORM VARYING

36. We plan to use the two migration logs.
Construct FSA representing the steps of the
process.
Why it changed
M. Goldstein, D. Raz, and I. Segall. Experience Report:Log-Based Behavioral Differencing. InISSRE, pages 282–293, 2017
36

37. We plan to use the two migration logs.
Construct FSA representing the steps of the
process.
Diff the FSAs to represent changes
Why it changed
M. Goldstein, D. Raz, and I. Segall. Experience Report:Log-Based Behavioral Differencing. InISSRE, pages 282–293, 201
37

38. Initial version of file (shortened)
Early results of log differencing
38
Intermediate version
consecutive IFs into IF THEN ELSIF
Loop initialisation
Removing labels
...

39. Second version of file (shortened)
Early results of log differencing
39
Intermediate version
consecutive IFs into IF THEN ELSIF
Intermediate version
consecutive IFs into IF THEN ELSIF
Intermediate version
consecutive IFs into IF THEN ELSIF
Loop initialisation
...

40. Diff of both graphs
➔ Change is simply expressed by change in probability
and a new path possible
Early results of log differencing
40

41. Two ideas to explore for advanced code differencing:
➔ Use control-flow graphs to perform coarser diffs
➔ Use logs and FSAs to understand why things changed (started)
Conclusion
41

42. Two ideas to explore for advanced code differencing:
➔ Use control-flow graphs to perform coarser diffs
➔ Use logs and FSAs to understand why things changed (started)
Thank you for your attention !
Conclusion
42