Recommending Software Refactoring Using Search-based Software Enginnering

Recommending Software Refactoring Using Search-based Software Engineering
Ali Ouni
ouniali@iro.umontreal.ca
Graduate School of Information Science and Technology
Department of Computer Science
Osaka University
10 December 2014

University of Montreal
November 18, 2014
Winter
Summer
Autumn

Montréal
Montréal downtown
Vieux-Port Montréal
Hockey
Poutine
Rue Hutchison

Tunisia: touristic destination
Sidi Bousaid
Sousse
Nabeul ceramic
Tozeurdesert
El Jemtheater
Tunisian monument
Yasmine
Couscous Brik

Outline
Context and problem
Contributions
Code-smells detection
Mono-objective software refactoring
Multi-objective software refactoring
Conclusion and perspectives
© Ali OuniRecommending Software Refactoring Using Search-based Software Engineering 10 December 2014 8

Context
Software systems have become prevalent in our everyday life
Software changes frequently
Add new requirements
Adapt to environment changes
Correct bugs
Changing a software can be a challenging task
These changes may degrade their design and QoS
The original developers are not around anymore
Systems, like people, get old
Increase in complexity and degrade in effectiveness
Maintain a high level of quality during the life cycle of a software system
9
© Ali OuniRecommending Software Refactoring Using Search-based Software Engineering 10 December 2014

Refactoring
“ The process of improving a code after it has been written by changing its internal structure without changing the external behavior ” (Fowler et al., ‘99)
Examples: Move method, extractclass, move attribute, ...
Eclipse, NetBeans, …
Advantages
Improve software quality, maintainability, readability
Provide better software extensibility
Increase the speed at which programmers can write and maintain their code
Challenges…
Manual refactoring is an error-prone task
What are the situations ? What are the refactoringsto apply?
10

Refactoring
Need for refactoring recommendation systems
11
Identification of refactoring solutions
Detection of code fragments to improve
(e.g., code-smells)

Step 1: Code-smells detection
Code-smells
Introduced during the initial design or during evolution
Anomalies, anti-patterns, bad smells, design flaws, …
“ Metaphor ” to describe problems resulting from bad design and programming practices
Time pressure, non-experienced programmers, unintentionally, code decay
Lead to software products suffering by poor performance and QoS
Code difficult to understand, modify, maintain, evolve ...
12
Code smells
What is that smell? Did you write that code?

Code-smellexamples
Blob
“Procedural-style design leads to one object with numerous responsibilities and most other objects only holding data or executing simple processes”
13
Spaghetti code
“It is a code with a complex and tangled control structure. This code-smell is characteristic of procedural thinking in object-oriented programming. Spaghetti Code is revealed by classes with no structure, declaring long methods with no parameters, and utilisingglobal variables”
Librairy_Main_Control
-borrow_date_Book
-current_Book
-current_Catalog
-fine_Amount
-listOfCatalogs
-librairy_opened
-reserved_Book
-return_date_Book
+add_Book()
+archive_Catalog()
+borrow_Book()
+check_Availabi_Book()
+check_Delay_Book()
+check_FineAmount()
+check_ValidityCard()
+close_Librairy()
+create_cheap_Book()
+display_Book()
+display_Catalog()
+do_Inventory()
+issue_LibrairyCard()
+list_Catalogs()
+open_Librairy()
+print_Catalog()
+remove__Book()
+reserve_Book()
+return_Book()
+search_Book()
+search_Catalog()
+sort_Catalog()
Catalog
-…
+…()
Book
-…
+…()
Data Class
Data Class

