A generic talk on my current domain of research

1. Software Evolution
in the Large
Nicolas.Anquetil@inria.com

2. 2 / 57Montpellier – 10/11/17
• Background
• Research Direction
• Past Research
• Future Project
• Wrapping Up
Agenda

3. BACKGROUND

4. 4 / 57Montpellier – 10/11/17
Software maintenance
• “Today, you will use 13 COBOL
applications” [P. Nieuwbourg, 01/25/12]
• To remain useful, systems must
evolve
– Adaptation to new needs (GUI, cloud, …)
– Prepare for future evolutions

5. 5 / 57Montpellier – 10/11/17
• Windows NT 3.1 (1993)
– 4 a 5 MLOC (M. Lines Of Code)
• Windows server 2003
– 50 MLOC
• Today
– ???
Software maintenance
42 m
( 60 lines/page,
both sides)
47 m

6. 6 / 57Montpellier – 10/11/17
• Ever living systems
– The problem is intrinsic to programs
– Involves understanding a mathematical
model (program)
– Independent of formalism
(programming language, Model Driven
Engineering, Software Product Lines,
aspects, …)
Software maintenance

7. VISION

8. 8 / 57Montpellier – 10/11/17
Evolution in
the small
Evolution in
the large
vs.

9. 9 / 57Montpellier – 10/11/17
Evolution in the small

10. 10 / 57Montpellier – 10/11/17
• Modifcation (refactoring)
– On 1 entity
– Small number of parameters
– Well defned behavior
– “Preserve code semantic”
– Generic (constrained only by the
programming language)
Evolution in the small

11. 11 / 57Montpellier – 10/11/17
Evolution in the LARGE
• Eclipse v2.1 → v3.0
v2.1 (Extensible IDE) v3.0 (Rich Client
Platform)

12. 12 / 57Montpellier – 10/11/17
Evolution in the LARGE
https://www.versionone.com/agile-101/
agile-software-programming-best-practices/refactoring

13. 13 / 57Montpellier – 10/11/17
Evolution in the LARGE
• Restructure architecture
• Large refactor
• Break a big class
• Introduce a design pattern (e.g. MVC,
factory, strategy, Hybernate)
• Migrate to a new library version
• …

14. 14 / 57Montpellier – 10/11/17
Evolution in the LARGE
• Can/Should occurs regularly (≠often)
in the life of a system
• Evolution
– On several entities
– Complex behavior
– Specifc to the domain, system, and task
– May break code semantic temporarily

15. 15 / 57Montpellier – 10/11/17
Evolution in the LARGE
• What can we do?
• What are the big activities?
• What tools are needed?

16. RESEARCH

17. 17 / 57Montpellier – 10/11/17
Evolution in the LARGE
• What can we do?
• Some propositions:
– System specifc refactorings
– Model Driven Transformation
– Programming language migration

18. 18 / 57Montpellier – 10/11/17
Evolution in the LARGE
• What can we do?
• Some propositions:
– System specifc refactorings
– Model Driven Transformation
– Programming language migration

19. 19 / 57Montpellier – 10/11/17
JHotDraw 7.4.1 → 7.5.1
class HSLColorSpace extends ColorSpace
{
public HSLColorSpace() { /* … */ }
// …
}
class HSLColorSpace extends ColorSpace
implements NamedColorSpace {
private static HSLColorSpace instance;
public static HSLColorSpace getInstance() {
/* … */ }
private HSLColorSpace() { /* … */ }
public String getName() {
return “HSL”;
}
// …
}
System Specifc Refactorings

20. 20 / 57Montpellier – 10/11/17
class HSVColorSpace extends ColorSpace
{
public HSVColorSpace() { /* … */ }
// …
}
class HSVColorSpace extends ColorSpace
implements NamedColorSpace {
private static HSVColorSpace instance;
public static HSVColorSpace getInstance() {
/* … */ }
private HSVColorSpace() { /* … */ }
public String getName() {
return “HSV”;
}
// …
}
System Specifc Refactorings
JHotDraw 7.4.1 → 7.5.1