Step 2: Refactoring
14
-borrow_date_Book
-current_Book
-current_Catalog
-fine_Amount
-listOfCatalogs
-librairy_opened
-reserved_Book
-return_date_Book
+add_Book()
+archive_Catalog()
+borrow_Book()
+check_Availab_Book()
+check_Delay_Book()
+check_FineAmount()
+close_Librairy()
+display_Book()
+display_Catalog()
+do_Inventory()
+list_Catalogs()
+open_Librairy()
+print_Catalog()
+remove_Book()
+reserve_Book()
+return_Book()
+search_Book()
+search_Catalog()
+sort_Catalog()
Catalog
-…
+…()
Book
-…
+…()
Data Class
Data Class
-current_Catalog
-listOfCatalogs
+sort_Catalog()
+add_Book()
+list_Catalogs()
+remove_Book()
+search_Book()
+search_Catalog()
Catalog
-current_Book
+archive_Catalog()
+display_Book()
+display_Catalog()
+do_Inventory()
+print_Catalog()
Book
-borrow_date_Book
-return_date_Book
-reserved_Book
+return_Book()
+borrow_Book()
+check_Delay_Book()
+reserve_Book()
Data Class
NewClass_1
-fine_Amount
+chek_FineAmount()
NewClass_2
-librairy_opened
+close_Librairy()
+open_Librairy()
Data Class
Blob
Refactoring
Move method
Extract class
Move field
Inline class
…

Goal
“Automated approach for recommending software refactoring”
Generate code-smells detection rules
Findrefactoring solutions to fix code-smells while preserving the design semantics 15

Proposal
16
recommended
refactorings
Part 2
Mono-objective code-smells correction
Generationof detection rules
(GP)
Mono-objectivesearch- based Refactoring
(GA / CRO)
detection rules
Part 1
Code-smells detection
Quality metrics
Part 3
Multi-objective refactoring
Examples
of
code-smells
Multi-objective search- based Refactoring
(NSGA-II)
Semanticmeasures
Modification score
Code-change history
Design-pattern detectors
recommended
refactorings
List of refactoring operations

Research methodology
Code-smells detection
Mono-objective software refactoring
Multi-objective software refactoring
17
recommended
refactorings
Part 2
(GP)
(GA / CRO)
detection rules
Part 1
Quality metrics
Part 3
Examples
of
code-smells
(NSGA-II)
Semanticmeasures
Modification score
Code-change history
recommended
refactorings
List of refactoring operationsProposal

Code-smellsdetection
Existing work
Manual(Brown et al. ‘98, Fowler and Beck ‘99)
Metrics-based(Palombaet al ‘13, Marinescuet al. ’04, Salehieet al. ’06, Maigaet al.‘12)
Visual(Dhambriet al. ’08, Langelieret al. ’05)
Symptoms-based(Moha et al. ’08, Murnoet al. ‘08)
18

Problem statement
Difficult to define/express detection rules
Large list of code-smell types to categorize
Large exhaustive list of quality metrics
Large number of possible threshold values
Huge space to explore: An expert to manually write and validate detection rules
Difficult to derive consensual rules
Diverge expert’s opinions
No consensual definition of symptoms
The same symptom could be associated to many code-smell types
Easier to describe examples than translating symptoms into rules
Idea: Infer detection rules from code-smell examples
19

Approach overview
20
Generation of
code-smells
detection rules
(Genetic Programming)
Software quality metrics
(CBO, WMC, NOA,…)
Code-smells detection rules
Examples of code-smells
System2
System1
System3
Code-smell instance

Genetic Programming
21
Population of solutions
Evaluation
Selection
Crossover
Mutation
Optimal or “good” solution found ?
Detection rules
Yes
No
START
END
Key elements
Representing of individual
Generate initial population
Deriving new individuals using genetic operators
Evaluating an individual

GP adaptation
WMC
LCOM
NOM
CBO
[1..500]
[1..100]
Quality metrics
NOA
Solution representation
22
1 : Blob
2 : Spaghetti code
3 : Functional decomposition
Baseofexamples
Code-smell instance
3 : If(NOA≥4) AND (WMC<3) ThenFunctional decomposition
2 : If(CBO≥151) ThenSpaghetti code
1 : If(LOCCLASS≥1500) AND (NOM≥20) OR (WMC>20) ThenBlob
R1:Blob
R2:SC
R3:FD
OR
OR
AND
AND
LOCClASS ≥ 1500
NOM ≥ 20
CBO≥ 151
NOA≥ 4
CBO<3
WMC≥ 20
N6
N1
N2
N3
N4
N5
N7
N8
N10
N9
Tree representation
Fitness function
푅푒푐푎푙푙= 푡푟푢푒푝표푠푖푡푖푣푒푠 푡표푡푎푙푛푢푚푏푒푟표푓푐표푑푒푠푚푒푙푙푠
푃푟푒푐푖푠푖표푛= 푡푟푢푒푝표푠푖푡푖푣푒푠 푛푢푚푏푒푟표푓푑푒푡푒푐푡푒푑푐표푑푒푠푚푒푙푙푠

23
Genetic operators
AND
NPA≥ 7
CBO<3
R2
OR
AND
LOCClASS
≥ 1500
NOM≥ 20
WMC≥ 20
R1
AND
CBO<3
WMC≥20
R’2
OR
AND
LOCClASS
≥ 1500
NOM≥ 20
NPA≥7
R’1
Crossover
 Crossover
 Mutation
OR
AND
LOCClASS
≥ 1500
NOM≥ 20
WMC≥
20
OR
AND
LOCClASS
≥ 1500
NOM≥ 20
CBO≥ 30
Mutation
© Ali Ouni Recommending Software Refactoring Using Search-based Software Engineering 10 December 2014

24
Studied systems
Three types of code-smells
Blob, Spaghetti code, Functional decomposition
6-fold cross validation
Detect smells in a system using the 5 other systems
Detection precision and recallEvaluation: detection results
Systems
# of classes
KLOC
# of code-smells
QuickUMLv2001
142
19
11
LOG4Jv1.2.1
189
21
17
GanttProjectv1.10.2
245
31
41
Xerces-Jv2.7.0
991
240
66
ArgoUMLv0.19.8
1230
1160
89
AZUREUSv2.3.0.6
1449
42
93

25
Detection results
System
Precision
Recall
GanttProject
Blob:100%
SC:93%
FD:91%
100%
97%
94%
Xerces-J
Blob:97%
SC:90%
FD:88%
100%
88%
86%
ArgoUML
Blob:93%
SC:88%
FD:82%
100%
91%
89%
QuickUML
Blob:94%
SC:84%
FD:81%
98%
93%
88%
AZUREUS
Blob:82%
SC:71%
FD:68%
94%
81%
86%
LOG4J
Blob : 87%
SC: 84%
FD: 66%
90%
84%
74%
Average
Blob:92%
SC:85%
FD:79%
97%
89%
86%

26
Examples-size variation
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1
2
3
4
5
Precision
Recall
Precision, recall%
Numberof systems

Proposal
27
recommended
refactorings
Part 2
(GP)
(GA / CRO)
detection rules
Part 1
Quality metrics
Part 3
Examples
of
code-smells
(NSGA-II)
Semanticmeasures
Modification score
Code-change history
recommended
refactorings

28
Manual approaches
–Standard refactorings(Fowler et al. ‘98)
Metric-based approaches
–Search-based techniques
•Find the best sequence of refactorings(Seng et al. ‘06, Harman et al. ’07, O’Keeffe et al. ’08,)
–Analytic approaches
•Study of relations between some quality metrics and refactoring changes (Sahraouiet al. ’00, Du Bois et al. ’04, Mohaet al. ’08)
Clustering-based approaches
–Fix code-smells (Marioset al, ’11, JDeodorant) Existing work on refactoring

29
Difficult to define "standard" refactorings
Pre-define refactoring solutions for each code-smell type
Difficult to establish the link between refactoring and quality improvement
Improving some quality metrics do not fix code-smells
Is not practical to correct code-smells separately
Correcting a code-smell may produce other code-smells
Do not consider the impact of refactoring
Do not take into consideration the semantic coherence dimensionProblem statement

30
Two scenarios
1.Enough time/resources
2.Time/resources limitationsMono-objective Refactoring
recommended
refactorings
Part 2
Basic Mono-objectiveRefactoring
(GA)
Prioritizing code-smells correction
(CRO)
List of refactoringoperations
+
Detection rules
Scenario 1
Scenario 2
recommended
refactorings

31
Basic mono-objective refactoring
Code to be refactored
Suggested refatorings
List of possible refactorings
Basic Code-smells correction
(Genetic Algorithm)
Scenario 1