21. 21 / 57Montpellier – 10/11/17
class HSVColorSpace extends ColorSpace
{
public HSVColorSpace() { /* … */ }
// …
}
class HSVColorSpace extends ColorSpace
implements NamedColorSpace {
private static HSVColorSpace instance;
public static HSVColorSpace getInstance() {
/* … */ }
private HSVColorSpace() { /* … */ }
public String getName() {
return “HSV”;
}
// …
}
System Specifc Refactorings
JHotDraw 7.4.1 → 7.5.1
Repeated
9 times

22. 22 / 57Montpellier – 10/11/17
PackageManager 0.58 → 0.59
class GreasePharo30CoreSpec
platform
package
addPlatformRequirement: #’pharo’.
package
addProvision: #’Grease-Core-Platform’
class GreasePharo30CoreSpec
platformRequirements
^ #( #’pharo’ )
provisions
^ #( #’Grease-Core-Platform’ )
class SeasideCanvas20CoreSpec
platform
package
addPlatformRequirement: #’pharo2.x’.
package
addProvision: #’Seaside-Canvas-Platform’
class SeasideCanvas20CoreSpec
platformRequirements
^ #( #’pharo2.x’ )
provisions
^ #( #’Seaside-Canvas-Platform’ )
System Specifc Refactorings

23. 23 / 57Montpellier – 10/11/17
PackageManager 0.58 → 0.59
class GreasePharo30CoreSpec
platform
package
addPlatformRequirement: #’pharo’.
package
addProvision: #’Grease-Core-Platform’
class GreasePharo30CoreSpec
platformRequirements
^ #( #’pharo’ )
provisions
^ #( #’Grease-Core-Platform’ )
class SeasideCanvas20CoreSpec
platform
package
addPlatformRequirement: #’pharo2.x’.
package
addProvision: #’Seaside-Canvas-Platform’
class SeasideCanvas20CoreSpec
platformRequirements
^ #( #’pharo2.x’ )
provisions
^ #( #’Seaside-Canvas-Platform’ )
System Specifc Refactorings
Repeated
19 times

24. 24 / 57Montpellier – 10/11/17
Pharo systems Found
PetitDelphi 21
PetitSQL I 6
PetitSQL II 98
PackageManager I 50
PackageManager II 19
PackageManager III 64
PackageManager IV 7
Jenkins 7
MooseQuery I 16
MooseQuery II 8
Pillar 99
Java systems Found
Eclipse I 26
Eclipse II 72
JHotDraw 9
MyWebMarket 7
VerveineJ 3
• Found (manually) in various systems
histories
System Specifc Refactorings

25. 25 / 57Montpellier – 10/11/17
• System/task specifc
• “Incomplete” (may break semantics)
• Complex
• Tedious
• Error prone
System Specifc Refactorings
Automate ?

26. 26 / 57Montpellier – 10/11/17
System Specifc Refactorings
developer
code edition
changed
code entity
new code
location
transformation
events
transformation
pattern
automatic
confguration
new changed
location
applying
transformations
INPUT RECORD
REPLAY
1
2
43
strategies

27. 27 / 57Montpellier – 10/11/17
System Specifc Refactorings
Operators’ parameters
(to adapt)
Recorded actions
(operators)
• Record

28. 28 / 57Montpellier – 10/11/17
System Specifc Refactorings
Custom
refactoring
name
IDE
(list of methods)
• Replay

29. 29 / 57Montpellier – 10/11/17
Pharo systems #Repetition #Operators #Parameters
PetitDelphi 21 2 3
PetitSQL I 6 3 5
PetitSQL II 98 3 6
PackageManager I 50 5 4
PackageManager II 19 3 5
PackageManager III 64 2 4
PackageManager IV 7 4 7
Jenkins 7 1 3
MooseQuery I 16 1 3
MooseQuery II 8 4 5
Pillar 99 4 9
• Case studies
System Specifc Refactorings

30. 30 / 57Montpellier – 10/11/17
System Specifc Refactorings
• “Can the tool confgure parameters?”
Pharo systems #repetitions #Operators #Parameters %Correct
PetitDelphi 21 2 3 99%
PetitSQL I 6 3 5 67%
PetitSQL II 98 3 6 83%
PackageManager I 50 5 4 29%
PackageManager II 19 3 5 54%
PackageManager III 64 2 4 72%
PackageManager IV 7 4 7 79%
Jenkins 7 1 3 49%
MooseQuery I 16 1 3 36%
MooseQuery II 8 4 5 28%
Pillar 99 4 9 56%