32
Genetic Algorithm
Individual = Sequence of refactoring operations
Controlling parametersGenetic algorithm adaptation
Refactorings
Controlling parameters
move method
(sourceClass,targetClass,method)
move field
(sourceClass,targetClass,field)
pull up field
pull up method
push down field
push down method
inline class
(sourceClass,targetClass)
extract class
(sourceClass,newClass)
1
moveMethod
2
pullUpAttribute
3
extractClass
4
inlineClass
5
extractSuperClass
6
inlineMethod

33
Population creation
Population: set of refactoring solutions
Fitness functionGenetic algorithm adaptation
Correctionratio= #codesmells푎푓푡푒푟푟푒푓푎푐푡표푟푖푛푔 #detectedcodesmells
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
pullUpAttribute
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
inlineClass
inlineMethod
extractSuperClass
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
pullUpAttribute
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass

34
Crossover
MutationGenetic algorithm adaptation
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
extractClass
moveMethod
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
Solution 1
Solution 2
Child 1
Child 2
Crossover(k=3)
moveMethod
pullUpAttribute
extractClass
inlineClass
extractSuperClass
inlineMethod
moveMethod
moveMethod
extractClass
inlineClass
extractSuperClass
inlineMethod
Mutation
(i=2, j=5)
Solution
Child

35
Evaluation: basic refactoring results
System
CCR
RP
GanttProject
95% (39|41)
52 %
Xerces-J
89% (59|66)
49 %
ArgoUML
85% (76|89)
59 %
QuickUML
90% (26|29)
59 %
LOG4J
88% (15|17)
51 %
AZUREUS
94% (87|93)
57 %
Average
90%
54%
퐂퐂퐑= #퐜퐨퐝퐞퐬퐦퐞퐥퐥퐬퐚퐟퐭퐞퐫퐚퐩퐩퐥퐲퐢퐧퐠퐫퐞퐟퐚퐜퐭퐨퐫퐢퐧퐠퐬 #퐜퐨퐝퐞퐬퐦퐞퐥퐥퐬퐛퐞퐟퐨퐫퐞퐫퐞퐟퐚퐜퐭퐨퐫퐢퐧퐠
퐑퐏= #퐦퐞퐚퐧퐢퐧퐠퐟퐮퐥퐫퐞퐟퐚퐜퐭퐨퐫퐢퐧퐠퐬 #퐩퐫퐨퐩퐨퐬퐞퐝퐫퐞퐟퐚퐜퐭퐨퐫퐢퐧퐠퐬

36
GA Scalability
0
10
20
30
40
50
60
70
0
200
400
600
800
1000
1200
1400
1600
Execution time (minutes)
Size of systems(numberof classes)
QuickUML
LOG4J
GanttProject
Xerces-J
ArgoUML
AZUREUS

37
Mono-objective Refactoring
recommended
refactorings
Part 2
Basic Mono-objectiveRefactoring
(GA)
Prioritizing code-smells correction
(CRO)
List of refactoringoperations
+
Detection rules
Scenario 1
Scenario 2
recommended
refactorings

38
Second scenario
Time / resources limitations
Don’t need to fix all code-smells -> only the most critical ones
Idea:Prioritize the correction of code smellsPriority-based refactoring
Priority-based code-smells correction
(Chemical reaction optimisation)
Code to be refactored
Suggested refatorings
Prioritisation schema

39
Four heuristics
Priority
rank code-smells according to the maintainers preferences
Severity
rank code-smells according to a set of design-properties (size, complexity, coupling, cohesion, hierarchy, etc.)
Risk
the risk score corresponds to the deviation from good design practices.
the more code deviates from good practices, the more it is likely to be risky
Importance
the importance of a class corresponds to their change frequency
the more a class undergoes changes, the more it is likely to be problematic
if a code-smell remains unmodified, the system may not experience problemsPrioritizing code-smells correction

40
Goal:
maximize the correction of the critical code-smells
Objective function
weighted sum of the prioritization heuristics
Chemical reaction optimisation (CRO)
Inspired by the phenomenon of chemical reactions
Molecule <--> solution
Potential energy <--> objective function value
Collision <--> change operator (mechanism to find new solution) Prioritizing code-smells correction

41
Comparison
1.Our CRO-based approach
2.CRO without prioritization
3.Basic GA approach
Refactoring comparison results for the five systems from 31 simulation runsValidation: CRO refactoring results

42
Comparison
1.Chemical Reaction Optimization (CRO)
2.Genetic Algorithm (GA)
3.Simulated Annealing (SA)
4.Particle Swarm Optimisation (PSO)
Refactoring comparison results for the five systems from 31 simulation runsSBSE validation

43
Stability
45
47
49
51
53
55
57
59
75
80
85
90
95
100
210
216
222
232
232
236
241
255
257
259
265
268
270
271
271
274
275
276
276
277
277
278
279
280
281
281
282
282
282
285
288
Number of refactorings
CCR (%)
ICR (%)
RCR (%)
SCR (%)
Time (min)
CCR (%), ICR(%), RCR(%) , SCR(%) Time (min)

44
Refactoringsdistribution

45
Advantages
Most of code-smells are fixed
Critical code-smells are fixed first (prioritized)
Limitations
Not all suggested refactoring operations are semantically feasible
Some refactoring solutions requires a considerable number of changes
Single perspective ? Mono-objective formulation

Proposal
46
recommended
refactorings
Part 2
(GP)
(GA / CRO)
detection rules
Part 1
Quality metrics
Part 3
Examples
of
code-smells
(NSGA-II)
Semanticmeasures
Modification score
Code-change history
recommended
refactorings

Intuition: preserve design semantics
Semantic approximation
Number of changes
Conformance with refactoring history
47
Multi-objective formulation
Multi-objective optimization problem

48
Refactoring history
Proposed
refactorings
Semantic
measures
D
Multi-objective Refactoring
(NSGA-II)
Source code with code-smells

NSGA-II: Non-dominated Sorting Genetic Algorithm(K.Deb et al., ’02)
49
NSGA-II overview
Parent Population
Offspring Population
Non-dominated sorting
F1
F2
F3
F4
Crowding distance sorting
Population in next generation

First population creation
Change operators (Crossover & Mutation)
Objective functions
50
NSGA-II adaptation

Four objective functions
1.Quality
Calculate the number of fixed code-smells
2.Code changes
Calculate the number of atomic changes required when applying refactoring
3.Approximate semantic similarity
Calculate cosine similarity between vocabulary used
4.Maintain the conformance with change history
Calculate a similarity score between the a suggested refactoring and a base of refactoringsapplied in the past
51
NSGA-II adaptation

52
Number of code changesRefactoring criteria. . .
-borrow_date_Book
-current_Book
-current_Catalog
-fine_Amount
-listOfCatalogs
-librairy_opened
-reserved_Book
-return_date_Book
+add_Book()
+archive_Catalog()
+borrow_Book()
+check_Delay_Book()
+check_FineAmount()
+close_Librairy()
+display_Book()
+display_Catalog()
+do_Inventory()
+list_Catalogs()
+open_Librairy()
+print_Catalog()
+remove_Book()
+reserve_Book()
+return_Book()
+search_Book()
+search_Catalog()
+sort_Catalog()
Catalog
-…
+…()
Book
-…
+…()
Data Class
Data Class
-current_Catalog
-listOfCatalogs
+sort_Catalog()
+add_Book()
+list_Catalogs()
+remove_Book()
+search_Book()
+search_Catalog()
Catalog
-current_Book
+archive_Catalog()
+display_Book()
+display_Catalog()
+do_Inventory()
+print_Catalog()
Book
-borrow_date_Book
-return_date_Book
-reserved_Book
+return_Book()
+borrow_Book()
+check_Delay_Book()
+reserve_Book()
Data Class
NewClass_1
-fine_Amount
+chek_FineAmount()
NewClass_2
-librairy_opened
+close_Librairy()
+open_Librairy()
Data Class
Code-smell: Blob
Refactoring
Solution 3
1. Move method
2. Extract class
3. Move field
4. Move method
5. Move method
6. Inline class
7. Move field
8. Extract class
9. Move method
10 Move field
Solution 1
1. Move method
2. Extract class
3. Move field
4.Move method
5.Move method
Solution 2
1.Move method.
2.Move method
3.Inline class
4.Move field
5.Extract class
Solution 4
1.Move method.
2.Move method
3.Inline class
4.Move field
5.Extract class
6.Move field
7.Extract class