31. 31 / 57Montpellier – 10/11/17
System Specifc Refactorings
• Efciency depends on type of
operator parameter
Param. type Correct Incorrect
%Correc
t
Class 21 3 77%
Method 6 5 98%
Pragma
(annotation)
98 6 13%
Prototype 50 4 99%
Source code 19 5 9%
variable 64 4 100%

32. 32 / 57Montpellier – 10/11/17
System Specifc Refactorings
• Improve results?
• Better automatic confguration of
parameters
– Specialize on parameter type
– New confguration strategy
– Select several replay location at a time
• Auto discover replay locations
• Automating recording

33. 33 / 57Montpellier – 10/11/17
Evolution in the LARGE
• What can we do?
• Some propositions:
– System specifc refactorings
– Model Driven Transformation
– Programming language migration

34. 34 / 57Montpellier – 10/11/17
Model Driven Transformation
Old
system
Idealized
organization
Renewed
system

35. 35 / 57Montpellier – 10/11/17
Model Driven Transformation
Old
system
Idealized
organization
Renewed
system
Round trip
Engineering
(Horseshoe)

36. 36 / 57Montpellier – 10/11/17
Model Driven Transformation
Piggyback
Horseshoe
oose

37. 37 / 57Montpellier – 10/11/17
Model Driven Transformation
●
SVN
●
Bugs
●
CSV
●
XML
oose●
Smalltalk
●
Java
●
Ada
●
C/C++
●
Fortran
●
4D

38. 38 / 57Montpellier – 10/11/17
Orion planner

39. 39 / 57Montpellier – 10/11/17
Orion planner
Versions of model

40. 40 / 57Montpellier – 10/11/17
Orion planner
• Creating working version

41. 41 / 57Montpellier – 10/11/17
Orion planner
Model of the system
(editable)

42. 42 / 57Montpellier – 10/11/17
Orion planner
• Interact w/ model (explore solutions)

43. 43 / 57Montpellier – 10/11/17
Orion planner
• Interact w/ model (explore solutions)

44. 44 / 57Montpellier – 10/11/17
Orion planner
• Interact w/ model (explore solutions)
• Create logical entities (e.g. modules)

45. 45 / 57Montpellier – 10/11/17
Orion planner
Validation (e.g.
architectural rules)

46. 46 / 57Montpellier – 10/11/17
Orion planner
• Defne Dependency Constraints

47. 47 / 57Montpellier – 10/11/17
Orion planner
• Check constraints on model

48. 48 / 57Montpellier – 10/11/17
Orion planner
• High level representation of the
system with “logical” entities
– Mapped to the code (piggyback
round trip)
– Editable
– Behave as real entities
(→ metrics, constraints)

49. FUTURE

50. 50 / 57Montpellier – 10/11/17
Orion planner
• High level representation of the
system with “logical” entities
– Mapped to the code (piggyback
round trip)
– Editable
– Behave as real entities
(→ metrics, constraints)
• Still missing

51. 51 / 57Montpellier – 10/11/17
Evolution in the LARGE
• What can we do?
• Some propositions:
– System specifc refactorings
– Model Driven Transformation
– Programming language migration
your photoyour photo
herehere

52. 52 / 57Montpellier – 10/11/17
Language Migration
• Numerical modeling application
• Used in all felds of science (biology,
physics, economics, …)
Induction in a stator

53. 53 / 57Montpellier – 10/11/17
Language Migration
• Numerical modeling application
• Many old applications
• Written in Fortran
– First compiled language (?)
– 50’s
– Low abstraction level
– Not taught anymore
– Less tools

54. 54 / 57Montpellier – 10/11/17
Language Migration
Fortran
to C++

55. 55 / 57Montpellier – 10/11/17
Language Migration
• Fortran to C++ migration
– Syntax migration ;
– Programming idioms : “Natural” C/C++
vs “Fortran-in-C-syntax”;
– Libraries migration ;
– Optimization patterns : specifc to the
domain of numerical modeling;
– Paradigm migration : procedural to
Object-Oriented

56. WRAPPING UP

57. 57 / 57Montpellier – 10/11/17
Evolution in the LARGE
• Software evolution is inevitable
• Evolution in the small vs. Evolution in
the LARGE
• How can we help?
– Macro recording
– Piggyback horseshoe w/ OrionPlanner
– Language migration