53
Semantic similarityRefactoring criteria. . .
Catalog
-current_Book
+archive_Catalog()
+display_Book()
+display_Catalog()
+do_Inventory()
+print_Catalog()
Book
-borrow_date_Book
-return_date_Book
-reserved_Book
+return_Book()
+borrow_Book()
+check_Delay_Book()
+reserve_Book()
NewClass_1
-fine_Amount
+chek_FineAmount()
NewClass_2
-librairy_opened
+close_Librairy()
+open_Librairy()
-borrow_date_Book
-current_Book
-current_Catalog
-fine_Amount
-listOfCatalogs
-librairy_opened
-reserved_Book
-return_date_Book
+add_Book()
+archive_Catalog()
+borrow_Book()
+check_Delay_Book()
+check_FineAmount()
+close_Librairy()
+display_Book()
+display_Catalog()
+do_Inventory()
+list_Catalogs()
+open_Librairy()
+print_Catalog()
+remove__Book()
+reserve_Book()
+return_Book()
+search_Book()
+search_Catalog()
+sort_Catalog()
NewClass_1
-fine_Amount
+chek_FineAmount()
Code-smell: Blob

Set of "good" refactoringsappliedin the past
54
Conformance with refactoringsapplied in the pastRefactoring criteria. . .
-borrow_date_Book
-current_Book
-current_Catalog
-fine_Amount
-listOfCatalogs
-librairy_opened
-reserved_Book
-return_date_Book
+add_Book()
+archive_Catalog()
+borrow_Book()
+check_Delay_Book()
+check_FineAmount()
+close_Librairy()
+display_Book()
+display_Catalog()
+do_Inventory()
+list_Catalogs()
+open_Librairy()
+print_Catalog()
+remove_Book()
+reserve_Book()
+return_Book()
+search_Book()
+search_Catalog()
+sort_Catalog()
Catalog
-…
+…()
Book
-…
+…()
Data Class
Data Class
Version 1.0
Move field
Move method
Move method
Move field
Inlineclass
Extractclass
Move method
Move method
Move method
Extractclass
ExtractInterface
Extractclass
Inlineclass
Inlineclass
-current_Catalog
-listOfCatalogs
+sort_Catalog()
+add_Book()
+list_Catalogs()
+remove_Book()
+search_Book()
+search_Catalog()
Catalog
-current_Book
+archive_Catalog()
+display_Book()
+display_Catalog()
+do_Inventory()
+print_Catalog()
Book
-borrow_date_Book
-return_date_Book
-reserved_Book
+return_Book()
+borrow_Book()
+check_Delay_Book()
+reserve_Book()
NewClass_1
-fine_Amount
+chek_FineAmount()
NewClass_2
-librairy_opened
+close_Librairy()
+open_Librairy()
Version 3.0
-borrow_date_Book
-current_Book
-current_Catalog
-librairy_opened
-reserved_Book
-return_date_Book
+add_Book()
+archive_Catalog()
+borrow_Book()
+check_Delay_Book()
+check_FineAmount()
+display_Book()
+display_Catalog()
+do_Inventory()
+list_Catalogs()
+open_Librairy()
Catalog
-current_Book
+archive_Catalog()
+display_Book()
+display_Catalog()
+do_Inventory()
+print_Catalog()
Book
-borrow_date_Book
-return_date_Book
-reserved_Book
+return_Book()
+borrow_Book()
+check_Delay_Book()
+reserve_Book()
Data Class
Data Class
Version 2.0
Nextversion

Studied systems
Three code-smell types
Blob, Spaghetti code, and Functional decomposition
Data
Collect refactoringsfrom previous versions (Ref-Finder)
Manual inspection
55
Evaluation
Systems
Release
# classes
# code- smells
KLOC
GanttProject
v1.10.2
245
49
41
Rhino
v1.7R1
305
69
42
JFreeChart
v1.0.9
521
72
170
JHotDraw
v6.1
585
25
21
Xerces-J
v2.7.0
991
91
240
Apache Ant
v1.8.2
1191
112
255

Survey
Questionnaire: evaluate the suggested refactorings
Sample of 10 refactoring operations
18 subjects
•graduate/undergraduate students, assistant professors, junior software developers
•Subjects are volunteers and familiar with java programming
•2 to 13 years experience on Java programming
•6 groups
Comparison to state-of-the-art research
Harman et al 2007, Basic GA approach
Comparison to other mono and multi-objective algorithms
MOGA, GA, Random Search
56
Empirical evaluation

57
Multi-objective refactoring results
Systems
Approach
CCR
RP
Changes score
Xerces
NSGA-II
83% (55|66)
81 %
3843
Harman et al. '07
N.A
41 %
2669
GA-based approach
89% (59/66)
37 %
4998
JFreeChart
NSGA-II
86% (49|57)
82 %
2016
Harman et al. '07
N.A
36 %
3269
GA-based approach
91% (5257)
37 %
3389
GanttProject
NSGA-II
85% (35|41)
80 %
2826
Harman et al. '07
N.A
23 %
4790
GA-based approach
95% (39|41)
27 %
4697
AntApache
NSGA-II
78% (64|82)
78 %
4690
Harman et al. '07
N.A
40 %
6987
GA-based approach
80% (66|82)
30 %
6797
JHotDraw
NSGA-II
86% (18|21)
80 %
2231
Harman et al. '07
N.A
37 %
3654
GA-based approach
% (|21)
43 %
3875
Rhino
NSGA-II
85% (52|61)
80 %
1914
Harman et al. '07
N.A
37 %
2698
GA-based approach
87% (53|61)
32 %
3365
Average
(all systems)
NSGA-II
84%
80 %
2937
Harman et al. '07
N.A
36 %
4011
GA-based approach
89%
34 %
4520

58
SBSE validation
0,50
0,55
0,60
0,65
0,70
0,75
0,80
0,85
0,90
CCR
Code-smells Correction Ratio
NSGA-II
GA
MOGA
Random search
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
RP
Refactoring Precision
NSGA-II
GA
MOGA
Random search
0
1000
2000
3000
4000
5000
6000
Code changes score
Code changes
NSGA-II
GA
MOGA
Random search

Search-based code-smells detection approach
Search-based approach : GP
Infer detection rules from code-smell examples
Mono-objective search-based code-smells correction
GA: maximize the number of fixed code-smells
CRO: Prioritize the correction of code-smells
Multi-objective search-based refactoring approach
Preserve design semantics and fix code-smells
Validation
Empirical evaluation
Very encouraging results
Comparison with existing approaches
59
Conclusion

 Service-oriented Architecture: SOA / Web services
 SOA application = a set of ready-made, reusable services
 Change continuously: add new requirements, environment changes
 May degrade their design quality –> Anti-patterns
60
Ongoing work: Possible collaborations
© Ali Ouni Recommending Software Refactoring Using Search-based Software Engineering 10 December 2014
Client
Travel Service
+ bookTrip() Internet
Flight Service
+ checkDates()
+ reserveFlight()
+ cancelFlight()
Rent Car Service
+checkAvailability()
+ reserveCar()
+ cancelCar()
HotelService
+ checkHotel()
+ reserveHotel()
+ cancelHotel()
XML technologies
{SOAP, WSDL, UDDI,...}
Service provider

SOA Anti-patterns detection
Examples of common SOA anti-patterns
61
Multi-service
Nano-service

Refactoring of SOA
Fix anti-patterns
Improve quality attributes
62
Refactoring
Interface Partitionning

Software Migration
Object oriented system Service oriented system
63
C27
C4
C1
C25
C26
C2
C24
C23
C22
C3
C5
C6
C14
C10
C7
C8
C20
C19
C17
C16
C15
C11
C12
C13
C18
C21
C9
Car Rental Service
Flight Booking Service
Payment Service
Hotel Reservation Service
Travel Agency
system

64
Thank you for your attention

Recommending Software Refactoring Using Search-based Software Enginnering

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Recommending Software Refactoring Using Search-based Software Enginnering

Similaire à Recommending Software Refactoring Using Search-based Software Enginnering (20)

Dernier

Dernier (20)

Recommending Software Refactoring Using Search-based Software Enginnering