Sei sulla pagina 1di 378

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/279190536

JCodeOdor: A Software Quality Advisor Through Design Flaws Detection

Thesis · September 2013

CITATIONS READS

6 894

1 author:

Vincenzo Ferme
University of Lugano
38 PUBLICATIONS   416 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

elasticity View project

All content following this page was uploaded by Vincenzo Ferme on 14 June 2017.

The user has requested enhancement of the downloaded file.


Università degli Studi di Milano-Bicocca
Dipartimento di Informatica, Sistemistica e Comunicazione
Corso di Laurea Magistrale in Informatica

JCodeOdor:
A Software Quality Advisor Through
Design Flaws Detection

Relatore: Francesca Arcelli Fontana


Co-relatore: Marco Zanoni

Tesi di Laurea Magistrale di:


Vincenzo Ferme
Matricola 744806

Anno Accademico 2012-2013


Ringraziamenti
Quando penso agli ultimi anni che ho trascorso e alle sfide che ho affron-
tato, mi rendo conto che arrivare a questo traguardo è stata davvero una
sfida entusiasmante, costruttiva, a tratti dura, e da cui ho imparato tanto.
Durante il mio percorso ho potuto apprezzare l’entusiasmo dei docenti che
amano il loro lavoro e ciò che fanno, a tal punto che io, seguendoli, non
ho potuto che non amarlo a mia volta. Ho incontrato nuovi amici che mi
hanno accompagnato lungo la strada, hanno corso con me ed hanno con-
diviso le mie “pazzie”. Tra tutti, Alessandro, con cui ho condiviso tante
idee e notti insonni. Ho avuto vicini i “vecchi” amici, quelli senza cui sai
di non poter andare avanti. Sono stato supportato dalla mia famiglia, che
ha sempre appoggiato tutte le mie scelte, soprattutto quando dicevo “an-
che se ci metterò un po’ di più, alcune esperienze le posso fare solo qui,
in università”. Ho avuto ed ho vicino una ragazza stupenda, che ha avuto
l’amore e la pazienza per accompagnarmi durante tutto il mio percorso,
dai primi passi della laurea triennale, agli ultimi che mi hanno portato alla
laurea magistrale. Ho avuto l’amorevole aiuto di Concetta, che mi ha sup-
portato e motivato durante la scrittura della tesi. Ho avuto la possibilità
di collaborare con Francesca Arcelli, che mi ha sempre guidato indiriz-
zandomi sulla giusta strada, dandomi la possibilità di lavorare ad articoli
pubblicati ad alcune conferenze importanti, dove ho potuto ricevere i com-
menti e le critiche costruttive dei revisori, e dove ho avuto il privilegio di
ascoltare di persona alcune delle grandi menti di cui avevo solo letto il
nome sui libri su cui ho studiato durante questi anni. Ho avuto il suppo rto
e il dedito aiuto di Marco Zanoni che ha condiviso con me alcuni momenti
di “pazzia” in laboratorio, guidandomi per tornare alla “normalità”. Ho
avuto ed ho la possibilità di collaborare con Carlo Batini e Matteo Palmo-
nari, che credono in me e mi hanno dato l’opportunità di iniziare un pro-
getto che si sta rivelando davvero molto interessante e stimolante.

Grazie a tutte le persone che mi hanno fatto, e mi faranno, crescere.


Grazie a tutte le persone che mi sono vicine e mi hanno aiutato.
Table of Contents
1. Introduction ................................................................................................ 1

1.1 Context and Motivation ........................................................................ 1

1.2 Goals of the Thesis ................................................................................ 3

1.3 Outline of the Thesis ............................................................................. 6

2. Design Flaws Detection Tools ....................................................................... 9

2.1 Review of Experimented Tools ............................................................. 9

2.2 Review of Other Tools ........................................................................ 12

2.3 Limitation of the Existing Tools........................................................... 14

3. JCodeOdor and DFMC4J Architecture ......................................................... 16

3.1 Requirements ..................................................................................... 16

3.2 Architecture ........................................................................................ 17

3.2.1 Source Code and Code Information Model ................................ 20

3.2.2 Design Features and Metrics Computation for Java................... 24

3.2.3 JCodeOdor .................................................................................. 36

4. Measurement of Software Design .............................................................. 40

4.1 Quality Model ..................................................................................... 40

4.2 Design Metrics and Design Information ............................................. 42

4.2.1 Design Metrics and Design Information Dependencies.............. 45

4.2.2 Design Information Definitions ................................................... 46

4.2.3 Design Metrics Definitions .......................................................... 46

4.3 Design Metrics and Information Validation ........................................ 48


4.4 Conclusion and Discussion .................................................................. 53

5. Determining Metric Thresholds .................................................................. 54

5.1 Problem Statement ............................................................................. 54

5.2 Code Smells Metrics Thresholds Derivation ........................................ 56

5.2.1 Code Smells Metrics Thresholds Definition ................................. 56

5.2.2 Common Fraction Thresholds ..................................................... 58

5.2.3 Benchmark-Based Thresholds (BBT) ........................................... 60

5.2.4 Considerations and Threats to Validity of BBT Method .............. 70

5.3 Conclusion and Discussion .................................................................. 76

6. Detection of Design Flaws .......................................................................... 78

6.1 Selection of Code Smells...................................................................... 78

6.2 Detection Approach ............................................................................ 81

6.2.1 Detection Strategy....................................................................... 83

6.2.2 Harmfulness Computation .......................................................... 85

6.2.3 Filters for Refining Detection Results .......................................... 92

6.2.4 Presentation of Detection Results............................................... 99

6.2.5 Code Smell Visualization ............................................................ 100

6.3 Investigated Code Smells ................................................................... 109

6.3.1 God Class ................................................................................... 109

6.3.2 Data Class .................................................................................. 119

6.3.3 Brain Method ............................................................................ 124

6.3.4 Shotgun Surgery ........................................................................ 129


6.3.5 Dispersed Coupling ................................................................... 133

6.3.6 Message Chains ........................................................................ 136

6.4 Conclusion and Discussion ................................................................ 139

7. Evaluation of Design Flaws Detection ....................................................... 141

7.1 Detection Results on the Qualitas Corpus ........................................ 141

7.2 Validation of the Approach............................................................... 152

7.2.1 Comparison with inFusion ........................................................ 152

7.2.2 Agreement with a Machine Learning Approach ....................... 173

7.2.3 Comparison with a Machine Learning Approach ..................... 174

7.2.4 Assessment of Effectiveness ..................................................... 181

7.3 Conclusion and Discussion ................................................................ 184

8. Threats to Validity.................................................................................... 186

8.1 Threats to Internal Validity ............................................................... 186

8.2 Threats to External Validity .............................................................. 188

9. Concluding Remarks and Future Plans ...................................................... 190

9.1 Concluding Remarks ......................................................................... 190

9.2 Future Plans ...................................................................................... 192

10.Appendices .............................................................................................. 198

A1 DFMC4J Model Details ...................................................................... 198

B1 Design Information Definition and Computation ............................. 214

B2 Design Metrics Definition and Computation .................................... 238

C1 Systems of Qualitas Corpus Used as Benchmark.............................. 277

C2 Aggregated Metrics Distribution Statistics ....................................... 282


C3 Benchmark-Based Derived Thresholds ............................................. 285

D1 Fowler’s Code Smells Definition ........................................................ 303

D2 Code Smells Impact on Software Quality .......................................... 305

D3 Code Smells Numerosity .................................................................... 312

D4 Code Smells Impact on Quality Dimensions ...................................... 315

E1 Code Smell Detection Results on Qualitas Corpus ............................ 315

E2 JCodeOdor Detection Results on Heritrix.......................................... 340

E3 Effectiveness of JCodeOdor, inFusion and MLCS .............................. 344

11.References............................................................................................... 347
List of Figures
Figure 1: JCodeOdor and DFMC4J Architecture Overview .............................. 18
Figure 2: JCodeOdor and DFMC4J Architecture Detailed ................................ 19
Figure 3: DFMC4J Model – Overview of Code Elements ................................. 21
Figure 4: DFMC4J Model – Code Information ................................................ 22
Figure 5: DFMC4J Components Interactions ................................................. 25
Figure 6: DFMC4J Sequence CodeInformation on the Model .......................... 34
Figure 7: DFMC4J Sequence CodeInformation Not on the Model 7 .................. 35
Figure 8: JCodeOdor Components Interactions ............................................. 36
Figure 9: JCodeOdor Detection Approach Steps ............................................ 37
Figure 10: Design Metrics and Information Dependencies Example ................ 45
Figure 11: Personal Lending Library Example ................................................ 49
Figure 12: Test Cases for TCC Computation Validation .................................. 52
Figure 13: Benchmark-Based Thresholds Derivation...................................... 61
Figure 14: Aggregated LOC Metric Quantile Chart Cropped at 90% ................. 64
Figure 15: NOM 𝑺𝒕𝒂𝒓𝒕𝑷𝒕 and 𝑺𝒕𝒂𝒓𝒕𝑽𝒂𝒍......................................................... 67
Figure 16: NOM Reference Distribution ....................................................... 68
Figure 17: Normal Q-Q plot of LOC of Heritrix Classes ................................... 71
Figure 18: Two-sample Kolmogorov-Smirnov Test Plot .................................. 74
Figure 19: Jasml NOPA Distribution ............................................................. 74
Figure 20: Most Common NOPA Distribution ................................................ 75
Figure 21: Mapping between CFT and BBT Reference ThPoint ........................ 77
Figure 22: Example of Harmfulness Level Points Selection. ........................... 87
Figure 23: Example of Harmfulness Computation. ......................................... 91
Figure 24: Presentation of Detection Results ................................................ 99
Figure 25: The Principles We Take from the Polymetric View. ...................... 102
Figure 26: Colour used to Visualize Code Smell Harmfulness. ....................... 103
Figure 27: Example of Shape and Attributes for Classes and Methods ........... 104
Figure 28: Example of belonging Relation. .................................................. 104
Figure 29: Example of hierarchy Relation. ................................................... 105
Figure 30: Example of generic Relation. ...................................................... 105
Figure 31: Code Smell Profile View Example. ............................................... 106
Figure 32: Code Smell Context View Example. ............................................. 107
Figure 33: Related Code Smell View Example............................................... 108
Figure 34: God Class Detection Strategy. ..................................................... 111
Figure 35: God Class Profile View Example. ................................................. 115
Figure 36: God Class Profile View Additional Information Example. .............. 116
Figure 37: God Class Context View Example. ............................................... 117
Figure 38: God Class Context View Additional Information Example. ............ 117
Figure 39: Related God Class View Example. ............................................... 119
Figure 40: Data Class Detection Strategy. .................................................... 120
Figure 41: Brain Method Detection strategy. ............................................... 126
Figure 42: Shotgun Surgery Detection strategy. ........................................... 129
Figure 43: Dispersed Coupling Detection Strategy. ...................................... 133
Figure 44: Message Chains Detection Strategy. ........................................... 137
Figure 45: Sparsity of Class Code Smells Detection Results ........................... 143
Figure 46: Sparsity of Class Code Smells Detection Results .......................... 144
Figure 47: Code Smell Harmfulness Distribution Chart ................................ 146
Figure 48: CrawlJobHandler God Class Profile View. ................................... 159
Figure 49: CrawlJobHandler God Class Context View. .................................. 161
Figure 50: Related CrawlJobHandler God Class View. .................................. 162
Figure 51: inFusion CrawlJobHandler God Class Internals View .................... 164
Figure 52: DFMC4J Model – Code Element Hierarchy................................... 207
Figure 53: DFMC4J Model – DataType ........................................................ 208
Figure 54: DFMC4J Model – Physical Entities .............................................. 208
Figure 55: DFMC4J Model – Top Hierarchy Logical Entities .......................... 209
Figure 56: DFMC4J Model – Type Entities ................................................... 210
Figure 57: DFMC4J Model – Procedure Entities ........................................... 211
Figure 58: DFMC4J Model – Variable Entities .............................................. 212
Figure 59: DFMC4J Model – Code Information Hierarchy ............................. 213
List of Tables
Table 1: Details of Code Smells Detection Experimented Tools ...................... 10
Table 2: Other Code Smells Detection Tools - Details .................................... 13
Table 3: Other Code Smells Detection Tools – Detected Code Smells .............. 14
Table 4: Entity the Different Types of Visitors Can Visit ................................ 29
Table 5: DFMC4J Visitors Dependencies Declaration Example ........................ 30
Table 6: DFMC4J Visitors Dependencies Set ................................................. 31
Table 7: DFMC4J Visitors Applicability Declaration Example .......................... 32
Table 8: List of Design Metrics Computed by DFMC4J ................................... 43
Table 9: List of Design Information Computed by DFMC4J ............................. 44
Table 10: Validation of TCC Design Metric .................................................... 52
Table 11: Common Fraction Thresholds Definition ........................................ 59
Table 12: Benchmark-Based Thresholds Definition ....................................... 68
Table 13: Selected Code Smells.................................................................... 80
Table 14: Example of Features of the Entities Affected by Code Smell ............ 97
Table 15: Example of Code Smell Top Characteristics Report ......................... 97
Table 16: Statistics about the 74 Qualitas Corpus Systems ........................... 142
Table 17: Numerosity of Class Code Smells .................................................. 143
Table 18: Numerosity of Method Code Smells ............................................. 143
Table 19: Impact of Filters-Aware Detection ............................................... 144
Table 20: God Class Related Code Smells Statistics ...................................... 147
Table 21: Data Class Related Code Smells Statistics ..................................... 148
Table 22: Brain Method Related Code Smells Statistics ................................ 148
Table 23: Shotgun Surgery Related Code Smells Statistics ............................ 149
Table 24: Dispersed Coupling Related Code Smells Statistics ........................ 150
Table 25: Message Chains Related Code Smells Statistics ............................. 150
Table 26: Methods Code Smells Co-Occurrence ............................................ 151
Table 27: Heritrix Systems Size Measures ................................................... 153
Table 28: Interpretation of Cohen’s Kappa Statistic Values .......................... 154
Table 29: God Class Detection Results Comparison with inFusion ................. 154
Table 30: JCodeOdor and inFusion God Class Detection Results .................... 155
Table 31: Harmfulness Comparison between JCodeOdor and inFusion .......... 158
Table 32: Data Class Detection Results Comparison with inFusion ................ 165
Table 33: JCodeOdor and inFusion Data Class Detection Result s ................... 165
Table 34: Brain Method Detection Results Comparison with inFusion ........... 167
Table 35: JCodeOdor and inFusion Brain Method Detect ion Results .............. 168
Table 36: Shotgun Surgery Detection Results Comparison with inFusion ....... 169
Table 37: JCodeOdor and inFusion Shotgu n Surgery Detection Results .......... 170
Table 38: Message Chains Detection Results Comparison with inFusion ........ 171
Table 39: JCodeOdor and inFusion Message Chains Detection Results ........... 171
Table 40: Statistics of a Machine Learning Code Smells Detection................. 173
Table 41: Detection Results Comparison with a Machine Learning ................ 174
Table 42: Jasml Systems Size Measures ....................................................... 175
Table 43: Agreement between JCodeOdor and Machine Learning ................. 176
Table 44: Manual Detected God Class on Jasml ........................................... 176
Table 45: JCodeOdor and MLCS God Class Detection Results on Jasml........... 177
Table 46: Manual Detected Data Class on Jasml .......................................... 178
Table 47: JCodeOdor and MLCS Data Class Detection Result s on Jasml ......... 178
Table 48: Manual Detected Brain Method on Jasml .................................... 179
Table 49: JCodeOdor and MLCS Brain Method Detection on Jasml ............... 179
Table 50: Precision and Recall of JCodeOdor Respect to the Oracle ............. 183
Table 51: DFMC4J Model CodeElement Description ..................................... 198
Table 52: DFMC4J Model CodeInformation Description ............................... 203
Table 53: Declared Class Design Information - Def. and Comput. ................. 215
Table 54: Implemented Interfaces Design Information - Def. and Comput. ... 216
Table 55: Methods Declared In Class Design Information - Def. and Comput. 216
Table 56: Attributes Of Class In Class Design Information - Def. and Comput.217
Table 57: Parent Class Design Information - Def. and Comput. .................... 218
Table 58: Ancestor Classes Design Information - Def. and Comput. .............. 218
Table 59: Children Classes Design Information - Def. and Comput. .............. 219
Table 60: Used Intra Variables Design Information - Def. and Comput. ........ 219
Table 61: Used Inter Variables Design Information - Def. and Comput. ........ 220
Table 62: Used Hierarchy Variables Design Information - Def. and Comput. . 222
Table 63: Used Variables Design Information - Def. and Comput. ................ 223
Table 64: Overridden Methods Design Information - Def. and Comput. ........ 224
Table 65: Inherited Methods Design Information - Def. and Comput. ........... 225
Table 66: Called Intra Methods Design Information - Def. and Comput. ....... 225
Table 67: Called Inter Methods Design Information - Def. and Comput. ....... 226
Table 68: Called Hierarchy Methods Design Information - Def. and Comput. 227
Table 69: Called Methods Design Information - Def. and Comput. ............... 228
Table 70: Used Intra Types Design Information - Def. and Comput. .............. 229
Table 71: Used Inter Types Design Information - Def. and Comput. .............. 230
Table 72: Used Hierarchy Types Design Information - Def. and Comput........ 231
Table 73: Used Types Design Information - Def. and Comput. ...................... 232
Table 74: Called Classes Design Information - Def. and Comput. .................. 234
Table 75: Calling Classes Design Information - Def. and Comput. ................. 235
Table 76: Calling Methods Design Information - Def. and Comput. .............. 236
Table 77: Message Chains Info Design Information - Def. and Comput. ........ 237
Table 78: LOC Design Metric - Definition and Computation ......................... 239
Table 79: LOCNAMM Design Metric - Definition and Computation ............... 241
Table 80: NOPK Design Metric - Definition and Computation ....................... 241
Table 81: NOCS Design Metric - Definition and Computation ....................... 242
Table 82: NOM Design Metric - Definition and Computation ....................... 243
Table 83: NOMNAMM Design Metric - Definition and Computation ............. 244
Table 84: NOA Design Metric - Definition and Computation ........................ 245
Table 85: CYCLO Design Metric - Definition and Computation ...................... 246
Table 86: WMC Design Metric - Definition and Computation ....................... 247
Table 87: WMCNAMM Design Metric - Definition and Computation ............. 248
Table 88: AMW Design Metric - Definition and Computation ....................... 248
Table 89: AMWNAMM Design Metric - Definition and Computation ............. 249
Table 90: MAXNESTING Design Metric - Definition and Computation ........... 250
Table 91: WOC Design Metric - Definition and Computation ........................ 250
Table 92: CLNAMM Design Metric - Definition and Computation ................. 251
Table 93: NOP Design Metric - Definition and Computation ......................... 252
Table 94: NOAV Design Metric - Definition and Computation ...................... 253
Table 95: ATLD Design Metric - Definition and Computation ....................... 254
Table 96: NOLV Design Metric - Definition and Computation ........................ 255
Table 97: TCC Design Metric - Definition and Computation .......................... 255
Table 98: LCOM5 Design Metric - Definition and Computation ..................... 257
Table 99: FANOUT Design Metric - Definition and Computation ................... 258
Table 100: FANIN Design Metric - Definition and Computation ..................... 259
Table 101: ATFD Design Metric - Definition and Computation ...................... 260
Table 102: FDP Design Metric - Definition and Computation ........................ 261
Table 103: RFC Design Metric - Definition and Computation ......................... 262
Table 104: CBO Design Metric - Definition and Computation ........................ 263
Table 105: CFNAMM Design Metric - Definition and Computation ................ 264
Table 106: CINT Design Metric - Definition and Computation ....................... 265
Table 107: CDISP Design Metric - Definition and Computation ..................... 266
Table 108: MaMCL Design Metric - Definition and Computation ................... 267
Table 109: NMCS Design Metric - Definition and Computation ..................... 267
Table 110: MeMCL Design Metric - Definition and Computation ................... 268
Table 111: CC Design Metric - Definition and Computation .......................... 269
Table 112: CM Design Metric - Definition and Computation ......................... 269
Table 113: NOAM Design Metric - Definition and Computation .................... 270
Table 114: NOPA Design Metric - Definition and Computation ..................... 271
Table 115: LAA Design Metric - Definition and Computation ........................ 271
Table 116: DIT Design Metric - Definition and Computation ......................... 272
Table 117: NOI Design Metric - Definition and Computation ........................ 273
Table 118: NOC Design Metric - Definition and Computation ........................ 274
Table 119: NMO Design Metric - Definition and Computation ...................... 274
Table 120: NIM Design Metric - Definition and Computation ........................ 275
Table 121: NOII Design Metric - Definition and Computation ....................... 276
Table 122: 74 Selected Systems from the Qualitas Corpus ............................ 278
Table 123: God Class Detection Strategy Metrics Distribution ...................... 282
Table 124: God Class Views Metrics Distribution ......................................... 282
Table 125: Data Class Detection Strategy Metrics Distribution ..................... 283
Table 126: Data Class Views Metrics Distribution ........................................ 283
Table 127: Brain Method Detection Strategy Metrics Distribution ................ 283
Table 128: Brain Method Views Metrics Distribution ................................... 283
Table 129: Shotgun Surgery Detection Strategy Metrics Distribution ............ 284
Table 130: Shotgun Surgery Views Metrics Distribution ............................... 284
Table 131: Dispersed Coupling Detection Strategy Metrics Distribution ........ 284
Table 132: Message Chains Detection Strategy Metrics Distribution ............. 284
Table 133: God Class LOCNAMM Metric Thresholds ..................................... 285
Table 134: God Class WMCNAMM Metric Thresholds ................................... 286
Table 135: God Class NOMNAMM Metric Thresholds ................................... 287
Table 136: God Class ATFD Metric Thresholds ............................................. 287
Table 137: God Class NOPA Metric Thresholds ............................................ 288
Table 138: God Class FANIN Metric Thresholds ............................................ 288
Table 139: Data Class WMCNAMM Metric Thresholds .................................. 289
Table 140: Data Class NOAM Metric Thresholds .......................................... 290
Table 141: Data Class NOPA Metric Thresholds ........................................... 290
Table 142: Data Class NOMNAMM Metric Thresholds .................................. 291
Table 143: Data Class FANIN Metric Thresholds ........................................... 292
Table 144: Data Class FANOUT Metric Thresholds ........................................ 292
Table 145: Brain Method LOC Metric Thresholds ......................................... 293
Table 146: Brain Method CYCLO Metric Thresholds ..................................... 294
Table 147: Brain Method MAXNESTING Metric Thresholds .......................... 294
Table 148: Brain Method NOLV Metric Thresho lds ...................................... 295
Table 149: Brain Method ATLD Metric Thresholds ....................................... 296
Table 150: Brain Method NOP Metric Thresholds ........................................ 296
Table 151: Brain Method CLNAMM Metric Thresholds ................................ 297
Table 152: Brain Method ATFD Metric Thresholds ...................................... 297
Table 153: Shotgun Surgery CC Metric Thresholds ...................................... 298
Table 154: Shotgun Surgery CM Metric Thresholds ..................................... 299
Table 155: Shotgun Surgery FANOUT Metric Thresholds .............................. 299
Table 156: Shotgun Surgery CFNAMM Metric Thresholds ............................ 300
Table 157: Dispersed Coupling CINT Metric Thresholds ............................... 301
Table 158: Message Chains MaMCL Metric Thresholds ................................ 301
Table 159: Message Chains MeMCL Metr ic Thresholds ................................ 302
Table 160: Message Chains NMCS Metric Thresholds .................................. 303
Table 161: Description of the 22 Fowler Code Smells .................................. 303
Table 162: Code Smells Impact on Software Quality .................................... 306
Table 163: Code Smells Numerosity ........................................................... 313
Table 164: Code Smells Impact on Quality Dimensions ................................ 315
Table 165: God Class Detection Results on the Qualitas Corpus ................... 316
Table 166: Data Class Detection Results on the Qualitas Corpus .................. 320
Table 167: Brain Method Detection Results on the Qualitas Corpus ............. 324
Table 168: Shotgun Surgery Detection Results on the Qualitas Corpus ......... 328
Table 169: Dispersed Coupling Detection Results on the Qualitas Corpus ..... 332
Table 170: Message Chains Detection Results on the Qualitas Corpus .......... 336
Table 171: JCodeOdor God Class on Heritrix ............................................... 340
Table 172: JCodeOdor Data Class on Heritrix .............................................. 341
Table 173: JCodeOdor Brain Method on Heritrix ......................................... 342
Table 174: JCodeOdor Shotgun Surgery on Heritrix ..................................... 343
Table 175: JCodeOdor Message Chains on Heritrix ...................................... 344
Table 176: Agreement and Cohen’s kappa between JCodeOdor and MLCS .... 344
Table 177: Agreement and Cohen’s kappa between JCodeOdor and inFusion 345
Table 178: Agreement and Cohen’s kappa between MLCS and inFusion ....... 345
Table 179: Precision ad Recall of JCodeOdor versus a Manual Oracle ........... 345
Table 180: Precision ad Recall of MLCS versus a Manual Oracle ................... 346
Table 181: Precision ad Recall of inFusion versus a Manual Oracle .............. 346
Chapter 1
Introduction

Nobody has a perfect life; everyone has his or her own problems. Everyone
during his or her life did some blood tests and took them to their doctor.
When the doctor looks at blood tests, uses as a reference some indicators
and a corresponding range of values to assess our health. To make a detailed
assessment the doctor never evaluates the various indicators individually,
but always looking at groups of them as a whole. For software, it is very
similar. Each software has its problems, we have instruments to analyse it
using some indicators, software metrics, and we can determine reference
values to understand whether the software is "sick" or not. The main differ-
ence between humans and software is that humans have similar physical
characteristics, with some exceptions, and software are very different, with
some exceptions. In this chapter, we discuss how we deal with software
"health" assessment, evaluating metrics as a whole as indicators, using code
smells (a particular kind of design flaw), and the problems that we have to
tackle with for doing that. We particularly refer to object-oriented software
design assessment.

1.1 Context and Motivation


Software development and quality assessment are complex activities,
and have to be monitored to avoid unexpected consequences. During the
development of a new software artefact, or the maintenance of a previously
realized one, it is common to make some non-optimal design choices. This
happens for lack of experience, time-to-market constraints, and other fac-
tors that influence the software lifecycle. Object-oriented software has dif-
ferent aspects that can be monitored, like coupling and cohesion. One of the
existing instruments useful for monitoring software design quality are de-
sign metrics [35].
1
Chapter 1. Introduction

Software design quality metrics give only a hint about software design qual-
ity; metrics are not enough semantically rich to enable users (e.g., develop-
ers and code maintainers) to really understand what is going wrong and find
a solution. Like a doctor that has to select groups of blood test indicators
and look them as a whole, also for the software it is important to look at a
set of selected metrics as a whole. Code smells [51][75] can provide a solu-
tion to this issue, identifying more complex and semantically rich structures
in source code. A code smell is a particular kind of design flaw 1, it captures
some characteristics of “design health” of a software artefact (e.g., “Classes
that are very large and complex, with many non-cohesive methods”), and
identifies artefacts that can be an obstacle to comprehend, maintain and
evolve software. Code smells in fact have been proved to be good indicators
of other problems of a software system that impact on comprehensibility,
maintenance and evolution, like faults [78][117] and change-proneness
[66][134].
The term code smell was coined by Fowler et al. in [51] referring to a struc-
ture to be detected in software design, to be used as a starting point to en-
hance system quality through refactoring. Code smells, indeed, have to be
carefully investigated to decide if they represent a problem in software de-
sign, and to determine the best way to enhance the design quality. Fowler
et al. define code smells in an informal way, and suggest that only an expert
can identify them. This is a difficult, tedious, and time-consuming task, and
for these reasons, different approaches have been proposed to automatically
detect them.
Code smells automatic detection is widely discussed [75][85][101][102],
but there are some open problems in the ways experts can approach code
smells automatic detection and show results to the users. There is a large
number of already defined code smells [51][75], many proposed ways to
detect them [8][75][101] during both software development and software
quality assessment, and a bunch of tools to detect them in an automated way
[101][104][143][146].
The starting point for tools that automatically detect code smells is the in-
formal definition that describes the characteristics of software artefact to be

1
Another design flaw is for example antipattern
2
Chapter 1. Introduction

captured. Because of the informal definition, sometimes a perfectly good


design choice can be detected as affected by code smell, becoming a false
positive. Another problem introduced by the informal definition, is that too
many entities can be identified as affected by code smells. The number of
identified entities depends on the criteria used to quantify elements of code
smell informal definition (e.g., “very large and complex” and “non -cohe-
sive”), when defining their automatic identification in source code through
software design metrics.
Very often, it is not possible to tackle all the potential problems of a soft-
ware system, because of other constraints, like deadlines. To allow experts
to effectively examine affected entities, it is fundamental to show to the
users the set of detected code smells in a prioritized way, and to define a set
of customized views representing all aspects related to the presence of a
potential design problem.

1.2 Goals of the Thesis


The primary goal of this thesis is the realization of JCodeOdor, a
tool for automatic code smells detection that takes into account all issues
discussed above and provides a solution.
JCodeOdor name is composed of “J”, which stands for Java, which is the
programming language on which we perform code smells detection, “Code”
which highlights that the problems are in the code of the software, and
“Odor” means that we want to offer to the users a way to “understand
smells” and find a way to “make them an odor” (i.e., good design choices).
JCodeOdor implements a code smells detection approach based on soft-
ware design metrics. The proposed detection approach tries to gather the
best from other detection approaches proposed in the literature, and pro-
vides some new features to enhance detection results quality, usefulness,
and comprehensibility.
To develop a metric-based code smells detection approach, the first step is
the selection of software design metrics. We need software design metrics
to build detection strategies (i.e., composed logical conditions based on
design metrics), useful to automatically detect code smells. We refer to the
literature of object-oriented design quality models based on code smells and
3
Chapter 1. Introduction

design metrics, and to the literature of well-defined object-oriented metrics


suites to select a set of software design metrics that measures different
aspects of object-oriented software design, like size, complexity, encap-
sulation, inheritance, coupling, and cohesion. We also define some new de-
sign metrics to better characterize properties of entities potentially affected
by code smells and to refine the detection strategies we propose for auto-
matic code smells detection.
The proposed detection approach is general enough to be applied to all code
smells; in this work, we deeply analyse six code smells, defining and testing
their detection strategies and discussing all elements of the pro posed ap-
proach. We select six code smells referring to the literature, to find the most
dangerous ones with respect to their impact on faults prediction and
change-proneness. The selected code smells are: God Class, Data Class,
Brain Method, Shotgun Surgery, Dispersed Coupling, and Message Chains.
To test and refine detection strategies and all parts of the proposed ap-
proach, a tool named Design Features and Metrics Computation for Java
(DFMC4J) has been developed. DFMC4J is able to extract information from
source code of systems and to compute software metrics in an automated
and scalable way, abstracting from source code and creating a simplified
representation of code elements. The tool allows executing computation on
demand on a single entity, as well as in batch on a set of software systems.
An on demand computation is useful, for example, to understand if a given
entity is affected or not by a code smell. Batch computation is useful, for
example, when we define detection strategies for code smells.
To define a detection strategy, we have to determine thresholds for the met-
rics it uses. We use thresholds to quantify elements of the informal defini-
tion (e.g., a threshold for metrics that measure class cohesion, to identify
“non-cohesive” classes). To address this problem we propose a method to
derive metrics thresholds from a benchmark of software systems , which
is repeatable, transparent, straightforward to carry out, and derives custom-
ized thresholds (for each code smell) that respect statistical properties of
the metric, such as metric scale and distribution. In this way, we can asso-
ciate to “non-cohesive” a threshold derived from the statistical distribution
of a metric measuring the cohesion of a class.

4
Chapter 1. Introduction

Once defined the detection strategies, we thoroughly analyse entities iden-


tified as affected by code smells, to identify a solution to false positive
problems, to be adopted and integrated into the detection approach we pro-
pose. We introduce and test Code Smell Filters [47] to address this problem
and reduce the number of false positive, taking care that this evaluation
could be subjective [28][86] or based on the specific system under investi-
gation.
In the entire set of detected code smells, it is fundamental to identify the
most harmful ones, to give to the users a way to select what to investigate
first, based on their constraints (e.g., deadline). We deal with this problem
introducing and implementing the Code Smell Harmfulness, an index about
how much each code smell is harmful compared to the other code smells.
The harmfulness allows presenting the detected code smells in a priori-
tized way. Code Smell Harmfulness enables users to identify the first po-
tential problems to tackle with; these potential problems are the most inter-
esting ones, according to the proposed Code Smell Filters.
Once the user selects the code smell to investigate, he has to understand if
it represents a problem for software design quality and has to identify the
correct way to fix it. Correction implies understanding the whole context,
hence we integrate as part of the proposed detection approach a set of views
that bring to the users all data he needs to efficiently and effectively under-
stand the potential problem and to evaluate how to fix it, among different
ways that generally exist to do that [51][99]. We propose personalized
views for each code smell, which show details about the code smell and
its impact on system design quality. We customize the views for each code
smell, because each code smell has its own characteristics and describes
some different design quality aspects of an object-oriented software system.
We evaluate the quality and effectiveness of all parts of our work, to understand
strengths and weaknesses, and identifying some future works to enhance results.
We discuss the results obtained by JCodeOdor, we evaluate the quality of detection
results, and the usefulness of Code Smell Harmfulness, Code Smell Filters and the
set of proposed views, with respect to the state-of-the-art tool inFusion [143]. We
detect code smells with both the tools and deeply investigating the obtained
results. We compare our results with respect to a machine learning approach for

5
Chapter 1. Introduction

code smells detection [8], to investigate commonalities and divergences re-


spect to a different approach for code smells detection. Finally, we assess
the effectiveness of the detection strategies we propose, matching JCodeO-
dor detection results with respect to an oracle built by hand, and comparing
JCodeOdor performance with the performance achieved by a machine learn-
ing approach and inFusion.

1.3 Outline of the Thesis


This thesis is organized as follows:
In Chapter 2, we present the existing code smells detection tools we exper-
imented with, and others that have been proposed in the literature, outlining
some limitations of the code smells detection approach the tools propose.
In Chapter 3, we present the architecture of JCodeOdor and DFMC4J, and
we discuss all the modules and components that realize both the tools.
In Chapter 4, we discuss how we select and compute software design met-
rics for different object-oriented quality dimensions.
In Chapter 5, we discuss about thresholds derivation for code smells detec-
tion, and we provide a method to automatically derive thresholds for de-
sign metrics from a benchmark of software systems.
In Chapter 6, we propose and explain the code smells detection approach
we implement in JCodeOdor, and discuss the details for the six code
smells we deeply investigate.
In Chapter 7, we discuss the results obtained by JCodeOdor and we eval-
uate the quality of the detection results with respect to the state-of-the-art
tool inFusion, with respect to a machine learning approach for code smells
detection and with respect to an oracle built by hand.
In Chapter 8, we discuss threats to validity.
In Chapter 9, we give concluding remarks and we discuss some foresee
future works.

6
Chapter 1. Introduction

During the Master Thesis work, we published three papers. We report them,
along with the abstract:

F. Arcelli Fontana, V. Ferme, A. Marino, B. Walter, and P. Martenka, “In-


vestigating the Impact of Code Smells on System’s Quality: An Empir-
ical Study on Systems of Different Application Domains,” in 29th IEEE
International Conference on Software Maintenance (ICSM 2013), 2013.

Abstract: Various activities support software maintenance. Program com-


prehension and detection of design anomalies and their symptoms, like code
smells and antipatterns, are particularly relevant for improving the quality
and facilitating evolution of a system. In this paper we describe an empirical
study on the detection of code smells, aiming at identifying the most fre-
quent code smells in systems of different domains and hence the domains
characterized by more smells. Moreover, we study possible correlations ex-
isting among code smells and the values of a set of software quality metrics
using Spearman’s rank correlation and Principal Component Analysis.

V. Ferme, A. Marino, and F. Arcelli Fontana, “Is it a Real Code Smell to


be Removed or not?,” in International Workshop on Refactoring & Testing
(RefTest), co-located event with XP 2013 Conference, 2013.

Abstract: Several kinds of code smells have been defined in the literature,
but no formal definition exists. Hence, the code smells detection tools pro-
vide different results, because the smells can be interpreted and detected in
different ways. Moreover, other aspects related to the domain of the system
under analysis, or its size and other design features are not usually taken
into account. For these reasons, the detected smells may not always be real
code smells and symptoms of problems to be solved. In this paper, we ad-
dress this question on the evaluation of code smells. We focus our attention
on the detection of two smells, God Class and Data Class on different sys-
tems, with the aim to identify possible filters to be used to improve or refine
the detection strategies of these smells. By identifying only real code smells,
the refactoring effort to inspect and remove them is reduced.
7
Chapter 1. Introduction

F. Arcelli Fontana, V. Ferme, and S. Spinelli, “Investigating the Impact


of Code Smells Debt on Quality Code Evaluation,” in 2012 Third Inter-
national Workshop on Managing Technical Debt (MTD), co-located event
with ICSE 2012 Conference, 2012, pp. 15–22.

Abstract: Different forms of technical debt exist that have to be carefully


managed. In this paper, we focus our attention on design debt, represented
by code smells. We consider three smells that we detect in open source sys-
tems of different domains. Our principal aim is to give advice on which
design debt has to be paid first, according to the three smells we have ana-
lysed. Moreover, we discuss if the detection of these smells could be tai-
lored to the specific application domain of a system.

8
Chapter 2
Design Flaws Detection Tools

Many tools for design flaws detection have been proposed, both industrial
projects and research prototypes. Some tools are dedicated to improve code
quality during software development, other to support reengineering and
maintenance activities. In this chapter, we discuss four tools released in a
stable version that we experimented with, and then we present other relevant
tools available. At the end of this chapter, we discuss some limitations of
the existing tools.

2.1 Review of Experimented Tools


A wide range of tools to detect design flaws exists, both industrial
projects and research prototypes. These tools exploit different techniques to
detect design flaws. Some of these techniques are metrics-based
[75][102][126][138][143], while others use a dedicated specification lan-
guage [101], or use a program analysis to identify refactoring opportunities
[48][76][146], or use a machine learning approach [8][59][84][85]. In this
section, we are discussing the tools we experimented. We deeply experiment
four solid tools: inFusion, which is a commercial tool, Checkstyle, JDeo-
dorant and PMD that are three tools released in a stable version. Checkstyle
and PMD detect code smells using an approach similar to inFusion (i.e.,
metrics-based), while JDeodorant approaches code smells detection using a
program analysis to identify refactoring opportunities. We select these four
tools among the ones we found in the literature because:

 It is possible to download the tool. This seems obvious, but most


of the times we are not able to find or retrieve (asking to the au-
thor) tools presented in the research papers;
 They are tools released in a stable version;

9
Chapter 2. Design Flaws Detection Tools

 They are developed to accomplish code smells detection during


different phases of the software developments process: Check-
style, PMD, and JDeodorant detect code smells to improve code
quality during software development, while inFusion 2 is dedi-
cated to support reengineering and maintenance activities.

Table 1 shows the details of the four considered tools, we report also if the
tool proposes the way to solve the detected code smell, using refactoring
[51], or does not.

Table 1: Details of Code Smells Detection Experimented Tools

Tool Experimented Version Prog. Language Refactoring


inFusion 1.7 3 (2012) Java, C, C++ No
Checkstyle 5.6 3 (2012) Java No
Java, JavaScript,
PMD 5.0.2 (2013) No
XML, XSL
JDeodorant 4.4.8 (2013) Java Yes

inFusion
inFusion [143] is a commercial tool developed by Intooitus, which detects
a large number of code smells and reports them along with a severity value.
The tool was born as an evolution of IPlasma, a tool by Lanza et al. pre-
sented in [75]. inFusion detects more than 20 code smells (e.g., God Class
and Data Class) using a metric-based approach, following for most of them
the definitions provided by Fowler et al. in [51] (refers to Appendix D1 for
a list of the definitions). This is the only tool we can experiments that pro-
vide a severity score, along with each detected code smell, that give a hint
and a way to sort the detection results in a prioritized way. inFusion sup-
ports the analysis and the investigation of the detected code smells, as for
example, visualizing a set of additional information related to the object -
oriented design quality dimensions the code smell impacts to. It offers also
a set of views to explore the impact of the code smell on the quality dimen-
sions.

2
Intooitus, the company behind inFusion development, propose also a simplified imple-
mentation of inFusion, to be used during the development: inCode [93].
3
This is the last version at 08/31/2013.
10
Chapter 2. Design Flaws Detection Tools

Checkstyle
Checkstyle [138] is a tool to validate source code conventions. One of the
most interesting feature of this tool is that the rules it provides to validate
source code conventions can be extended with new custom defined rules .
Checkstyle is able to detect the Long Method, Long Parameter List and
Large Class code smells defined by Fowler. Along with these code smells,
Checkstyle also detects duplicate code. Checkstyle is a tool born to be used
as an integrated tool in the build process or in the development environment,
it can be integrated for example with a wide range of IDE, like Eclipse
[139]. During our experimentation we find out that code smells Checkstyle
detects are not precise. We think this is a consequence that the tool is not
dedicated only to code smells detection, but they are a small portion of the
entire set of coding convention Checkstyle proposes. Another issue is the
absence of all the information useful to investigate the detected code smells,
like severity and proposed views. The possibility of adding new customized
rules partially fulfil the discussed shortcomings, but a programmer has to
be expert of code smells detection and has to define a way to detect them.
This task if done well requires a great effort.

PMD
PMD [147] scans Java source code and looks for potential problem s or pos-
sible bugs, and duplicated code. The techniques PMD uses are very similar
to the ones by Checkstyle. PMD is able to detect Large Class, Long Method,
Long Parameter List, and Duplicated Code smells, and allows the user to
set the thresholds values for the exploited metrics. As for Checkstyle, even
with PMD is possible to define customized rules to improve and extend
existing ones. This functionality is very useful because PMD, like Check-
style, does not perform well detecting code smells, and we think the reason
is the same as for Checkstyle: it is not dedicated exclusively to code smells
detection.

11
Chapter 2. Design Flaws Detection Tools

JDeodorant
JDeodorant [146] detects code smells and can automatically refactor se-
lected code smells instances. JDeodorant detects code smells using a pro-
gram analysis to identify refactoring opportunities. This approach leads to
present to the user only that code smells the automatic algorithm that per-
form the program analysis detects as candidate to refactor. At this time the
tool detects Long Method [49], Feature Envy [48] and Type Checking [128]
code smells defined by Fowler. JDeodorant reports the entities affected by
each code smell in a different list, along with a visualization that identify
the possible refactoring in the source code. The user can select the code
smells to refactor and JDeodorant automatically performs the refactoring.
The automatic refactoring offered by JDeodorant is a great feature but has
to be used with caution. JDeodorant does not explicitly report the reasons
behind each single refactoring proposal, hence the user has to manually in-
vestigate the code to understand if to refactor or not the potential problem
indicated by the code smell.

2.2 Review of Other Tools


In addition to the code smells detectors we experimented and dis-
cussed in the previous section, other tools have been proposed [42]
[75][84][101][104][120][126]. Most of the proposed tools are research pro-
totype; in this section, we are discussing the most relevant ones and then
we report a summary of principal details of the others.
DECOR [101] implements a dedicated specification language for code
smells detection, allowing the specification of the code smells detection
strategies directly by the user. DECOR proposes the detection strategies of
six code smells proposed by Fowler.
CodeNose is a code smells detection prototype developed by Slinger [120].
It is developed as an Eclipse plugin and detects design problems by travers-
ing Abstract Syntax Trees, a tree representation of the abstract syntactic
structure of source code, where each node of the tree denotes a construct
occurring in the source code. Design problems are inferred with a relational
algebra [124] calculator using collected primitive and derived code smells
aspects.

12
Chapter 2. Design Flaws Detection Tools

Stench Blossom [104] provides an interactive ambient visualization de-


signed to give users a quick, high-level overview of the code smells in their
code. Starting from this view the users can deeply investigate the charac-
teristics for the affected entities through a list of details that justify and
explain the code smell presence. The detection approach Stench Blossom
follows is the metrics-based one.
SMURF [84] implements a novel approach to detect antipatterns and code
smells, based on a machine learning technique - support vector machines
(SVM) - and taking into account practitioners’ feedback. SVM allows learn-
ing the detection strategies from a set of known occurrences of code smells
and not code smells.
jCOSMO [42] is a prototype code smells browser that detects and visualizes
code smells in JAVA source code of the entire software project. jCOSMO
proposes a graph representation of the entities affected by code smells and
their relations.
Table 2 reports some details of other tools we find, while Table 3 shows the
detected code smells by each of the tools presented in Table 2. All the re-
ported tools are research prototypes, among them only JCodeCanine sup-
ports refactoring suggesting the most suited to remove the code smell.

Table 2: Other Code Smells Detection Tools - Details

Prog.
Tool Detection Appr.
Lang.
JCodeCanine [106] Metrics-based Java
Anti-Pattern Scanner [132] Metrics-based Java
BSDT Eclipse Plugin [34] Metrics-based Java
EvoOnt [123] Metrics and program analysis Java
SCOOP [83] Metrics and program analysis Java
CodeVizard [115] Metrics-based Java

13
Chapter 2. Design Flaws Detection Tools

Table 3: Other Code Smells Detection Tools – Detected Code Smells

JCodeCanine

Anti-Pattern

CodeVizard
Scanner

SCOOP
EvoOnt
Eclipse
Plugin
BSDT
Code Smell 4
Data Class X X X X
God Class X X X X
Feature Envy X X
Switch Statements X X
Long Method X X
Long Parameter List X X
Shotgun Surgery X X
Lazy Class X X
Parallel Inheritance
X
Hierarchies
Duplicated Code X

2.3 Limitation of the Existing Tools


During our experimentations and investigations of code smells de-
tection tools, we find out some common limitations. We discuss the ones
that we consider the most important, particularly referring to the tools we
experimented. All the experimented and investigated tools share some com-
mon problems: the most common is that some of the detected code smells
are not real problems of software design. This happens also for the ap-
proaches that use machine learning techniques to learn the characteristics
of a code smell. This problem is common because code smells represent
hints of potential problems, and they are not formally defined structures.
For the same reason, we realize that different tools provide different results,
because of the subjective interpretation of the code smell definition [5] and
the approach the tools implement to detect affected entities.
Among the tools we experimented with and we found in the literature, we
argue that inFusion is the most exhaustive tool for code smells detection
4
Appendix D1 gives an overview respect to the cited code smells definition
14
Chapter 2. Design Flaws Detection Tools

and investigation. It only misses some characteristics that we propose in our


JCodeOdor code smells detection approach. For example, sometimes inFu-
sion detects some entities as affected by code smells that we think are not a
problem and that can be simply identified as false positive 5 (e.g., test classes
or methods). We think that the severity provided by inFusion is not well
mapped to the human perception when the user sees the related affected
entities. Another critique is about the views inFusion proposes. inFusion
documentation states that it proposes “polymetric views that are graphical
visualizations of some characteristics of interest in a program's design”
[143]. The views inFusion proposes are far to be considered intuitive, at
least without a deep understanding of the model behind them, and we think
the mayor problem is that they are particularly suited to explore the entire
system, but not effective for exploring a single entity affected by one or
more code smells.
In the remaining of this work, we discuss how we tackle with these problems
and the solutions we propose in JCodeOdor.

5
Refers to Section 7.2.1
15
Chapter 3
JCodeOdor and DFMC4J Architecture

In this chapter, we discuss JCodeOdor architecture, the tool we imple-


mented for automatic code smells detection, and we present DFMC4J archi-
tecture, the tool offering design metrics and design features (or information)
computation capabilities. We design JCodeOdor to be used by different us-
ers in different contexts: it is suited for code smells detection during both
development and software quality assessment. We build JCodeOdor on top
of DFMC4J to exploit design metrics and design features computation. We
introduce DFMC4J, we describe all the functionalities it offers to the tools
built on top of it, and the way it enables design metrics and design features
computation through an abstract model offering a simplified representation
of the source code elements.

3.1 Requirements
JCodeOdor is a tool for code smells detection for Java. It analyses
the source code of a project, retrieves and computes information, w hich is
stored in a way that can be analysed and visualized by users. We design
JCodeOdor to be used by different user profiles. The two main user profiles
we refer to are:

1. Developer: tracks code smells during the development process.


The main requirements from the developer point of view are, as
stated by Murphy-Hill et al. in [103]:
a. Scalability;
b. Availability of code smells information as soon as they are
present in the project;
c. Unobtrusiveness (i.e., the tool should not block the user
from other work while it analyses or finds code smells);

16
Chapter 3. JCodeOdor and DFMC4J Architecture

d. Context-sensitivity (i.e., the tool should tell the user first


and foremost about code smells related to the code he is
working on);
e. Expressiveness of the code smell information;
f. Relativity (i.e., place more emphasis on the smells that are
more difficult to recognize without a tool);
g. Relationality (i.e., showing relationships between code
fragments that give rise to code smells).
2. Code maintainer (or reviewer): tracks code smells during the
quality assessment phase of a project.

In our long-term vision, we plan to implement JCodeOdor as an Eclipse IDE


Plugin supporting developers during the implementation of a system, as
well as a version for code maintainers, working in batch mode and display-
ing the results of code smells detection using a web interface. Currently, we
developed a prototype that implements all the features needed to enable both
scenarios, but not yet the interfaces for IDE integration and full access to
information.
We want to allow JCodeOdor to be extended with other design flaws, such
as antipatterns [19], and other programming languages, hence it has been
designed to allow extensions with little effort. To accomplish these require-
ments, we propose an architecture that is modular, scalable, and open.

3.2 Architecture
We develop JCodeOdor on top of another tool we developed during
this Master Thesis: Design Features and Metrics Computation for Java
(DFMC4J). Figure 1 presents an overview of JCodeOdor and DFMC4J,
while Figure 2 shows the main modules of the proposed architecture.
DFMC4J offers functionalities to abstract from java code (module 1 and 3
of DFMC4J in Figure 2) and to extract information from source code and
compute software design metrics (module 4 of DFMC4J in Figure 2).
DFMC4J bases information extraction on Abstract Syntax Trees [140] rep-
resentation of the analysed system, or a part of it. To obtain ASTs it offers
functionalities to parse and compile java source code, relying on Eclipse
JDT [140], and to convert data from the source code point of view (i.e. ,
17
Chapter 3. JCodeOdor and DFMC4J Architecture

ASTs and Bindings [140]) to the DFMC4J Model point of view (i.e., Java
Objects). The DFMC4J Model is stored both in main memory and on a
datastore, if needed. DFMC4J exposes computed information to the users
and to the tools built on top of it (module 2 of DFMC4J in Figure 2), like
JCodeOdor.
JCodeOdor relies on DFMC4J for metrics computation, while it implements
the code smells detection approach we present in this thesis. JCodeOdor is
realized by a set of components that handle the different parts of the pro-
posed detection approach (module 1 of JCodeOdor in Figure 2), and that
show detected code smells to the users (module 2 of JCodeOdor in Figure
2).
We decide to realize two different tools, because a part of the work we do
for code smells detection is useful also for other tasks (e.g., analysis of the
metrics of software quality). For this reason, we developed DFMC4J as a
library that can be used in more applications and different contexts.

Parser & Compiler JCodeOdor


Thresholds
Eclipse Datastore
ASTs Code Smells Detector
JDT

Java
Code
Harmfulness Manager
Information Extraction

Abstract
Metrics Execution Engine Filters Manager
Model
Results & Views
Metrics Data

COLORS LEGEND:

DFMC4J

JCodeOdor

Figure 1: JCodeOdor and DFMC4J Architecture Overview

18
Chapter 3. JCodeOdor and DFMC4J Architecture

MODULE 2:
Detection Results Code Smell Views
Results
Presentation

Harmfulness Visualization
Manager Manager MODULE 1:
Thresholds Thresholds Code
Datastore Handler Smells
Filters
Detector Detection
Manager

JCodeOdor
DFMC 4J

AST Hybrid Model Source Code


Visitors Visitors Visitors Compiler
MODULE 4:
Information
Extraction
Job Controller Source Code Parser

Information Handler Binding Handler MODULE 3:


Information
Handling

Model Handler Model Manager


MODULE 2:
Model
Model Serialization Handling
Model CRUD Cache Manager
Manager

Source Code
and Code MODULE 1:
Informat ion Model Datastore Data
Model Storage

Figure 2: JCodeOdor and DFMC4J Architecture Detailed

In the following, we discuss the modules in more detail, describing the com-
ponents that realize the modules functionalities. We start our description
discussing DFMC4J (see Section 3.2.2) and the model we use to store the
information extracted from source code (see Section 3.2.1). Then we discuss
JCodeOdor, showing the “service” that DFMC4J offers to the applications
realized on top of it.
19
Chapter 3. JCodeOdor and DFMC4J Architecture

3.2.1 Source Code and Code Information Model


The first module of DFMC4J in Figure 2 implements data storage
functionalities through the Source Code and Code Information Model (in
the following DFMC4J Model). Figure 3 and Figure 4 present an overview
of the DFMC4J Model, in particular the part more related to the Java pro-
gramming language. Abstraction from source code to a model is useful to
enable the scalability to other languages, is useful to fast and easy retrieve
the already computed information, to enable the modularity of computations
(e.g., we can store an information in a way that can be used by all other
computations that need it) and to use less data to represent source code,
retaining only the information useful to perform computation tasks.
We use as starting point the model implemented in MARPLE 6 [133], which
share some common elements with FAMIX [40]. As reported by Zanoni in
[133], “The meta-model entities are subdivided in different categories, rep-
resenting logical or physical entities of the system […]” . Referring to
CodeElement package in Figure 3, Project, Package, CompilationUnit and
the entities deriving from Code Entity are logical entities, Resource, Direc-
tory and File are physical entities. In the following, we discuss the main
features of the model. Refer to Appendix A1 for all the implementation de-
tails.

6
MARPLE is an Eclipse plugin for the recognition of software architectures and of design
patterns inside Java programs. It is developed by the Evolution of Software SystEms and
Reverse Engineering (ESSeRE) laboratory where I did my internship .
20
Chapter 3. JCodeOdor and DFMC4J Architecture

Figure 3: DFMC4J Model – Overview of Code Elements

21
Chapter 3. JCodeOdor and DFMC4J Architecture

Figure 4: DFMC4J Model – Code Information


22
Chapter 3. JCodeOdor and DFMC4J Architecture

Code Elements
Figure 3 gives an overview of the Code Elements. All the entities of the
DFMC4J Model inherit ProjectComponent (i.e., a generic entity of the pro-
ject). They all have a snapshotTimestamp that stores the last update time of
the entity. This timestamp is useful when the model is used during the de-
velopment phase, when the entities are evolving and we have to decide if
the measures stored in the model are up to date. Related to the logical enti-
ties there are CodeInformation entities (Figure 4), representing all the meta-
data not directly belonging to the source code or the project structure, such
as Metrics. CodeInformation can be stored and mapped to the relative Meas-
urable, which represent an entity of the project on which it is possible to
measure something.

Code Information
Figure 4 shows the available CodeInformation, the relation among them and
the mapping from a CodeInformation to the related Measurable. The main
CodeInformation entities are DesignInformation and Metric.

DesignInformation
A DesignInformation represents generic qualitative information associated
to a Measurable. It optionally has a PositionInformation and involves zero
or more other Measurable. A PositionInformation collects data for finding
a DesignInformation in the source code. The involved Measurables are de-
scribed using a map (StringToMeasurableMapEntry), where the key repre-
sents the reason on the involvement and the value is a list of one or more
involved Measurable. A usage example in a InterClassDesignInformation
(i.e., a specialized DesignInformation) is the data related to the detection of
the Feature Envy [51] code smell (i.e., methods that make extensive use of
another class). With this map, we can keep more information, such as ex-
ternal attributes of the class that is used by the method, in a flexible way.
The InterClassDesignInformation has an additional relation (respect to its
superclass), which directly maps the Measurable on which it is computed
to one or more related Measurables.

23
Chapter 3. JCodeOdor and DFMC4J Architecture

Metrics
A Metric represents quantitative information computed on a Measurable. It
is contained by the Measurable on which it is computed.

Enhancements to the MARPLE Model


With respect to the MARPLE Model [133], the main enhancements are that
we add more details on the model (e.g., DesignInformation, LocalVariable),
we extend the model to use it during the development phase (e.g., we add a
state to track the computed CodeInformation), we enable the serialization
and we create a standalone version of the model (i.e., a .jar library).

3.2.2 Design Features and Metrics Computation for Java


Design Features and Metrics Computation for Java (DFMC4J) is a
tool we implement to support the core functionalities needed to extract in-
formation and compute metrics on source code. In Figure 2, modules two,
three and four represent the components realizing DFMC4J. We design
DFMC4J to be integrated as a library in other projects. For this reason, we
decide to hide as much as possible the steps needed to compute the infor-
mation on source code. The user can only ask for information with a direct
getInformation interaction, if he needs information on a specific entity, or
a computeInformation interaction, if he needs to compute some data on a
set of specific entities (e.g., all the classes of a system). Figure 5 shows the
components of DFMC4J and their interactions. In the following, we explain
the main components and their role.

Model Handler
The Model Handler is the central component of DFMC4J. It acts as a medi-
ator, and is the entry point of all calls to DFMC4J. Model Handler delegates
to Information Handler the decoding of information from the source code
point of view to the DFMC4J Model point of view. Model Manager manages
the interactions with the entities of the model and with Job Controller, ask-
ing for the computation of CodeInformations if they are not already present
or updated on the model (Figure 7).

24
Chapter 3. JCodeOdor and DFMC4J Architecture

Model Visitors Source Code


Compiler

Hybrid Visitors Job Controller


Source Code Parser

AST Visitors

Binding Handler
Model Handler

Information Handler

Model Model Manager Model CRUD


Datastore

Model Serialization
Cache Manager Model
Manager

ARROWS LEGEND: COLORS LEGEND:


Function call Application Logic
Data response Model Handling
Model access Information Handling
Datastore access Data Storage

Figure 5: DFMC4J Components Interactions

Information Handler and Binding Handler


The Information Handler manages the extraction of information from ASTs
[140] to a set of datatypes used to exchange the details about entities of the
model among the components. We have five datatypes that correspond to
CodeElements: DecodedPackage, DecodedType, DecodedMethod, Decod-
edAttribute, DecodedLocalVariable, and one datatype that corresponds to
CodeInformation: DecodedDesignInformation. The Information Handler
has an important role, because extracting the information from the source
code is not a simple task. In order to accomplish its role, the Information
Handler interacts with the Binding Handler that is responsible for resolving

25
Chapter 3. JCodeOdor and DFMC4J Architecture

the binding of ASTs’ nodes. “A binding represents a named entity in the


Java language. The world of bindings provides an integrated pictur e of the
structure of the program as seen from the compiler's point of view” [140].

Model Manager and others Model Handling Components


The Model Manager is the component that manages the interaction with the
entities of the model. It collaborates with the Cache Manager that stores the
mapping between source code elements and already created model elements
(for Project, Package, Type, Method, CompilationUnit, Directory), with the
Model CRUD that performs Create, Read, Update, Delete operations on the
entities of the model and with Model Serialization Manager that serializes
the model on a datastore.

Concurrent Access to the Model Entities


The Model Manager also has the responsibility to manage the concurrent
access to the model entities. DFMC4J is designed to parallelize as much as
possible the computation. The Job Controller does this, which is able to
execute more computations in parallel. Since different computations may
involve the same entities of the model, it is necessary to manage concurrent
access to them. We decide to implement the concurrent access using the
Java ReentrantReadWriteLock [148]. We use this type of lock because we
need to allow many readers access the model at a time, as most of our com-
putations access different data on the model but write only once. Reen-
trantReadWriteLock also allows us to get a read lock inside a write lock,
which is a common situation if we have to add information on an entity that
depends on some data on another entity.

Consistency of the DFMC4J Model


Given that the model has a set of containment relations, a set of constraints
to assure the consistency of the entities, we have to manage the consistency
of the model, and we do this in the Model Manager component. For exam-
ple, if we have to add a ComplexType, we first need to create its Package,
the CompilationUnit, and the declaring ComplexType, if existing. When we
need to create some entities to assure the consistency, if the entity that we

26
Chapter 3. JCodeOdor and DFMC4J Architecture

need to create depends itself from other entity, the process is iterated until
all the entities are created and the model is consistent.

Job Controller and Visitors


When a user asks Model Handler for a CodeInformation which is not yet on
the model, the Model Handler relies on the Job Controller to compute them.
Figure 6 and Figure 7 respectively show the main interactions among
DFMC4J components when the requested CodeInformation is already pre-
sent (or not) on the model.
The Job Controller is a component developed by a colleague of mine, Ales-
sandro Marino, during his Master Thesis [95]. It interacts with a set of com-
ponents developed by us: Source Code Parser, Source Code Compiler, AST
Visitors, Model Visitors, Hybrid Visitors, Binding Handler, and the Model
Handler. The Job Controller’s main responsibilities are:

1. Managing of the computation of CodeInformation in a multi-


thread manner, to efficiently scale on large projects;
2. Resolving the dependencies among the computation of CodeIn-
formation (e.g., the computation of Lines Of Code (LOC) of a
package, depends on computation of LOC on all the classes inside
the package).

Visitors
AST Visitors, Model Visitors, and Hybrid Visitors manage the computation
of CodeInformation. The name “visitor” is due to the use of the Visitor
Pattern by the Eclipse JDT [140] used to implement AST Visitors and some
Hybrid Visitors; we use this name also for Model Visitors because they visit
the model to compute the information. Each visitor has the responsibility of
the computation of only one CodeInformation. This is fundamental to ena-
ble the reuse of computed CodeInformation by other visitors (see Chapter 4
for details about the visitors we implement and the relations that link the
CodeInformation each other) and to enable DFMC4J to be open and easily
expandable with other computations.

27
Chapter 3. JCodeOdor and DFMC4J Architecture

AST Visitor
The AST Visitor visits the AST structure of a source code entity, extracts or
computes information on it, and asks the Model Handler to store the com-
putation results on the model. Some AST Visitors needs to resolve binding
to perform the computation, hence they need to interact with the Binding
Handler.

Model Visitor
The Model Visitor starts its visit from an entity of the DFMC4J Model,
computes information on it, and asks the Model Handler to store the com-
putation results on the model.

Hybrid Visitor
The Hybrid Visitor visits the AST structure of a source code entity or an
entity of the DFMC4J Model, extracts or computes information on it, and
asks the Model Handler to store the computation results on the model.

Visitors Dependencies
We define a protocol to support the dependencies declaration among visi-
tors. Given the Current-Visitor, which is the visitor where we have to de-
clare the dependencies, we define its dependency, which specifies the set of
data we have to compute before of the current one. The set of dependency
information are declared in terms of:

 Dep-Visitor: The visitor that calculates the information on which the


Current-Visitor depends on;
 Dep-Entity: The entity (e.g., a class) of the source code or of the
DFMC4J Model where to execute the Dep-Visitor. We can also de-
clare the characteristics of the entity (e.g., only the non-abstract clas-
ses);
 Dep-Level: The set of Dep-Entity of the project where to execute the
Dep-Visitor (e.g., all the classes of the project). The Dep-Level can
be also the current entity (i.e., the entity on which the Current-Visitor
is called), or the entity that contains the current entity (e.g. , the class
that contains current method).

28
Chapter 3. JCodeOdor and DFMC4J Architecture

A visitor can compute the CodeInformation on different entities. We use the


protocol to express the dependencies for each visit operation the visitor per-
forms (e.g., the LOC can be computed for Method, ComplexType, Package,
and Project). Table 4 shows all the entities AST Visitor and Model Visitor
can actually visit. Hybrid Visitor can visit the union of the entities supported
by the other two kinds of visitor.

Table 4: Entity the Different Types of Visitors Can Visit

Visitor Type Entity Visitor can visits


Project, Package, Compilation Unit, Class, Nested
AST Visitor Class, Anonymous Class, Interface, Enumeration, An-
notation, Method, Member of an Annotation
Model Visitor Project, Package, ComplexType, Method

Dependencies Declaration Details


To set the dependencies of a Current-Visitor we have to declare:
 Dep-Visitor
 Dep-Entity
 Dep-Level

We have to declare Dep-Visitor, Dep-Entity, and Dep-Level for each entity


the visitor can visit and information on which it depends.

Dep-Visitor
The Dep-Visitor is the visitor that calculates the information on which the
Current-Visitor depends. The set of Dep-Visitor consists of all the Design
Information and Metrics we discuss in Chapter 4.

Dep-Entity
The set of Dep-Entity (i.e., 𝐷𝑒𝑝 − 𝐸𝑛𝑡𝑖𝑡𝑖𝑒𝑠) that can be defined is

𝐷𝑒𝑝 − 𝐸𝑛𝑡𝑖𝑡𝑖𝑒𝑠 ≝
(1)
{𝑃𝑟𝑜𝑗𝑒𝑐𝑡, 𝑃𝑎𝑐𝑘𝑎𝑔𝑒, 𝐶𝑜𝑚𝑝𝑖𝑙𝑎𝑡𝑖𝑜𝑛𝑈𝑛𝑖𝑡, 𝑇𝑦𝑝𝑒, 𝑀𝑒𝑡ℎ𝑜𝑑,
𝐴𝑛𝑛𝑜𝑡𝑎𝑡𝑖𝑜𝑛𝑇𝑦𝑝𝑒𝑀𝑒𝑚𝑏𝑒𝑟}

29
Chapter 3. JCodeOdor and DFMC4J Architecture

The Dep-Entity defines the entity on which the Dep-Visitor has to be exe-
cuted. For example, if a Current-Visitor that computes LOC on a class has,
as Dep-Visitor, LOC with 𝐷𝑒𝑝 − 𝐸𝑛𝑡𝑖𝑡𝑦 = 𝑀𝑒𝑡ℎ𝑜𝑑, it means that the visitor
depends on LOC executed on Method.

Dep-Level
The set of Dep-Level (i.e., 𝐷𝑒𝑝 − 𝐿𝑒𝑣𝑒𝑙𝑠) that can be defined contains the
same elements of 𝐷𝑒𝑝 − 𝐸𝑛𝑡𝑖𝑡𝑖𝑒𝑠. The Dep-Level declares the set of Dep-
Entity of the project where to execute the Dep-Visitor.

Dependencies Declaration Example


Consider the LOC visitor as Current-Visitor. The LOC visitor computes the
Lines Of Code and can be executed on Method, ComplexType, Package, and
Project. For each one of the four entities we declare the dependencies using
the defined protocol. Table 5 shows the details concerning the dependencies
declaration.

Table 5: DFMC4J Visitors Dependencies Declaration Example

Current-Visitor: LOC

Method Dependencies

Dep-Visitor: - Dep-Entity: - Dep-Level: -

Class Dependencies

Dep-Visitor: - Dep-Entity: - Dep-Level: -

Package Dependencies

Dep-Visitor: LOC Dep-Entity: Type Dep-Level: Package

Project Dependencies

Dep-Visitor: LOC Dep-Entity: Package Dep-Level: Project

If we want to execute the Current-Visitor on the Project, the declared de-


pendencies specify that we have to execute the Dep-Visitor LOC on Pack-
ages of the Project. When we have execute the Dep-Visitor LOC on Pack-

30
Chapter 3. JCodeOdor and DFMC4J Architecture

ages of the Project, the declared dependencies specify that we have to exe-
cute the Dep-Visitor LOC on Types of the Packages. At the end of the de-
pendencies resolution the execution order is:

1. Dep-Visitor LOC on Types of the Packages;


2. Dep-Visitor LOC on Packages of the Project;
3. Current-Visitor LOC on the Project.

We use 𝐷𝑒𝑝 − 𝐸𝑛𝑡𝑖𝑡𝑖𝑒𝑠 defined in equation (1) for all the three types of
visitors. Table 6 shows the mapping between 𝐷𝑒𝑝 − 𝐸𝑛𝑡𝑖𝑡𝑖𝑒𝑠 elements, pro-
ject elements, and DFMC4J Model entities.

Table 6: DFMC4J Visitors Dependencies Set

Dep-Entities element Project element Model entity


Project Project Project
Package Package Package
CompilationUnit Compilation Unit CompilationUnit
Class, Nested Class, ComplexType
Anonymous Class,
Type
Interface, Enumera-
tion, Annotation [56]
Method Method Method
Method of a Com-
plexType with a
AnnotationTypeMember Member of an Anno-
typeDefinition
[140] tation
equal to Annota-
tion.

Visitor Applicability
Some CodeInformation can be only computed on specific types of an entity.
The Depth Of Inheritance Tree (DIT), for example, cannot be computed on
an Anonymous Class by definition. We declare this type of constraints de-
fining the Applicability for each type of visit of the visitor. The Applica-
bility is defined as the set of entities (e.g., package, class, and methods) of
the source code or of the DFMC4J Model where the Current-Visitor can be
31
Chapter 3. JCodeOdor and DFMC4J Architecture

executed. The set of all possible Applicability elements is the same as 𝐷𝑒𝑝 −
𝐸𝑛𝑡𝑖𝑡𝑖𝑒𝑠. We can also specify the type of the entity, e.g., only private meth-
ods.
The Applicability is particularly useful during dependencies resolution, to
determine automatically on what type of entities a Dep-Visitor can be exe-
cuted, and collect only the correct entities from source code, accordingly.
Table 7 shows an example of Applicability declaration related to the previ-
ously shown example.

Table 7: DFMC4J Visitors Applicability Declaration Example

Current-Visitor: LOC

Method visit

Applicability: All the methods.

Class visit

Applicability: All the classes.

Package visit

Applicability: All the packages

Project visit

Applicability: Project

Job Controller Execution Graph


The Job Controller, given the CodeInformation to compute and the entity
to analyse, reads all the dependencies of the involved visitors, checks for
already computed information (interacting with the Model Handler), and
builds a directed acyclic graph, where the vertices are visitors to be exe-
cuted on a specific entity and the edges are the dependency relations among
them. Once the graph is built, the Job Controller begins the computation
starting from the vertices with an in-degree equals to zero, and executes all
the visitors following the dependency relations among them.
During the building of this graph, the Job Controller needs to interact with
the Source Code Parser and the Source Code Compiler, to obtain the Com-

32
Chapter 3. JCodeOdor and DFMC4J Architecture

pilationUnits on which to compute the requested information and the Com-


pilationUnits containing the entities to be analysed by the Dep-Visitors.
From the set of Compilation Units, the Job Controller obtains all the entities
on which to execute the computation (see Table 4) with a set of visitors that
collects them visiting the ASTs of the Compilation Unit or of a specific
entity. If, for example, we need all the methods of a specific class, we find
the Compilation Unit that declares the class, and then we collect the meth-
ods.

Source Code Parser


The Source Code Parser parses the source code of a single Java file, a pack-
age, or an entire Java project and converts them into a set of Compilation
Units. The parsing relies on the Eclipse JDT ASTParser [140] and offers a
set of related functionalities:
 collects all the Java files and jar files to set the environment used
during the parsing;
 automatically it sets the code version (e.g., Java 7) from a given
compiled class of the project;
 enables the options to recover corrupted statements and to obtain the
bindings;
 collects, and returns to the caller, the set of warnings and errors en-
countered during the parsing, properly formatted to be simply
mapped to the corresponding source code lines.

Source Code Compiler


Parsing the source code is not enough to guarantee the ability to resolve all
the bindings during the computation of CodeInformation. We have to check
for source code compilability. The Source Code Compiler does this job.
Also the Source Code Compiler relies on Eclipse JDT [140] and performs
all the steps needed to compile the source code:
 it constructs the compilation environment (i.e., Compilation Units of
the project and all the classes inside the jars needed to compile the
project);
 it collects the Compilation Units to compile;
 it sets the compiler options;
33
Chapter 3. JCodeOdor and DFMC4J Architecture

 it collects, and returns to the caller, the set of warnings and errors
encountered during the compilation process.

The Source Code Parser and Source Code Compiler have also an internal
cache storing the Compilation Units and the timestamp of the last save of
the corresponding Java file at a time of creation. We use a cache because
we need to use DFMC4J also during development, and in this way, we op-
timize the number of Java files that we have to parse and compile.

Figure 6: DFMC4J Sequence CodeInformation on the Model 7

7
The External User represents a system that uses DFMC4J as a library (e.g., JCodeOdor).
34
Chapter 3. JCodeOdor and DFMC4J Architecture

Figure 7: DFMC4J Sequence CodeInformation Not on the Model 7

35
Chapter 3. JCodeOdor and DFMC4J Architecture

3.2.3 JCodeOdor
JCodeOdor is the design flaws detector we implement on top of
DFMC4J library. JCodeOdor components implement the code smells detec-
tion approach we describe in Section 6.2, except the code smells detection
strategies with default thresholds (see Chapter 6), which are integrated in
DFMC4J as CodeInformation computed by Model Visitors. We decide to
integrate the detection strategies in DFMC4J, to allow other projects that
use DFMC4J library to detect code smells using our strategies. Figure 8
shows the relations among JCodeOdor components in Figure 2.

Code Smell Views Detection Results

Thresholds Harmfulness
Thresholds
Handler Manager
Datastore

Visualization Detector Filters Manager


Manager

JCodeOdor
DFMC 4J

Model Handler

ARROWS LEGEND: COLORS LEGEND:


Function call Application Logic
Data response Presentation
Datastore access

Figure 8: JCodeOdor Components Interactions

The currently implemented prototype of JCodeOdor is mostly suited to be


used to evaluate the code smells detection effectiveness of our detection
36
Chapter 3. JCodeOdor and DFMC4J Architecture

approach. For this reason, it actually misses some components, which we


will add in the next version, interacting with the Eclipse IDE [139] to mon-
itor the development process and automatically update the detection results .
Figure 9 shows the detection approach steps.

Thresholds Handler sets the thresholds value for each code smell

Detector asks Model Handler to detect code smell

Filters Manager applies filters

Harmfulness Manager computes harmfulness for each code smell

Detection Results shows the detection results

ON USER REQUEST:

Visualization Manager builds the views for selected code smell

Code Smell Views shows the views to the user

Figure 9: JCodeOdor Detection Approach Steps

In the following, we discuss the components in Figure 8.

Detector
The code smells detection starts with the Detector component that first asks
the Thresholds Handler for the thresholds of each code smell to detect (see
Chapter 5) and then requests to the Model Handler component the compu-

37
Chapter 3. JCodeOdor and DFMC4J Architecture

tation of code smells on specific entities or on the entire project under anal-
ysis. DFMC4J implements the detection strategies described in Chapter 6
that use a set of metrics with specific threshold values. The Detector, before
asking for computation writes these thresholds on a configuration file, if
they differ from the default ones, and each code smell visitor reads them
before performing the detection. We decide to use a configuration file to set
the thresholds to easily update their values if needed, because, as described
in Chapter 5, setting the thresholds is a difficult and sensible task. After the
detection is performed, the Model Handler, along the detection results, re-
turns for each detected code smell the values for each metric used by the
detection strategy. These values are useful to compute the harmfulness of
the detected code smells by the Harmfulness Manager.

Harmfulness Manager
The harmfulness is an index about how much each code smell is harmful
compared to the other code smells of the same type, and it is estimated using
the information we compute on a set of reference systems (see Section 5.2).
This justifies the interaction between Harmfulness Manager and Thresholds
Handler. We detail how we compute Harmfulness in Section 6.2.2.

Filter Manager
Before presenting the results of the detection, the Detector interacts with
the Filter Manager, which performs some filtering operations on the code
smells detection results, using information asked to Model Handler. As we
deeply discuss in Section 6.2.3, there are some entities, detected as code
smells, which completely match the code smell definitions, but that we do
not consider relevant to show to the user because they do not represent a
real problem for the system quality. Refer to Section 6.2.3 for the role of
Code Smell Filters.

Presentation of the Detection Results 8


At the end of the detection approach, the Detector asks the Detection Re-
sults component to show the code smells detection results to the user. The

8
We do not implement yet the Detection Results and the Visualization Manager compo-
nents, but we detail their design and user interfaces, that we use to present detected code
smells to the users.
38
Chapter 3. JCodeOdor and DFMC4J Architecture

results are enriched with all the data collected during the previous steps.
We detail them in Section 6.2.4, along with the options that the user can set
to personalize them. Starting from each detected code smell, the user can
ask JCodeOdor to show a view that graphically describes all the facet s of
the detected code smell, to increase the user's understanding about the de-
tected problem.

Visualization Manager 8
The view is built by the Visualization Manager, which asks the Model Han-
dler for the information it needs to build it, given the code smell to visual-
ize. As we discuss in Section 6.2.5, each code smell has its own personalized
set of views, because each code smell captures different characteristics of
the project design. Thanks to DFMC4J, we can build these views using the
information stored in the model during the code smells detection process
and ask the Model Handler to compute some data to enable the user to better
understand the impact of the code smell on the rest of the system. Once the
Visualization Manager has collected all the information useful to build the
views, it asks the Code Smell Views component to show them.

39
Chapter 4
Measurement of Software Design

The measurement of software design quality is a fundamental task of the


development and assessment process. Lack of measurement brings the risk
of losing control on the system’s evolution, with the consequent losses in
terms of maintenance time. Metrics are an instrument to realize this meas-
urement [35]. To properly exploit them, metrics are generally organized and
used in a quality model. In this chapter, we discuss how we select the met-
rics we use to measure systems components. We define the relations among
them that allow their computation, expressed using the protocol we imple-
mented in DFMC4J. In appendices B1 and B2, we define the metrics and
other information we compute, and discuss how we compute them.

4.1 Quality Model


Our aim is the measurement of the design quality of object -oriented
systems. The design of object-oriented systems has different characteristics,
like: size, complexity, cohesion, coupling, inheritance and encapsulation
[22][60][77]. In order to select a proper set of metrics to be used fo r code
smells detection, we refer to the literature to identify some quality models
that have been proposed for code smell detection or quantitative measure-
ment of object-oriented software design characteristics.
The models we refer to, and we use to select a proper set of metrics, are the
ones defined by:

1. R. Marinescu et al., in “Quantifying the Quality of Object-Oriented


Design: the Factor-Strategy Model” [94], proposes a model that pro-
vides explicit mappings between metrics and quality criteria. The au-
thors propose a method to define explicit and formal rules quantifia-
ble to measure software quality, relying on code smells. By using

40
Chapter 4. Measurement of Software Design

code smells, the authors offer a more abstract level of interpretation


than individual metrics do.
2. Bansiya et al., in “A hierarchical model for object-oriented design
quality assessment” [12], introduce QMOOD, a hierarchical quality
model dedicated to the assessment of object-oriented software design
quality. Useful contributions of this work are: the identification of
specific design properties for the object-oriented paradigm (e.g., pol-
ymorphism, data abstraction, hierarchies), a mapping of design p rop-
erties to quality attributes (like reusability, flexibility and compre-
hensibility), and a mapping of quality attributes to design metrics.
3. F. Balmas et al., in “The Squale Quality Model” [11], proposes a
model inspired by the factors-criteria-metrics model (FCM) by
McCall in [97]. The authors call the model SQUALE and provide a
bottom-up approach, aggregating low-level measures into more ab-
stracted quality elements.

Starting from the three referenced quality models, we identify six funda-
mental categories of object-oriented software quality metrics, related to
code smells characteristics:

 Size: measures the size of systems in terms of lines of code, number


of packages, classes, methods, and so on. The larger the system, the
more difficult it is to manage.
 Complexity: measures the degree of difficulty in understanding the
internal and external structure of classes [12]. More complex the
classes are, more difficult it is to understand them.
 Cohesion: assesses the relatedness of methods and attributes in a
class [12]. Cohesiveness of methods within a class is desirable since
it promotes encapsulation, and lack of cohesion implies that classes
should probably be split into two or more sub-classes [41].
 Coupling: defines the interdependency of an object on other objects
in a design. It is a measure of the number of other objects that wou ld
have to be accessed by an object to function correctly [12]. There-
fore, the stronger the coupling between objects, the more difficult
these objects are to understand, to change, and to correct.

41
Chapter 4. Measurement of Software Design

 Encapsulation: is defined as the enclosing of data and behaviour


within a single construct. In the object-oriented paradigm the prop-
erty specifically refers to designing classes that prevent access to
attribute declarations by defining them to be private, thus protecting
the internal representation of the object [12]. Lack of encapsulation
in classes, leads to unauthorized parties of the system direct access
to them.
 Inheritance: measures the “is-a” relationship between classes. This
relationship is related to the level of nesting of classes in an inher-
itance hierarchy [12]. More deep is the class in the system inher-
itance hierarchy, more it is difficult to understand , because of the
inherited methods and attributes from the ancestor classes.

4.2 Design Metrics and Design Information


Fenton et al. stated: “Measurement is the process by which numbers
or symbols are assigned to attributes of entities in the real world in such a
way as to describe them according to clearly defined rules” [45]. In the
context of software systems, the entities we measure are, e.g., methods,
classes and packages. Metrics, instead, represent the clearly defined rules
that assign a number to attributes (or properties) of entities.
We define two kinds of measurement for the properties of software ent ities:

1. Design Metric:

A design metric represents a quantitative information computed on


an entity of a project (e.g., class, method). A design metric measures
one or more properties of a project entity.

2. Design Information:

A design information represents a generic qualitative information as-


sociated to an entity of a project (e.g., class, method). A design in-
formation is an information extracted from the source code of a pro-
ject that represent characteristics of the project related to its design ,
as presented in Chapter 4.

42
Chapter 4. Measurement of Software Design

We identify a set of design metrics for each of the six categories of object-
oriented software quality we discuss in the previous section. To select rel-
evant metrics, we refer to well-defined and accepted metric suites proposed
in the literature [2][22][39][81], and to published works concerning the ca-
pability of the metrics to predict defects [1][119][122], faults [13][36][57],
maintainability [31], and change [69].
We add also other metrics, defined in this work, to bet ter capture properties
of entities useful to understand if they are affected by code smells or not.
The metrics we add are generally slight variations of metrics al ready de-
fined in the literature.
The metrics we select, categorized with respect to the qual ity dimension
they measure, are reported in Table 8, while their discussion is reported in
Section 4.2.3. The metrics we identify with “*” are defined by us.

Table 8: List of Design Metrics Computed by DFMC4J

Encapsulation

Inheritance
Complexity

Coupling
Cohesion
Size

LOC CYCLO TCC FANOUT NOAM DIT


LOCNAMM * WMC LCOM5 FANIN NOPA NOI
NOPK WMCNAMM * ATFD LAA NOC
NOCS AMW FDP NMO
NOM AMWNAMM * RFC NIM
NOMNAMM * MAXNESTING CBO NOII
NOA WOC CFNAMM *
CLNAMM * CINT
NOP CDISP
NOAV MaMCL *
ATLD * MeMCL *
NOLV NMCS *
CC
CM

43
Chapter 4. Measurement of Software Design

All the metrics we select from the literature comply with the following re-
quirements:

 well-known and accepted in industry and/or in the academic litera-


ture;
 well-defined and unambiguous computation algorithm.

Design metrics often measure the same properties of entities from different
points of view; for example, the number of public methods and the number
of non-public methods measure something related to methods, but from two
different points of view. Some metrics are defined in terms of mathematical
functions combining other metrics, e.g., average or sum.
We introduce the concept of design information to characterize the infor-
mation related to the properties of entities, used by the metrics. Table 9 list
the design information we compute and the quality dimension they repre-
sent, while their discussion is reported in Section 4.2.2.

Table 9: List of Design Information Computed by DFMC4J

Quality Dimension List of Design Information


Size Declared Classes
Attributes Of Class
Methods Declared In Class
Cohesion Called Methods (Called Intra Methods, Called Hi-
erarchy Methods)
Used Variables (Used Intra Variables, Used Hier-
archy Variables)
Used Types (Used Intra Types, Used Hierarchy
Types)
Coupling Called Inter Methods
Used Inter Variables
Used Inter Types
Called Classes
Calling Methods
Message Chains Info 9

9
A design information that we use to collect some information underlying the detection
of Message Chains code smell (refer to Section 6.3.6)
44
Chapter 4. Measurement of Software Design

Inheritance Parent Class


Ancestor Classes
Children Classes
Implemented Interfaces
Overridden Methods
Inherited Methods

We use this information also in our detection approach we discuss in Chap-


ter 6 (e.g., to apply filters to the code smells detection results).

4.2.1 Design Metrics and Design Information Dependencies


DFMC4J allows specifying dependencies among design metrics and
design information (refers to Section 3.2.2). Figure 10 shows an example of
dependency between the FANIN metric and other design information.

Dependency
from A to B

Methods B
Declared In Class

Called Inter A
Methods

Called Hierarchy
Methods

Calling Classes

FANIN

Figure 10: Design Metrics and Information Dependencies Example


FANIN is the “Number of calling classes”, that is the number of other clas-
ses of the system calling at least one method of the measured one. We com-
pute FANIN as the sum of the Calling Classes design information, so the

45
Chapter 4. Measurement of Software Design

latter must be computed before the former. Calling Classes depends from
others design information (i.e., Methods Declared In Class, Called Inter
Methods, and Called Hierarchy Methods), as defined in Table 75 in Appen-
dix B1 . After the computation of FANIN and its dependencies, each of them
is stored in the model, enabling the reuse of the performed analysis.

When we describe the design information and the design metrics in Appen-
dix B1 and B2 respectively, we use the dependency declaration protocol.

4.2.2 Design Information Definitions


The design information we define and extract from source code con-
cern different properties of software entities:

 structure and size of classes and methods, e.g., declared classes, at-
tributes of the classes, methods declared by the classes;
 inheritance relations, e.g., extended classes, implemented interfaces,
overridden and inherited methods by the classes;
 coupling relations, e.g., coupled class, called methods by another
method);
 cohesion details, e.g., variable of the class a method uses.

The code smells we compute are defined as a particular type of design in-
formation, as we discuss in Chapter 3. We omitted them from the previous
list because we report their detailed definition in Chapter 6.

For the details about the definitions, and about how we compute the design
information refer to Appendix B1.

4.2.3 Design Metrics Definitions


In this section, we report an overview of the design metrics we com-
pute on the source code, for each one of the quality dimension we present
in Table 8. For the details about the definitions and how we compute all the
design metrics, refer to Appendix B2.

46
Chapter 4. Measurement of Software Design

Size
We measure the size of the project using the number of lines of code, the
number of packages and the number of classes. The size measures we pro-
pose are, for the classes: number of methods, number of attributes and lines
of code; for the methods, we compute the lines of code.

Complexity
We implement some metrics to measure methods functional complexity: cy-
clomatic complexity, nesting level of control constructs (e.g., if, while, for,
switch). Some metrics measure complexity to understand the methods (e.g.,
number of parameters, number of local variable). Other complexity
measures refer to the classes’ functional complexity.

Cohesion
We implement, to measure cohesion: Tight Class Cohesion, which is a
measure of the cohesion of the public interface of a class (i.e., excluding
private methods), and Lack of Cohesion in Methods, which computes cohe-
sion considering all methods, private or not.

Coupling
We implement several coupling measures for classes and methods. For clas-
ses, we measure the incoming coupling using the FANIN metric, which rep-
resents the coupling introduced by the classes calling the measured class,
and the outgoing coupling using the FANOUT metric, which represents the
coupling introduced by the measured class calling other classes of the sys-
tem. We also measure the coupling introduced by the use of data belonging
to classes different from the measured one (e.g., Access to Foreign Data,
Foreign Data Provider).

Encapsulation
The measures we propose for encapsulation refer to the way other classes
have to access the data from measured class: we measure the number of
public attributes and the number of public methods.

47
Chapter 4. Measurement of Software Design

Inheritance
The inheritance measure we implement is the depth of inheritance tree, and
others regarding the use that a class makes of inheritance: number of imple-
mented interface, number of inherited methods, and number of overridden
methods.

We use most of the design metrics we define for our code smells detection
approach (see Chapter 6); others are useful to describe properties of entire
systems (e.g., number of classes, number of packages and so on), and others
are used by Alessandro Marino, a colleague of mine, during his Master The-
sis work: “Code Smell Detection Through Machine Learning Techniques
and Metrics Analysis” [95]

4.3 Design Metrics and Information Validation


Software metrics computation is subject to error, like any other ac-
tivity. The most common error is the possible deviation of the computation
algorithm from the definition. When we define the way we compute soft-
ware design metrics in Appendix B2, we face the problem of choosing the
elements of the Java language to consider (or not) for the computation of
the metric, given its definition. Often the metric definition does not explic-
itly declare, for example, if to consider or not constructors of a class when
computing a cohesion metric [79]. For this reason, in Appendix B2 , we try
to be as clearer as possible with respect to these details. Another factor that
introduces a difference between the metric definition and its computation is
the algorithm itself, which has to be verified. We tested the computatio n of
all design metrics and design information we defined. We use as a reference
test system the popular “Personal Lending Library”, a small sample appli-
cation to manage a personal library of books [37]. We report its class dia-
gram in Figure 11.

48
Chapter 4. Measurement of Software Design

Figure 11: Personal Lending Library Example 10

We took the source code of this example system from [70] and we modified
it to add all the elements we need to validate the design metrics and the
design information. The elements we added are: more packages, chained
calls, inheritance hierarchies, methods overriding and overloading, complex
functionalities like search algorithms and most of the elements of Java 7
[56], like interfaces, abstract classes, annotations, enumerations, classes
nested in other class or in methods, anonymous classes, type casting, gener-
ics, static blocks. In the rest of this section, we discuss how we perform the
validation for the most relevant design metrics and design information.

Design Information

We rely on Eclipse JDT [140] to implement visitors that visit the source
code and collect design information. We verify the correctness of design
information computation referring to the JDT ASTNode hierarchy, which is
an abstract superclass of all Abstract Syntax Tree (AST) node types. An
AST node represents a Java construct, such as a name, type, expression,
statement, or declaration [140]. We check that all the data described by the
ASTs hierarchy’s classes are extracted.
For some other design information, like Overridden Methods and Inherited
Methods, we refer to The Java® Language Specification [56] to realize the
computation algorithm. For this type of design information, we check also

10
We report the class diagram as presented in [37]
49
Chapter 4. Measurement of Software Design

the computation according the definition and the examples reported on The
Java® Language Specification.

Design Metrics

We define different types of software metrics, belonging to different object-


oriented software quality dimensions. Among them, there are some whose
computation is simply a count, a sum or an average computed from design
information or other design metrics. Others, e.g., Tight Class Cohesion
(TCC), are more complex to compute and are more subject to bias from the
definition. For this type of metric, we check for the correctness of compu-
tation, after we ensure the correctness of the design information and design
metrics they depend on, by checking the obtained result on different entities
of the example system we use.
We are discussing now the validation we perform for the more algorithmi-
cally complex metric we implement: TCC.

Tight Class Cohesion (TCC)


“TCC is the normalized ratio between the number of methods directly con-
nected with other methods through an instance variable and the total num-
ber of possible connections between methods. A direct connection between
two methods exists if both access the same instance variable directly or
indirectly through a method call. TCC takes its value in the range [0,1]”
[41]

We describe the computation details in Table 97 in Appendix B2. In the


following, we report only the fundamental definitions and equation:

Maximum number of possible connections (NP):


𝑁∗(𝑁−1)
𝑁𝑃 = , where 𝑁 is the number of visible methods.
2

Number of direct connections (NDC):

NDC: is computed using an NxN connectivity matrix that records all direct
connected methods. Its cells have value 1 if two methods are connected and
0 otherwise. NDC is the sum of the cells of the lower half matrix except the
diagonal.

50
Chapter 4. Measurement of Software Design

The value of TCC is computed as:


𝑁𝐷𝐶
{𝑇𝐶𝐶 = 𝑁𝑃
𝑁𝑃 ≠ 0
𝑇𝐶𝐶 = 1 𝑁𝑃 = 0

We verify the correctness of the computation for all the cases shown in
Figure 12. Each case corresponds to a class with four methods (m 1 , m 2 , m 3 ,
m 4 ) and four attributes (a 1 , a 2 , a 3 , a 4 ), where each method accesses zero or
more attributes and calls zero or more other methods. We identify these
cases because they cover the access to attributes of a class both directly and
through accessor methods.

Class 1 Class 2 LEGEND:

attributes
a1 a4 a1 a4
a1 a2

m1 m4 m1 m4 m1 m2

Class 3 Class 4 methods

attribute access
a1 a4 a1 a4

a1
m1 m4 m1 m4

m1
Class 5 Class 6

a1 a4 a1 a4 method call

m1 m4 m1 m4 m1 m2

Class 7 Class 8

a1 a4
a1 a4

m1 m4
m1 m4

51
Chapter 4. Measurement of Software Design

Class 9

a1 a4

m1 m4

Figure 12: Test Cases for TCC Computation Validation

We describe in Table 10 the verification we do, along with the expected and
obtained result, and a detail of the computation. 𝑁𝑃 is the same for all the
classes because we have always four methods:
4∗(4−1)
𝑁𝑃 = =6
2

Table 10: Validation of TCC Design Metric

Class Computation Expected and Ob-


tained Result
1
Class 1 𝑁𝐷𝐶 = 1: m 1 and m 2 both accessing a 1 𝑇𝐶𝐶 =
6
Class 2 𝑁𝐷𝐶 = 2: m 1 and m 2 both accessing a 1 , 1
𝑇𝐶𝐶 =
m 3 and m 4 both accessing a 4 3

Class 3 𝑁𝐷𝐶 = 2: m 1 and m 2 both accessing a 1 , 1


𝑇𝐶𝐶 =
m 2 and m 3 both accessing a 3 3

Class 4 𝑁𝐷𝐶 = 3: m 1 and m 2 both accessing a 1 ,


m 2 and m 3 both accessing a 3 where m 2 1
𝑇𝐶𝐶 =
access a 3 trough m 3 , m 3 and m 4 both ac- 2
cessing a 3 where m 4 access a 3 trough m 3 .
1
Class 5 𝑁𝐷𝐶 = 1: m 1 and m 2 both accessing a 1 𝑇𝐶𝐶 =
6
Class 6 𝑁𝐷𝐶 = 4: m 1 and m 2 both accessing a 1 ,
m 1 and m 4 both accessing a 2 , m 2 and m 3 2
𝑇𝐶𝐶 =
both accessing a 3 , m 3 and m 4 both ac- 3
cessing a 4 .
Class 7 𝑁𝐷𝐶 = 3: m 1 and m 2 both accessing a 1 ,
1
m 2 and m 3 both accessing a 1 , m 1 and m 3 𝑇𝐶𝐶 =
2
both accessing a 1.
52
Chapter 4. Measurement of Software Design

Class 8 𝑁𝐷𝐶 = 3: m 1 and m 2 both accessing a 1 ,


a 2 and a 3 , m 2 and m 3 both accessing a 1 , 1
𝑇𝐶𝐶 =
a 2 and a 3 , m 1 and m 3 both accessing a 1 , 2
a 2 and a 3.
Class 9 𝑁𝐷𝐶 = 4: m 1 and m 2 both accessing a 1 ,
m 1 and m 3 both accessing a 2 , m 2 and m 3 2
𝑇𝐶𝐶 =
both accessing a 3 , m 3 and m 4 both ac- 3
cessing a 4 .

4.4 Conclusion and Discussion


We refer to the literature of well-defined design metrics suites, and
to the literature of software quality models that use both code smells and
software design metrics, to describe software quality. We identity a set of
well-defined and accepted design metrics measuring different aspects of an
object-oriented software:

 size (e.g., number of methods of a class);


 complexity (e.g., maximum nesting level of control structures);
 cohesion (e.g., tight class cohesion);
 coupling (e.g., number of calls to other classes in the s ystem);
 encapsulation (e.g., number of public attributes of a class);
 inheritance (e.g., depth of inheritance tree).

We discuss how we implement metrics computation using the protocol we


implement in DFMC4J (see Section 3.2.2). The implemented protocol al-
lows expressing dependencies among metrics. We use dependencies rela-
tions to compute metrics in a scalable way, reusing already computed infor-
mation and storing on the DFMC4J model the abstract representation of
some source code elements that represent the starting point for computation
of many design metrics (e.g., attributes and methods of a class).
We define and discuss computation details of the selected metrics and in-
formation stored on DFMC4J model in appendices B1 and B2.

53
Chapter 5
Determining Metric Thresholds

In this chapter, we discuss the problem of metrics thresholds derivation, and


we present the method we propose to derive thresholds for software design
metrics in the context of code smells detection. We use common fractions
(e.g., fraction like 1⁄2) to derive thresholds for metrics defined as ratio of
values, and an automated method to empirically derive metrics thresholds
from the measurement of a benchmark of software systems, for metrics de-
fined in ℝ or ℕ. Respect to metrics defined in ℝ or ℕ, we first pool and
aggregate the measurement data for different software systems . Then we
derive five different thresholds that (i) respect the statistical properties of
the metric, i.e., its distribution and (ii) help focusing on the most interesting
values. We aggregate the measurement data in a customized way based on
the code smell we derive thresholds for.

5.1 Problem Statement


When we deal with software metrics, and use them as a base point
to evaluate software quality, we must know what is too high or too low.
Metrics, by themselves, do not mean anything: we need some reference val-
ues, to be used as thresholds. Setting a threshold allows to correctly inter-
pret the values we compute on a software system, so that we can evaluate
its quality. Sadly, some problems arise when identifying thresholds. The
most important one is the generality of the identified thresholds. A thresh-
old value can be good in a setting, but we cannot be sure that it is good in
every setting.
In the literature, we can find many proposed approaches to derive metrics
thresholds. Many authors define metric thresholds according to their expe-
rience [25][96][105]. Some other authors face the thresholds computation

54
Chapter 5. Determining Metric Thresholds

using metric analysis. Often these analyses assume that the metrics are nor-
mally distributed [44], but we, and other experts [27][82][131], experiment
that it is not true in most cases (refer to Section 5.2.4). Shatnawi et al. [118]
and Benlarbi et al. [15] try to find thresholds investigating the correlation
of the metrics with the existence of bugs or failures. All the cited methods
have some shortcoming. Deriving thresholds from experience makes them
difficult to generalize to different software system. Wrongly assuming nor-
mality leads to the use of wrong statistical techniques (e.g., the 3 -sigma rule
identifies 16% of the observations as indicating potential problem). Finally,
the two approaches that derive thresholds from the correl ation with bugs or
failures generally are valid only for a specific error prediction model and
lack generality.
One of the most recent work in the area of thresholds derivation is the one
by Alves et al. in [3]. The authors propose a solid and well-defined method
for deriving metrics thresholds. The thresholds are derived with sys -tem
maintainability evaluation in mind. The main characteristics of the method
proposed by Alves et al. in [3] are:

 the method should not be driven by expert opinion but by measure-


ment data from representative set of systems (data-driven);
 the method should respect the statistical properties of the metric,
such as metric scale and distribution and should be resilient against
outliers in metric values and system size (robust);
 the method should be repeatable, transparent, and straightforward to
carry out (pragmatic).

In the rest of this chapter, we detail and discuss our method for threshold
derivation for code smells detection, that starts from the baseline posed by
the approach by Alves et al. in [3].

55
Chapter 5. Determining Metric Thresholds

5.2 Code Smells Metrics Thresholds Derivation


We develop a method to derive metrics thresholds for code smells
detection. We distinguish two ways of computing thresholds based on the
characteristics of the metric under analysis:

 Common Fraction Thresholds (or CFT, see Section 5.2.2);


 Benchmark-Based Thresholds (or BBT, see Section 5.2.3).

The difference is due to the existence of some metrics, like TCC, that are
defined in terms of normalized ratio with a well-defined semantics, and
other metrics (e.g., LOC) having their values on an interval of the extended
real number line (i.e., ℝ or [−∞, +∞]) or of the natural number line (i.e.,
ℕ0 ).

The rest of this chapter is organized as follows: in Section 5.2.1 we define


the thresholds we derive for code smells detection; in Section 5.2.2 we de-
scribe the approach to derive CFT thresholds, in Section 5.2.3 we introduce
our method to derive thresholds (BBT) from a benchmark of software sys-
tem; in Section 5.2.4 we discuss some consideration an threats to validity
of the proposed BBT derivation method.

5.2.1 Code Smells Metrics Thresholds Definition


Code smells define some properties of software design that should
be identified in the system to capture potential problems. The defined prop-
erties are often in the form of “identify classes that have LOW cohesion” or
“identify methods that have a VERY-HIGH complexity”. We want to derive
thresholds in a way that they can be semantically mapped to these informal
requirements, to find out what LOW cohesion or VERY-HIGH complexity
means in terms of the metrics we use to measure cohesion and complexity
of the software system.
With this need in mind, we compute, for each metric, a set of five thresholds
that identifies five points on the metrics distribution, for BBTs, and five
points among common fractions for CFTs.

56
Chapter 5. Determining Metric Thresholds

We define a threshold using three attributes:

 a name or label;
 a corresponding percentile (for BBT), or a corresponding common
fraction (for CFT);
 a type.

We use the name to refer to a threshold with a semantic meaning. The names
we use for the five thresholds are: VERY-LOW, LOW, MEAN, HIGH,
VERY-HIGH. VERY-LOW represents the lowest threshold, while VERY-
HIGH the highest one. We call VERY-LOW and VERY-HIGH extreme
thresholds.
The corresponding percentile, or 𝑇ℎ𝑃𝑜𝑖𝑛𝑡, is the point on the reference set
of points (i.e., the percentiles of the metrics distribution) representing where
to find the value for the given threshold (i.e., 𝑇ℎ𝑉𝑎𝑙𝑢𝑒).
The corresponding common fraction is the 𝑇ℎ𝑃𝑜𝑖𝑛𝑡 on the reference set of
common fractions, that represents where to find the value for CFTs ( i.e.,
𝑇ℎ𝑉𝑎𝑙𝑢𝑒).
Each threshold is mapped to a value by the function 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 =
𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑇ℎ𝑃𝑜𝑖𝑛𝑡). 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 is the threshold used for comparing other val-
ues of the metric.
As part of our code smells detection approach, described in Chapter 6, we
offer to the user the possibility of hardening or softening thr esholds values.
Hardening or softening threshold values is useful because of the difficulty
to generalize the obtained thresholds to all the possible software systems;
we offer to the user the possibility of moving thresholds to achieve more or
less strict constraints.

The type allows us to define different typologies of thresholds for each


name/label, based on the selection we do in these sense. We define three
possible types of thresholds:

 Default: the default selection we offer to the user;


 Harden: the set of thresholds we offer to the user when he wants to
try to reduce the number of entities evaluated as affected by a code
smell;

57
Chapter 5. Determining Metric Thresholds

 Soften: the set of thresholds we offer to the user when he wants to


try to raise the number of entities evaluated as affected by a code
smell.

When we set Harden and Soften, we have to refer to the characteristics of


the metric and to the property of the system we want to measure, to under-
stand if they have a direct or inverse correlation. To select properly the
threshold we refer always to the definition we give in Appendix B2, in par-
ticularly to the “Worse” attribute, and to the detection strategies we define
for each code smell in Chapter 6.
As for example, consider the LOC metric and a generic 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 correspond-
ing to the HIGH threshold. If we want to capture “class with a HIGH number
of lines of code”, we can compare LOC and 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 using: 𝐿𝑂𝐶 ≥
𝑣𝑎𝑙𝑢𝑒𝑂𝑓(HIGH). Hardening the threshold in this situation means that we
have to select a greater 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 for the HIGH threshold, so that the number
of entities that exceeds the threshold can be reduced. Conversely, if we want
to capture “class with a LOW number of lines of code”, we can compare
LOC to the 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 corresponding to the LOW threshold: 𝐿𝑂𝐶 ≤
𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝐿𝑂𝑊). Here hardening the threshold means that we have to select
a lower 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 for the LOW threshold, so that the number of entities that
exceeds the threshold can be reduced.

In Sections 5.2.2 and 5.2.3, we discuss in details the attributes of the thresh-
olds we defined, based on the way we derive thresholds (i.e., Benchmark -
Based Thresholds or Common Fraction Thresholds).

5.2.2 Common Fraction Thresholds


Some metrics are defined as normalized ratio with well -defined se-
mantics. Consider for example the Tight Class Cohesion (TCC) metric, de-
fined as:

“TCC is the normalized ratio between the number of methods directly c on-
nected with other methods through an instance variable and the total num-
ber of possible connections between methods”

58
Chapter 5. Determining Metric Thresholds

The higher the TCC, the more cohesive the class. For this type of metrics,
when we think at a LOW value it is common to refer to values l ower than
or equal than 1⁄3 that in the case of TCC means that utmost 1⁄3 of the
possible method-method connection of the class is present. Fractions like
1⁄3 or 1⁄2 are defined as common fraction by Lanza et al. [75]. We use
metrics like TCC in some of the detection strategies we define in Chapter 6
for code smells detection: TCC for God Class, Weight Of A Class (WOC),
and TCC for Data Class and Coupling Dispersion (CDISP) for Dispersed
Coupling 11. Because all these metrics are defined as a normalized ratio in
the [0,1] interval and we use common fractions, the 𝑇ℎ𝑃𝑜𝑖𝑛𝑡, and conse-
quently the 𝑇ℎ𝑉𝑎𝑙𝑢𝑒, we define are the same for all the metrics. Table 11
shows the detailed description for all the type of thresholds we define. Ob-
viously, when we refer to Hardened and Softened thresholds we cannot di-
rectly use common fractions as defined by Lanza et al. [75]. Anyway, as we
always rely on fractions in the same range, the technique is consistent.

Table 11: Common Fraction Thresholds Definition

Name or Label
VERY- VERY-
LOW MEAN HIGH
LOW HIGH
Type: Default

ThPoint 1⁄ 1⁄ 1⁄ 2⁄ 3⁄
4 3 2 3 4
ThValue 0.25 0.33 0.50 0.66 0.75

Type: Harden (DCO) / Soften (TCC, WOC)

ThPoint 1⁄ 19⁄ 3⁄ 71⁄ 3⁄


4 50 5 100 4
ThValue 0.25 0.38 0.60 0.71 0.75

Type: Harden (TCC, WOC) / Soften (DCO)

ThPoint 1⁄ 7⁄ 2⁄ 61⁄ 3⁄
4 25 5 100 4
ThValue 0.25 0.28 0.40 0.61 0.75

11
Respect to the metrics defined in Chapter 4, the only one we do not use and that belong
to this type of metrics is LAA.
59
Chapter 5. Determining Metric Thresholds

The way we select Hardened and Softened thresholds consists in moving


the MEAN ThPoint by 1⁄10 to the right or to the left and then LOW and
HIGH ThPoint by 1⁄20 in the same direction.
The VERY-LOW and VERY-HIGH thresholds points and values are the
same for all types because they are extreme threshold we use as reference
points to some part of our detection approach (e.g., harmfulness computa-
tion, described in Section 6.2.2), but we do not use them for code smells
detection strategies.

5.2.3 Benchmark-Based Thresholds (BBT)


The most sensible part of our method is the one for Benchmark-
Based Thresholds derivation. Most of the metrics we define in Chapter 4
have as range of possible values an interval of the extended real line (i.e.,
ℝ or [−∞, +∞]) or of the natural number line (i.e., ℕ0 ), most of the times
from zero on. For this reason, we define a method to derive thresholds, to
be used in the code smells detection context, from a dataset of software
systems used as benchmark. The starting point of our method is the one
proposed by Alves et al. in [3], which follows three core requirements: data-
driven, robust and pragmatic.
We fully agree with these requirements, so we decided to follow these re-
quirements, to develop a method for computing metrics thresholds using a
benchmark of systems. We cannot follow directly the method proposed by
Alves et al. in [3] because the proposed method is suited for system main-
tainability evaluation, and assumes the system to be completely developed.
In the context of code smells detection, we have to identify code smells also
in a system that does not exist in all its parts, hence, for example, we cannot
use measures at system level (e.g., the LOC of system).
The method we propose allows us to compute in an automated way thresh-
olds that are customized based on the code smell for which we have to use
the metric we are deriving the threshold to. We add some requirements to
the method proposed by Alves et al., because each code smell affects spe-
cific types of entities (e.g., only public methods), and we want to gather
knowledge to compute thresholds only from the entities that can be a code
smell. We develop a method that is as automatic as possible, because we
need to add more systems to the benchmark during time to gather more
60
Chapter 5. Determining Metric Thresholds

knowledge. Hence, we need a method that is scalable and requires a slight


manual effort for deriving thresholds. Figure 13 shows the main steps of the
method we propose and a description of the output of each step.

1. Metrics Computation

Metrics values for


classes and methods

2. Metrics Aggregated Distribution


Analysis

Percentiles of the interesting


part of the metrics distribution

3. Metrics Thresholds Derivation

MEAN

Figure 13: Benchmark-Based Thresholds Derivation

Step 1: Metrics Computation

The first step consists of identifying a set of systems to be used as a bench-


mark, and computing the metrics values (code smells metrics set in the fol-
lowing), for all the entities that can be affected by the code smell we ana-
lyse 12. The systems we select as a benchmark are the ones from the Qualitas
Corpus, a curated collection of 111 open source systems created by Tempero
et al. [125]. refer to this set of software systems because the authors did a
great work in selecting and curating this set of software systems , suited for

12
Refer to Chapter 6 for all the details regarding code smells detection
61
Chapter 5. Determining Metric Thresholds

performing empirical studies. The main and most useful characteristics of


the Qualitas Corpus are that:

 The systems are written in Java;


 The systems are of different sizes in terms of LOC;
 The systems belong to different application domains (e.g., graphics,
IDE, database, visualization, parser, testing and others);
 The systems have a significant history of development;
 The authors added to each system a set of useful metadata, like:
o core: the list of packages representing only classes that have
been written for the system, e.g., not classes from external
libraries (often included in the source code of the downloaded
systems);
o status: an indication of the development status of the system;
o releasedate.

To apply our method and derive meaningful thresholds we need the system
to be compilable. The Qualitas Corpus does not guarantee compilability of
the systems, so we had to verify it and fix encountered problems. This pro-
cess reduced the number of considered systems from the 111 composing the
Qualitas Corpus (version 20120401r) to 74 systems that we were able to
compile (refer to Appendix C1 for the complete list). Approximately, only
20 systems compile without changes, while for the others we have to fix
some problems. The most common problems are missing libraries and syn-
tax errors. To solve the first problem we refer to the build file, if present,
or to the metadata Tempero et al. define for each system [125].
We use the metadata from the Qualitas Corpus to consider only the “ core”
for our analysis, to select and compute metrics only for the most representa-
tive parts of the systems. During the manual evaluation of the systems to
solve compilation problems, we also removed all the test packages we were
able to identify, and that Tempero et al. [125] do not remove.

We rely on DFMC4J to compute all the metrics we use for our code smells
detection approach and to save the systems model on a database, using the
Model Serialization Manager component. To analyse the metrics in an effi-
cient way we save them also on a separate database where we report only
62
Chapter 5. Determining Metric Thresholds

the information to unambiguously identify the entities and the correspond-


ing metric values.
At the end of the metrics computation step, we obtain a benchmark database
for each code smell (benchmark datasets in the following) containing only
the entities that can be affected by the code smell and the values for all the
metrics that are part of the code smells metrics set. As for example, the
Shotgun Surgery code smell refers to methods that are called by many other
methods and classes in the system (see Section 6.3.4). Shotgun Surgery
clearly cannot affect a private method, so in the benchmark dataset for Shot-
gun Surgery we do not add the private methods and the related metrics.

Step 2: Metrics Aggregated Distribution Analysis

At the end of step 1, we obtain, for each code smells metrics set, an aggre-
gated set of values related to entities belonging to many systems. We ag-
gregate, separately for each metric, all the values obtaining an
𝐴𝑔𝑔𝑟𝑒𝑔𝑎𝑡𝑒𝑑𝐷𝑖𝑠𝑡𝑟𝑖𝑏𝑢𝑡𝑖𝑜𝑛, and we plot the Inverse Cumulative Density
Function (i.e., the Quantile Function (𝑄𝐹)) for the aggregated metric distri-
bution of each system. There are many methods to estimate the quantiles of
a population and define the 𝑄𝐹. We refer to the one proposed by the Na-
tional Institute of Standards and Technology (NIST) on [137]. We plot the
entire 𝑄𝐹 and the ones cropped at 70%, 80% and 90%, because most of the
metrics 𝑄𝐹𝑠 have greater variability in these sections of the chart (Figure
14 shows the ones for LOC of classes cropped at 90%).
The 𝑄𝐹 represents on the x-axis the percentage of observations (e.g., per-
centage of classes in Figure 14), and on the y-axis the observed variable
values (e.g., the values of LOC in Figure 14).
We use the Quantile Function to have a quick look at the aggregated distri-
bution of the metrics. Most of the metrics in the code smells metric set have
a common heavily skewed distribution: most of the values are thickened in
a small portion of the possible values, the one closest to the lowest quan-
tiles.
The Quantile Function makes this fact clear because it grows very slowly
for most of the quantiles (the lowest ones), and for the other part it grows
very fast. In Appendix C2 we report some statistics useful to have an over-
view of the distribution for all the metrics we consider.
63
Chapter 5. Determining Metric Thresholds

Figure 14: Aggregated LOC Metric Quantile Chart Cropped at 90%

If we use this distribution to derive the five thresholds we need using com-
mon statistics approaches (e.g., the boxplot approach by Norman et al. [45]),
we run in the risk of obtaining values that do not well identify problematic
entities, because, e.g., the lower thresholds (e.g., VERY-LOW, LOW) are
often equal to the lowest value the metric can have (e.g., zero for LOC). For
this reason, we define an automatic method to select the point of the metric
distribution where the variability among values starts to be fairly high, and
we use it as the starting point for deriving thresholds.

Finding Interesting Part of the Aggregated Metric Distribution

Given the 100 percentiles we can obtain from the Quantile Function, that
span from 0.01 to 1 with a step of 0.01, we select a point of the 𝑄𝐹 from
where the 𝑄𝐹 has a significative variability in terms of adjacent correspond-
ing values ( 𝑆𝑡𝑎𝑟𝑡𝑃𝑡 ). We proceed in the same way for all the code smells
metrics set, because we notice that all the metrics have a heavily skewed
distribution, similar to the one in Figure 14.

64
Chapter 5. Determining Metric Thresholds

Assuming a continuous and weakly monotonic distribution 𝐹 : ℝ → (0,1],


like the ones we have for the considered metrics 13, the Quantile Function is:

𝑄𝐹 (𝑝) = 𝑖𝑛𝑓 {𝑥 ∈ ℝ ∶ 𝑝 ≤ 𝐹(𝑥)}

where 𝐹 (𝑥) = 𝑃 (𝑋 ≤ 𝑥), and 𝑋 is a random variable representing the metric.


For a probability 0 < 𝑝 ≤ 1, 𝑄𝐹 (𝑝) returns the minimum value of 𝑥 for
which 𝑝 ≤ 𝐹 (𝑥). The returned value represents the value below which ran-
dom draws from the given distribution would fall 𝑝 ∗ 100 percent of the
time. We refer to this value also using the 𝑄 𝐹′ : (0,100] → ℝ, that is the
quantile function with the percentiles defined in a scale from one to 100
( 𝑃𝑡 ), to refer them in a clearer way:
𝑃𝑡
𝑄𝐹 ′ (𝑃𝑡) = 𝑄𝐹 ( ) ∀ 0 < 𝑃𝑡 ≤ 100
100
Given the set of values of 𝑄𝐹 ′ , our automatic method searches for a 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙
value in this way:

𝑣 = 𝑛𝑢𝑙𝑙
𝑤ℎ𝑖𝑙𝑒 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙 𝑖𝑠 𝑛𝑜𝑡 𝑠𝑒𝑡
𝑖𝑓 𝑖𝑠𝐸𝑚𝑝𝑡𝑦(𝑑𝑒𝑠𝑐𝑒𝑛𝑑𝑖𝑛𝑔𝑂𝑟𝑑𝑒𝑟(𝑄𝐹 ′ ))
𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙 = 𝑣
𝑒𝑙𝑠𝑒
𝑣 = 𝑝𝑜𝑝(𝑑𝑒𝑠𝑐𝑒𝑛𝑑𝑖𝑛𝑔𝑂𝑟𝑑𝑒𝑟(𝑄𝐹 ′ ))
𝑖𝑓 𝑓𝑟𝑒𝑞(𝑣) <= 𝐸𝑞𝑢𝑎𝑙𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝑃𝑡
𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙 = 𝑣
𝑒𝑛𝑑 𝑖𝑓
𝑒𝑛𝑑 𝑖𝑓
𝑒𝑛𝑑 𝑤ℎ𝑖𝑙𝑒

where:

 𝑖𝑠𝐸𝑚𝑝𝑡𝑦 and 𝑝𝑜𝑝 are default stack operations;

 𝑑𝑒𝑠𝑐𝑒𝑛𝑑𝑖𝑛𝑔𝑂𝑟𝑑𝑒𝑟(𝑄𝐹 ′ ) is the set of values of 𝑄𝐹 ′ sorted according


to the descending order;

13
There may be "flat spots" in the Cumulative Density Function range
65
Chapter 5. Determining Metric Thresholds

 𝑓𝑟𝑒𝑞(𝑣) is the frequency of value 𝑣 in 𝑄𝐹 ′ ;

 𝐸𝑞𝑢𝑎𝑙𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝑃𝑡 is:

∑𝑣∈𝑄𝐹′ 𝑓𝑟𝑒𝑞(𝑣)
𝐸𝑞𝑢𝑎𝑙𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝑃𝑡 =
|𝑄𝐹 ′ |
𝐸𝑞𝑢𝑎𝑙𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝑃𝑡 is the 𝑓𝑟𝑒𝑞 of values of 𝑄𝐹 ′ if we equally distribute
them on the 100 percentiles. Consequently, ∑𝑣∈𝑄𝐹′ 𝑓𝑟𝑒𝑞(𝑣) is always 100
because we have 100 percentiles among which to distribute the values.
Given 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙, we search for the first percentile assuming the 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙
value:

𝑆𝑡𝑎𝑟𝑡𝑃𝑡 = argmin 𝑄𝐹 ′ (𝑃𝑡) = 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙


0<𝑃𝑡≤100

We then select the values (𝑆𝑒𝑙𝑒𝑐𝑡𝑒𝑑𝑉𝑎𝑙𝑢𝑒𝑠) from the entire set of metric
values (i.e., the AggregatedDistribution) such that:

𝑆𝑒𝑙𝑒𝑐𝑡𝑒𝑑𝑉𝑎𝑙𝑢𝑒𝑠 = 𝑣 ∈ 𝐴𝑔𝑔𝑟𝑒𝑔𝑎𝑡𝑒𝑑𝐷𝑖𝑠𝑡𝑟𝑖𝑏𝑢𝑡𝑖𝑜𝑛 ∶ 𝑣 ≥ 𝑄𝐹′(𝑆𝑡𝑎𝑟𝑡𝑃𝑡).

In this way, we obtain our reference distribution for thresholds computa-


tion. The computation of 𝑆𝑡𝑎𝑟𝑡𝑃𝑡 is useful to understand what part of the
initial aggregated metric distribution we consider at the end of this process.
Figure 15 shows an example of the computed 𝑆𝑡𝑎𝑟𝑡𝑃𝑡 = 75, corresponding
to the 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙 = 8, for the NOM metric that represents the number of meth-
ods of a class. 𝑆𝑡𝑎𝑟𝑡𝑉𝑎𝑙 is selected because:

 𝑑𝑒𝑠𝑐𝑒𝑛𝑑𝑖𝑛𝑔𝑂𝑟𝑑𝑒𝑟(𝑄𝐹 ′ ) = {674, 60, 42, 34, 29, 25, 23, 21, 19,

17, 16, 15, 14, 13, 12, 11, 10, 9, 𝟖, 7, 6, 5, 4, 3, 2, 1, 0}

 with corresponding frequencies 𝑓𝑟𝑒𝑞 = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

1, 1, 1, 1, 2, 2, 2, 3, 𝟑, 4, 4, 6, 8, 10, 14, 26, 2}


∑𝑣∈𝑄𝐹′ 𝑓𝑟𝑒𝑞(𝑣) 100
 𝐸𝑞𝑢𝑎𝑙𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝑃𝑡 = |𝑄𝐹′ |
= = 3.70
27

66
Chapter 5. Determining Metric Thresholds

Figure 15: NOM 𝑺𝒕𝒂𝒓𝒕𝑷𝒕 and 𝑺𝒕𝒂𝒓𝒕𝑽𝒂𝒍

Using this method, we exclude all the metric values that are common among
entities, so that the obtained distribution contains (mostly) the values that
can be considered interesting references to identify the entities that could
be affected by code smells. Figure 16 shows the obtained reference distri-
bution for the NOM metric. The obtained distribution is still skewed be-
cause of the extreme values, but it grows faster and in the case of NOM it
represents the top higher 25% values of the initial AggregatedDistribution.

Alves et al. [3] too, as part of their method, select a part of the distribution
where to pick dangerous reference values for a metric. They do this work
by hand, and highlight the problem of identifying those points according to
the metric distribution. Alves et al. use 70th, 80th, and 90th percentile as
common choice and then they adapt the selection based on metric distribu-
tion. Our method executes this task in an automated way, achieving valid,
and sometime similar to Alves et al., results.

67
Chapter 5. Determining Metric Thresholds

Figure 16: NOM Reference Distribution

Step 3: Metrics Thresholds Derivation

From the reference distribution we obtain at the end of step 2, we compute


the Quantile Function (𝑄𝐹) and then we derive five thresholds for each of
the three types we define: Default, Harden, and Soften. Table 12 shows how
we select the values that respect the distribution of the metric. Also for this
type of metrics, the selection for Harden and Soften thresholds depends on
the metrics definition and the use we do of them. In Table 12 we assume
that the metric gets worse for higher values and we want to find entities that
have a high value for that metric.

Table 12: Benchmark-Based Thresholds Definition

Name or Label
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

68
Chapter 5. Determining Metric Thresholds

Type: Harden

ThPoint 10 30 60 80 90

Type: Soften

ThPoint 10 20 40 70 90

The way we select Harden and Soften thresholds consists on moving the
MEAN ThPoints by 10 percentiles to the right or to the left and the LOW
and HIGH ThPoints by five percentiles in the same direction. Because we
select the thresholds moving the percentiles, there is no guarantee that the
corresponding 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 is different. We proceed in this way because we
want to respect the metric distribution; anyway, for most metric the
𝑇ℎ𝑉𝑎𝑙𝑢𝑒𝑠 change. As for the CFT, the VERY-LOW and VERY-HIGH
thresholds percentiles are the same for all types because they are extreme
thresholds we use as reference points in some part of our detection approach
(e.g., harmfulness computation), but that we do not use for code smells de-
tection strategies.
The 𝑇ℎ𝑉𝑎𝑙𝑢𝑒 depends on the particular metric. Appendix C3 reports all the
thresholds along with the 𝑇ℎ𝑉𝑎𝑙𝑢𝑒𝑠 we set for the six code smells we inves-
tigate.

Thresholds Recalibration

Our method derives thresholds using the percentile from the Quantile Func-
tion. When we pick the values for the five thresholds we define, it can hap-
pen that the values of two or more thresholds are the same, also when refer-
ring to the output of step 2. This situation is a problem for both the seman-
tics associated with the metric (e.g., if we have LOW, MEAN and HIGH
thresholds with the same value it makes no sense), and the code smells de-
tection approach we discuss in Chapter 6 (e.g., for Code Smell Harmfulness
computation).
We develop an automatic thresholds recalibration method to mitigate this
problem. The values we try to obtain are the ones that differ as little as
possible from the values assigned to the thresholds before the recalibration.

69
Chapter 5. Determining Metric Thresholds

We perform the recalibration by moving the percentiles assigned to the


ThPoints on the set of possible percentiles (i.e., from 1 to 100). The proce-
dure tries first to move only the percentiles different from the extreme
thresholds. This is useful to try to represent the same portion of the refer-
ence distribution inside the range delimited by VERY-LOW and VERY-
HIGH thresholds. If this is not possible (i.e., there are not sufficient differ-
ent values), we move all the percentiles, maintaining fixed the MEAN
threshold if there is a sufficient number of different values, until we get five
different values. If there are no sufficient different values among the 100
percentiles, we try to differentiate as much as possible the values, leaving
some duplicate 𝑇ℎ𝑉𝑎𝑙𝑢𝑒.
After recalibration, for all the metrics part of the code smells metrics set,
we succeeded in finding five different 𝑇ℎ𝑉𝑎𝑙𝑢𝑒𝑠 corresponding to five dif-
ferent 𝑇ℎ𝑃𝑜𝑖𝑛𝑡𝑠.

5.2.4 Considerations and Threats to Validity of BBT Method


We now discuss some considerations and threats to validity of the “Bench-
mark-Based Thresholds” derivation method we propose.

Considerations about Selected Percentiles and Code Smells Detect.


We set five thresholds to enable all the steps of our code smells detection
approach. When we define code smells detection strategies in Chapter 6 we
do not use the extreme thresholds. The extreme thresholds are defined be-
cause they are useful to set two reference points for other part s of our de-
tection approach (e.g., for Code Smell Harmfulness computation).

Non-Normality of Metrics Distribution


As reported by a large number of work in the literature, we know that , gen-
erally, software metrics distribution is not normal [3][27]. We also verify
that for our benchmark. Knowing if the distribution is normal or not it is
important to identify the statistical approaches and tests we have to use. We
check for normality plotting the Normal Quantile-Quantile plot (Q-Q plot
[55]) of the metric distribution versus the normal distribution. The Q-Q plot

70
Chapter 5. Determining Metric Thresholds

is a graphical method for comparing two probability distributions 14 by plot-


ting their quantiles against each other, in the case of Normal Q-Q plot the
second distribution is the normal one. If the two distributions being com-
pared are similar, the points in the Q-Q plot will approximately lie on the
line 𝑦 = 𝑥 . Figure 17 shows the Q-Q plot for the LOC metric computed on
the classes of Heritrix [32] system. The graphical result we obtain for LOC
metric is similar to the ones for all the metrics in the code smells metric set
for all the systems. Given that the points do not lie on (or near) the line 𝑦 =
𝑥 the distribution cannot be assumed to be normal.

Figure 17: Normal Q-Q plot of LOC of Heritrix Classes

In addition to the Q-Q plot, we use one parametric and one nonparametric
statistical test to automate the normality check. We use the Shapiro-Wilk
(S-W) parametric test [116], mostly suited for small samples [114], and
Kolmogorov-Smirnov (K-S) non-parametric test for goodness of fit [63],
good also for larger samples. We use both methods because we have systems

14
A probability distribution assigns a probability to each measurable subset of the possi-
ble outcomes of a random experiment, survey, or procedure of statistical inference.
71
Chapter 5. Determining Metric Thresholds

of different size in our benchmark. We apply S-W to systems with a sample


size less or equal 5,000 and K-S to systems with a bigger sample size. The
null hypothesis (𝐻0 ) for both the tests is the same: “The samples come from
a normally distributed population”, as well as the alternative hypothesis
(𝐻1 ): “The samples do not come from a normally distributed population” .
All the metrics we have in our code smells metrics set for all the systems
reject the null hypothesis with an 𝛼 = 0.05.

System Metrics Distribution Check


We refer to a set of open source systems from the Qualitas Corpus [125]. In
the context of thresholds derivation from a benchmark of reference systems
it is common to select some open source or commercial system based on
some criteria [3][27][82][131]. The information we have on the selected
systems design quality are generally limited. Because we cannot trust the
systems’ quality and we aggregate metrics values computed on these sys-
tems to derive thresholds, we need to have at least a bird's eye view on their
design and their quality. To accomplish this we use the two-sample Kolmo-
gorov-Smirnov test, for each of the metric in the code smells metrics set.
Our assumption is that the metrics capture and represent some design as-
pects of the systems; hence, they can be considered as a reference to check
for the system’s quality.

Two-sample Kolmogorov-Smirnov test


We use the two-sample Kolmogorov-Smirnov test (K-S test) [53], the two-
sided ones, with an 𝛼 = 0.05 to compute the equality of the metrics distri-
bution between all the pairs of system. The K-S test is a nonparametric test
for the equality of continuous, one-dimensional probability distributions,
which can be used to compare two samples. In our case, the two samples
are the metric values from each pair of systems. The K-S test allows evalu-
ating if the null hypothesis (𝐻0 ):
“The true distribution function of the sample is equal to the distribution
function of the other sample”
is rejected or not respect to the alternative hypothesis (𝐻1 ):
“The true distribution function of the sample is not equal to the distribution
function of the other sample”

72
Chapter 5. Determining Metric Thresholds

The K-S test computes a statistic that quantifies a distance between the em-
pirical distribution functions of two samples, where the empirical distribu-
tion function is “the cumulative distribution function associated with the
empirical measure of the sample” [53].
We decide to use the K-S test because it makes no assumptions about the
underlying distribution of the samples 15, has a high statistical power given
our samples size 16 [112], and it is sensitive to differences in both location
and shape of the empirical cumulative distribution functions of the two sam-
ples. The last property is particularly useful in our case, because the metrics
distribution have similar shapes for most of the systems, but often a differ-
ent location.
We plot in red the Quantile Function of the distribution that does not pass
the K-S test versus any of the other distributions in the benchmarks. We
plot on the same chart, in black, all the distributions that pass the K-S test
versus at least one of the others. Figure 18 shows an example of this plot
for the NOPA (Number of Public Attributes) metric.
We use this plot to have a quick look at the distribution of the systems (and
the underlying data), to select the systems to manually investigate, to check
if they have some problems. Respect to the Figure 18 the only system we
mark in red is Jasml [144] whose NOPA distribution is showed in Figure 19 ,
while all the other systems in the benchmark have distribution similar to the
one shown in Figure 20. The distribution of Jasml differs a lot, as expected,
given that we set the significance level 𝛼 equal to 0.05.

15
We cannot use tests that may be more sensitive (e.g., T -Test) because of non-normality
of the sample distribution.
16
We use metrics computed on classes and/or methods, and the systems we refer to have
a significative number of classes and methods.
73
Chapter 5. Determining Metric Thresholds

Figure 18: Two-sample Kolmogorov-Smirnov Test Plot

Figure 19: Jasml NOPA Distribution

74
Chapter 5. Determining Metric Thresholds

Figure 20: Most Common NOPA Distribution

We analyse all the entities in the part of the distribution having more dif-
ferences (e.g., in Figure 19, from the 30th percentile on) to check if they
represent a well-defined choice or a problem that is present in the system’s
core part (e.g., test classes, prototype classes and so on). At the end of the
process, we did not find any system or entities to exclude, ana lysing only
about 5% of the entities. In Jasml, for example, the NOPA metric differs
because the system has many classes that expose data, which is a well -de-
fined choice.
This is an important step, because, although in our benchmark we found
nothing to exclude (perhaps because the set of systems is curated), in gen-
eral the kind of contents found in software systems is unknown.

Checking for Outliers


In statistics, it is common practice to check for the existence of outliers. An
outlier is an observation whose value is distant relative to a set of observa-
tions. When we check for the distribution of the metrics to be sure that the
system has not problems, we plot the Quantile Function of a given metrics
75
Chapter 5. Determining Metric Thresholds

for all the systems (e.g., like the one in Figure 18). Because during the cited
check we find that the systems in the benchmark do not present problem s,
and also because an outlier exists only if the data comes from a known dis-
tribution with known properties, we do not remove any value among the
ones in the reference distribution.

5.3 Conclusion and Discussion


We develop a method to derive thresholds for two types of software
design metrics:

 defined as normalized ratio in [0,1];


 defined in ℝ or ℕ0 .

For the first type of metrics we select thresholds according to common frac-
tions (e.g., 1⁄2), that identify a point in the [0,1] interval with a well-defined
semantic, with respect to the rationale that defines the metric. We use this
technique for metrics like Tight Class Cohesion (TCC), that is defined as
“the normalized ratio between the number of methods directly connected
with other methods through an instance variable and the total number of
possible connections between methods” [41]. When we think at LOW values
for this metric, we refer to values lower or equal than 1⁄3 fraction, which,
in the case of TCC, means utmost 1⁄3 of the possible method-method con-
nections of the class are present.
For the second type of metrics, whose distributions are often heavily
skewed, we propose an automatic method to derive thresholds. Starting from
metric values computed on a benchmark of software system s, it determines
thresholds that (i) are customized based on the code smell for which we use
the metric, (ii) respects the statistical properties of the metric, such as its
distribution, and (iii) helps focusing on the most interesting metric values.
Both the methods allow us to obtain valid thresholds for a wide range of
different metrics. We use these thresholds in Chapter 6, when we define
code smells detection strategies and information related to the presence of
code smell in the system.

76
Chapter 5. Determining Metric Thresholds

Because of the differences between Benchmark-Based Thresholds, that are


described using percentiles as ThPoints, and Common Fraction Thresholds,
that are described using common fractions as ThPoints, we decide to uni-
form the way we refer to thresholds, to be clear and concise when we refer
to them in the rest of this work (e.g., in Chapter 6). We uniform the ThPoint
of the Common Fraction Thresholds to the percentiles we use for ThPoint
of the Benchmark-Based Thresholds, as exemplified in Figure 21.

Percentiles 17

1 st 2 nd 3 rd 4 th ……… 97 th 98 th 99 th 100 th

1 2 3 4 97 98 99 100
………
100 100 100 100 100 100 100 100

Common Fractions

Figure 21: Mapping between CFT and BBT Reference ThPoint

17
The zero value is not present, but we never refer to it because of the selected thresholds
(see Table 11)
77
Chapter 6
Detection of Design Flaws

In this chapter, we present the JCodeOdor code smells detection approach


and its application on six duly selected code smells. We first discuss the
criteria we use to identify six relevant code smells among the ones already
proposed in the literature. Then we discuss our metric-based code smells
detection approach and we analyse the new features provided to enhance
the detection results quality, usefulness, and comprehensibility, with re-
spect to other detection approaches proposed in the literature. The main
features we add are:

1. a Code Smell Harmfulness, that is an index about how each code smell
is harmful compared to the other code smells and is useful to present
detection results to the user in a prioritized way;
2. Code Smell Filters that we use to refine detection results to remove false
positive code smells, to show to the user only the real code smells;
3. a set of customized views to present code smell main characteristics to
the user.

In the last part of the chapter, we discuss the application of the proposed
detection approach to the six code smells we selected: God Class, Data
Class, Brain Method, Shotgun Surgery, Dispersed Coupling, and Message
Chains.

6.1 Selection of Code Smells


A large number of code smells have been defined. One of the first
and most comprehensive catalogue is the one proposed by Fowler in its book
“Refactoring: improving the design of existing code” [51] in 1999. Fowler
reports a list of 22 code smells 18, they capture potential problems related to
most of the object-oriented software quality dimension discussed in Chapter
18
Refers to Table 161 in appendices C2 for code smells definitions.
78
Chapter 6. Detection of Design Flaws

4 and of the Coad and Yourdon four essential traits of a good object -ori-
ented design [23], namely: low coupling, high cohesion, moderate complex-
ity and proper encapsulation. After Fowler’s work, who reports only an in-
formal definition and possible refactorings for each code smell, more ex-
perts start to find a way to automatically detect them
[75][84][85][101][102][126]. The automatic code smells detection has
given rise to numerous studies that correlate the presence of code smells to
faults and change-proneness during maintainability. This kind of studies al-
lows us to better understand the capacity of code smells to represent a hint
that something might be wrong, if they remain in the system. We refer to
this type of studies to identify a set of relevant code smells to investigate
and to analyse, and detect using JCodeOdor. Our code smells selection cri-
teria are guided by the aim to give to users a hint on the most dangerous
problems, related to all the four Coad-Yourdon traits. We report the criteria
we take into account, in priority order:

1. Code smells correlation to faults or change-proneness;


2. Code smells numerosity;
3. Object-oriented quality dimension that code smells impact.

To evaluate the first criterion we refer to the literature. Table 162 in Ap-
pendix D2 reports all the papers we refer to, and a short description of the
finding related to the correlation of the code smells to faults and change-
proneness. The most harmful code smells are:

1. God Class (or Large Class);


2. Brain Method (or Long Method);
3. Shotgun Surgery;
4. Message Chains;
5. Dispersed Coupling;
6. Intensive Coupling;
7. Feature Envy

Respect to the evaluation of the second criterion, we refer to our previous


work that investigates the numerosity of code smells in a large dataset of
software system [46] from the Qualitas Corpus [125], and to the only related

79
Chapter 6. Detection of Design Flaws

work we are able to find in the literature [30]. Table 163 in Appendix D3
reports the results of the cited studies. The most numerous code smells are:

1. Data Class;
2. God Class (or Large Class);
3. Shotgun Surgery;
4. Feature Envy;
5. Brain Method (or Long Method);
6. Refused Parent Bequest;
7. Dispersed Coupling;
8. Intensive Coupling;
9. Tradition Breaker;
10. Speculative Generality.

For the third criterion we refer to a work published by R. Marinescu in [90],


extended by us for the relevant code smells and quality dimensions not con-
sidered in his work. Table 164 in Appendix D2 shows the impact on soft-
ware quality dimensions for each code smell we take into account.
From the entire set of code smells, we select the six ones that satisfy our
three criteria. Table 13 shows the list of code smells in priority order.

Table 13: Selected Code Smells

Impacted Object-Ori-
Affected
Code Smell Intra/Inter ented Quality Dimen-
entity
sions
God Class or Coupling, Cohesion,
Class Intra Class
Large Class Complexity, Size
Brain Method or Coupling, Cohesion,
Method Intra Class
Long Method Complexity, Size
Shotgun Surgery Method Inter Class Coupling
Message Chains Method Inter Class Coupling
Dispersed Cou- Coupling, Cohesion,
Method Inter Class
pling Complexity
Encapsulation, Data Ab-
Data Class Class Intra Class
straction

80
Chapter 6. Detection of Design Flaws

In Table 13 for each code smell, we report also if it is an:

 Intra Class code smell: the code smell affects a single entity in the
source code;
 Inter Class code smell: the code smell affects more entities in the
source code.

Some of the code smells reported in Table 13 have different names. This is
because we combined some code smells that can be found in the literature
with similar definition, but with a different name.
The code smell that Fowler [51] considers the most dangerous one, Dupli-
cated Code, is not part of Table 13. This because Duplicated Code is a code
smell that is strongly different respect to most of the ones we considered.
We think, like other experts in this area [136], that Duplicated Code should
be investigated separately from other code smells.

6.2 Detection Approach


The proposed code smells detection approach starts from the idea
presented by Lanza et al. in [75], which is one of the first that do a compre-
hensive work in the area of code smells automatic detection. Starting from
the idea we found in his book, consulting nearly a decade of discussions on
the topic, and elaborating our ideas to improve the quality, usefulness and
comprehensibility of code smells detection results, we develop a detection
approach that take care of users requirements and propose them the potential
problems captured by code smells in a more useful and comprehensive way.
Our detection approach is composed by four parts:

1. A detection strategy that allows to capture the entities affected


by the code smell;
2. A set of Code Smell Filters that identify, among the entities cap-
tured by the detection strategy, the ones that surely or probably
are false positive;
3. Computation of Code Smell Harmfulness for each code smell;
4. A set of views that shows the details about the code smell and its
impact on the system design.

81
Chapter 6. Detection of Design Flaws

Respect to previous works, point one follows the ideas settled by Lanza et
al., except for the details of the detection strategies and how we compute
the thresholds (see Chapter 5). An additional difference respect to previous
works is the introductions of the possibility by the user to select harden or
soften thresholds for the detection strategies. Given a detection strategy and
a set of default thresholds, the user can select to upper or lower them ac-
cording to his perception of the results obtained on the system under devel-
opment. We discuss more details about how it is important to introduce this
feature in Section 6.2.1.
The Filters and the computation of Harmfulness we propose are new in this
context and represent a step forward in the usefulness of code smells detec-
tion results. Respect to step four, we can already find in the literature some
proposed Visualizations, but no one proposes a complete set of views that
enable the user to fully and simply understand the potential problems cap-
tured by the code smell, and that can be personalized for each code smell.
We argue that there is a need to propose a visualization framework that it is
simple to understand by users, enough general to represent all the code
smells and open to be personalized for each code smell. The possibility to
personalize is a key factor because each code smell has its own characteris-
tics and capture different problems in the source code, hence each of them
need a personalized view to present the captured problem s to the users.
We describe details of the implementation of our detection approach for all
the six code smells we select in Section 6.1, that have a lot of differences
among each other.
The proposed detection approach is applicable to the entire catalogue of
code smells. To add a new code smell we need to define the detection strat-
egy, define the set of filters (if needed), and define the personalized views.
Once this is done, the code smell becomes part of the detected code smells
by JCodeOdor. In the rest of this chapter, we detail each part of the detection
approach, we show how the detection results are displayed to users and dis-
cuss the instantiation of the approach for each of the six code smells we
select.

82
Chapter 6. Detection of Design Flaws

6.2.1 Detection Strategy


As discussed in Chapter 2, various techniques to detect design flaws
have been proposed. We decide to use a metrics-based approach, and in this
section we present our approach on combining metrics in order to serve the
detection of code smells. We decide to use a metrics-based approach be-
cause is the most suited to enable all the part of our detection approach,
particularly for what concerns Harmfulness computation and Visualization.
A metrics-based detection strategy, as defined by R. Marinescu in [91], is:

“A composed logical condition, based on metrics, by which design frag-


ments with specific properties are detected in the source -code”

From an implementation point of view:

 each logical condition based on a metric compares the metric against


a threshold;
 the design fragments with specific properties it detects is a code
smell, that affects the design fragments if the composed logical con-
dition is true for the fragments.

A detection strategy implementation starts from the informal definition of


the code smell. As starting point we refer to the two most important works
in this area, by Fowler et al. (1999) in [51] and by Lanza et al. (2006) in
[75], that propose code smells definitions. For each of the six code smells
we examine, we start from the definition given on these references and pro-
pose our definition that tries to be as clear as possible. Once we give our
definition, we define a detection strategy that capture the defined code smell
in an automated way, breaking down the informal definition in a correlated
set of symptoms (e.g., high coupling) that can be captured by a single met-
ric.
The detection strategies we describe in the following of this chapter use
only two logical operators to compose logical conditions: AND and OR.
Each logical condition of a detection strategy is composed by:

1. A metric;
2. An Absolute Comparator;
3. A threshold.
83
Chapter 6. Detection of Design Flaws

The metric is carefully selected to capture an interesting property of the


source code. The metric is compared against a statistically identified thresh-
old using an Absolute Comparator [91]. An Absolute Comparator, as de-
fined by R. Marinescu in [91], is:

“The classical comparators for numbers, i.e., > (greater than) ; ≥ (greater
than or equal to); < (less than); ≤ (less than or equal to).”

We select this type of comparator, among other proposed by R. Marinescu


(e.g., Relative Comparators that use operators like highest values and low-
est values), because an Absolute Comparator only uses the information
computed on the specific entity under investigation, and not for example at
system level. This is important with the aim to use JCodeOdor also in the
earlier phase of the development, when the system is under development.
When an expert works with code smells to build metric-based detection
strategies to identify them, he has to select the software metrics that capture
as well as possible the characteristics of the affected entity. Sometimes the
metrics we can found in the literature are not enough to capture at best the
properties of entities, to evaluate if they are affected by a code smell or not.
For this reason, some of the metrics we use, discussed in Section 4.2.3 , are
defined by us to better capture the interesting properties of the entity.
Our detection approach introduce the possibility to select harden or soften
thresholds. During the code smell detection strategy evaluation we some-
time face the problem of some entities that are not code smell, but most of
the metrics that are part of the detection strategy are near to the thresholds.
For these entities, we ask ourselves: Are these entities to be considered code
smell or not? We decide do not consider these entities affected by the code
smell because the threshold is a point in the space of the possible value s for
a metric, which is selected to differentiate entities. We offer to the user
harden and soften thresholds so that he can select lower thresholds if he
thinks that the results are not enough (e.g., this situation can happen in small
systems, where there are generally a few number of entities affected by code
smells), or he can select higher thresholds if he thinks that the number of
detected code smells is too high.

84
Chapter 6. Detection of Design Flaws

6.2.2 Harmfulness Computation


The Code Smell Harmfulness is an index about how each code smell
is harmful. The idea behind the harmfulness computation is the need to have
a way to prioritize the code smells, and accordingly propose a more useful
view to the users. To allow the user to intuitively understand the information
related to Code Smell Harmfulness, we decide to present them using a nu-
meric value that span from one to ten, and a label that provides a semantic
description of the harmfulness. We have five harmfulness level:

1. Bother: 1

2. Warning: 3.25

3. Trouble: 5.5

4. Problem: 7.75

5. Harm: 10

Each harmfulness level has its own numeric harmfulness level value (e.g.,
harmfulness level Bother has a harmfulness level value equal to 1), that
allows us to aggregate them with the algorithm we show in the following of
this section. We use a scale that span from one to ten, where ten is the most
harmful, because it seems to be the most suited to be intuitively understood
by the users [98].
The harmfulness computation is strictly joined with the threshold computa-
tion, and the metrics distribution discussed in Chapter 5. Also for the harm-
fulness computation, as for the thresholds, we keep the choice to be guided
by the distribution of the metric values (i.e., percentiles). We refer to the
distribution of the metrics used in the detection strategy of the code smell
(i.e., represented by 100 percentiles) and we:

1. Compute the harmfulness for each metric used by detection strategy:


a. we equally distribute five points corresponding to the harm-
fulness level, starting from the percentile corresponding to the
threshold value to the percentile corresponding to the extreme
threshold;

85
Chapter 6. Detection of Design Flaws

b. we compare the metric value with the value corresponding to


the five harmfulness points, and set as harmfulness the point
that has as its value the worst one exceeded by the value of
the metric.
2. Aggregate the harmfulness of each metric to obtain a single harmful-
ness index, using the semantic behind the logical operator that com-
pose the detection strategy.

Harmfulness Computation Details


As discussed in the previous section, a code smell is captured using a dedi-
cated detection strategy, composed by one or more logical condition made
by: a metric, an Absolute Comparator, and a threshold.
Given the metric, if its value exceeds the threshold value 19, we refer to its
statistical distribution to compute the metric values where to place the
harmfulness level points. The threshold defines the value where to start to
place the harmfulness level points, and the Absolute Comparator (i.e., >, ≥,
< or ≤) defines the side of the metric distribution where to place the points
(i.e., the left side or the right side of the distribution starting from the
threshold). The defined side is always the side of the distribution where the
metric get worse, because when we write a logical condition for a detection
strategy, or we select a metric to show to the user, we refer to values that
could introduce problems. Figure 22 shows an example for the LOC metric
compared with a threshold greater than the MEAN (50 Pt), and an example
of TCC lower than the MEAN (50 Pt).

19
There can be some of the metrics in the detection strategy that do not exceed the thresh-
old, for example when we use the OR logical operator to compose logical condition.
86
Chapter 6. Detection of Design Flaws

LOC ≥ MEAN

Bother Trouble Harm


Warning Problem

VERY-LOW LOW MEAN HIGH VERY-HIGH

1Pt 10Pt 25Pt 50Pt 75Pt 90Pt 100Pt

TCC ≤ MEAN

Harm Trouble Bother


Problem Warning

VERY-LOW LOW MEAN HIGH VERY-HIGH

1Pt 10Pt 25Pt 50Pt 75Pt 90Pt 100Pt

Figure 22: Example of Harmfulness Level Points Selection.

Starting from the threshold, we compute the value for each of the five harm-
fulness level points, observing the statistical distribution of the metric. The
values for the two extreme harmfulness level points can be directly as-
signed:

 𝐵𝑜𝑡ℎ𝑒𝑟 = 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑))

𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑉𝐸𝑅𝑌 − 𝐻𝐼𝐺𝐻)) 𝑖𝑓 ≥
 𝐻𝑎𝑟𝑚 = {
𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑉𝐸𝑅𝑌 − 𝐿𝑂𝑊)) 𝑖𝑓 ≤

where 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑) is a function that given the threshold returns


the corresponding percentile, and 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒) is defined as a func-
tion that selects from the metric distribution the value corresponding to the
percentile passed as its argument (i.e., the ThValue defined in section 5.2.1).

87
Chapter 6. Detection of Design Flaws

The remaining part of the algorithm is more dependent by the side where to
place the points, defined by the Absolute Comparator. In the following, we
show the algorithm computation steps differentiating where the side intro-
duces changes.
In order to set the values for the three remaining harmfulness level points
we proceed as follow:

1. We compute 𝐵𝑜𝑡ℎ𝑒𝑟𝑃𝑡 = 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑), that is the percen-


tile of the metric distribution that corresponds to the threshold value,
that is equal to Bother harmfulness level value;

2. We compute

𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑉𝐸𝑅𝑌 − 𝐻𝐼𝐺𝐻) 𝑖𝑓 ≥
𝐻𝑎𝑟𝑚𝑃𝑡 = {
𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑉𝐸𝑅𝑌 − 𝐿𝑂𝑊) 𝑖𝑓 ≤

that is the percentile of the metric distribution that corresponds to the


extreme value, that is equal to Harm harmfulness level value;

3. We compute the number of percentiles between 𝐵𝑜𝑡ℎ𝑒𝑟𝑃𝑡 and


𝐻𝑎𝑟𝑚𝑃𝑡:

𝐻𝑎𝑟𝑚𝑃𝑡 − 𝐵𝑜𝑡ℎ𝑒𝑟𝑃𝑡 𝑖𝑓 ≥
𝑁𝑢𝑚𝑃𝑡 = {
𝐵𝑜𝑡ℎ𝑒𝑟𝑃𝑡 − 𝐻𝑎𝑟𝑚𝑃𝑡 𝑖𝑓 ≤

4. We compute an interval to set the other three harmfulness points:

𝑁𝑢𝑚𝑃𝑡
𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 = 𝑟𝑜𝑢𝑛𝑑( )
4

Once we have the 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙, we set the other three harmfulness level points
according to the Absolute Comparator:

𝐵𝑜𝑡ℎ𝑒𝑟𝑃𝑡 + 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 𝑖𝑓 ≥
𝑊𝑎𝑟𝑛𝑖𝑛𝑔𝑃𝑡 = {
𝐵𝑜𝑡ℎ𝑒𝑟𝑃𝑡 − 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 𝑖𝑓 ≤

𝑊𝑎𝑟𝑛𝑖𝑛𝑔𝑃𝑡 + 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 𝑖𝑓 ≥
𝑇𝑟𝑜𝑢𝑏𝑙𝑒𝑃𝑡 = {
𝑊𝑎𝑟𝑛𝑖𝑛𝑔𝑃𝑡 − 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 𝑖𝑓 ≤

88
Chapter 6. Detection of Design Flaws

𝑇𝑟𝑜𝑢𝑏𝑙𝑒𝑃𝑡 + 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 𝑖𝑓 ≥
𝑃𝑟𝑜𝑏𝑙𝑒𝑚𝑃𝑡 = {
𝑇𝑟𝑜𝑢𝑏𝑙𝑒𝑃𝑡 − 𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 𝑖𝑓 ≤

and the corresponding values:

 𝑊𝑎𝑟𝑛𝑖𝑛𝑔 = 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑊𝑎𝑟𝑛𝑖𝑛𝑔𝑃𝑡);
 𝑇𝑟𝑜𝑢𝑏𝑙𝑒 = 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑇𝑟𝑜𝑢𝑏𝑙𝑒𝑃𝑡);
 𝑃𝑟𝑜𝑏𝑙𝑒𝑚 = 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑟𝑜𝑏𝑙𝑒𝑚𝑃𝑡).

Given the five harmfulness level point values, we find the one that satisfy
the condition (2):

argmax 𝑀𝑒𝑡𝑟𝑖𝑐𝑉𝑎𝑙𝑢𝑒 ≥ 𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙𝑉𝑎𝑙𝑢𝑒 𝑖𝑓 ≥


𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙𝑉𝑎𝑙𝑢𝑒
{
argmin 𝑀𝑒𝑡𝑟𝑖𝑐𝑉𝑎𝑙𝑢𝑒 ≤ 𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙𝑉𝑎𝑙𝑢𝑒 𝑖𝑓 ≤ (2)
𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙𝑉𝑎𝑙𝑢𝑒

where 𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙𝑉𝑎𝑙𝑢𝑒 =
{𝐵𝑜𝑡ℎ𝑒𝑟, 𝑊𝑎𝑟𝑛𝑖𝑛𝑔, 𝑇𝑟𝑜𝑢𝑏𝑙𝑒, 𝑃𝑟𝑜𝑏𝑙𝑒𝑚, 𝐻𝑎𝑟𝑚}

and we select the corresponding harmfulness level for the metric that is part
of the logical condition under computation. The equation (2) has always one
solution because 𝐵𝑜𝑡ℎ𝑒𝑟 = 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑)) and the harm-
fulness computation for a given logical condition starts only if:

𝑀𝑒𝑡𝑟𝑖𝑐𝑉𝑎𝑙𝑢𝑒 ≥ 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑)) 𝑖𝑓 ≥
{
𝑀𝑒𝑡𝑟𝑖𝑐𝑉𝑎𝑙𝑢𝑒 ≤ 𝑣𝑎𝑙𝑢𝑒𝑂𝑓(𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑖𝑙𝑒(𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑)) 𝑖𝑓 ≤

We iterate this process for each logical condition that composes the detec-
tion strategy. This allows us to obtain a harmfulness level for each of the
metric used by the detection strategy. To compute the Code Smell Harmful-
ness, we calculate the average of the harmfulness level value corresponding
to each of the metrics that exceed the threshold:

∑𝑚𝑒𝑡𝑟𝑖𝑐 𝑒𝑥𝑐𝑒𝑒𝑑𝑖𝑛𝑔 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 ℎ𝑎𝑚𝑓𝑢𝑙𝑛𝑒𝑠𝑠 𝑙𝑒𝑣𝑒𝑙 𝑣𝑎𝑙𝑢𝑒


𝐻𝑎𝑟𝑚𝑓𝑢𝑙𝑛𝑒𝑠𝑠𝑉𝑎𝑙𝑢𝑒 =
𝑁𝑢𝑚𝑏𝑒𝑟𝑂𝑓𝑀𝑒𝑡𝑟𝑖𝑐𝑠𝐸𝑥𝑐𝑒𝑒𝑑𝑖𝑛𝑔𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑

89
Chapter 6. Detection of Design Flaws

and the corresponding harmfulness level:

𝐻𝑎𝑟𝑚𝑓𝑢𝑙𝑛𝑒𝑠𝑠𝐿𝑒𝑣𝑒𝑙 =

argmax 𝐻𝑎𝑟𝑚𝑓𝑢𝑙𝑛𝑒𝑠𝑠𝑉𝑎𝑙𝑢𝑒 ≥ 𝑁𝑢𝑚𝑒𝑟𝑖𝑐𝑉𝑎𝑙𝑢𝑒(𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙)


𝐻𝑎𝑟𝑚𝐿𝑒𝑣𝑒𝑙

This aggregation technique allows us to obtain an index that equally con-


siders the harmfulness of each metric used by the detection strategy.
Figure 23 shows an example of harmfulness computation, given a detection
strategy.

Detection Strategy:

LOC ≥ MEAN (50 ≥ 33)

OR
WMC ≥ MEAN (18 ≥ 7)

Harmfulness level computation

LOC WMC

Bother = 33
Bother = 7
Harm = 115
Harm = 18
BotherPt = 50
BotherPt = 50
HarmPt = 90
HarmPt = 90
NumP = HarmPt – BotherPt = 40
NumP = HarmPt – BotherPt = 40
40
Interval = round( 4 ) = 10 𝟒𝟎
Interval = round( 𝟒 ) = 10
WarningPt = 50 + 10 = 60
WarningPt = 50 + 10 = 60
TroublePt = 60 + 10 = 70
TroublePt = 60 + 10 = 70
ProblemPt = 70 + 10 = 80
ProblemPt = 70 + 10 = 80
Warning = 50
Warning = 9
Trouble = 74
90
Chapter 6. Detection of Design Flaws

Problem = 96 Trouble = 12
Problem = 15

Harmfulness computation for each metric (Eq. (2))

LOC WMC

MetricValue = 50 MetricValue = 18
Harmfulness = Warning Harmfulness = Harm
NumHarm = 3.25 NumHarm = 10

Total harmfulness computation

NumberOfMetricsExceedingThreshold = 2
3.25+10
HarmfulnessValue = = 6.625
2
HarmfulnessLevel = Trouble

Figure 23: Example of Harmfulness Computation.

When we compute the harmfulness of each of the metric used by the detec-
tion strategy, we also compute a ratio between the metric value and the
threshold value:

𝑅𝑎𝑡𝑖𝑜𝑀𝑒𝑡𝑟𝑖𝑐𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 = 𝑀𝑒𝑡𝑟𝑖𝑐𝑉𝑎𝑙𝑢𝑒/𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉𝑎𝑙𝑢𝑒

We then sum all these values to obtain an index that represents how many
times the metrics used by the detection strategy exceed the thresholds. We
use this index when we have to show the detection results to the user and
there are some code smells with the same harmfulness level value, in this
case, we show them sorted by this second index.
Due to the characteristics of the algorithm, sometimes it can happen that
more harmfulness level correspond to the same metric value. In this case,
we set the harmfulness level in this way:
 if the metric value is equal to the threshold value, we set the harm-
fulness level to the median one in the set of harmfulness level asso-
ciated to the same metric value, if exists (i.e., there are more than
two harmfulness level associated to the same metric value);

91
Chapter 6. Detection of Design Flaws

 otherwise, we set the harmfulness level to the highest one in the set
of harmfulness level associated to the same metric value.
Before proposing our harmfulness computation algorithm, we consulted the
literature to find something similar. To the best of our knowledge, there are
no works that propose an index to prioritize the code smells respect to the
harmfulness, but there are some works that propose and index related to
code smell for other purposes. The most recent and complete one is “As-
sessing technical debt by identifying design flaws in software systems” by
R. Marinescu in [92]. The author introduces a severity score that is based
on the most critical symptom of the flaw, measured by one or more metrics.
He then uses the severity, along with other index he defines to compute an
aggregated index related to the entire system under a nalysis. We decide to
implement our severity index for code smell, which we call harmfulness,
because we think that harmfulness computation need to take into account
all the metrics used by the detection strategy. This because, given that code
smell captures some more complex flaw in the source code respect to the
metrics, we argue that its most critical symptom cannot determine by itself
the Code Smell Harmfulness.

6.2.3 Filters for Refining Detection Results


Because of the informal definition of code smells, sometimes a per-
fectly good design choice can “smell” like a code smell. When an entity is
detected as code smell, but it is a good design choice, we call them a false
positive, because it does not represent a problem for the quality of the code.
To deal with this kind of situations we introduce the concept of Code Smell
Filters. The concept of Filter is already present in the literature related to
code smell, but to the best of our knowledge, no one has discussed in a
comprehensive and structured way an approach to identify the filter s. More-
over, the filters we define are in most part different from the ones that we
are able to find in the literature, because we use a bottom-up approach that
starts from a deeper analysis of entities that generally are affected by code
smells. The most relevant works related to filters are by C. Marinescu in
[87], that shows how the detection accuracy of two well-known code smells
(i.e., Data Class and Feature Envy [51]) can be improved by taking into

92
Chapter 6. Detection of Design Flaws

account particularities of enterprise applications, and by Ratiu [111] who


uses the historical information of the suspected flawed structure to increase
the accuracy of the automatic problem detection. In his work, C. Marinescu
proposes some interesting filter for our purpose that we investigate to de-
cide what can be taken into account. On the contrary in his work Ratiu pro-
poses filters based on the evolution of the system, that are not applicable
during the development of a new system, for these reason we postponed the
analysis of these type of filters to future works.
We follow two main approaches to identify the filters for each one of the
six code smells that we detect:

 A manual analysis carried out in a previous work [47], where we


investigated two code smells, God Class and Data Class, detected by
iPlasma [88] on 12 systems from the Qualitas Corpus [125]. This
work sets the basis for our investigation related to Code Smell Fil-
ters. We explore the characteristics of the entities affected by code
smells, trying to understand what are the characteristics of entities
affected by a problem, that could be instead a good design choice;
 An automatic analysis of the results obtained using JCodeOdor on a
set of 74 systems from the Qualitas Corpus [125] (see Section 7.1).
We automatically analyse these results to identify the most common
characteristics of the entities affected by code smells. We then inves-
tigate these characteristics to find out some common patterns that
can be considered good choices.

When we perform the manual investigation during the previous work, we


realized that some of the characteristics we found could be detected in an
automated way. Some of them can be detected in a precise manner ( e.g., a
class that uses a specific library), while the others require the use of heuris-
tics to be identified in an automated way. For this reason, we define two
types of filters: Strong Filter, Weak Filter.

93
Chapter 6. Detection of Design Flaws

Strong Filter

Definition:

A Strong Filter is defined as

 A property of the source code entities, which can be automatically


computed in a precise manner. That means that a Strong Filter cannot
lead to filter out code smell that could be a problem for the system
quality.
 A relation between an entity matched by a Strong Filter and other
“smelly” entities.

Identifier: Each Strong Filter is identified by a short textual description.


This short textual description is useful to show the filtered entities to the
user, if the user asks for them.

Example:

Source Code Entity Property

The class implements a library of the JUnit framework.

Relation of the Matched Entity

A God Class filtered by a Strong Filter calls methods from some Data Clas-
ses. We filter out also the Data Classes if the only class that use them is the
filtered God Class.

Weak Filter

Definition:

A Weak Filter is defined as a property of the source code entities, which


can be automatically computed using a heuristic. That means that a Weak
Filter can lead to match code smell that could be a problem for the system
quality.

Identifier: A short label identifies each Weak Filter. This label is useful to
quickly present to the user the information related to the Weak Filters that
match the entity.
94
Chapter 6. Detection of Design Flaws

Example:

A class is a Parser: we can identify a parser with a heuristic based for ex-
ample on the name of the class and/or the name of the methods the class
declares.

Strong Filters define a subset of the detected code smells, which can be
excluded from the detection results. The Weak Filters capture some charac-
teristics of affected entities that can enrich their presentation to the users.
The Weak Filters are useful to guide the user when he does not have enough
time to explore all the detection results. Along with harmfulness, a hint on
some relevant characteristic of affected entities can speed up the user deci-
sion about what to investigate.
In the following of this section we detail the two approaches we exploit to
identify filters.

Manual Analysis

We detect God Class and Data Class on a set of 12 systems from the Qualitas
Corpus, using iPlasma. We manually check all the detected code smells to
explore the characteristics of the affected entities. After checking all the
instances of a given code smell in all the systems, we identify common char-
acteristics and the cases that do not represent a problem for the quality of
the code. The set of identified common characteristics allow us to define
some filters for each of the two investigated code smells.

Automatic Analysis

The manual analysis is time consuming. To identify quickly all the most
common characteristics of affected entities, and to scale to a large number
of systems to analyse to gather more knowledge, we need to automate the
process.
Starting from the common characteristics found during the manual analysis,
we define an automatic technique that allows us to identify the most salient
ones (i.e., the most commons).

95
Chapter 6. Detection of Design Flaws

Datasets Construction

We construct several datasets to collect all the features that we consider


useful to investigate. For each class code smell, we construct three datasets
that for each affected entity contain respectively:

 Ancestors (see Appendix B1 for definition) on the class;


 Interfaces (see Appendix B1 for definition) that the class imple-
ments;
 Packages that contain the Called Classes (see Appendix B1 for defi-
nition) by the class.

We collect only the information that belongs to the external libraries used
by the systems, and not the ones that are part of the system’s source code.
We collect the same types of information for the entities not affected by the
code smell.
For each method code smell, we construct three datasets that for each af-
fected entity contain respectively:

 Ancestors (see Appendix B1 for definition) on the class that define


the method;
 Interfaces (see Appendix B1 for definition) implemented by the class
that declares the method;
 Packages that contain the Called Classes (see Appendix B1 for defi-
nition) by the class that defines the method.
 The packages that contain the types of the method’s parameters.

DFMC4J support us to compute and retrieve all these data from the model.

Computation of Most Salient Characteristics

After generating the dataset, we run on each of them an algorithm that re-
turns the top most common characteristics of the entities affected by code
smell. Along with the characteristics, we compute some meta-data that we
use during the analysis of the algorithm results.
We start from a dataset of information related to entities affected by code
smell, exemplified in Table 14 that shows a part of real data referring to
God Class and to the Ancestors dataset.
96
Chapter 6. Detection of Design Flaws

Table 14: Example of Features of the Entities Affected by Code Smell

Entity Feature 1 Feature 2 Feature 3


1 Java.awt.Compo- Javax.swing.JPanel Java.awt.Window
nent
2 junit.frame- junit.frame- Javax.swing.JCom-
work.TestCase work.Assert ponent

We count the number of lines that contain each of the automatic collected
features. We repeat this process for the entities not affected by the code
smell. Starting from these data, we generate a report like the one exempli-
fied in Table 15.

Table 15: Example of Code Smell Top Characteristics Report

Percentage
Number of
Feature Occurrence of Code
systems
Smells
Java.awt.Component 88 11.0% 21 out of 74
Javax.swing.JComponent 57 7.0% 15 out of 74

For each feature we report the number of code smells in the dataset that
have it, the percentage of the entire set of code smells that have the feature
and the number of system where the code smells that have the feature came
from. We compute the same information for the entities not affected by the
code smell, adding the percentage of entities with a feature that are detected
as “smelly”, to have a quick view on the characteristics of the entire set of
entities. In order to analyse the report we sort them according to occurrence,
so we explore first the most salient characteristics.
We use the results obtained from the manual analysis and the automatic
analysis to define a set of filters for each code smell that we discuss in the
section dedicated to each of them. The entire set of filters can be classified
based on the characteristics of the entities they exploit to detect the code
smell to filter.

97
Chapter 6. Detection of Design Flaws

The categories of filters we define are:

 Library Implementer or Extender


A filter that uses information on the class that the “smelly” entity
extends or the library that the “smelly” class implements.

 Method Caller
A filter that uses information about the methods that the “smelly”
entity calls.

 Related Code Smell


A filter that uses information about filtered entities and relation
among different type of code smells.

 Name Matcher
A filter that uses the name of the class and/or the name of its meth-
ods. Only Weak Filters can belong to this category.

The filters we define are not exclusive, and can belong to more than one
category. An entity affected by a code smell can be filtered by more than
one filter.
To optimize the filtering process we define a priority order to apply the
filters:

 If an entity can be filtered by a Strong Filter, we filter it out and do


not apply any other filters;
 If a Weak Filter matches an entity, we apply the filter and check for
all other Weak Filter, to find out all the Weak Filters that filter the
entity.

The approach differs according to the type of filter, due to the impact they
have on the set of detected code smells. The Weak Filters information is
shown to the users and if more than one Weak Filter filters an entity, this is
a useful information to show to the user. In Section 7.2 we evaluate our
code smells detection approach and show these data for real systems.
We perform our analyses about what can be considered a good design
choice, that can lead to a filter, based on our past experiences in quality
evaluation [7]. We know that these types of evaluation can be biased due to
98
Chapter 6. Detection of Design Flaws

the subjectivity of the expert. For this reason, in our approach, we allow the
user to disable some or all the filters we implements in JCodeOdor, if he
disagrees with our analysis. For the same reason we plan for next releases
of JCodeOdor, to add a functionality that allows the user to add new filters
(see Section 9.2 for more details).

6.2.4 Presentation of Detection Results


In this section we discuss the presentation of the code smells detec-
tion results. We present the results to the user using all the information
computed during the detection, using a tabular view to display them. Figure
24 shows an example of the structure of this view, in Section 7.2 we present
some examples with entities belonging to a real system.

Code Smell Name N Filtered / M Possibly Filtered

Affected Entity Harmfulness Possibly Filtered Visualizations

Weak Filters that


Name N/10 (Level) match the code [Visualizations]
smell.

Figure 24: Presentation of Detection Results

We show the code smells detection results displaying on top the code smells
that affect the classes and then the ones that affect the methods. A single
section that contains the results related to one code smell can be collapsed
or expanded to enhance exploration of the results. For each affected entity,
we report:

 The name, mapped to the corresponding source code entity;


 The harmfulness value and the corresponding level;
 A list of Weak Filters that match the code smell;
 A link to open the visualizations (or views) related to the code smell.

On top of the list of the detected code smells, we report the number N of
code smells filtered by Strong Filters, and the number M of code smells
matched by Weak Filters that we call Possibly Filtered.

99
Chapter 6. Detection of Design Flaws

The list of entities affected by code smells is sorted according to the harm-
fulness value, to offer a prioritized view to the users. The user can open a
list of code smells filtered out by Strong Filters if he needs to consult them.

The information we compute with our detection strategy can be also useful
to enhance the usability of the detection results. A user can select, for ex-
ample, the minimum level of harmfulness for which show the code smells.

6.2.5 Code Smell Visualization


Code smells affect mainly classes and methods. Most of them capture
potential problems related to complex aspects of object-oriented systems,
such as coupling. A code smell is useful to investigate potential problems
and decide whether and how to try to fix them. It is important to offer to the
user all the data useful to quickly understand what is possibly going wrong.
We think that reporting a code smell without the description of one or more
visualization that shows its characteristics, is less useful because more hard
to investigate.
The literature in the area of software visualization and code smells visuali-
zation is rich. We refer particularly to the code smells visualization litera-
ture, where we can find two main approaches:

1. Visualization relative to the entire system [42][43]. This type of vis-


ualization use the entire set of detection results to show information
related to the quality of the entire system;
2. Explore the characteristics of each instance of detected code smells.
There are two main types of visualization: guided by the character-
istics of each code smell [109], generic for the entire set of detected
code smells (e.g., the Class Blueprint by Lanza [73], based on poly-
metric views and used for code smells visualization by the same au-
thor in [75]).

The first approach allows the user to have a complete view about the quality
of the system. Visualize the information related to the entire system can
lead to a view with too many objects, that reduce its usability. In such a
view, it is difficult to investigate all the characteristics of a potential prob-
lem, and understand how to fix them.

100
Chapter 6. Detection of Design Flaws

The second approach is most suited to code smell characteristics visualiza-


tion. We think that the ones guided by the characteristics of each code smell
are the best ones. We follow this approach to define our visualization frame-
work.
Our visualization framework is guided by the following considerations:

 Each code smell has specific characteristics, quantified by the met-


rics used in the detection strategy;
 A code smell is sometimes related to other code smells [110]. For
example a God Class often uses data from one or more Data Classes
[9].

We propose a solution that is a compromise between the richness o f the


representation, and the intuitiveness of the results offered to the user.

We think that a good code smell visualization has to:

 Use a simple visualization paradigm, possibly already familiar to the


users;
 Offer more view to the users, personalized for each code smell. Some
code smells (e.g., God Class) capture complex structure in the sys-
tem, so we need more views to better show their characteristics and
the relation with other entities in the system.

The framework we propose describes the source code entities and the rela-
tion among them. The framework uses the graph structure where the ver-
texes are entities and edges are relations among them. We use the graph
structure because we think it is the most suited to visualize the elements of
our framework, and have been proposed in a large number of software vis-
ualization [26][43][52].
We decide to use the Polymetric View paradigm proposed by Lanza [74],
because it fits well our requirements and it is a well-known paradigm. Fig-
ure 25 shows the main graphical elements we take from the Polymetric View
[75].

101
Chapter 6. Detection of Design Flaws

Figure 25: The Principles We Take from the Polymetric View.

In the following, we discuss all the elements of the framework that allow us
to visualize the characteristics of the six code smells we analyse. The code
smells we investigate refers to classes and methods. Because of the diversity
and the large number of code smells, the framework has to be robust against
addition of new code smells.

Elements of the Visualization Framework

We use the graph structure of the Polymetric View with vertices and edges.

Vertices

Vertices are represented by a rectangle with a certain width and height, and
a colour. They have two labels: the name of the entity, and a code smell
label for the “smelly” entities. The width and height are proportional to
some software metrics related to the entity represented by the vertex. The
vertex can be used to show “smelly” and not “smelly” entities. For the not
“smelly” entities, we use the white colour. For “smelly” entities, we use a
graduated scale of colours that span from light orange to dark orange, pre-
sented in Figure 26. Each colour of the scale corresponds to a specific harm-
fulness level.

102
Chapter 6. Detection of Design Flaws

Bother Warning Trouble Problem Harm

Figure 26: Colour used to Visualize Code Smell Harmfulness.

We decide to use these colours in the scale because we can expect the user
intuitively assigns more harmful to darker colours: the more vivid the colour
of the cell, the more the entity is worth the user attention.

Edges

An arrow with a weight and a label represents edges. The label offers a
description about the semantic of the relation. The weight represents the
strength of the relation (e.g., the number of attribute used by a class from
another one). A more weighted relation makes the arrow wider (e.g., greater
the number of attributes used by a class from another one, wider the arrow
is). Both the weight and the label are optional.

Elements Implementation Details

Vertices

We use vertices to represent classes and methods. Figure 27 shows the at-
tributes we use and an example of shape.

Height Width
Shape Name Smell Label Colour
Metric Metric
Class A God Class LOC WMC Problem
WMC
(GC)
LOC

Class
A
GC

103
Chapter 6. Detection of Design Flaws

Method F Brain Method LOC CY- Warning


CYCLO
(BM) CLO

LOC
Method
F
BM

Figure 27: Example of Shape and Attributes for Classes and Methods

Edges

We use edges to represent relation between classes and methods. We define


three types of edges, which represent the three typ es of relations we have:
belonging relation, hierarchy relation, and generic relation.

Class
B
belongs to

Method
F

LM

Figure 28: Example of belonging Relation.

The belonging relation maps an entity to the entity that contains it (e.g., a
method belonging to a class). It has the label “belongs to” and no weight.

104
Chapter 6. Detection of Design Flaws

Class
B

Class
A
GC

Figure 29: Example of hierarchy Relation.

The hierarchy relation binds a class to its superclass. It has no label and no
weight.

calls methods from


Class Class
A B
GC

Figure 30: Example of generic Relation.

The generic relation connects two entities that share something. It has a
label and a weight. An example is the generic relation that connects a class
to another class based on method calls from the one to the other.

Code Smell Views

We propose three views that show the code smell characteristics and their
impact on the system design. We characterize these three views for each of
the six code smells we analyse, using the framework discussed before.

Code Smell Profile View

The purpose of this view is to show to the users the characteristics of the
source code entity captured by the code smell. This is the first one we pro-
pose to users when he selects to open the code smell visualizations, and it
105
Chapter 6. Detection of Design Flaws

is suited to quickly understand the reasons that lead to the presence of the
smell. This view focalizes the user attention on the “smelly” entity that is
shown in the centre of the screen, and describes the properties of the code
smell in terms of information underlying the metrics used in the detection
strategy. Figure 31 shows a generic example of the elements that are part of
this view, where “Class A” is the investigated code smell.

Class
C
GC

Class
A
GC

Class
B

Figure 31: Code Smell Profile View Example.

Along with the graph view, we also graphically present some related infor-
mation. Code Smell Profile View reports also a table with the information
on the metrics used in the detection strategy, and some other interesting
metrics and information that we select based on the code smell to visualize.
The presentation we use to graphically represent this information is the
same of the one we use for visualize Code Smell Harmfulness. The colours
we use are the same, and they are selected based on the five thresholds we
set for the metrics (see Section 5.2.1). When a metric for a specific infor-
mation is worst for high values, we set the darker colour on higher thresh-
olds; when a metric for a specific information is worst for lower values, we
set the darker colour on lower thresholds. When we have to show Boolean
information, we simply use the false or true label.

106
Chapter 6. Detection of Design Flaws

Code Smell Context View

This view enriches the previous one with some entities and relations that
better pose the code smell in the system context it belong to. It is important
by the user who investigates for a potential problem, to find out the inter-
action with the code smell by other parts of the system. The “smelly” entity
remains in the centre of the view, and the information we add is generally
related to other classes of the system that call the “smelly” class or method .
Figure 32 shows a generic example of the elements that are part of this view,
where “Class A” is the investigated code smell.

Class
C
GC

Class calls methods from Class


D A
GC
GC

Class
B

Figure 32: Code Smell Context View Example.

As for the Profile View, also for this view we add some additional infor-
mation. Along with the information already present on the Code Smell Pro-
file View, we add some additional metrics and information that better de-
scribe the impact of the code smell on the system.

Related Code Smell View

A code smell can be strictly related to other code smells [62][110]. This
information can be useful to better understand the best way to refactor it
[51][80]. The last view we propose offers to the user a visualization of se-
lected related code smells. For each code smell that we analyse, we carefully
select and detect related code smells to show them to the user. Figure 33

107
Chapter 6. Detection of Design Flaws

shows an example of this view that reports the well-known relation between
two code smells [9]: God Class (GC) and Data Class (DC).

Class
E
DC

Class
A
GC

Class
F
DC

Figure 33: Related Code Smell View Example.

When we designed the visualization framework described in this section,


we do not add too much visualization elements. More elements there are,
more the resulting view is difficult to understand by the user. We think the
visualization elements used in our framework are quite simple to avoid the
need of a legend. Probably the only one that is more difficult to remember
could be the colour association to harmfulness or threshold, so it is the only
element that we describe in a legend offered to the user.

We implemented in JCodeOdor all the functionalities needed to obtain and


evaluate all the information underlying the visualization we propose. A
complete implementation is beyond the scope of this work. Since we have
all the information used in the views, we can use them for the evaluations
that we present in Chapter 7.

108
Chapter 6. Detection of Design Flaws

6.3 Investigated Code Smells


We investigate six code smells, selected following the criteria dis-
cussed in Section 6.1 .
In the following of this section, we present and discuss the application of
our detection approach to all of the six code smells.

Each section dedicated to a code smell is organized as follow:

1. code smell definition: from the literature to our definition;


2. code smell detection strategy. We define the detection strategies of
the code smell starting from the informal definition, exploiting the
symptoms (e.g., high coupling) that can be captured by a single met-
ric and selecting proper metrics and thresholds that best quantify
each of the identified properties. Along with the detection strategy
we also show the values corresponding to the thresholds we use for
the metrics that compose the detection strategy, and we denote the
entities in the source code where the code smell detection strategy
applies to;
3. Code Smell Filters that we identify during our investigation. They
represent an initial set we implement to enhance the detection results.
They can be extended in terms of captured properties and number
of identified filters;
4. Description of the information we show on the three personalized
view for the code smell. For the God Class code smell, we provide
also an example of these views.

We omit the harmfulness computation specification, because in the Section


6.2.2 we showed a generic algorithm that compute them based on the code
smell detection strategy.
When we present the values related to the selected thresholds, we refers
only to the default thresholds, for the sake of clarity.

6.3.1 God Class


God Class is one of the most complex code smell. It captures poten-
tial problems related to Coupling, Cohesion, Complexity, and Size. It is also
known as: Large Class [51].
109
Chapter 6. Detection of Design Flaws

God Class Definition


Fowler et al. [51]

“When a class is trying to do too much, it often shows up as too many in-
stance variables. When a class has too many instance variables, duplicated
code cannot be far behind. […] As with a class with too many instance var-
iables, a class with too much code is prime breeding ground for du plicated
code, chaos, and death.”

Lanza et al. [75]

“The God Class design flaw refers to classes that tend to centralize the
intelligence of the system. A God Class performs too much work on its own,
delegating only minor details to a set of trivial classes and using the data
from other classes.”

Our Definition

The God Class code smell refers to classes that tend to do too much work
on its own. A God Class tend to have too much code, tend to be complex,
to implement several functionalities that accomplish different tasks, and to
use many data from other classes.

God Class Detection Strategy


Figure 34 shows the detection strategy we develop for God Class.

110
Chapter 6. Detection of Design Flaws

LOCNAMM ≥ HIGH (176)

WMCNAMM ≥ MEAN (22)

NOMNAMM ≥ HIGH (18) AND

TCC ≤ LOW (0.33)

ATFD ≥ MEAN (6)

Figure 34: God Class Detection Strategy.


Applies to: Concrete or abstract classes.

Discussion about metrics and thresholds selection:

 LOCNAMM ≥ HIGH: Too much code.

We use LOCNAMM instead of LOC, because getter and setter methods


are often generated by the IDE. A class that has getter and setter meth-
ods, and a class that has not getter and setter methods, must have the
same “probability” to be detected as God Class.

 WMCNAMM ≥ MEAN: Too much work and complex.

Each method has a minimum cyclomatic complexity of one, hence also


getter and setter add cyclomatic complexity to the class. We decide to
use a complexity metric that exclude them from the computation.

 NOMNAMM ≥ HIGH: Implements a high number of functionalities.

111
Chapter 6. Detection of Design Flaws

We exclude getter and setter because we consider only the methods that
effectively implement functionality of the class.

 TCC ≤ LOW: Functionalities accomplish different tasks.

 ATFD ≥ MEAN: Uses many data from other classes.

God Class Filters


Strong Filters
1. Identifier: GUI Library

When a class implements an element of a graphical interface, often use s a


set of well-known libraries (e.g., Swing). Realizing an element of a graph-
ical interface can require a lot of code, because of the multiple aspects to
handle (e.g., shape, colour, and position). This type of class can be fre-
quently detected as God Class, but we think that having all the information
in the same class is better than split them along multiple classes.

Categories: Library Implementer or Extender.

Captured properties:

 The class directly implements an interface from “javax.swing.table”


package;
OR
 At least one of the Ancestor of the class is from the following pack-
ages: “javax.swing.table”, “swing.treetable”, or is “ja-
vax.swing.JComponent”.

2. Identifier: Test Class

Test classes are generally organized in a specific package, so that the user
can simply exclude them from the detection results. During our analysis on
the Qualitas Corpus, we find out that this is not generally true for a large
number of projects. For this reason, we introduced a filter to capture test
classes and exclude them from detection results. This is because we think
test classes are not part of the primary analysis respect to the system design
quality.
112
Chapter 6. Detection of Design Flaws

Category: Library Implementer or Extender, Method Caller.

Captured properties:

 At least one method of the class calls a method of classes that are
part of “org.junit” or “junit.framework” packages;
OR
 At least one of the Ancestor of the class is “org.junit.TestCase” or
“junit.framework.TestCase”.

3. Identifier: Entity Modeling Class

Entity Modeling Framework, such as EMF by Eclipse [121], tends to gen-


erate large and complex classes to represent the entities. Bec ause the source
code of these classes is automatically generated, and is managed through
the framework facilities, we exclude these classes from the detection re-
sults.

Category: Library Implementer or Extender.

Captured properties:

 At least the class or one of the Ancestor of the class implements


“org.eclipse.emf.ecore.EObject” interface.

Weak Filters
4. Identifier: Parser Class

A parser generally does much work because of its scope. It tends to be a


God Class, but we think it does not represent a problem for system quality,
as already stated by other experts [108]. Split the logic of the parser among
more classes could make it harder to understand.

Category: Name Matcher

113
Chapter 6. Detection of Design Flaws

Captured properties:

 The class name contains one of the following words: “Parse”, “Par-
ser”, “Parsing”. We search for the words after we split the class name
according to the CamelCase notation for Java classes.
OR
 At least two methods of the class contain one of the following word:
“parse”, “Parse”, “parser”, “Parser”, “parsing”, “Parsing”. We search
for the words after we split the class name according to the
CamelCase notation for Java methods.

5. Identifier: Visitor Class

The class that implements the visitor design patters [72], often implements
a lot of visit methods. These visit method can introduce a lot of complexity.

Category: Name Matcher

Captured properties:

 The class name contains one of the following words: “Visit”, “Visi-
tor”. We search for the words after we split the class name according
to the CamelCase notation for Java classes.
OR
 At least two methods of the class contain one of the following word:
“visit”, “Visit”, “visitor”, “Visitor”. We search for the words after
we split the class name according to the CamelCase notation for Java
methods.

6. Identifier: Persistence Class

Classes that handle persistence in a system tend to be large and complex.


This is because they usually interact heavily with a database. We think that
implementing the persistence action in a single class is a good design
choice. In this way, it is simple to identify the class that handle the persis-
tence and to modify them.

Category: Method Caller.


114
Chapter 6. Detection of Design Flaws

Captured properties:

 At least half of the visible methods (i.e., not private methods) call a
method in a class in one of the following packages: “java.sql”, “ja-
vax.sql”, “hibernate”.

God Class Views


Code Smell Profile View

Graphical elements:

The God Class (label: GC) is on the centre of the screen, with all the infor-
mation to describe the code smell. We introduce one generic relation:

 “uses attributes from”: from the God Class to the classes where are
defined the attributes the God Class uses (information related to
ATFD metric).

Figure 35 shows an example.

Class
C
DC

Class
A
GC

Class
B

Figure 35: God Class Profile View Example.

Additional information:

All the metrics used by the detection strategy.

115
Chapter 6. Detection of Design Flaws

NOPA (Number of Public Attributes) and NOAM (Number of Accessor


Methods): more information expose to other classes, more God Class is
worst (as stated by Fowler definition [51]).

Number of static methods: we use a Boolean flag that became true if the
number of static methods is at least the half of the total number of methods.

Figure 36 shows an example.

Detection Strategy Metrics Values


LOCNAMM WMCNAMM ATFD TCC NOMNAMM
1,228 173 26 0.25 55

Additional Information
NOPA NOAM STATIC
≥ HIGH ≥ HIGH false

Figure 36: God Class Profile View Additional Information Example.

Code Smell Context View

Graphical elements:

To the Code Smell Profile View we add one generic relation:

 “calls methods from”: from other classes in the systems that call
methods of the God Class (information related to FANIN metric, that
is part of the additional information).

Figure 37 shows an example.

116
Chapter 6. Detection of Design Flaws

Class
Class
C
G DC

GC

Class
A
GC

Class Class
D B
GC

Figure 37: God Class Context View Example.

Additional information:

The ones in the Code Smell Profile View.

FANIN: number of classes that uses the God Class. More the God Class is
used, more it is the “probability” that tend to centralize the intelligence of
the system.

Figure 38 shows an example.

Detection Strategy Metrics Values


LOCNAMM WMCNAMM ATFD TCC NOMNAMM
1,228 173 26 0.25 55

Additional Information
NOPA NOAM FANIN STATIC
≥ HIGH ≥ HIGH ≥ LOW false

Figure 38: God Class Context View Additional Information Example.

117
Chapter 6. Detection of Design Flaws

Related Code Smell View

Graphical elements:

The God Class (label: GC) is on the centre of the screen, with all the infor-
mation to describe the code smell. We show different related code smells:

 Data Classes used by the God Class:


o We introduce three generic relations based on the relation be-
tween the God Class and the Data Class: “uses attributes
from”, “calls methods from” or “uses attributes and calls
methods from”.
 Classes with code smells that call the God Class:
o We introduce three generic relations based on the relation be-
tween the class with code smell and the God Class: “uses at-
tributes from”, “calls methods from” or “uses attributes and
calls methods from”.
 Other code smells inside the God Class (e.g., Brain Method):
o For code smells on the God Class: we introduce a label for
each code smell;
o For code smells on God Class methods: we introduce a be-
longing relation to map the “smelly” method to the God Class;

Figure 39 shows an example.

118
Chapter 6. Detection of Design Flaws

Class
E
DC

Class calls methods from Class


G A
GC
GC

belongs to
Class
F
Method DC

A
BM

Figure 39: Related God Class View Example.

6.3.2 Data Class


Data Class is one of the most studied code smell [136]. It captures
potential problems related to Encapsulation and Data Abstraction.

Data Class Definition


Fowler et al. [51]

“These are classes that have fields, getting and setting methods for the
fields, and nothing else. […] they need to take some responsibility.”

Lanza et al. [75]

“Are “dumb” data holders without complex functionality but other classes
strongly rely on them.”

Our Definition

The Data Class code smell refers to classes that manly hold data and exposes
them. A Data Class has a low complexity and offers a few number of func-
tionalities, because it has only public fields and methods to access them.

119
Chapter 6. Detection of Design Flaws

Data Class Detection Strategy


Figure 40 shows the detection strategy we develop for Data Class.

WMCNAMM ≤ LOW (14)

WOC ≤ LOW (0.33)

AND

NOAM ≥ MEAN (4)

OR
NOPA ≥ MEAN (3)

Figure 40: Data Class Detection Strategy.


Applies to: Concrete classes.

Discussion about metrics and thresholds selection:

 WMCNAMM ≤ LOW: Methods are not complex.

Each method has a minimum cyclomatic complexity of one, hence


also getter and setter add cyclomatic complexity to the class. We de-
cide to use a complexity metric that exclude them from the computa-
tion.

 WOC ≤ LOW: The class offers few functionalities.

This metrics is computed as the number of functional (non-accessor)


public methods, divided by the total number of public methods. A
low value for the WOC metric means that the class offers few func-
tionalities.

120
Chapter 6. Detection of Design Flaws

 NOAM ≥ MEAN: The class has many accessor methods.

 NOPA ≥ MEAN: The class has many public attributes.

Data Class Filters


Strong Filters
1. Identifier: Exception Handling Class

Classes that handle exception can often be identified as Data Class. These
classes cannot be considered “smelly” because they represent a good design
choice.

Categories: Library Implementer or Extender.

Captured properties:

 At least one of the Ancestors of the class is “java.lang.Throwable”.

2. Identifier: Serializable Class

Classes that have to be serialized often "smell" like a Data Class. This is
because they are data holder, without complex functionalities. We think that
if a class has been explicitly declared serializable by a developer, it does
not represent a problem for the quality of the system. It is a design choice,
because of a precise requirement: the object needs to be serialized.

Category: Library Implementer or Extender.

Captured properties:

 At least one of the Ancestors of the class is “java.io.Serializable”.

3. Identifier: Test Class

The same we introduced for God Class.

Category: Library Implementer or Extender, Method Caller.

121
Chapter 6. Detection of Design Flaws

Captured properties:

 At least one method of the class calls a method of classes that are
part of “org.junit” or “junit.framework” packages;
OR
 At least one of the Ancestor of the class is “org.junit.TestCase” or
“junit.framework.TestCase”.

4. Identifier: Strong God Class Data

When a Data Class is only used by a God Class filtered out by a Strong
Filter, we think that also a Data Class has to be filtered out. This becau se a
God Class often use some Data Classes to exploit its functionalities. If we
consider the God Class not to be a problem, also the Data Clas s can be
considered a good choice. If for example a Test Class uses some Data Clas-
ses to access some data, also these Data Classes are not a problem for the
system quality.

Category: Related Code Smell.

Captured properties:

 A Data Class which methods are called only by a strong filtered God
Class.

Weak Filters
5. Identifier: Logger Class

Classes used to wrap and offer logger functionalities can be identified as


Data Class. This is because they generally have low complex methods and
some getter and setter methods to configure logger properties and to obtain
them. We think that wrap logger functionalities in a class is not a problem
for the system quality.

Category: Name Matcher

122
Chapter 6. Detection of Design Flaws

Captured properties:

 The class name contains one of the following words: “Log”, “Log-
ger”. We search for the words after we split the class name according
to the CamelCase notation for Java classes.
OR
 At least two methods of the class contain one of the following word:
“log”, “Log”, “logger”, “Logger”. We search for the words after we
split the class name according to the CamelCase notation for Java
methods.

Data Class Views


Code Smell Profile View

Graphical elements:

The Data Class (label: DC) is on the centre of the screen, with all the infor-
mation to describe the code smell.

Additional information:

All the metrics used by the detection strategy.

TCC: lower the cohesion, more the methods tend to handle different data of
the class. More the different data of the class the methods handle, more it
is the “probability” the class is used as Data Class.

NOMNAMM (Number of Not Accessor or Mutator Methods): less the Data


Class offer functionality, more it is the “probability” the class is used as
Data Class.

Only Getter and Setter: the class only has getter and setter methods and
attributes (excluding constructors).

Only static final field: the class has only static final fields and no methods.
This additional information corresponds to the Pool micro pattern [68].

123
Chapter 6. Detection of Design Flaws

Code Smell Context View

Graphical elements:

To the Code Smell Profile View we add two generic relation:

 “calls methods from”: from other classes in the systems that call
methods of the Data Class (information related to FANIN metric, that
is part of the additional information).
 “calls methods from”: from the Data Class to other classes where are
defined the methods the Data Class calls (information related to
FANOUT metric, that is part of the additional information).

Additional information:

The ones in the Code Smell Profile View.

FANIN: Number of other classes using the data (accessing the methods of
the Data Class).

FANOUT: Number of called classes. Lower the number of other classes the
Data Class calls, greater is its responsibility on the data.

Related Code Smell View

Graphical elements:

Classes with code smells that call the Data Class:

 We introduce three generic relation based on the relation between


the class with code smell and the Data Class: “uses attributes from”,
“calls methods from” or “uses attributes and calls methods from ”.

6.3.3 Brain Method


Brain Method captures potential problems related to Coupling, Co-
hesion, Complexity, and Size. It is similar to Long Method by Fowler [51].
It is also known as: God Method [117].

124
Chapter 6. Detection of Design Flaws

Brain Method Definition


Fowler et al. [51]

“The object programs that live best and longest are those with short meth-
ods. Programmers new to objects often feel that no computation ever takes
place, that object programs are endless sequences of delegation. When you
have lived with such a program for a few years, however, you learn just how
valuable all those little methods are.”

Lanza et al. [75]

“Brain Methods tend to centralize the functionality of a class, in the same


way as a God Class centralizes the functionality of an entire subsystem, or
sometimes even a whole system.”

Our Definition

The Brain Method code smell refers to methods that tend to do too much of
the work of the class. A Brain Method tends to have too much code, to have
a high functional complexity, to be difficult to understand, and to use many
of the data of the class.

Brain Method Detection Strategy


Figure 41 shows the detection strategy we develop for Brain Method.

125
Chapter 6. Detection of Design Flaws

LOC ≥ HIGH (33)

CYCLO ≥ HIGH (7)

MAXNESTING ≥ HIGH (6)


AND

NOLV ≥ MEAN (6)

OR
ATLD ≥ MEAN (5)

Figure 41: Brain Method Detection strategy.

Applies to: Methods in concrete or abstract classes and enums, which are
not abstract or default constructor.

Discussion about metrics and thresholds selection:

 LOC ≥ HIGH: Too much code.

 CYCLO ≥ HIGH: High functional complexity.

 MAXNESTING ≥ HIGH: High functional complexity. Difficult to un-


derstand.
 NOLV ≥ MEAN: Difficult to understand.

More the number of local variable, more the method is difficult to


understand.

 ATLD ≥ MEAN: Uses many of the data of the class.

More the number of attributes of the class the method uses, more the
method is difficult to understand.

126
Chapter 6. Detection of Design Flaws

Brain Method Filters

We have not defined any filter for Brain Method. We think that a Brain
Method could be always reorganized to more methods. Sometimes it is not
true for complex algorithm, but we cannot define a filter for them.

Brain Method Views

Code Smell Profile View

Graphical elements:

The Brain Method (label: BM) is on the centre of the screen, with all the
information to describe the code smell. We introduce two types of relations:

 belonging relation: to map the Brain Method to the class that declares
it;
 generic relation:
o “uses attributes from”: from the Brain Method to the class that
declares it (information related to ATLD metric).
o “calls methods from”: from the Brain Method to the class that
declares it (information related to CLNAMM metrics, that is
part of the additional information)

Additional information:

All the metrics used by the detection strategy.

NOP (Number of Parameters): more the number of parameters are more it


is difficult to understand method signature and consequently the function-
ality it implements.

CLNAMM (Called Local Not Accessor Methods): less the number of local
non-accessor methods the method calls, more it tends to centralize the work
of the class.

More return point: we report if the method has more than one return point,
because it is more difficult to understand.

127
Chapter 6. Detection of Design Flaws

Code Smell Context View


Graphical elements:

To the Code Smell Profile View we add one generic relation:

 “uses attributes from”: from the Brain Method to the classes that de-
fines the attributes the Brain Methods uses (information related to
ATFD metric, that is part of the additional information).

Additional information:

The ones in the Code Smell Profile View.

ATFD (Access to Foreign Data): more the number of foreign data is, the
more it is difficult to understand the functionality offered by the method.

Related Code Smell View

Graphical elements:

Code smells on the class that contains the Brain Method (e.g., God Class):

 we introduce a belonging relation to map the Brain Method to the


“smelly” class that contains it;

Classes with code smells that call the Brain Method:

 We introduce three generic relations based on the relation between


the class with code smell and the Brain Method: “uses attributes
from”, “calls methods from” or “uses attributes and calls methods
from”.

Other code smells inside the Brain Method (e.g., Dispersed Coupling, Mes-
sage Chains):

 We introduce a label for each code smell.

128
Chapter 6. Detection of Design Flaws

6.3.4 Shotgun Surgery


Shotgun Surgery captures potential problems related to Coupling.

Shotgun Surgery Definition


Fowler et al. [51]

“You whiff this when every time you make a kind of change, you have to
make a lot of little changes to a lot of different classes. ”

Lanza et al. [75]

“This design disharmony means that a change in an operation implies many


(small) changes to a lot of different operations and classes. ”

Our Definition

The Shotgun Surgery code smell refers to methods that implement a func-
tionality used by a large number of other classes and methods. A change to
a Shotgun Surgery method implies many changes to many other methods in
a large number of classes.

Shotgun Surgery Detection Strategy


Figure 42 shows the detection strategy we develop for Shotgun Surgery.

CC ≥ HIGH (5)

CM ≥ HIGH (6) AND

FANOUT ≥ LOW (3)

Figure 42: Shotgun Surgery Detection strategy.

Applies to: Methods in concrete or abstract not anonymous classes and


enums, which are not abstract, default constructor or constructor.

129
Chapter 6. Detection of Design Flaws

Discussion about metrics and thresholds selection:

 CC >= HIGH: Many classes call the method.

 CM >= HIGH: Many methods to change.

 FANOUT >= LOW: The method is subject to being changed.


If a method interacts with other classes, it is not a trivial one. We use
the FANOUT metric to refer Shotgun Surgery only to those methods
that are more subject to be changed. We exclude for example most of
the getter and setter methods.

Shotgun Surgery Filters


Strong Filters

1. Identifier: Exception Handling Method

Methods in Classes that handle exceptions can often be identified as Shot-


gun Surgery. This happens because an exception can be catched in different
part of the system, hence many classes access the methods offered by the
exception handling class. This can be considered a good design choice.

Categories: Library Implementer or Extender.

Captured properties:

 At least one of the Ancestors of the class that contains the method is
“java.lang.Throwable”.

2. Identifier: Test Class Method

The same we introduced for God Class. Sometimes a method of a tes t class
can be detected as Shotgun Surgery, because many other test classes use
them. Think for example to a method that generate or retrieve data used by
a large number of test cases.

Category: Library Implementer or Extender, Method Caller.

130
Chapter 6. Detection of Design Flaws

Captured properties:

 At least one method of the class that contains the Shotgun Surgery
calls a method of classes that are part of “org.junit” or “junit.frame-
work” packages;
OR
 At least one of the Ancestor of the class that contains the method is
“org.junit.TestCase” or “junit.framework.TestCase”.

Weak Filters

3. Identifier: Getter/Setter Method.

Getter and setter methods can be more complex than the ones we detect (see
Appendix B1). Some of them interact with other methods of the same clas s
of from other classes. We think that this type of methods do not represent a
problem because they are more stable respect to other methods.

Category: Name Matcher

Captured properties:

 The method contains one of the following word: “set”, “get”. We


search for the words after we split the class name according to the
CamelCase notation for Java methods.

Shotgun Surgery Views


Code Smell Profile View

Graphical elements:

The Shotgun Surgery (label: SS) is on the centre of the screen, with all the
information to describe the code smell. We introduce two types of relations:

 belonging relation: to map the Shotgun Surgery to the class that de-
clares it;
 generic relation:
o “calls”: from the classes that call the Shotgun Surgery (infor-
mation related to CC metric).

131
Chapter 6. Detection of Design Flaws

o “calls methods from”: from the Shotgun Surgery to the classes


that define the methods it calls (information related to FAN-
OUT metric).

Additional information:

All the metrics used by the detection strategy.

CFNAMM (Called Foreign Not Accessor or Mutator Methods): more the


number of foreign called methods are, more the method tends to be changed
because of changes in the methods it calls.

Code Smell Context View

Graphical elements:

The same as Code Smell Profile View.

Additional information:

The ones in the Code Smell Profile View.

Related Code Smell View

Graphical elements:

Code Smells on the class that contains the Shotgun Surgery:

 we introduce a belonging relation to map the Shotgun Surgery to the


“smelly” class that contains it.

Classes with code smells that call the Shotgun Surgery:

 We introduce one generic relation “calls” from the “smelly” classes


to the Shotgun Surgery.

Other code smells inside the Shotgun Surgery (e.g., Dispersed Coupling,
Message Chains)

 We add a label for each code smell.

132
Chapter 6. Detection of Design Flaws

6.3.5 Dispersed Coupling


Dispersed Coupling captures potential problems related to Coupling,
Cohesion, and Complexity. It is also known as: Extensive Coupling [127].

Dispersed Coupling Definition


Fowler et al [51] does not define this code smell.

Lanza et al. [75]

“This is the case of an operation which is excessively tied to many other


operations in the system, and additionally these provider methods that are
dispersed among many classes. In other words, this is the case where a
single operation communicates with an excessive number of provider clas-
ses, whereby the communication with each of the classes is not very intense
i.e., the operation calls one or a few methods from each class. ”

Our Definition

The Dispersed Coupling code smell refers to methods that call a large num-
ber of other methods in a large number of different classes. The Dispersed
Coupling interaction with other classes is weak, because it only calls a few
number of methods from each class.

Dispersed Coupling Detection Strategy


Figure 43 shows the detection strategy we develop for Dispersed Coupling.

CINT ≥ HIGH (8)

AND

CDISP ≥ HIGH (0.66)

Figure 43: Dispersed Coupling Detection Strategy.

133
Chapter 6. Detection of Design Flaws

Applies to: Methods in concrete or abstract classes and enums, which are
not abstract or default constructor.

Discussion about metrics and thresholds selection:

 CINT ≥ HIGH: The method calls too many other methods.

With CINT metric, we measure the number of distinct methods called


from the measured method.

 CDISP ≥ HIGH: Calls are dispersed in many classes.

With CDISP metric, we measure the dispersion of called methods:


the number of classes in which the methods called from the measured
method are defined in, divided by CINT.

Dispersed Coupling Filters


Strong Filters

1. Identifier: Test Class Method

The same we introduced for Shotgun Surgery. Sometimes a method of a test


class can be detected as Dispersed Coupling, because it calls many methods
in different classes.

Category: Library Implementer or Extender, Method Caller.

Captured properties:

 At least one method of the class that contains the Dispersed Coupling
calls a method of classes that are part of “org.junit” or “junit.frame-
work” packages;
OR
 At least one of the Ancestor of the class that contains the method is
“org.junit.TestCase” or “junit.framework.TestCase”.

Weak Filters

134
Chapter 6. Detection of Design Flaws

Dispersed Coupling Views


Code Smell Profile View

Graphical elements:

The Dispersed Coupling (label: DCO) is on the centre of the screen, with
all the information to describe the code smell. We introduce two types of
relations:

 belonging relation: to map the Dispersed Coupling to the class that


declares it;
 generic relation “calls methods from”: from the Dispersed Coupling
to the classes that declare the methods it calls (information related to
CINT metric).

Additional information:

All the metrics used by the detection strategy.

Code Smell Context View

Graphical elements:

The same as Code Smell Profile View.

Additional information:

The ones in the Code Smell Profile View.

Related Code Smell View

Graphical elements:

Code smell on the class that contains the Dispersed Coupling (e.g., God
Class):

 We introduce a belonging relation to map the Dispersed Coupling to


the “smelly” class that contains it.

Class with code smells among the classes that Dispersed Coupling calls:

 We introduce one generic “calls methods from” from the Dispersed


Coupling to the “smelly” classes.

135
Chapter 6. Detection of Design Flaws

Other code smells inside the Dispersed Coupling (e.g., Brain Method, Mes-
sage Chains):

 We add a label for each code smell.

6.3.6 Message Chains


Message Chains is one of the less studied code smell [136]. Message
Chains captures potential problems related to Coupling.

Message Chains Definition


Fowler et al. [51]

“You see message chains when a client asks one object for another object,
which the client then asks for yet another object, which the client then asks
for yet another object, and so on. You may see these as a long line of getThis
methods, or as a sequence of temps.”

Lanza et al. [75] does not define this code smell.

Our Definition

The Message Chains code smell refers to methods that contain long se-
quences of method calls to get data from other classes. A Message Chains
has a minimum length of two chained calls.

Message Chains Detection Strategy


Figure 44 shows the detection strategy we develop for Message Chains.

136
Chapter 6. Detection of Design Flaws

MaMCL ≥ MEAN (3)

OR
NMCS ≥ MEAN (3)

AND

MeMCL ≥ LOW (2)

Figure 44: Message Chains Detection Strategy.

Applies to: Methods in concrete or abstract classes and enums, which are
not abstract or default constructor.

Discussion about metrics and thresholds selection:

 MaMCL ≥ MEAN: Maximum Message Chain Length.

A Message Chains has a minimum length of two chained calls, be-


cause a single call is trivial. We use the MaMCL metric to find out
the methods that have at least one chained call with a length greater
than the mean.

 NMCS ≥ MEAN: Number of Message Chain Statements.

There can be more Message Chain Statement: different chains of call.


More the number of Message Chain Statements, more the method is
interesting respect to Message Chains code smell.

 MeMCL ≥ LOW: Mean of Message Chain Length.

We would find out non-trivial Message Chains, so we need always to


check against the Message Chain Statement length.

137
Chapter 6. Detection of Design Flaws

Message Chains Filters


Strong Filters
1. Identifier: Test Class Method

The same we introduced for Dispersed Coupling.

Captured properties:

 At least one method of the class that contains the Message Chains
calls a method of classes that are part of “org.junit” or “junit.frame-
work” packages;
OR
 At least one of the Ancestor of the class that contains the method is
“org.junit.TestCase” or “junit.framework.TestCase”.

Message Chains Views


Code Smell Profile View

Graphical elements:

The Message Chains (label: MC) is on the centre of the screen, with all the
information to describe the code smell. We introduce two types of relations:

 generic relation “calls”: from the Message Chains to methods it calls


(information related to MeMCL metric). The weight of the relation is
proportional to the Number of Message Chain Statement (NMCS met-
ric) from Message Chains to the method it calls.
 belonging relation:
o to map the Message Chains to the class that declares it;
o to map each method the Message Chains calls to the class that
declares it.

Additional information:

All the metrics used by the detection strategy.

138
Chapter 6. Detection of Design Flaws

Code Smell Context View


Graphical elements:

The same as Code Smell Profile View.

Additional information:

The ones in the Code Smell Profile View.

Related Code Smell View

Graphical elements:

Code smells on the class that contains the Message Chains (e.g., God Class):

 We introduce a belonging relation to map the Message Chains to the


“smelly” class that contains it.

Class with code smells among the classes in the Chain:

 We introduce one generic “calls methods from” from the Message


Chains to the “smelly” classes.

Other code smells inside the method affected by Message Chains (e.g.,
Brain Method, Dispersed Coupling):

 We add a label for each code smell.

6.4 Conclusion and Discussion


In this chapter, we introduced the metric-based approach for code
smells detection implemented by JCodeOdor, and its application to six code
smells selected referring to the literature, to find the most dangerous code
smells with respect to their impact on faults prediction and change -prone-
ness. Although we work on six code smells, the proposed detection approach
is general enough to be applied to all of them. JCodeOdor detection ap-
proach is realized by more elements:

 Detection strategies, i.e., composed logical conditions based on de-


sign metrics, useful to automatically detect code smells.
 Code Smell Filters to reduce the number of false positive detected
code smells, taking care that this evaluation could be subjective or

139
Chapter 6. Detection of Design Flaws

based on specific system under investigation. We define two types of


filters. The first are Strong Filters, which define a subset of the de-
tected code smells that can be excluded from the detection results.
The second are Weak Filters, which capture some characteristics of
affected entities that can enrich their presentation to the users. We
classify the proposed filters in some categories, based on the charac-
teristics of the entities they exploit to detect the code smells to filter.
 Code Smell Harmfulness, an index about how much each code smell
is harmful compared to the other code smells. The harmfulness al-
lows presenting the detected code smells in a prioritized way. We use
a label to show harmfulness information to the users.
 A set of personalized views for each code smell, which show details
about the code smell and its impact on system design quality 20. The
views we propose allow the users to deeply investigate the potential
problems pointed out by the presence of the detected code smells.

We also discuss how we present detection results to the user, using elements
of the proposed approach to suggest first the more harmful and relevant
code smells.

20
We already design and discuss the proposed views for each of the six code smells we
investigate, but we have not implemented yet.
140
Chapter 7
Evaluation of Design Flaws Detection

In this chapter, we discuss the evaluations of JCodeOdor we perform, to


assess the usefulness and the effectiveness of the code smells detection ap-
proach it implements. We first discuss the results obtained by JCodeOdor
detection approach on a set of 74 systems from the Qualitas Corpus [125],
evaluating the usefulness of Code Smell Harmfulness and Code Smell Fil-
ters. Then we evaluate the quality of the detection results, with respect to
the state-of-the-art tool inFusion. Finally, we evaluate the effectiveness of
our detection strategies, with respect to a machine learning approach for
code smells detection and to an oracle built by hand.

7.1 Detection Results on the Qualitas Corpus


We apply our detection approach, implemented in JCodeOdor, on the
set of 74 systems from the Qualitas Corpus [125] used as benchmark for
metrics thresholds computation (see Section 5.2.3). In the following, we
discuss the code smells detection results in terms of:

 Numerosity of code smells;


 Impact of Filters-Aware Detection;
 Harmfulness of code smells;
 Related code smells;
 Code smells Co-Occurrence.

All the data we report in this section refer to the detected code smells after
the application of Strong Filter, except the one we report for the “Impact of
Filters-Aware Detection” for Strong Filter. Appendix E1 contains all the
data we discuss in this section, referred to each of the 74 systems we inves-
tigate.

141
Chapter 7. Evaluation of Design Flaws Detection

Statistics about 74 Qualitas Corpus Systems

Table 16 shows some statistics about the 74 systems analysed. The reference
dataset contains a large number of heterogeneous systems in terms of func-
tionalities and size (see Section 5.2.3). The 74 systems have nearly
7,000,000 of Code, 60,000 classes and 400,000 methods.

Table 16: Statistics about the 74 Qualitas Corpus Systems

Number of Lines of Number of Number of Number of


Systems Code Packages Classes Methods
74 6,785,568 3,420 51,826 404,316

Numerosity of Code Smells

The first evaluation we do is to investigate the number of entities affected


by code smells respect to the total number of entities in the systems. The
number of entities affected by code smells is quite low. This is an expected
evidence because of the detection strategies characteristics . The detection
strategies in fact select only a little subset of the total number of entities of
the systems, the ones for which the metrics used in the detection strategy
exceeds the thresholds.

Numerosity of class code smells

Table 17 shows the number and the percentage of affected classes for class
code smells: God Class and Data Class. The percentage of affected classes
is nearly 2-3%. The proportion in terms of percentage between God Class
and Data Class is aligned to a previous experiment [6] we did with another
tool, iPlasma [88]. Figure 45 shows how the affected classes span over 60-
70 systems respect to the 74. Most systems are affected by the class code
smells; in particular, Data Class is present in more than 95% of the systems.

142
Chapter 7. Evaluation of Design Flaws Detection

Table 17: Numerosity of Class Code Smells

Code Smell # of Affected Classes % of Affected Classes


God Class 808 1.56%
Data Class 1,605 3.10%

Sparsity of Class Code Smell Detection Results


100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
God Class Data Class

Affected Systems (%) Not Affected Systems (%)

Figure 45: Sparsity of Class Code Smells Detection Results

Numerosity of method code smells

Table 18 shows the number and the percentage of affected methods for
method code smells. The percentage of affected methods is nearly 0-1%.
The affected methods belong to 40-70 systems respect to the 74 systems
(Figure 46). Brain Method and Dispersed Coupling affect more than 90% of
the systems, while Shotgun Surgery and Message Chains more than 50% of
the systems.
Table 18: Numerosity of Method Code Smells

Code Smell # of Affected Method % of Affected Method


Brain Method 2,701 0.67%
Shotgun Surgery 497 0.12%
Dispersed Coupling 3,188 0.79%
Message Chains 634 0.16%

143
Chapter 7. Evaluation of Design Flaws Detection

Sparsity of Method Code Smell Detection Results


100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Brain Method Shotgun Surgery Dispersed Coupling Message Chains

Affected Systems (%) Not Affected Systems (%)

Figure 46: Sparsity of Class Code Smells Detection Results

Impact of Filters-Aware Detection

An important part of our detection approach is the introduction of filters,


aimed at reducing the number of false positives among the code smells de-
tection results. Table 19 reports the impact of the filters-aware detection.
Filters have a greater impact on detection results for some code smells re-
spect to the others. The difference in terms of impact is due either to the
characteristics of the analysed system, either to the different number of fil-
ters we propose for the different code smells.

Table 19: Impact of Filters-Aware Detection 21

Code Smell Strong Filtered Weak Filtered


God Class 28/836 (3.35%) 47/808 (5.82%)
Data Class 118/1,723 (6.85%) 18/1,605 (1.12%)
Brain Method - -
Shotgun Surgery 11/508 (2.17%) 177/497 (35.61%)
Dispersed Cou- 367/3,555 (10.32%) -
pling
Message Chains 40/674 (5.93%) -

21
The – symbol means that we do not introduce filters for the corresponding code smell
144
Chapter 7. Evaluation of Design Flaws Detection

Strong Filters

Strong Filters reduce the number of code smells detection results, removing
some entities that we do not consider a problem for the system quality. The
mean of strong filtered code smells, among the six we investigate, is ap-
proximately 6%. Removing the six percent of code smells from the results
is a good enhancement, because each code smell requires some time to be
investigated by the user. The numbers we report in Table 19 refer to 39 out
of 74 systems where we find at least one code smell to filter. This means
that it is quite common to find some entities that have to be filte red out.

Weak Filters

Weak Filters identify some additional information to show to the user along
with the detection results. The user can use this information to decide
whether to investigate the entity. The mean of weak filtered code smells,
among the six we investigate, is approximately 14%. The Shotgun Surgery
code smell is the one with the higher percentage (35.61%). The Shotgun
Surgery percentage is high because there are many getter and setter methods
that we cannot filter with a Strong Filter.

Harmfulness of Code Smells

Figure 47 shows the harmfulness distribution for each of the six analysed
code smell. The distribution for God Class, Data Class, Brain Method, and
Shotgun Surgery is similar although with different percentag es. The most
common harmfulness level is Problem, the rarest is Bother. Bother is the
rarest also for Dispersed Coupling and Message Chains. A low number of
code smells with a Bother harmfulness is an evidence of the fact that the
metrics and the corresponding thresholds we use for define detection strat-
egies, well characterize entities affected by code smells.
The Message Chains code smell is the only one that has its harmfulness
label in the range of Warning – Problem. This happens due to the distribu-
tion of the metrics we use for the detection of this code smell. As reported
in Table 132 in Appendix C2, the three metrics we use in the detection
strategy (MaMCL, MeMCL, and NMCS) are distributed in a little range of
values.

145
Chapter 7. Evaluation of Design Flaws Detection

The results we obtain in terms of the harmfulness distribution show the im-
portance of this index. We use the harmfulness to sort the code smells de-
tection results to show them to users in a priority order. A user that has only
the time to investigate the most critical problems, he can for example refers
only to the Harm code smells. In this way, the user can check only nearly
10% of detection results, which are the most harmfulness in terms of the
values of the metrics used by the detection strategies.

Harmfulness Distribution Chart


100,00%

90,00%

80,00%

70,00%

60,00%

50,00%

40,00%

30,00%

20,00%

10,00%

0,00%
Brain Shotgun Dispersed Message
God Class Data Class
Method Surgery Coupling Chains
Harm (%) 19,18% 22,49% 8,11% 5,84% 13,05% 0,00%
Problem (%) 54,33% 64,92% 64,16% 45,67% 21,30% 40,69%
Trouble (%) 22,77% 10,16% 23,10% 32,19% 39,02% 24,29%
Warning (%) 3,47% 2,37% 4,59% 14,69% 26,63% 35,02%
Bother (%) 0,25% 0,06% 0,04% 1,61% 0,00% 0,00%

Figure 47: Code Smell Harmfulness Distribution Chart

Related Code Smells

As part of our detection approach, we identify related code smells, which


are particularly useful to better understand and investigate the detected code
smells.

146
Chapter 7. Evaluation of Design Flaws Detection

God Class

The set of related code smells we identify for God Class is:

A. Data Classes used by the God Class;


B. Classes with code smells that call the God Class;
C. Other code smells inside the God Class.

Table 20 shows some statistics for each set of related code smells, where:

 Min is the minimum number of entities related to one God Class that
is affected by code smell;
 Max is the maximum number of entities related to one God Class
that is affected by code smell
 > 0 (#) is the number of God Class with at least one related of the
type reported on the corresponding column;
 > 0 (%) is the percentage of God Class with at least one related code
smell of the type reported on the corresponding column.

Table 21 to Table 25 follow the same format.

Table 20: God Class Related Code Smells Statistics

A B C
Min 0 0 0
Max 12 41 25
> 0 (#) 207 468 464
> 0 (%) 25.62% 57.92% 57.43%

There is a large number of God Class that access data from Data Classes. A
very large number of entities affected by God Class are called by at least
one class that contains code smells (57.92%). Approximately 60% of the
God Classes has at least one method affected by at least one of the method
code smell we investigate.

147
Chapter 7. Evaluation of Design Flaws Detection

Data Class

The only one related code smell we identify for Data Class is:

A. Classes with code smells that call the Data Class

The data reported in Table 21 shows that 38% of the Data Classes are used
by other classes affected by code smells. We investigate these classes and
find out that God Class affects most of them.

Table 21: Data Class Related Code Smells Statistics

A
Min 0
Max 9
> 0 (#) 307
> 0 (%) 38.00%

Brain Method

The set of related code smells we identify for Brain Method is:

A. Other code smells inside the Brain Method;


B. Code smells on the class that contains the Brain Method;
C. Classes with code smells that call the Brain Method.

Table 22 shows that the number of method that are affected by Brain Method
and at least one other code smell is low (9.85%), approximately 16% of
Brain Methods are in classes affected by code smells (mainly God Class)
and are called seldom by entities affected by code smells.

Table 22: Brain Method Related Code Smells Statistics

A B C
Min 0 0 0
Max 2 1 5
> 0 (#) 266 432 137
> 0 (%) 9.85% 15.99% 5.07%

148
Chapter 7. Evaluation of Design Flaws Detection

Shotgun Surgery

The set of related code smells we identify for Shotgun Surgery is:

A. Classes with code smells that call the Shotgun Surgery;


B. Code smells on the class that contains the Shotgun Surgery;
C. Other code smells inside the Shotgun Surgery.

Table 23: Shotgun Surgery Related Code Smells Statistics

A B C
Min 0 0 0
Max 11 1 2
> 0 (#) 262 150 53
> 0 (%) 52.72% 30.18% 10.66%

As reported in Table 23, Shotgun Surgery is called by a large number of


classes affected by code smells. The Shotgun Surgery is a code smell that
identifies those methods that are called by a large number of classes; our
analysis shows that almost 50% of the classes that call a Shotgun Surgery
are affected by at least one code smell. Approximately 30% of classes that
contain at least a method affected by Shotgun Surgery are affected by a code
smell. Only the 11% of the Shotgun Surgery methods are affected also by
other code smells.

Dispersed Coupling

The set of related code smells we identify for Dispersed Coupling is:

A. Classes with code smells among the classes that Dispersed Coupling
calls;
B. Code smells on the class that contains the Dispersed Coupling;
C. Other code smells inside the Dispersed Coupling.

Quite often (70% of the times, as reported in Table 24) the classes that Dis-
persed Coupling calls are affected by code smells. Approximately 17% of
the classes that contain Dispersed Coupling are affected by code smells,

149
Chapter 7. Evaluation of Design Flaws Detection

while only the 8% of the method affected by Dispersed Coupling are af-
fected also by other code smells.

Table 24: Dispersed Coupling Related Code Smells Statistics

A B C
Min 0 0 0
Max 47 1 2
> 0 (#) 2,242 531 254
> 0 (%) 70.33% 16.66% 7.97%

Message Chains

The set of related code smells we identify for Message Chains is:

A. Other code smells inside the Message Chains;


B. Code smells on the class that contains the Message Chains.

Approximately 27% of the Message Chains methods are affected by at least


another code smell and 21% of the classes that contains Message Chains are
affected by code smells.

Table 25: Message Chains Related Code Smells Statistics

A B
Min 0 0
Max 2 1
> 0 (#) 172 131
> 0 (%) 27.13% 20.66%

Table 20 to Table 25 show that a code smell is often not isolated. It is com-
mon having at least another related code smell, and this happens in almost
all the systems we investigate (refers to Appendix E1). It is important to
capture and to show these relations to the users, they are fundamental to
better understand the impact of code smell in the systems, and decide the
best way to remove it. Consider for example a God Class, knowing if it uses
150
Chapter 7. Evaluation of Design Flaws Detection

some Data Classes can be relevant to understand how to refactor the God
Class. We can for example move some methods from the God Class to the
Data Classes it uses, to remove both God Class and Data Classes [51].

Code Smells Co-Occurrence

Table 26 reports methods code smells co-occurrence, that summarizes part


of the information regarding the related code smells discussed above (the
ones in the form of “Other code smells inside the given code smell”). Co-
occurrence of two investigated class code smells is zero, because they de-
scribe classes with completely different characteristics.

Table 26: Methods Code Smells Co-Occurrence

Two Code Smell Three Code Smell Four Code Smell


161/2.73% BM-DCO 3/0.07% SS-DCO-MC 0/0.00%
85/2.55% BM-MC 2/0.03% BM-DCO-MC BM-SS-DCO-MC
78/2.04% DCO-MC 1/0.02% BM-SS-DCO
14/1.24% SS-MC 0/0.00% BM-SS-MC
23/0.72% BM-SS
20/0.54% SS-DCO

LEGEND:
BM: Brain Method, SS: Shotgun Surgery, DCO: Dispersed Coupling and
MC: Message Chains.

In the reference dataset of 74 systems, at least two code smells affect ap-
proximately 1-2% of the methods. The most common co-occurrence couples
are Brain Method – Dispersed Coupling and Brain Method – Message
Chains. The Brain Method code smell tends to centralize the intelligence of
the class that contains it, often this means that it tends to interact with many
classes, hence the co-occurrence with two code smells that impacts on cou-
pling quality dimension.

151
Chapter 7. Evaluation of Design Flaws Detection

7.2 Validation of the Approach


We evaluate the effectiveness of our detection approach performing
two experimentations:

1. A qualitative comparison of JCodeOdor detection approach with


inFusion [143], a valid code smells detection tool;
2. A qualitative and quantitative comparison with the machine learn-
ing code smells detection approach (MLCS) by Marino in [95]. In
this experiment, we manually investigate a system to find out all
the affected entities, and then we compare JCodeOdor detection
results versus MLCS detection results.

The first experiment aims at comparing our detection approach and detected
code smells with the one proposed by inFusion. We evaluate the usefulness
of the harmfulness labels and the values we associate to each of the detected
code smell, the impact of the filters and the views we propose as part of our
detection approach. The second experiment allows us to investigate the dif-
ferences respect to another approach in the area of code smells detection.
Starting from the manually marked affected entities we use in the second
experimentation, we compare the precision and the recall of our detection
approach respect to the MLCS approach and the inFusion one and we report
the result in Section 7.2.4.

7.2.1 Comparison with inFusion


We decide to compare our approach versus inFusion because it is a
commercial tool released in a stable version, and is the only one that shows
the results in a prioritized way (using and index called severity), similar to
what JCodeOdor does using the harmfulness value.
inFusion detects five out of the six code smells we detect in JCodeOdor.
The one it does not detect is Dispersed Coupling. To make the comparison
possible, we map the code smells detected by inFusion to the ones detected
by JCodeOdor. Because inFusion has not an official reference where the
detected code smells are defined, we refer to the definition it reports along
with the detection results directly inside the tool.

152
Chapter 7. Evaluation of Design Flaws Detection

We select a system on which to detect code smells with both inFusion and
JCodeOdor. The criteria we use for the selection of the system are:

 Large enough to expect a consistent number of affected entities;


 Well documented: we need a developer documentation to effectively
analyse the design choices and understand if the detected code smell
represents or not a problem for the system quality.

The selected system is Heritrix, “the Internet Archive's open-source, exten-


sible, web-scale, archival-quality web crawler project” [32], because it has
a developer documentation manual [58] and is well described in a paper by
the creators [32]. Table 27 shows some statistics that describe the system in
terms of size measures.

Table 27: Heritrix Systems Size Measures

Number of Number of Number of


Lines of Code
Packages Classes Methods
94,240 45 649 5,366

In the rest of this section, we discuss the detection results for each of the
five code smells we share with inFusion, reporting also the harmfulness
(i.e., the harmfulness value for JCodeOdor, and the severity value for inFu-
sion). For each code smell we compute the agreement and the Cohen’s
Kappa [24] between the JCodeOdor and inFusion detection results. The
agreement is a measure of the overall consistency of the detection results,
while the Cohen’s kappa is a statistical measure of inter-rater agreement for
qualitative (categorical) items, which takes into account the agreement oc-
curring by chance. Zero or negative values indicate no accordance; values
close to one indicate good accordance. Viera et al. group Cohen’s Kappa
statistic values into six categories of agreement [129], as reported in Table
28. Using these six categories, we can better understand the results we ob-
tain when we compute Cohen’s Kappa statistic.

153
Chapter 7. Evaluation of Design Flaws Detection

Table 28: Interpretation of Cohen’s Kappa Statistic Values

Kappa statistic values Level of agreement


< 0 Less that chance agreement
0.01 – 0.20 Slight agreement
0.21 – 0.40 Fair agreement
0.41 – 0.60 Moderate agreement
0.61 – 0.80 Substantial agreement
0.81 – 0.99 Almost perfect agreement

We use these values to have a quick statistical look in the detection results,
and then we go on with a qualitative analysis.

God Class

Table 29 shows the agreement and Cohen’s Kappa [24] between JCodeOdor
and inFusion detected God Classes, while Table 30 reports the detection
results for both the tools. Table 171 in Appendix E2 shows the detection
result using the JCodeOdor detection results presentation (see Section
6.2.4). We define God Class in Section 6.3.1, inFusion defines God Class
as:

 The class is excessively large and complex, due to its methods hav-
ing a high cyclomatic complexity and nesting level;
 This class is very non-cohesive, in terms of how class attributes are
used by its methods;
 The class uses many attributes from external classes, directly or
via accessor methods.

Table 29: God Class Detection Results Comparison with inFusion


JCodeOdor

inFusion
None

Both

Code Smell Agreement Kappa

God Class 679 3 5 12 0.99 0.74

154
Chapter 7. Evaluation of Design Flaws Detection

Table 30: JCodeOdor and inFusion God Class Detection Results

JCodeOdor inFusion

Entity Name Harmfulness Entity Name Harmfulness

CrawlController Harm (10) FetchHTTP 10

CachedBdbMap Harm (10) AbstractFrontier 10

CrawlJobHandler Harm (10) AdaptiveRevisitFrontier 9

AbstractFrontier Harm (10) StatisticsTracker 9

StatisticsTracker Harm (10) WorkQueueFrontier 8

Heritrix Problem (9.55) PreconditionEnforcer 7

FetchHTTP Problem (9.55) WriterPoolProcessor 7

WriterPoolProcessor Problem (9.10) ToeThread 6

CrawlSettingsSAXSource Problem (7.75) CrawlJobHandler 5

AdaptiveRevisitFrontier Problem (7.75) CrawlSettingsSAXSource 5

WorkQueueFrontier Problem (7.75) CrawlServer 4

SettingsHandler Problem (7.75) CrawlController 3

ToeThread Problem (7.75) Heritrix 3

WARCWriterProcessor Trouble (5.95) CrawlURI 3

Processor Warning (3.70) MirrorWriterProcessor 2

SettingsHandler 2

ARCReader 2

JCodeOdor and inFusion have a very high agreement and a high Kappa,
which means the two tools substantially agree in identifying God Classes.

Overview of God Class Detection Results

Most of the detected God Classes identified by JCodeOdor are t he same as


the ones identified by inFusion. We use the red colour to emphasize them
in Table 30. We could expect this result because the definitions of the code
smell are almost equal. A large number of the God Classes detected in Her-
itrix are part of the Frontier, a component of Heritrix design (refer to Sec-
tion 4.1 of Heritrix developer documentation [58]). The developer docu-
mentation describes the Frontier as: “The Frontier is responsible for hand-

155
Chapter 7. Evaluation of Design Flaws Detection

ing out the next URI to be crawled. It is responsible for maintaining polite-
ness, which is making sure that no web server is crawled too he avily. After
a URI is crawled, it is handed back to the Frontier along with any newly
discovered URIs that the Frontier should schedule for crawling” .
The main problem of classes that are part of the Frontier that make them
God Classes, is that they are written without separation of concern in mind.
All the detected God Classes in this component of Heritrix system are very
large and expose different functionalities, like: handling of the order of
URIs to be crawled, keeping state of the crawler using files, and manage
bandwidth. Reorganizing the concern in different classes definitely im-
proves the quality and comprehensibility of the code, thus removing the
identified God Classes.

Main Differences between JCodeOdor and inFusion Detection Results

The most harmful God Class JCodeOdor detects and inFusion does not de-
tect is CachedBdbMap. This class implements java.util.concurrent.Concur-
rentMap<K,V>, and the complexity and size of the class is a consequence
of the intrinsic complexity of the map data structure. We think that this class
can be considered a good design choice, and so we do not want it to be
reported as God Class. JCodeOdor fails in this case, but offers a function-
ality that allows us to enhance the detection result gathering knowledge
from this analysis: the filters. This type of situation is suited to be handled
with a Strong Filter of the “Library Implementer or Extender” category.
Another God Class that inFusion detects and JCodeOdor does not is Pre-
conditionEnforcer. PreconditionEnforcer, as reported by the developer doc-
umentation [58], “makes sure dns and robots are checked ahead of any
fetching”. Analysing PreconditionEnforcer class we think that this is not a
God Class because it is a quite cohesive class (TCC: 0.60) and implements
a single and well-defined functionality.

Impact of Filters on the Detection Results

As reported in Table 171 in Appendix E2 we filter out one God Class with
a Strong Filter, and we mark CrawlSettingsSAXSource with the “Parser”
Weak Filter. CrawlSettingsSAXSource is God Class for both JCodeOdor and

156
Chapter 7. Evaluation of Design Flaws Detection

inFusion. This class implements an XML reader from the SAX Parser pro-
ject [149]. Marking this class with the “Parser” label is a hint to the user to
decide if or not to investigate the class.

Evaluation of the Harmfulness

inFusion does not explicitly defines how the index it uses to prioritize code
smells presentation to the user, called severity, is computed. For some de-
tected God Class the JCodeOdor and inFusion have similar prioritization
index values (e.g., AbstractFrontier), for other the values are different (e.g.,
CrawlController and CrawlJobHandler). Respect to the JCodeOdor harm-
fulness the severity computed by inFusion is distributed among more val-
ues. Because inFusion is a tool developed by Intooitus, a startup co-founded
by R. Marinescu, and after a deep analysis of the severity results, we think
that inFusion could implements the “Severity” introduced by R. Marinescu
in [92]:

“Severity is computed by measuring how many times the value of a chosen


metric exceeds a given threshold. For example, in God Class, the severity
is based on the ATFD metric.”

This way of calculate harmfulness does not assign a value based on the dis-
tribution of the metrics used by the detection strategy. Looking at the re-
sults, we do not think for example that StatisticsTracker and Heritrix clas-
ses should have a completely different harmfulness, like the ones assigned
by inFusion. In our opinion, a similar harmfulness for these two classes, as
for JCodeOdor detection result, is more correct. This because the two clas-
ses have similar God Class characteristics, as reported in Table 31: are large
and complex, non-cohesive and use many data from other classes. inFusion
uses only ATFD metric for compute harmfulness, which is the only metric
higher for StatisticsTracker respect to Heritrix.

157
Chapter 7. Evaluation of Design Flaws Detection

Table 31: Harmfulness Comparison between JCodeOdor and inFusion

LOC- NOM- WMC- TCC


ATFD
NAMM NAMM NAMM
Statis-
1,080 62 27 147 0.13
ticsTracker
Heritrix 2,453 101 16 325 0.22

Evaluation of JCodeOdor Views

We now demonstrate the views we propose, as part of JCodeOdor detection


approach. We do not implement yet these views in JCodeOdor, but we al-
ready store in our model all the information needed to realize them. The
mockups we present in the following fully comply with the visualization
framework we discussed in Section 6.2.5. We reduce only the space dedi-
cated to the views due to page layout constraints. We use as an example the
proposed views to investigate the God Class CrawlJobHandler, classified
with a Harm harmfulness level, and identified as God Class also by inFu-
sion. The first view we propose to user is the Code Smell Profile View
(Figure 48), whose purpose is to show to the user the main characteristics
of the entity captured by the code smells detection strategy.

158
Chapter 7. Evaluation of Design Flaws Detection

Crawl-
Setting

CrawlJob

Crawl-
JobErro-
rHandler
Crawl-
JobHandler
GC Setting-
sHandler
GC

XMLSet-
tingsHand-
ler

Com-
plexType

Detection Strategy Metrics Values


LOCNAMM WMCNAMM ATFD TCC NOMNAMM
1,228 173 26 0.25 55

Additional Information
NOPA NOAM STATIC
≥ HIGH ≥ HIGH false

Figure 48: CrawlJobHandler God Class Profile View.

Looking at the CrawlJobHandler God Class Profile View, the user can im-
mediately see that CrawlJobHandler interacts a lot with CrawlJob. Moreo-
ver, he notices that CrawlJobHandler uses some attributes from the Set-
tingsHandler God Class, which has a Problem harmfulness level. Starting

159
Chapter 7. Evaluation of Design Flaws Detection

from these evidences, the user can decide to investigate method s of


CrawlJobHandler accessing attributes from CrawlJob. When he does this,
he finds that one of them, loadJob(File), has a comment “Move test into
CrawlJob”. This is a clear sign that something is wrong in design choices,
then he could decide to refactor loadJob(File) moving it to CrawlJob.
When he proceeds the investigation, he analyses the interactions with Set-
tingsHandler. He understands that these relations exists to manage settings
of jobs added during time to the crawler queue, hence he decides to do not
change anything respect to this.
The last set of attributes accesses he could decide to analyse are the ones
from CrawlerSetting, CrawlJobErrorHandler, XMLSettingsHandler, and
Complextype. During the investigation, he identifies some methods that
manage a profile, which “is a template for a crawl job. It contains all the
configurations that a crawl job would” [58]. He annotates these fact and
proceeds with the investigation.
The second view we propose to the user is the Code Smell Context View.
We propose this view to offer to the user a contextualization of the detected
code smell in the system. We do this visualizing the interaction of other
parts of the system with the code smell. Figure 49 shows this view for
CrawlJobHandler. The user can see that some classes call CrawlJob-
Handler, and one of them is a God Class. This could be due to the “≥ HIGH”
Number of Public Attributes (NOPA) and Number of Public Methods
(NOAM) CrawlJobHandler exposes.

160
Chapter 7. Evaluation of Design Flaws Detection

Crawl-
Setting
JobConfi-
gureUtils

CrawlJob

Heritrix

Crawl-
GC JobErro-
rHandler
Crawl-
SelfTest- JobHandler
Crawl- GC Setting-
JobHand-
ler sHandler
GC

XMLSet-
CrawlJob tingsHand-
ler

Com-
plexType

Detection Strategy Metrics Values


LOCNAMM WMCNAMM ATFD TCC NOMNAMM
1,228 173 26 0.25 55

Additional Information
NOPA NOAM FANIN STATIC
≥ HIGH ≥ HIGH ≥ LOW false

Figure 49: CrawlJobHandler God Class Context View.

Last view we propose to the user is the Related Code Smell View. We pro-
pose this view because often code smells are related to other code smells,
and this information is useful to understand how to approach their removal.
Figure 50 shows the related code smells for CrawlJobHandler. Heritrix, a
161
Chapter 7. Evaluation of Design Flaws Detection

God Class with harmfulness level equal to Problem, calls methods and ac-
cesses attributes from CrawlJobHandler. Moreover, one of the methods de-
clared by CrawlJobHandler, loadProfiles(), is affected by a Brain Method
with harmfulness equal to Trouble. This method is part of the set of methods
that manage a profile, identified during the first step of analysis of
CrawlJobHandler. The user definitively decides to refactor these methods
to enhance design quality. All the methods that manage a profile access only
one variable from CrawlJobHandler, hence he decides to refactor these
methods extracting a class to contain them, because they offer a high cohe-
sive functionality that can be moved to a dedicated class. After extracting
the class, moving also loadProfiles(), he decides to apply the extract method
refactoring to loadProfiles(), so that he could remove Brain Method and
enhance comprehensibility of the method previously affected by the Brain
Method code smell.

calls methods and uses attributes from Crawl-


Heritrix
JobHandler
GC
GC
belongs to

loadProfi-
les()
BM

Figure 50: Related CrawlJobHandler God Class View.

After performing the discussed refactorings, identified thanks to the set of


customized views, the user is able to improve the quality of the design,
removing the identified code smell, and another he identifies thanks to the
Related Code Smell View.

162
Chapter 7. Evaluation of Design Flaws Detection

inFusion also offers some views to visualize some aspects of the presence
of a code smell. Despite this, the proposed views are not designed to capture
the specific properties of each code smell. They are instead related to five
“quality attributes”: size & complexity, encapsulation, cohesion, coupling
and hierarchies [143]. inFusion proposes four views:

 Internals view: uses colours to show collaboration of methods and


data (calls, accesses) within the selected class. Helps to explore co-
hesion and complexity;
 Encapsulation view: uses colours to show the data exposed by class,
and the external data used by the class (directly or via accessor meth-
ods);
 Coupling view: uses colours to show the methods of the class that
call or are called by external methods, and these external collaborator
methods;
 Hierarchy view: uses colours to show all the hierarchy-specific in-
teractions between the class and all its ancestors and descendants.
Helps to explore interactions within hierarchies.

Through these views, the user can explore some of the information we pro-
pose on our views, but he has to understand a more complex and less intui-
tive visualization framework, and the association of a large number of col-
our to the corresponding semantic. In fact, the views inFusion proposes use
the same layout, but the colours are specific to each type of view [143]. For
God Class it proposes to the user to open the Internals view (Figure 51),
which shows information very close to the one we offer to the user with the
Profile View.

163
Chapter 7. Evaluation of Design Flaws Detection

Figure 51: inFusion CrawlJobHandler God Class Internals View

We think that the Internals view proposed by inFusion is more complex to


understand respect to the Profile View we propose, and we argue that one
of the reasons is that inFusion does not select specific characteristics to
show, given the code smell to visualize to the user.
Respect to our Context View, inFusion has a Coupling view that has a similar
purpose. The main difference is that our Context View directly shows to the
user the interesting relations among entities, while using the Coupling view
proposed by inFusion, the user has to select its elements (i.e., the blocks in
Figure 51) to show the relations. inFusion, even having this view, does not
propose to the user to use the view to explore the God Class.
For what concern additional information we show, inFusion presents some
information related to the “quality attributes”, but does not select them for

164
Chapter 7. Evaluation of Design Flaws Detection

each code smell, hence the user has to understand by himself what is inter-
esting and what it is not. The Related Code Smell View has not an equiva-
lent view in inFusion.

Data Class

Table 32 shows the agreement and Cohen’s Kappa [24] between JCodeOdor
and inFusion detected Data Classes, while Table 33 reports the detection
results for both the tools. Table 172 in Appendix E2 shows the detection
result using the JCodeOdor detection results presentation (see Section
6.2.4). We define Data Class in Section 6.3.2, inFusion define Data Class
as:

 The class is exposing a significant amount of data in its public


interface, either via public attributes or via public accessor methods.

Table 32: Data Class Detection Results Comparison with inFusion


JCodeOdor

inFusion
None

Both

Code Smell Agreement Kappa

Data Class 691 5 3 0 0.99 0.00

Table 33: JCodeOdor and inFusion Data Class Detection Results

JCodeOdor inFusion

Entity Name Harmfulness Entity Name Harmfulness

MatchesFilePatternDeci… Harm (10) CrawlSubstats 3

LowDiskPauseProcessor Problem (9.25) SettingsFrameworkTes… 2

RegexpLineIterator Problem (8.50) SeedRecord 1

StringIntPair Problem (7.75)

DomainScope Trouble (7.00)

165
Chapter 7. Evaluation of Design Flaws Detection

JCodeOdor and inFusion have a very high agreement, because most of the
classes are detected as not affected by Data Class. The Cohen’s Kappa is
zero, which means the two tools disagree in identifying Data Classes.

Overview of Data Class Detection Results

JCodeOdor and inFusion completely disagree respect to the identified Data


Classes. This is due to the differences in the definition we follow to detect
a Data Class. For JCodeOdor a Data Class has to expose a significant
amount of data in its public interface (like for inFusion), but also must have
a low complexity and does not handle the data it exposes. All the differences
in terms of detection results can be explained by the differences in the def-
inition of Data Class, because:

 CrawlSubstats: it exposes a high number of data but it is cohesive,


because it manages the update of statistics (see Section 12 of Heritrix
developer manual [58]) based on the status of the crawled URI;
 SettingsFrameworkTestCase: it is a class that “sets up a couple of
settings to test different functions of the settings framework” as re-
ported by the javadoc, and it is cohesive;
 SeedRecord: it “records of all interesting info about the most-recent
processing of a specific seed”, as reported by the Javadoc, and offers
the functionalities to save and update the info it manages.

The Data Class identified by JCodeOdor are almost all data container clas-
ses. One of them that is also the most harmful one, MatchesFilePatternDe-
cideRule, corresponds also to the Pool micropattern [54] and we show this
to the user as additional information in the views we offer to evaluate Data
Class.

Impact of Filters on the Detection Results

As reported in Table 172 in Appendix E2 we filter out one Data Class with
a Strong Filter. The name of the filtered Data Class in Link, and is filtered
because it implements Serializable. This class represent an edge in the web
navigation graph Heritrix builds during the crawling of a web site. Because

166
Chapter 7. Evaluation of Design Flaws Detection

the graph has to be serialized, we think this class is not a problem for the
quality of the system and it is a good choice to filter it out.
Among the Data Classes detected by inFusion there is one named Settings-
FrameworkTestCase that as the name says, implements a TestCase to test
different functions of the SettingsFramework of Heritrix (see Section 5 of
Heritrix developer documentation [58]). This class is part of the package
“org.archive.crawler.settings” of Heritrix and it is not separated in a pack-
age dedicated exclusively to collect test case, which is a common choice
during the development of a system. We think that this class cannot be con-
sidered a problem for the system quality, because it is not really part of the
system and should not be proposed to the user. If inFusion had implemented
the filters, we propose as part of our detection approach, it could avoid this
type of wrong results.

Brain Method

Table 34 shows the agreement and Cohen’s Kappa [24] between JCodeOdor
and inFusion detected Brain Methods, while Table 35 reports the detection
results for both the tools. Table 173 in Appendix E2 shows the detection
result using the JCodeOdor detection results presentation (see Section
6.2.4). We define Brain Method in Section 6.3.3, inFusion calls Brain
Method with the name of “Blob Operation”, and defines it as:

 The method is excessively large and complex, having a high cy-


clomatic complexity and nesting level.

Table 34: Brain Method Detection Results Comparison with inFusion


JCodeOdor

inFusion
None

Both

Code Smell Agreement Kappa

Brain
5,323 20 19 4 0.99 0.17
Method

167
Chapter 7. Evaluation of Design Flaws Detection

Table 35: JCodeOdor and inFusion Brain Method Detection Results

JCodeOdor inFusion

Entity Name Harmfulness Entity Name Harmfulness

importQueuesFrom... Problem (9.44) processGeneralTag… 7

processGeneralTag(… Problem (9.10) handleJobAction(C… 6

uriToFile(String,Cr… Problem (9.10) processGeneralTag(… 6


handleJobAction(Cr… Problem (9.10) parseUriReference(… 6

processGeneralTag(… Problem (9.10) uriToFile(String,Cr… 6

tail(RandomAccessF… Problem (8.88) processGeneralTag(… 6

checkAttribute(Mod… Problem (8.88) doCmdLineArgs(Str… 5

getByRegExpr(Inpu… Problem (8.88) main(String[]) 5

getByRegExpr(Inpu… Problem (8.88) main(String[]) 5

importCompletionIn… Problem (8.88) innerProcess(Crawl… 5

extract(CrawlURI) Problem (8.31) load(String) 5

format(Matcher,Stri… Problem (8.31) CrawlJob(File,Craw… 5


processBdbLogs(Fil… Problem (8.31) Robotstxt(Buffered… 5

load(String) Problem (7.75) fixup(String,URI,St… 5

buildRegex(String,S… Problem (7.75) invoke(String,Objec… 4

next() Trouble (7.30) uriToFile(CrawlURI… 4

initialize(CrawlCont… Trouble (6.63) innerProcess(Crawl… 4

replaceComplexTyp… Trouble (6.40) putIfAbsent(Object,… 4

loadProfiles() Trouble (6.06) invoke(String,Objec… 4

loadCookies(String) Trouble (6.06) finished(CrawlURI) 3

getFrom(FrontierM… Trouble (5.50) parseHeaders(Input… 3

filesFoundInArc() Trouble (5.50) fetch(CrawlURI,Clie... 3

enforceBandwidthT… Warning (4.60) createWcdx(ARCRe… 2

_getDisk(Object) Warning (4.38)

The Cohen’s Kappa is 0.17, which means the two tools slight agree in iden-
tifying Brain Methods.

168
Chapter 7. Evaluation of Design Flaws Detection

Overview of Brain Method Detection Results

Both JCodeOdor and inFusion identify almost the same more harmfulness
methods, but the rest of the detection results are different. A deep look at
the detection results allows us to conclude that the difference is mainly due
to the differences in the definition of Brain Method between the tools. in-
Fusion search only for methods that are large and complex, we consider also
that the method has to access local data of the class or have a large number
of local variable.
We think that both the tools detect relevant entities respect to the corre-
sponding definition.

Shotgun Surgery

Table 36 shows the agreement and Cohen’s Kappa [24] between JCodeOdor
and inFusion detected Shotgun Surgeries, while Table 37 reports the detec-
tion result for both the tools. Table 174 in Appendix E2 shows the detection
result using the JCodeOdor detection results presentation (see Section
6.2.4). We define Shotgun Surgery in Section 6.3.4, inFusion defines it as:

 The method has a large number of external operations calling it,


and these operations are spread over a significant number of dif-
ferent classes. As a result, the impact of a change in this method will
be large and widespread;
 At the same time, the method is calling a large number of external
operations. This means that the method itself is prone to change,
which in turn will impact its many clients.

Table 36: Shotgun Surgery Detection Results Comparison with inFusion


JCodeOdor

inFusion
None

Both

Code Smell Agreement Kappa

Shotgun Surgery 841 3 0 0 1.00 0.00

169
Chapter 7. Evaluation of Design Flaws Detection

Table 37: JCodeOdor and inFusion Shotgun Surgery Detection Results

JCodeOdor inFusion

Entity Name Harmfulness Entity Name Harmfulness

setAttribute(Crawle… Problem (8.50) - -

getController() Problem (7.75)

addLabelValue(Stri… Trouble (5.50)

The Cohen’s Kappa [24] is zero because inFusion does not detect any Shot-
gun Surgery, while JCodeOdor detects three Shotgun Surgery.

Overview of Shotgun Surgery Detection Results

The differences in the detection results are probably due to the differences
in the threshold JCodeOdor and inFusion uses to detect Shotgun Surgery,
given that the definition are almost equal. It is known in the literature that
inFusion is generally more conservative [5], hence it detects as “smelly”
less entities. The methods affected by Shotgun Surgery we detect in Heritrix
are methods that are called by a large number of classes and methods, and
interact with many other classes. One of them, getController(), is affected
also by Message Chains. getController() method return the controller that
handle the crawling process, a change in the signature of this methods will
impact many other classes.

Message Chains

Table 38 shows the agreement and Cohen’s Kappa [24] between JCodeOdor
and inFusion detected Message Chains, while Table 39 reports the detection
result for both the tools. Table 175 in Appendix E2 shows the detection
results using the JCodeOdor detection results presentation (see Section
6.2.4). We define Message Chains in Section 6.3.6, inFusion defines it as:

 The method uses one object to access another object, then uses the
obtained object to access another object, and so on, all objects having
different types.

170
Chapter 7. Evaluation of Design Flaws Detection

Table 38: Message Chains Detection Results Comparison with inFusion

JCodeOdor

inFusion
None

Both
Code Smell Agreement Kappa

Message
27 6 0 11 0.86 0.69
Chains

Table 39: JCodeOdor and inFusion Message Chains Detection Results

JCodeOdor inFusion

Entity Name Harmfulness Entity Name Harmfulness

evaluate(Object) Problem (7.75) evaluate(Object) 3

evaluate(Object) Problem (7.75) evaluate(Object) 1

buildSurtPrefixSet() Problem (7.75) getDiversionLog(Str… 1

dumpSurtPrefixSet() Problem (7.75) kickUpdate() 1

getSeedfile() Problem (7.75) buildSurtPrefixSet() 1

readPrefixes() Problem (7.75) readPrefixes() 1

kickUpdate() Problem (7.75) getSeedfile() 1


importRecoverLog(… Problem (7.75) dumpSurtPrefixSet() 1

getDiversionLog(Str… Problem (7.75) loadMap() 1

loadMap() Problem (7.75) importRecoverLog(…) 1

readPrefixes() Problem (7.75) writeRequest(WAR… 1

DecideRule:getCont… Problem (7.75) readPrefixes() 1

initialTasks() Problem (7.75)

loadCheckpointSeri… Problem (7.75)

Processor:getContro… Problem (7.75)

execute(Object) Trouble (5.50)

writeHostsReportTo… Trouble (5.50)

JCodeOdor and inFusion have a high agreement, because most of the meth-
ods are detected as not affected by Message Chains. The Cohen’s Kappa

171
Chapter 7. Evaluation of Design Flaws Detection

[24] is 0.69, which means the two tools substantially agree in identifying
Message Chains.

Overview of Message Chains Detection Results

JCodeOdor identifies six Message Chains more than inFusion, among the
less harmful. Analysing the entities affected by Message Chains we identify
that all the identified methods have a chain of at least three classes. Respect
to the harmfulness JCodeOdor generally sets the harmfulness to higher val-
ues, because of the differences in the computation. We think that both tools
perform well, and the Message Chains JCodeOdor identifies and inFusion
does not, are relevant results. In fact, they have a chain of at least three
classes and an average of five Message Chains Statement (NMCS) that in-
volve different classes.

Because inFusion does not detect Dispersed Coupling, we cannot compare


our detection results with this tool. We manually inv estigate also the detec-
tion results we obtain for Dispersed Coupling, to understand i f they are rep-
resentative or not of the definition we discussed in Section 6.3.5. We verify
that the obtained results have a high coupling dispersion and intensity be-
cause they are coupled to a large number of classes and call 10 methods out
of 5,366 of Jasml on average. Our detection approach filters 10 false posi-
tive code smells using a Strong Filter. All the filtered code smells are test
methods that are in class mixed with the core classes of Heritrix. The harm-
fulness levels are distributed among Warning, Trouble, Problem, and Harm.
The identified Dispersed Coupling methods call very often classes affected
by God Class and roughly the 40% are in classes that are affected by God
Class. Some of the Dispersed Coupling methods are also affected by other
code smells, like Brain Method and Message Chains.

172
Chapter 7. Evaluation of Design Flaws Detection

7.2.2 Agreement with a Machine Learning Approach


A colleague of mine, A. Marino, during his Master Thesis [95] de-
veloped a Machine Learning Approach to detect code smells (MLCS) using
software design metrics as features of the algorithms he uses. He identified
four code smells to investigate (i.e., God Class, Data Class, Brain Method
and Feature Envy); he manually marked, along with other two master stu-
dents, a set of entities to train a set of six different machine learning algo-
rithm, using different configurations of parameters. After he trained the al-
gorithms, he tested the obtained predictors to select the best one for each of
the four code smells, which he used to detect code smells. He manually
marked nearly 140 affected entities and 280 not affected entities for each
code smell. Table 40 shows the results he obtained in terms of precision,
recall and F-Measure [65] for the three code smells detected also by JCode-
Odor.

Table 40: Statistics of a Machine Learning Code Smells Detection

God Class Data Class Brain Method


Precision 0.99 0.99 0.99
Recall 0.98 0.99 1.00
F-Measure 0.98 0.99 0.99

Because our second experiment, that we discuss in Section 7.2.3, aims at


comparing our detection results with the ones obtained by the MLCS, we
have to know how much our results are similar or differ.
Given that the precision and the recall he obtains is high, we use the entire
set of detected code smells on the 74 systems we present in Section 7.1
instead of only use the manual marking, to compute the agreement and the
Cohen’s Kappa [24] statistic with our detection approach. Table 41 reports
the obtained values.

173
Chapter 7. Evaluation of Design Flaws Detection

Table 41: Detection Results Comparison with a Machine Learning

JCodeOdor

Learning
Machine
None

Both
Code Smell Agreement Kappa

God Class 46,312 9 4,137 799 0.92 0.26


Data Class 45,698 771 1,396 834 0.96 0.41
Brain
368,918 1,151 2,987 1,548 0.99 0.42
Method

The agreement is high for all the code smells because JCodeOdor and MLCS
generally agree that most of the entities are not affected by code smells. The
Cohen’s Kappa [24] statistics shows that for God Class the two approaches
fair agree in judge what is a “smelly” entity and what is not, for Data Class
and Brain Method they moderate agree in the detected “smelly” entities. In
Section 7.2.3 we compare JCodeOdor results with MLCS on one selected
system, and deeply investigate the reasons underlying the obtained Kappa
values. The main motivation is that my colleague and I do not completely
agree respect to all the characteristics to capture in the source code to iden-
tify a given code smell.

7.2.3 Comparison with a Machine Learning Approach


In Section 7.2.2 we verify that the accordance between our approach
and the MLCS approach by A. Marino is quite low, but it is high enough to
assume it possible to build a shared oracle, against which to compare the
performance of the respective detection strategies. To compare the detection
strategies, in terms of the code smells they detected, my colleague and I
selected a system and manually investigated it to find all the “smelly” enti-
ties. The system my colleague and I selected is Jasml [144], that “is a tool
providing alternative ways, other than the commonly used Java program-
ming language, to view and edit the Java class file”, because it satisfy the
following requirements:

 Small enough so it can be manually analysed;

174
Chapter 7. Evaluation of Design Flaws Detection

 Large enough to expect a consistent number of affected entities;


 Well documented: we need a documentation to effectively analyse
the design choices.

Table 42: Jasml Systems Size Measures

Number of Number of Number of


Lines of Code
Packages Classes Methods
6,694 4 48 245

My colleague and I manually investigated Jasml (see Table 42 for some


statistics) to detect all the code smells and mark them. We manually marked
all the six code smells detected by JCodeOdor and one detected only by the
MLCS: Feature Envy [51]. Because JCodeOdor and MLCS detect only three
code smells in common (i.e., God Class, Data Class and Brain Method), we
compared the two approach only for these three code smells. The other code
smells we marked are used in Section 7.2.4, where we compute the effec-
tiveness of our detection approach.
The procedure we followed to investigate Jasml and mark the affected enti-
ties consists of the following steps, where A. Marino and me:

1. independently analyse all the classes and the methods of Jasml and
mark the code smells;
2. compare our marking and discuss every mark where we disagree, to
reduce the bias given by the known sensibility of code smells detec-
tion based on single developer intuition [86]. During the discussion,
we take care of the differences in our perception of the code smell
that affect the entity for which we disagree and we try to find a way
to definitely decide if the entity is affected or not by the code smell.
To do that we deeply investigate Jasml, referring to its documenta-
tion and to our past experience in code smells detection [6][7][47];
3. identify a set of entities affected by code smells to be used as an
oracle.

175
Chapter 7. Evaluation of Design Flaws Detection

Once we constructed the oracle, we detected the code smells using the re-
spective detection strategies. We discuss the obtained results in the follow-
ing of this section. Since the system we manually investigate is small, we
know that we have to take with caution the obtained results.

Agreement and Cohen’s Kappa

Table 43 shows the comparison in terms of agreement and Cohen’s Kappa


between JCodeOdor and MLCS. The two approaches have a good agree-
ment, because they generally agree to consider most of the entities as not
affected by code smell. The Cohen’s Kappa indicates a fair agree for God
Class, no agreement for Data Class and a substantial agreement for Brain
Method. The obtained Kappa statistics indicate that the two approaches
have quite different results in some cases.

Table 43: Agreement between JCodeOdor and Machine Learning


JCodeOdor

Learning
Machine
None

Both

Code Smell Agreement Kappa

God Class 43 0 5 1 0.90 0.26


Data Class 39 10 0 0 0.80 0.00
Brain
236 0 5 4 0.98 0.61
Method

God Class

The oracle consists of two manually identified God Classes (Table 44),
JCodeOdor detects one God Class, and MLCS detects six God Classes.

Table 44: Manual Detected God Class on Jasml

Manual Detected God Classes


JavaClassParser Util

176
Chapter 7. Evaluation of Design Flaws Detection

In Table 45 we compare the detection results of the two approach es, and
report the precision and recall against the manual detected ones.

Table 45: JCodeOdor and MLCS God Class Detection Results on Jasml

JCodeOdor Machine Learning

Entity Name Harmfulness Entity Name

Util Problem (9.55) Util

ConstantPoolGenerator

JavaClassParser

Scanner

SourceCodeBuilder

SourceCodeParser

Precision: 100% Recall: 50% Precision: 33% Recall: 100%

JCodeOdor obtains a precision of 100% and a recall of 50%, while MLCS


obtains a precision of 33% and a recall of 100%. We detect one of the God
Class MLCS detects too: Util, which for JCodeOdor has a harmfulness level
of Problem. MLCS detects many false positive God Classes, this is because
the approach by A. Marino tends to detect as God Class all the large and
complex classes, JCodeOdor instead needs that the class is also fair cohe-
sive. The Util class JCodeOdor detects is a class that has no instance nor
class variable and many methods and implements different functionalities.
The obtained precision shows that the approach by JCodeOdor identify bet-
ter what to consider God Class and what not, but when selecting affected
entity it fails to identify some true God Classes (i.e., the recall is not 100%).
The God Class JCodeOdor fails to detect is JavaClassParser, that is a parser
of “.class” files. JCodeOdor does not detect this God Class because it is
quite cohesive, but we think that some of the functionalities it implements
could be moved to other classes it interacts with.

Data Class

The oracle consists of 12 manually identified Data Classes (Table 46),


JCodeOdor detects 10 Data Classes, and MLCS detects zero Data Class.

177
Chapter 7. Evaluation of Design Flaws Detection

Table 46: Manual Detected Data Class on Jasml

Manual Detected Data Classes


Constants Attribute

Field Attribute_Code
JavaClass Attribute_Code.ExceptionTableItem

Method Attribute_InnerClasses.InnerClass

OpcodeInfo Attribute_LocalVariableTable.LocalVariable
Scannable ConstantPool

In Table 47 we compare the detection results of the two approach es, and
report the precision and recall against the manual detected ones.

Table 47: JCodeOdor and MLCS Data Class Detection Results on Jasml

JCodeOdor Machine Learning

Entity Name Harmfulness Entity Name

Constants Harm (10.00) -

JavaClass Harm (10.00)

OpcodeInfo Harm (10.00)

Attribute_Code Problem (9.25)

Attribute_LocalVa… Problem (8.50)

Method Problem (8.50)

Field Problem (8.50)

Attribute_InnerCl… Problem (8.50)

Attribute_Code.Ex… Problem (8.50)

Attribute Trouble (5.50)

Precision: 100% Recall: 83% Precision: - Recall: 0%

JCodeOdor obtains a precision of 100% and a recall of 83%, while MLCS


does not identify any Data Class then it has a recall of 0%.

178
Chapter 7. Evaluation of Design Flaws Detection

When we build the oracle, my colleague and I disagree a lot in what to


consider a Data Class and what not. To align our views we refer to the lit-
erature and to Data Class examples by other experts on other systems , e.g.,
[100]. After this work, we agree to mark as Data Class all the classes that
expose many data in the public interface (directly or through accessor meth-
ods) and that do not handle their data. All the manually identified Data
Classes are data holders (i.e., OpcodeInfo expose 14 attribute and has no
methods). The Data Class JCodeOdor fails to identify are almost “smelly”
but the metrics do not exceed the normal thresholds we set in the detection
strategy. If we use soften threshold we find also these classes.

Brain Method

The oracle consists of nine manually identified Brain Methods (Table 48),
JCodeOdor detects four Brain Methods, and MLCS detects nine Brain Meth-
ods.

Table 48: Manual Detected Brain Method on Jasml

Manual Detected Brain Method


dumpAttribute(Attribute) calculateReferences(Method)

nextToken() toString(Attribute_Code,HashSet)

parseMethodInstructions(Method) processOpcode(Node)

parseMethodSignature(Method,Ar- toViewableString(String)

rayList)

parseOpcodes(byte[])

In Table 49 we compare the detection results of the two approach es, and
report the precision and recall against the manual detected ones.

Table 49: JCodeOdor and MLCS Brain Method Detection on Jasml

JCodeOdor Machine Learning

Entity Name Harmfulness Entity Name

calculateReferences(M… Harm (10.00) parseMethodInstructions(Method)

parseMethodInstructi… Problem (9.10) parseOpcodes(byte[])

179
Chapter 7. Evaluation of Design Flaws Detection

toString(Attribute_Co… Problem (8.88) calculateReferences(Method)

parseOpcodes(byte[]) Problem (8.88) toString(Attribute_Code,HashSet)


dumpAttribute(Attribute)

nextToken()

readAttribute(DataInputStream)
processOpcode(Node)

toViewableString(String)

Precision: 100% Recall: 44% Precision: 89% Recall: 89%

JCodeOdor obtains a precision of 100% and a recall of 44%, while MLCS


obtain a precision of 89% and a recall of 89%. JCodeOdor fails to detect
some of the manually identified code smells. As for Data Class, also for
Brain Method this is due to the thresholds we set in the detection strategy.
The false negative methods have metrics values very close to the thresholds
but not enough to be considered Brain Methods. The MLCS approach does
not suffer as our approach of the problem of thresholds, consequently it has
a better recall.

Main differences in detection results between JCodeOdor and MLCS are


due to the differences in the subjective evaluation between my colleague
and me. My colleague and I mitigate the subjective evaluation referring to
other experts to reach an agreement and build the oracle. Another important
difference between JCodeOdor and MLCS is the approach follo wed to de-
fine the detection strategies or train machine learning algorithm respec-
tively. We deeply analyse the characteristics of entities that are generally
affected by code smells to produce detection strategies as part of a more
complex detection approach we propose. MLCS refers to a set of detection
strategies selected from the literature (named advisors) applied on a set of
entities to detect code smells to be manually evaluated and integrated in the
sample set used to train machine learning algorithms. The MLCS approach
misses one detail: given that the code smells definition is informal, a code
smell can affect an entity in different forms. Data Class, which is one of the
code smells where JCodeOdor and MLCS disagree most, can for example
affect an entity that:
180
Chapter 7. Evaluation of Design Flaws Detection

 has only public attributes;


 has many of public attributes and non-complex methods;
 has some public attributes and public non-complex methods;
 has only private attributes, many public getter and setter methods to
access them, and a few others non-complex methods.

JCodeOdor Data Class detection strategy treats all cases, because, before
we develop the detection strategy, we have analysed in detail all the char-
acteristics that identify a Data Class. MLCS, instead, relies only on advisors
and on a subset on the possible affected entities, to train machine learning
algorithms. If in the training set, there are not all the possible faces of a
code smell, machine learning algorithms used by MLCS miss that faces. We
think that by combining forces of the two approaches we can obtain an over-
all better result.

The obtained results by JCodeOdor with respect to the oracle built by hand
are interesting. We know that we have to expand this analysis to larger sys-
tem and to more than one system, but we can conclude that what JCodeOdor
captures in the source code is a good representation of the results obtained
by a human that manually investigate a project.
During the manual investigation of Jasml, my colleague and I try to assign
also a value of harmfulness to the identified code smells. We use these val-
ues to have a first look at how well the automatic harmfulness label assigned
by JCodeOdor could represents the human perception. We find out that for
the most harmful code smells the automatic label and the human perception
have an almost perfect agreement. For the less harmful code smells, the
automatic label and the human perception slightly agree. Because the most
harmful code smells are the one that JCodeOdor propose on top of the de-
tection results, having a high agreement for that is a positive result.

7.2.4 Assessment of Effectiveness


In this section we use the manual oracle we built in Section 7.2.3 to
compute some typical performance indexes of information retrieval and su-
pervised classification to detection results by JCodeOdor: precision, recall,
F-Measure and accuracy [65].
181
Chapter 7. Evaluation of Design Flaws Detection

Definitions

Given:

 TP (True Positive): the number of manually identified code smells


also identified by JCodeOdor;
 FP (False Positive): the number of manually identified not affected
entities that JCodeOdor identifies as code smells;
 TN (True Negative): the number of not affected entities both for
manual oracle and JCodeOdor;
 FN (False Negative): the number of manually identified code smells
JCodeOdor identifies classify as not affected entities.

The precision is the percentage of retrieved code smells that are also man-
ually identified (i.e., they are not false positive):

𝑇𝑃
𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 =
𝑇𝑃 + 𝐹𝑃

The recall is the percentage of manually identified code smells that JCode-
Odor retrieve:

𝑇𝑃
𝑅𝑒𝑐𝑎𝑙𝑙 =
𝑇𝑃 + 𝐹𝑁

The F-Measure is a measure that combines precision and recall:

𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 ∗ 𝑅𝑒𝑐𝑎𝑙𝑙
𝐹 − 𝑀𝑒𝑎𝑠𝑢𝑟𝑒 = 2 ∗
𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 + 𝑅𝑒𝑐𝑎𝑙𝑙

The accuracy is the percentage of true results (both TP and TN) in the de-
tection results by JCodeOdor:

𝑇𝑃 + 𝑇𝑁
𝐴𝑐𝑐𝑢𝑟𝑎𝑐𝑦 =
𝑇𝑃 + 𝑇𝑁 + 𝐹𝑃 + 𝐹𝑁

182
Chapter 7. Evaluation of Design Flaws Detection

Table 50 shows the obtained values.

Table 50: Precision and Recall of JCodeOdor Respect to the Oracle

Code Smell TP FP TN FN Precision Recall F-Measure

God Class 1 0 47 1 100% 50% 67%


Data Class 10 0 37 2 100% 83% 91%
Brain
4 0 236 5 100% 44% 62%
Method
Shotgun
0 0 245 0 - - -
Surgery
Dispersed
1 1 240 3 50% 25% 33%
Coupling
Message
0 0 245 0 - - -
Chains

JCodeOdor obtains a precision of 100% for three out of six code smells and
50% for Dispersed Coupling. The recall is lower tha n the precision, only
for Data Class is considerably high. For Shotgun Surgery and Message
Chains we do not find any instance during the manual investigation, hence
the measures are not defined. For all the code smells, we have an accuracy
nearly to 100%, because we agree with the manual oracle that most of the
entities are not affected by code smells.

We compute the same measures also for MLCS and inFusion, to understand
if our results are better, worse or aligned. We report the obtained results in
Appendix E3. Respect to inFusion and MLCS JCodeOdor obtains better re-
sults in terms of precision and the recall is slightly worse than MLCS but
better than inFusion.

The MLCS approach obtains better results in terms of recall and the com-
mon reason we find out is that the metrics values of false negative code
smells are close to the threshold used in the detection strategy, but not
enough to let the entities be considered as “smelly”. Our approach is in part
183
Chapter 7. Evaluation of Design Flaws Detection

resilient to this situation because we propose the user a set of soften thresh-
olds that can increase the recall. We think that we can improve the recall of
JCodeOdor combining the strengths of the two approaches, calibrating the
thresholds using manually marked entities. We explore this topic a s part of
our future works, in Chapter 9.

Because the manually investigated system is only one, we know that w e


cannot consider the obtained values to be general. As part of our future
works, we plan to manually investigate larger systems to increase the sta-
tistical validity of the obtained results.

7.3 Conclusion and Discussion


The experiments we did in this chapter show that JCodeOdor has re-
sults comparable to inFusion, a valid commercial tool, in terms of quality
of overall detection results; better in terms of precision and almost aligned
in terms of recall with respect to a machine learning approach for code
smells detection.
A comprehensive analysis of the detection results of 74 systems from the
Qualitas Corpus [125] (see para 7.1) highlights the importance of all the
steps that differentiate our code smells detection approach respect to the
literature:

 The filters we define reduce the number of detected code smells to


the most interesting ones. They remove 6% false positive code smells
on average, among the six code smells we investigate (see Table 19);
 The detected code smells are distributed among different harmful-
ness level, and approximately, only the 10% are classified as Harm
(i.e., the highest harmfulness level). The harmfulness is useful to al-
low the user to focus his analysis on the most harmful code smells,
if he does not have enough time to analyse all the affected entities;
 Approximately 20%-30% of code smells have at least one related
code smell. This shows that it is important to identify and detect the
set of possible related code smells for each code smell, because the
user has to take into account these data during the investigation of
the affected entities, as stated also by other experts [51][80].

184
Chapter 7. Evaluation of Design Flaws Detection

We argue that the results JCodeOdor obtains on a system (Heritrix) are good
and relevant (see Section 7.2.1 ). We clearly find that the code smells de-
tection approach we propose in Chapter 6 produces valid results, and the
use of Code Smell Harmfulness and Code Smell Filters we propose has a
good impact during the prioritized selection of interesting code smells to
investigate. Preliminary evaluations revealed that the proposed views are
useful for the comprehension of the problems captured by the detected code
smells.

In Section 7.2.3 we compare JCodeOdor detection results with the results


obtained by a machine learning approach to detect code smells (MLCS). We
evaluate the effectiveness of the detection strategies we propose with an
oracle built by hand. We obtain better results in terms of precision and al-
most aligned results in terms of recall with respect to the MLCS approach.
Investigating the code smells detected by the two approaches, we find out
that the lower recall is due to the metrics values of false negative code
smells that are close to the threshold used in the detection strategy, but not
enough to let the entities be considered as “smelly”. In Section 7.2.4 we
compare the six code smells JCodeOdor detects against a set of manually
identified entities. We obtain a very high precision and a good recall. Re-
spect to inFusion, JCodeOdor obtains better results in terms of precision
and recall.

185
Chapter 8
Threats to Validity

In any experimental study, there are factors that can be viewed as possible
influences and threats to validity [20]. In this chapter, we discuss the ones
we identify in our work, categorizing them in Threats to Inte rnal Validity
and Threats to External Validity. The main two are the ones referred to the
way we aggregate measurements on software entities belonging to different
systems (for Benchmark-Based Thresholds derivation), and the ones related
to the evaluation of JCodeOdor detection approach we discuss in Chapter 7.

8.1 Threats to Internal Validity


Threats to internal validity concern any confounding factors that
could have influenced the obtained results.

Design Metrics and Code Smells Selection


We identify most relevant design metrics and code smells referring to some
particular kinds of studies in the literature. Although we try to do the most
to identify most relevant studies, there are surely other studies we may have
missed, that could report different results changing the selected design met-
rics and code smells.

Design Metrics and Design Information Validation


In Section 4.3 we discuss how we validate the design metrics and design
information computation. We verify the computation respect to the defini-
tion taking into account all the possible biasing factors, but this activity
certainly introduces a threat to internal validity in our works. For example
we cannot verify if all the entities where to compute a given metrics are
identified or not, among the entities of the analysed system. We do this

186
Chapter 8. Threats to Validity

check on a test system (refers to Section 4.3), but we cannot verify this on
all the systems.

Benchmark-Based Thresholds
In Section 5.2.3 we present a method to derive thresholds from a benchmark
of software systems in an automated way. The method we propose makes
use of some statistical procedure, like statistical test and statistical func-
tions. To reduce the possibility of error we rely on solid library (i.e., Apache
Commons Math [152] and Numerical Method’s SuanShu [150]) to do these
tests. Although we carefully select statistical libraries, they can introduce
some bias in the results if the algorithms they use are not completely cor-
rect.

One of the step of the proposed method consists in aggregating the values
for a metric computed on entities belonging to different classes , and com-
puting the Quantile Function of the aggregated distribution . When we de-
cide to proceed in this way, we know that larger systems (i.e., systems with
more entities, like classes and methods) would influence the overall result.
This happen because larger system add more information to the aggregated
distribution respect to smaller system. We decide to still follow this choice
because we would gather knowledge from the entire world of entities (i.e.,
the set of classes and methods from benchmark systems, in our case), and
in this way the Quantile Function of the aggregated distribution allow us to
do this.

Evaluation of JCodeOdor Code Smells Detection Approach


In Chapter 7 we present the experimentations we do to evaluate JCodeOdor
code smells detection approach. When we compare JCodeOdor detection
results with the ones by inFusion, we investigate only the code smells de-
tected by JCodeOdor, inFusion or both the tools. Doing this we cannot be
sure if the affected entities represent the entire set of code smells of the
investigated system. We try to overwhelm this lack doing this check on a
smaller system in Section 7.2.4.

187
Chapter 8. Threats to Validity

8.2 Threats to External Validity


Threats to external validity concern the possibility of generalizing
the obtained results.

Benchmark-Based Thresholds
In Section 5.2.3 we discuss the methods we propose to derive software de-
sign metrics thresholds from a benchmark of software systems. Referring to
a benchmark of carefully selected object-oriented systems can introduce a
problem in the possibility of generalize the obtained thresholds, because the
selected systems cannot obviously represents the entire world of software
systems. Conscious of this, the method we develop is straightforward to
carry out, so that we can increase the set of reference systems and increase
the generalizability of obtained thresholds. Moreover, when we derive the
thresholds to be used for code smells detection, we select several types of
threshold (refer to Section 5.2.1) to be used to customize the code smells
detection according to the system, if necessary.
Another choice that can lack of generalization (and then represents a threat
to external validity) in our method, is the way we use to determine the dis-
tribution where to derive thresholds. We make a choice based on the as-
sumption that the metrics we refer to have a heavily skewed distribution,
with most of the values thickened in a small portion of the possible values
(i.e., the one closest to the lowest quantiles). We cannot guarantee that our
method generalize also to other types of distribution, but we know that most
of the software design metrics have the same distribution of the ones we
deal with [3][27].

JCodeOdor Code Smells Detection Approach


In Chapter 6 we present our code smells detection approach. As we said,
code smells definitions are informal and the building of automated detection
strategies able to detect them, is subject to the bias introduced by the expert
that performs this task. For this reason, the code smells detection strategies
could be considered a threat to internal validity of our work, although we
cannot do much to avoid it.

188
Chapter 8. Threats to Validity

As part of the proposed approach for code smells detection we define Code
Smell Filters (refers to Section 6.2.3). We identify the filters based on our
previous experience in code smells detection [47], and though an analysis
of the entities that are generally affected by code smells. Because this task
is closely tied to the subjective view of the evaluator, although expert, it
has to be considered a threat to internal validity. We are aware of this, and
for this reason, we enable the user to decide how to use the filters and what
filter to use and what not (refers to Section 6.2.3)

Evaluation of JCodeOdor Code Smells Detection Approach


In Chapter 7, we evaluate the quality of the detection results with respect to
the state-of-the-art tool inFusion. We do this evaluation only on one system,
hence we cannot guarantee the generalizability of the obtained results.
As part of our evaluation, we analyse the effectiveness of our detection
strategies with respect to a machine learning approach for code smells de-
tection and with respect to an oracle built by hand. Because the manually
investigated system is only one, we know that we cannot consider the ob-
tained results to be general.

For future works, we plan to manually investigate larger systems to increase


the statistical validity of the obtained results.

189
Chapter 9
Concluding Remarks and Future Plans

Several avenues of future work are foreseen. In this chapter, we first discuss
the results we obtain from our work. Then we detail the most significative
and interesting works we are planning for the future. The most relevant are:
extending and refining detection strategies and Code Smell Filters, tuning
thresholds computation to enhance JCodeOdor detection effectiveness in
terms of recall, bringing JCodeOdor to a beta version integrating it with
Eclipse IDE and implementing the views we propose.

9.1 Concluding Remarks


In this thesis, we have presented JCodeOdor, a tool for automatic
code smells detection. Code smells capture some characteristics of the de-
sign of a software artefact, and represent a hint that something might be
wrong. Unlike software design metrics, code smells allow identifying the
potential problematic code with a well-defined semantics, expressing soft-
ware artefact properties to be detected, like "class that is very large, with a
very high complexity". The steps that bring from the informal definition
just given, to the automatic identification of code smells in the code, re-
quire:

 Building detection strategies to automatically detect code smells:


o identifying and computing software design metrics to be
used as part of the realized detection strategies;
o determining what “very large class” and “very high com-
plexity” means in a quantifiable way, to identify some
thresholds to be used as part of detection strategies to pick
up the entities affected by code smells.

190
Chapter 9. Concluding Remarks and Future Plans

 Testing and refining detection strategies contextualizing them in


a detection approach that tackles the most important needs to
bring detection results to the user in a way that the results can be
understandable and useful. Code smells, in fact, have to be care-
fully investigated to decide if they represent a problem in the soft-
ware design, and to determine the best way to enhance the design
quality.

In this thesis, we have addressed the whole process, in part by referring to


the literature, in part by proposing new solutions to open issues , known or
identified by us, in the existing approaches for automatic code smells de-
tection. We have proposed a code smells detection approach based on soft-
ware design metrics, and we have tested it on six duly selected code smells.
We have built detection strategies, using some well-known software design
metrics and defining some new design metrics useful in the context of code
smells detection.
We have proposed an automatic method to derive design metrics thresholds
from a benchmark of software systems. We have derived customized thresh-
olds that respect the metrics distribution for each code smell. Finally, we
have used thresholds to quantify elements of the informal definition (e.g., a
threshold for metrics that measure class complexity, to identify “very high
complexity” classes).
As part of JCodeOdor code smells detection approach, we have proposed
Code Smell Filters to refine detection results trying to keep only the most
important and real problems of software design. We have proposed Code
Smell Filters considering also that filters identification could be subjective
or based on specific system under investigation.
We have developed a way to prioritize code smells presentation to the user,
according to a Code Smell Harmfulness, that is an index about how each
code smell is harmful compared to the other code smells.
The Code Smell Harmfulness enables the users to identify the first problems
to tackle with, and these problems are the most interesting ones because of
the Code Smell Filters. Once the user selects the code smell to investigate,
he has to understand if it represents a problem for software design quality ,

191
Chapter 9. Concluding Remarks and Future Plans

and has to identify the correct way to fix it. Correction implies understand-
ing the whole context, hence we have integrated, as a part of the proposed
detection approach, a set of views that bring to the users all data he needs
to efficiently and effectively understand the potential problems and evaluate
how to fix them, among different ways that generally exist to do that
[51][99]. We have proposed personalized views for each code smell, which
show details about the code smell and its impact on system design quality.
We have customized the views for each code smell because each code smell
has its own characteristics and describes some different design quality as-
pects of an object-oriented software system.

We have evaluated the quality and the effectiveness of all parts of our work,
to understand the strengths and the weaknesses and identifying some future
work to enhance the results. In Chapter 7, we discussed the results obtained
by JCodeOdor and we have evaluated the quality of the detection results
and the usefulness of Code Smell Harmfulness, Code Smell Filters, and
views, with respect to (i) the state-of-the-art tool inFusion, (ii) a machine
learning approach for code smells detection and (iii) an oracle built by hand.
The experiments we have performed clearly showed that JCodeOdor is com-
parable to inFusion in terms of quality of overall detection results; it is bet-
ter in terms of precision and almost aligned in terms of recall respect to a
machine learning code smells detection approach and it is better for preci-
sion and respect to than inFusion. Moreover, we have found that Code Smell
Harmfulness and Code Smell Filters have a good impact during the priori-
tized selection of interesting and relevant code smells to investigate. Fi-
nally, preliminary evaluations have revealed that the proposed views are
useful for the comprehension of the problems captured by the detected code
smells; we plan the full implementation and experimentation of the views
for future work.

9.2 Future Plans


We identify several avenues of future works, to enhance detection
results we obtain, and to complement and extend the work discussed in
this thesis. We plan to grow our research on several important direction:
192
Chapter 9. Concluding Remarks and Future Plans

extending and refining detection strategies, refining code smells metrics


threshold computation, implementing all the components of JCodeOdor to
bring the prototype to a beta version that can be tested in a real environment.

Extending and Refining Detection Strategies

Detect more code smells. In Chapter 6 we present our code smells detection
approach and we test it on a set of six carefully selected code smells. Be-
sides these six code smells there are many other to be investigated [51]. An
important first step to plan is the extension of JCodeOdor detected code
smells to more of them. The first code smells to add respect to the criteria
we use to select the six currently implemented (refers to Section 6.1) are:
Intensive Coupling and Feature Envy [51]. Another direction in this sense
is the integration of detection of code smells of different forms with respect
the ones we investigate, e.g., Duplicated Code [51]. Duplicated Code can
impact on system quality and sometimes can be the basic problem that lead
to the presence of a code smells, like for example a God Class [80]. We will
evaluate the detection of Duplicated Code referring to the literature
[10][71][113], taking care that if it is present can be the cause of another
code smell, and this fact has to be reported to the user to enhance detection
results usefulness.

Refine Code Smell Filters. As part of our detection approach, we propose


Code Smell Filters to reduce the number of detected code smells to the most
interesting ones respect to the impact on software design quality. We pro-
pose a way to systematic identify them from a set of software, that can be
enhanced adding more systems and using different techniques (e.g., cluster-
ing [4][64]), and we propose a first set of filters for the six code smells we
deeply analyse. When we propose Code Smell Filters we are aware that they
can be biased by subjective evaluation of the expert who analyses code
smells and to the specific characteristics and domain of the system under
investigation [61]. We plan to bring to the user the possibility, along with
the one that allow his to disable Code Smell Filters, to add new filters. This
feature can be added without many changes because of the characteristics
of the filters we propose (refer to 6.2.3). For example if a user would add a
193
Chapter 9. Concluding Remarks and Future Plans

library to an already defined Library Implementer or Extender filter, we can


enable it through a configuration panel. In the same way if the user would
add a new Method Caller filter, he could set all the needed information and
add a new one. Along this we plan to investigate deeply the possibility to
identify Design Patterns [130] in software design, referring to the work by
Zanoni [133], to increase the set of proposed filters. Design Patterns often
introduce some code smells that are obviously false positive. For example
there is a well-known Design Pattern named Data Transfer Object (DTO)
defined by Fowler [50], according to which Data Classes can be used in
order to minimize the number of performed remote calls. In this case, the
detected Data Classes are not considered as a negative factor affecting soft-
ware design quality. We postponed this work to future plan because Design
Patterns detection allow us only to identify Weak Filters because of the
difficulties in identifying them with a precision of 100% [87].
Respect to Code Smell Filters we plan also to verify if the entities we filter
out are less changed during the system evolution, respect to the other code
smells that we do not filter. We plan to verify this referring to development
activities of more systems, collecting information from a versioning system ,
detecting code smells using JCodeOdor and applying some well-defined
analysis of software evolution respect to change-proneness of code smells
[66]. This investigation will be useful to deeply understand the impact of
filtered code smells on systems.

JCodeOdor for software quality assessment. JCodeOdor is suited to be


used during the development of a software system as well as during the
assessment of software quality. During the assessment, we could have more
knowledge to integrate in the detection approach to enhance detection re-
sults, because the system exists and probably exist some different versions.
We plan to investigate and to create a version of JCodeOdor that add more
knowledge to the detection approach to try to enhance detection results, like
changes history [111]. We think that adding these features we can obtain
even better results when we use JCodeOdor for assessment, because of the
more knowledge we can add. For example, a class that in version 𝑣 of the
system is affected by a code smell but remain stable (i.e., does not change

194
Chapter 9. Concluding Remarks and Future Plans

a lot 22) during the evolution of the system, can be considered not problem-
atic for software quality, especially if the entities are affected by a code
smell in almost all the versions (i.e., is not persistent). We can handle
knowledge concerning the evolution of the system adding more categories
and instances to the set of Strong and Weak Filters we propose. Knowledge
about evolution of “smelly” entities can also be used to add a new parameter
to the Harmfulness we compute for each code smell, for example calibrating
the presentation to the used also referring to the evolution of the “smelly”
entities [33].

Refining Code Smells Metrics Thresholds Computation

Tuning the Thresholds. In Chapter 5 we discuss how we derive thresholds


for software design metrics to understand what means for example “high
complexity”. We use the obtained thresholds as part of the code smells de-
tection strategies we propose. In Chapter 7 we verify the effectiveness of
the detection strategies using an oracle built by hand and we find out that
they have a very good precision, but only a moderate recall. The reason of
moderate recall is that the metrics values of some entities we manually iden-
tify are very close to the thresholds, but not enough to let the entities being
detected as affected by code smells. We plan to enhance the recall of our
strategies, following an approach already proposed in the literature, named
“Tuning Machine” [100]. The “Tuning Machine” tries to automatically find
the appropriate threshold values of a given detection strategy with an “ini-
tial” set of thresholds. This approach is based on building a repository of
“flaw samples” i.e., design fragments that have been identified by engineers
as being affected by a particular design problem, and “healthy samples” i.e.,
entities classified by the experts as not affected by design problems. Based
on these reference samples, the “tuning machine” selects those threshold s
values that maximize the number of correctly classified entities (i.e.,
“flawed” entities classified as flawed, and “healthy” entities classified as
healthy), using a genetic algorithm.

22
A drawback of this check is that it is very difficult to under stand if the changes of
classes that conversely change a lot, are caused by the presence of the code smell.
195
Chapter 9. Concluding Remarks and Future Plans

Following this approach, as stated by the authors, requires a lot of efforts


because of the need of manually identify many affected and not affected
entities to obtain generalizable thresholds values. Moreover, it requires a
starting point for search to the thresholds, which can be the values we com-
pute with our automatic method proposed in Chapter 5. We are planning to
join forces and knowledge with Alessandro Marino, that has experience in
the area of manual identification of entities affected and not affected by
code smells [95], and develop a method to tune the thresholds carefully se-
lecting all the different forms that a code smell can have (e.g., for Data
Class we have to select entities with only public attributes and no methods,
along with entities with all private attribute and a lot of getter and setter
methods). We are planning to apply the “Tuning Machine” on entities that
we consider real problem for software design quality, then we will use only
not Strong filtered code smells. We plan also to extend the method to be
able to derive five thresholds and not only one for each metrics, as “Tuning
Machine” does. We need more than one threshold because of the require-
ments of our code smells detection approach. The idea is to use the “Tuning
Machine” to find thresholds that split the set of entities in “smelly” and not
“smelly”, and to use the aggregated metric distribution described in Section
5.2.3 to find other points near the ones we find.

Another future work regarding software design metrics thresholds deriva-


tion we are planning is to derive thresholds for specific software domains,
because they could be biased by the particular software domain where a
system belongs to [29]. For doing this we have to select a benchmark o f
software system for each domain, that is large enough to derive meaningful
thresholds.

Bring JCodeOdor to a Beta Version

Integration with Eclipse IDE. The actual version of JCodeOdor we imple-


ment is a prototype suited to test and to evaluate the proposed code smells
detection approach. We plan to bring JCodeOdor to a beta version, imple-
menting the integration with the Eclipse IDE, as plugin.

196
Chapter 9. Concluding Remarks and Future Plans

Implementation of Visualization Framework. We plan to implement the


visualization framework we propose in Section 6.2.5, using Gephi [14], an
open source software for graph visualization and manipulation. Gephi offer s
to the developer a Java library that exposes all the functionalities we need
to implements our framework:

 Vertex and Edge shape and colour customization;


 Vertex and Edge labels;
 Hierarchical graphs;
 Layout algorithms;
 Vertex and Edge filtering mechanism.

Gephi is well documented, simply customizable and with a lot of already


developed plugin that simplify the development.

Evaluation of JCodeOdor in a Real Environment. Once we have the Beta


version, we want to test JCodeOdor in a real environment during both de-
velopment and assessment and on different systems, to evaluate usability
and effectiveness, and enhance JCodeOdor calibrating the choices we h ave
done, with some requisites we may have missed. We plan also to extend the
evaluation we discuss in Chapter 7 to try to generalize better the obtained
results.

Last but not least, we plan to extend JCodeOdor to be able to detect other
design flaws, like antipatterns [19], and to other programming languages.
We develop JCodeOdor in a way that we can do this with the minimum
possible effort: relying of DFMC4J it uses a Model that abstract from source
code and most of the measures we propose in Chapter 4 are language inde-
pendent because they are based on an abstracted model, and not on a con-
crete source code. Moreover we would explore the steps needed to “Closing
the Gap Between design flaws Detection and Correction” [91], and propose
a way to approach code smells resolution to the users.

197
Appendices
Appendices

A1 DFMC4J Model Details


In Section 3.2 we report an overview of the DFMC4J Model showed
in Figure 3 and Figure 4. To better explain and show the characteristics and
details of the DFMC4J Model, we decide to realize different views on its
entities. Figure 52 to Figure 59 show all the DFMC4J Model details.

Code Element
In Figure 52 we show the hierarchy of the DFMC4J Model entities belong-
ing to source code and project structure. Table 51 presents a description of
the entities.

Table 51: DFMC4J Model CodeElement Description

Entities and Description

ProjectComponent
Represents a generic entity of a project. The snapshotTimestamp stores
the last update time of the entity saved in the model. In particular snap-
shotTimestamp is:

 the timestamp of the last modification of the file that declare s the
CodeEntity (for CodeEntity);
 the timestamp of the last change to the files belonging to a pack-
age (for Package);
 the timestamp of the last change to the files belonging to all pack-
ages of the project (for the Project);
 the timestamp of the last modification (for Files);
 the timestamp of the last modification to the file corresponding to
the compilation unit (for Compilations Unit);
 the timestamp of the last change to files in a directory (for Direc-
tory).
198
Appendices.

Resource

Represents a generic descriptor for all physical resources of the project.


The path represents the physical path of the resource on the file system.
It has two methods to handle IPath, used in the Eclipse environment
[139].

Directory

Represents a physical directory of the project.

File

Represents a physical file of the project.

CompilationUnit

Represents a compilation unit (see Section 7.3 of [56]) related to a file.

Measurable

Represents an entity of the project on which it is possible to measure


something. Each Measurable has an analysisState that is the list of Co-
deInformation computed on the Measurable. This list is useful to know
if the information has been computed and, for example, it is empty, or it
has not already been computed.

Project

Represents a project.

Package

Represents a package. It has a qualifiedName that represents an unam-


biguous name of the package, and a flag that marks if the package be-
longs to source code of the project or to a referred library.

199
Appendices.

CodeEntity

Represents an entity belonging to the source code of a compilation unit.


It has a name and a list of modifiers (see Figure 53 for a complete list
for Java programming language).

Type

Represents a type of programming language.

PrimitiveType

Represents a primitive type (e.g., int, float, double)

ComplexType

Represents a complex type (e.g., Class, Interface, Enum, Annotation,


Map, and List). It has a typeDefinition (see Figure 53 for the possible
values, where Class, AnonymousClass, Interface, Enum and Annotation
are the only ones that can have a compilation unit for Java programming
language) and the flag isPackageMember that marks whether or not the
ComplexType is a package member (see para 7.1 of [56]).

Procedure

Represents a procedure. The method getSignature() returns the signature


of the procedure, according to The Java® Language Specification (see
Section 8.4.2 of [56]).

Function

Represents a function.

Method

Represents a method. It has three flags that mark whether or not the
Method is a constructor (see Section 8.8 of [56]), a default constructor
or an accessor (i.e., getter) or mutator (i.e., setter) method.

200
Appendices.

Variable

Represents a variable.

Attribute

Represents an attribute of a ComplexType.

LocalVariable

Represents a local variable of a ComplexType or a Method.

GlobalVariable

Represents a global variable.

Analysis

Represents a single or multi project analysis. Each analysis has a name


that uniquely identifies the analysis.

Physical Entities
Figure 54 shows the relation among the physical entities of the DFMC4J
Model (i.e., Resource, Directory, and File). A Directory contains one or
more Resource. We set a lower bound of one because we assume that we
have at least one resource in the project. The Analysis contains zero or more
root directories (i.e., a Directory that is not a subDirectory of any of the
Directories in the model).

Top Level Logical Entities


Figure 55 shows the set of top-level logical entities (i.e., Measurable, Pro-
ject, Package, and CodeEntity) and their relations. A Project has one Di-
rectory and zero or more Package and a Package belongs to zero or more
Project 23. All the Projects and Packages are contained in the Analysis, to
optimize the model serialization process.

23
A library Package for example does not belong to any projects.
201
Appendices.

The relations Project — projectPackages → Package and Package — be-


longToProject → Project are inverse operations, as many of the relation in
the model. We set the inverse relation for each relation that we need to
navigate in both directions, without abusing, so as not to make th e model
too heavy, especially for serialization (i.e., more relations need more space
to be stored).

Type Entities
Figure 56 shows the entities that belong to the Type entity (i.e., Primitive-
Type and ComplexType) and their relations. A Type belong to a Package 24,
that contain zero or more Types, is returned by zero or more Procedure and
is the Type of zero or more Variables. A ComplexType has zero or more
Methods, zero or more Attributes, and zero or more LocalVariables. Each
ComplexType can declare zero or more ComplexType in its declaration
block (i.e., Inner Class and Anonymous Class (see Chapter 8 of [56])), and
belong to zero or one CompilationUnit (e.g., ComplexTypes that belong to
library Package do not belong to any CompilationUnit).

Procedure Entities
Figure 57 shows the entities that belong to Procedure entity (i.e., Function
and Method) and their relations. A Procedure has zero or more parameters
and LocalVariables, and zero or one return Type. A Function belongs to a
Package, that contains zero or more Functions, and to zero or one Compi-
lationUnit (e.g., Functions that belong to library Package do not belong to
any CompilationUnit). A Method is declared within one ComplexType.

Variable Entities
Figure 58 shows the entities that belong to Variable entity (i.e., GlobalVar-
iable, LocalVariable, and Attribute) and their relations. A Variable has zero
or one Type and has three specialized entity:

24
Also a PrimitiveType can have a Package in our model. This is not true for the Ja va
language but it is useful in order to maintain a clean model and manage its persistence
using only the root (Analysis) without create a relation between PrimitiveType and the
Analysis, which is not clean. In order to collect PrimitiveType in a Package we use a
Package named "%primitive%" that is an unsupported name for real packages, and then
we are sure that in this Package we have only the PrimitiveType.
202
Appendices.

 The GlobalVariable belong to a Package and belong to zero or one


CompilationUnit (e.g., GlobalVariables that belong to library Pack-
age do not belong to any CompilationUnit). The Package contains
zero or more GlobalVariable;
 The Attribute belong to a ComplexType;
 The LocalVariable belong to a CodeEntity (i.e., a ComplexType or a
Method).

Code Information
In Figure 59 we show the hierarchy relations among Code Information (i.e.,
Metrics and DesignInformation). Table 52 presents a description of the en-
tities.
Table 52: DFMC4J Model CodeInformation Description

Entities and Description

Metric

Represents a quantitative information computed on a Measurable. Each


Metric is identified by a unique name.

DesignInformation

Represents a generic qualitative information associated to a Measurable.


A design information is a piece of information extracted from the source
code of a project that represents characteristics of the project related to
its design (e.g., code smell). A DesignInformation has a name such that
the intersection of the sets of names of each one of the subclasses of
DesignInformation is an empty set.

PositionInformation

Represents the position of a DesignInformation inside the Measurable to


whom it is associated.

For example: The number of line and position inside the text of the line
of a Type where there is a method that is Long Method [51] or the number

203
Appendices.

of line and position inside the text of the line of a Method where a Type
is used, and so on.

StringToMeasurableMapEntry

An Entry of a Map used to collect information about Measurables in-


volved in a DesignInformation and describe, using the key, the reason of
involvement. This entity is introduced due to the limit of EMF Frame-
work that do not support the Map type for the attributes of an entity, if
the attribute is declared not Volatile (see [121] for details).

IntraClassDesignInformation

Represents a DesignInformation collected within the bounds of a class


(e.g., comments).

InterClassDesignInformation

Represents a DesignInformation collected among classes.

CodeSmell

Represents a generic code smell (see Chapter 6)

IntraClassCodeSmell

Represents an intra-class CodeSmell: as for example a Long Method


[51].

InterClassCodeSmell

Represents an inter class CodeSmell: as for example Duplicated Code


[51] in different classes.

BestPractice

Represents a generic “best practice”, for example “Synchronize Critical


Sections Only” [145]

204
Appendices.

IntraClassBestPractice

Represents an intra-class BestPractice.

InterClassBestPractice

Represents an inter class BestPractice.

Feature

Represents a generic “feature”, for example the import of a given library.

IntraClassFeature

Represents an intra class Feature.

InterClassFeature

Represents an inter class Feature.

DFMC4J Model Implementation Details


We use the EMF Framework [121] to realize the DFMC4J Model. We select
this framework because it allows us to realize the model using a graphical
editor and the corresponding Java code is automatically generated. EMF
Framework [121] has a lot of properties that enable some useful customiza-
tion on the model. We use these properties particularly to enable the serial-
ization of the model, which also check for the consistency of the stored
entities. The serialization offered by the EMF Framework [121] is also use-
ful when the model is too big to be completely handled in memory. In this
case we can split the information that we store in memory and the infor-
mation that we persist, and Teneo [151] handle the retrieval of information
from the datastore if we ask the model for some data not already present in
main memory.
Another great feature of the EMF Framework [121] is that during the code
generation it add all the accessor and mutator methods, and also automati-
cally manage the inverse relations, so that we can set one property of an
205
Appendices.

object and EMF generated classes automatically handle the setting of its
inverse property that we define on the model.

Serialization of the DFMC4J Model


The Analysis entity allow us to collect all the top-level entities of the model
(see Figure 55 for the complete set of top-level entities), and simplify the
serialization process of the model. The serialization is done by the use of
Teneo [151], supported by the Hibernate ORM 25 Framework [142]. Collect-
ing all the reference to top level entities of the model in one entity allow us
to ask the framework to serialize Analysis, delegating to the framework the
burden of navigate the model and serialize all the entities following the
containment relations existing among the model entities.

25
Object Relational Mapping
206
Appendices.

Figure 52: DFMC4J Model – Code Element Hierarchy

207
Appendices.

Figure 53: DFMC4J Model – DataType

Figure 54: DFMC4J Model – Physical Entities

208
Appendices.

Figure 55: DFMC4J Model – Top Hierarchy Logical Entities

209
Appendices.

Figure 56: DFMC4J Model – Type Entities

210
Appendices.

Figure 57: DFMC4J Model – Procedure Entities

211
Appendices.

Figure 58: DFMC4J Model – Variable Entities

212
Appendices.

Figure 59: DFMC4J Model – Code Information Hierarchy


213
Appendices.

B1 Design Information Definition and Computation


In Table 53 to Table 77, we present all the design information we compute
on the source code (refers to Section 4.2.2). A design information can de-
pend upon one or more other design information, hence we report every
design information after other design information it depends on. We organ-
ize design information using a structure that encapsulates their definitions
(i.e., an enum). In this way, users can ask DFMC4J for them in a consistent
way.

For each design information, we report:

 The Name: the identifier we assign to the design information;


 Definition;
 Computation Details: all the important details about the computa-
tion, if needed;
 Visitor Type: the visitor type as defined in Section 3.2.2, one of AST
Visitor, Model Visitor or Hybrid Visitor;
 Implementation details for each entity the visitor can visit:
o visit: the visited entity, according to Table 4 where we refer
to Class, Nested Class, Anonymous Class, Interface, Enumer-
ation, Annotation with Class and to Method and Member of
an Annotation with Method. The Applicability indicates
which among the set are considered. When we refer specifi-
cally to Annotation, we use Annotation;
o Type of the visited entity: AST from source code or a
DFMC4J model element (refers to Section 3.2.2);
o Applicability: the entities of the source code where we apply
the measure implemented by the design information, as de-
fined in Section 3.2.2;
o Dependencies Information: the information from which the
defined design information depends on, as described in Sec-
tion 3.2.2. We use the Dep-Entities element from Table 6 to
describe Dep-entity and Dep-level fields.

214
Appendices.

When we collect methods from source code of a project, we identify also


getter and setter methods. We call them respectively acces sor and mutator.
We define an accessor method as:

Non-static method, whose name starts with "get", has no parameters and
returns a class attribute.

We define a mutator method as:

Non-static method whose name starts with "set", has at least one parameter
and has void as return type.

We refer to the Eclipse JDT [140] documentation, to determine the set of


nodes to visit when for example we have to collect attributes and variables
usage by a class or method and methods calls.

When we collect attributes, variable and types use, along with the use, we
collect also the context of the use, described by the node where we find
them in the AST structure. For doing this we use a stack where we push and
pop the context of interest of AST visit during the traversing of the tree. In
this way, we always know where the attributes, variables, or types are used.

Table 53: Declared Class Design Information - Def. and Comput.

Declared Classes

The collection of classes declared in a Package or in a Pro-


Definition
ject.
Visitor
Hybrid Visitor
Type

Implementation details for each entity the visitor can visit

visit: Compilation Visit Type: AST Visitor


Unit Applicability: Compilation Unit

Visit Type: Model Visitor


visit: Package
Applicability: Package

215
Appendices.

Dependencies Information:

Dep-visitor Dep-entity Dep-level


Declared Classes CompilationUnit Package

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Declared Classes Package Project

Table 54: Implemented Interfaces Design Information - Def. and Comput.

Implemented Interfaces

The collection of interfaces implemented by a class. The


Definition interfaces belonging both to the system source code and to
libraries it uses.
Visitor
AST Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration, Annotation

Table 55: Methods Declared In Class Design Information - Def. and Com-
put.

Methods Declared In Class

List of methods declared in a class. Does not collect the


Definition
inherited methods.
216
Appendices.

Computa- Before saving the information, we compute also if each


tion Details method is an accessor (i.e., getter) or a mutator (i.e., setter).
Visitor
AST Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration, Annotation

Table 56: Attributes Of Class In Class Design Information - Def. and


Comput.

Attributes Of Class

Definition List of attributes of the class.

Because of tree structure of AST and the possibility in Java


Computa- to declare nested class, we use a visit level to visit only the
tion Details sub tree of the class under computation, without trespass
into the nested class.
Visitor
AST Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration, Annotation

217
Appendices.

Table 57: Parent Class Design Information - Def. and Comput.

Parent Class

The class that the measured class extends, belonging both


Definition
to the system and to the libraries it uses.
Visitor
AST Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration, Annotation

Table 58: Ancestor Classes Design Information - Def. and Comput.

Ancestor Classes

Collection of the ancestors of a class, as defined by The


Java® Language Specification [56]. The ancestor classes
Definition
belonging both to the system source code and to the librar-
ies it uses.
We collect the ancestors using a queue initialized with the
Parent Class of the current class. We then proceed as fol-
lows:
Computa- while(!queue.isEmpty())
tion Details 𝑎𝑛𝑐𝑒𝑠𝑡𝑜𝑟𝑠 = 𝑎𝑛𝑐𝑒𝑠𝑡𝑜𝑟𝑠 ∪ 𝑠𝑢𝑝𝑒𝑟𝑐𝑙𝑎𝑠𝑠(𝑞𝑢𝑒𝑢𝑒. ℎ𝑒𝑎𝑑())
𝑞𝑢𝑒𝑢𝑒 = 𝑞𝑢𝑒𝑢𝑒 ∪ 𝑠𝑢𝑝𝑒𝑟𝑐𝑙𝑎𝑠𝑠(𝑞𝑢𝑒𝑢𝑒. ℎ𝑒𝑎𝑑())
𝑞𝑢𝑒𝑢𝑒 = 𝑞𝑢𝑒𝑢𝑒 − 𝑞𝑢𝑒𝑢𝑒. ℎ𝑒𝑎𝑑()
end while
Visitor
AST Visitor
Type

Implementation details for each entity the visitor can visit

visit: Class Visit Type: AST Visitor

218
Appendices.

Applicability: Class, Nested Class, Anonymous


Class, Interface, Enumeration, Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Parent Class Type Type (i.e., the current
class)

Table 59: Children Classes Design Information - Def. and Comput.

Children Classes

Definition The set of classes that extend the measured one.

Computa- We search for all the classes that have as their Parent Class
tion Details the measured one.
Visitor
Model Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Nested nor Anonymous Com-
plexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Parent Class Type Project

Table 60: Used Intra Variables Design Information - Def. and Comput.

Used Intra Variables

For class: collection of the attributes of the measured


Definition class used by the measured class.
For method:

219
Appendices.

 collection of the attributes of the class that declare


the measured method, used by the measured
method;
 collection of the variables declared by the meas-
ured method, used by the measured method.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables Method Type

Visit Type: AST Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables AnnotationTypeMember Type

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Annota-
tion

Table 61: Used Inter Variables Design Information - Def. and Comput.

Used Inter Variables

For class: collection of the attributes of classes different


from the measured class and the ones in the hierarchy of
Definition
the measured class, used by the measured class.
For method, collection of the attributes:

220
Appendices.

 of classes different from the class that declares the


measured method, used by the measured method;
 of classes in the hierarchy of the class that de-
clares the measured method, used by the measured
method.

Attributes belonging both to the system and to the librar-


ies it uses.
We consider also attributes declared by Nested Classes
or Anonymous Classes declared inside the measured one.
Computation
We do not need a dependency to know the class in the
Details
hierarchy because we obtain this information from the
binding [140].
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Variables Method Type

Visit Type: AST Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Variables AnnotationTypeMember Type

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Annota-
tion

221
Appendices.

Table 62: Used Hierarchy Variables Design Information - Def. and Com-
put.

Used Hierarchy Variables

For class: collection of the attributes of classes in the


hierarchy of the measured one, used by the measured
class.
For method: collection of the attributes of classes in the
Definition hierarchy of the class that declares the measured method,
used by the measured method.

Attributes belonging both to the system and to the librar-


ies it uses.
We do not need a dependency to know the class in the
Computation
hierarchy because we obtain this information from the
Details
binding [140].
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Hierarchy Varia- Method Type
bles

Visit Type: AST Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Hierarchy Varia- AnnotationTypeMember Type
bles

222
Appendices.

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Annota-
tion

Table 63: Used Variables Design Information - Def. and Comput.

Used Variables

The set given by the union of “Used Intra Variables”,


Definition
“Used Inter Variables”, and “Used Hierarchy Variables”.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables Type Type
Used Inter Variables Type Type
Used Hierarchy Varia- Type Type
bles

Visit Type: Model Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables AnnotationTypeMember AnnotationType
Member
Used Inter Variables AnnotationTypeMember AnnotationType
Member
Used Hierarchy Varia- AnnotationTypeMember AnnotationType
bles Member
223
Appendices.

Visit Type: Model Visitor


visit: Method Applicability: Method, Member of an Annota-
tion
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables Method Method
Used Inter Variables Method Method
Used Hierarchy Varia- Method Method
bles

Table 64: Overridden Methods Design Information - Def. and Comput.

Overridden Methods

The methods the current class overrides, belonging both to


Definition
the system and to the libraries it uses.
Computa- We refer to the The Java® Language Specification [56] to
tion Details determine the overridden methods.
Visitor
Model Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


Applicability: Not abstract ComplexType,
visit: Class
Nested ComplexType, Anonymous ComplexType,
Enumeration ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Ancestor Classes Type Type
Methods Declared In Type Project
Class

224
Appendices.

Table 65: Inherited Methods Design Information - Def. and Comput.

Inherited Methods

The methods the current class inherits from the Ancestor


Definition
Classes.
We refer to the The Java® Language Specification [56] to
Computa- determine the inherited methods. We skip the method in-
tion Details herited from object, because all the Java classes inherit
them.
Visitor
Model Visitor
Type

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


Applicability: Not abstract ComplexType,
visit: Class
Nested ComplexType, Anonymous ComplexType,
Enumeration ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Ancestor Classes Type Type
Overridden Methods Type Type
Methods Declared In Type Project
Class

Table 66: Called Intra Methods Design Information - Def. and Comput.

Called Intra Methods

For class: collection of methods belonging to the meas-


ured class and called by itself.
Definition For method: collection of the methods of the class that
declare the measured method, called by the measured
method.

225
Appendices.

We refer to the Eclipse JDT [140] documentation, to de-


Computation
termine the set of nodes to visit in order to collect meth-
Details
ods calls.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Intra Methods Method Type

Visit Type: AST Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.

Table 67: Called Inter Methods Design Information - Def. and Comput.

Called Inter Methods

For class: collection of the methods declared in classes


different from the measured class and the ones in the hi-
erarchy of the measured class, called by the measured
class.
For method: collection of the methods of classes differ-
Definition ent from the class that declares the measured method and
the ones in the hierarchy of the class that declares the
measured method, called by the measured method.

Method belonging both to the system and to the libraries


it uses.

226
Appendices.

We refer to the Eclipse JDT [140] documentation, to de-


termine the set of nodes to visit in order to collect meth-
Computation
ods calls.
Details
We consider also calls from Nested Classes or Anony-
mous Classes declared inside the measured one.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Inter Methods Method Type

Visit Type: AST Visitor


visit: Method Applicability: not Abstract Method, not from In-
terface and Annotation ComplexType.

Table 68: Called Hierarchy Methods Design Information - Def. and Com-
put.

Called Hierarchy Methods

For class: collection of the methods of classes in the hi-


erarchy of the measured one, called by the measured
class.
For method: collection of the methods of classes in the
Definition hierarchy of the class that declares the measured method,
called by the measured method.

Method belonging both to the system and to the libraries


it uses.

227
Appendices.

We refer to the Eclipse JDT [140] documentation, to de-


Computation
termine the set of nodes to visit in order to collect meth-
Details
ods calls.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Hierarchy Method Type
Methods

Visit Type: AST Visitor


visit: Method Applicability: not Abstract Method, not from In-
terface and Annotation ComplexType.

Table 69: Called Methods Design Information - Def. and Comput.

Called Methods

The set given by the union of “Called Intra Methods”,


Definition “Called Inter Methods”, and “Called Hierarchy Meth-
ods”.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: not Annotation ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Intra Methods Type Type
228
Appendices.

Called Inter Methods Type Type


Called Hierarchy Type Type
Methods

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from In-
terface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Intra Methods Method Method
Called Inter Methods Method Method
Called Hierarchy Method Method
Methods

Table 70: Used Intra Types Design Information - Def. and Comput.

Used Intra Types

For class: collection of the current class type or types


declared in the measured class used by the measured
class.
For method: collection of the current class type or the
types declared in the class that declare the measured
Definition method, used by the measured method.

A class or method uses a type in different context, like


method call and field access. We collect use in every pos-
sible context as defined by Eclipse JDT [140] documen-
tation.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

visit: Class Visit Type: AST Visitor

229
Appendices.

Applicability: Class, Nested Class, Anonymous


Class, Interface, Enumeration
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Types Method Type

Visit Type: AST Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Types AnnotationTypeMember Type

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Annota-
tion

Table 71: Used Inter Types Design Information - Def. and Comput.

Used Inter Types

For class: collection of the type of classes different from


the measured class and the ones in the hierarchy of the
measured class, used by the measured class.
For method: collection of the type of classes different
from the class that declares the measured method and the
ones in the hierarchy of the class that declares the meas-
ured method, used by the measured method.
Definition

A class or method uses a type in different context, like


method call and field access. We collect use in every pos-
sible context as defined by Eclipse JDT [140] documen-
tation.
Types belonging both to the system and to the libraries it
uses.

230
Appendices.

Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Types Method Type

Visit Type: AST Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Types AnnotationTypeMember Type

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Annota-
tion

Table 72: Used Hierarchy Types Design Information - Def. and Comput.

Used Hierarchy Types

For class: collection of the type of classes in the hierar-


chy of the measured one, used by the measured class.
For method: collection of the type of classes in the hier-
archy of the class that declares the measured method,
Definition used by the measured method.
A class or method uses a type in different context, like
method call and field access. We collect use in every pos-
sible context as defined by Eclipse JDT [140] documen-
tation.

231
Appendices.

Types belonging both to the system and to the libraries it


uses.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Class Applicability: Class, Nested Class, Anonymous
Class, Interface, Enumeration
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Hierarchy Types Method Type

Visit Type: AST Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Hierarchy Types AnnotationTypeMember Type

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Annota-
tion

Table 73: Used Types Design Information - Def. and Comput.

Used Types

The set given by the union of “Used Intra Types”, “Used


Definition
Inter Types”, and “Used Hierarchy Types”.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: not Annotation ComplexType

232
Appendices.

Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Types Type Type
Used Inter Types Type Type
Used Hierarchy Types Type Type

Visit Type: Model Visitor


visit: Annotation
Applicability: Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Types AnnotationTypeMember AnnotationType
Member
Used Inter Types AnnotationTypeMember AnnotationType
Member
Used Hierarchy Types AnnotationTypeMember AnnotationType
Member

Visit Type: Model Visitor


visit: Method Applicability: Method, Member of an Annota-
tion
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Types Method Method
Used Inter Types Method Method
Used Hierarchy Types Method Method

233
Appendices.

Table 74: Called Classes Design Information - Def. and Comput.

Called Classes

For class: collection of classes of the system called in


the field declaration part of the class and by the methods
it declares. The calls to the measured class are not con-
sidered.
For method: collection of classes of the system called by
Definition
the method. The calls to the class containing the methods
are not considered.

Classes belonging both to the system and to the libraries


it uses.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Type
Class
Called Inter Methods Type Type

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Inter Methods Method Method

234
Appendices.

Table 75: Calling Classes Design Information - Def. and Comput.

Calling Classes

For class: collection of classes of the system that call


methods from the measured class. The calls from the
measured class and the methods it declares are not con-
sidered.
Definition
For method: collection of classes of the system that call
the measured method. The calls from the current method
to the methods in the same class containing the measured
method are not considered.
For class: we consider also the calls from the classes in
the hierarchy of the measured one.
Computation
For method: we consider also the calls from the methods
Details
declared by the classes in the hierarchy of the one that
declared the measured method.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: not Anonymous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Project
Class
Called Inter Methods Type Project
Called Hierarchy Meth- Type Project
ods

Visit Type: Model Visitor


visit: Method Applicability: Method not declared in Anony-
mous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


235
Appendices.

Methods Declared In Type Project


Class
Called Inter Methods Method Project
Called Hierarchy Meth- Method Project
ods

Table 76: Calling Methods Design Information - Def. and Comput.

Calling Methods

For class: collection of methods of the system that call


methods from the measured class. The calls from the
measured class and the methods it declares are not con-
sidered.
Definition
For method: collection of methods of the system that call
the measured method. The calls from the current method
to the methods in the same class containing the measured
method are not considered.
For class: we consider also the calls from the classes in
the hierarchy of the measured one.
Computation
For method: we consider also the calls from the methods
Details
declared by the classes in the hierarchy of the one own-
ing the measured method.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: not Anonymous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Project
Class
Called Inter Methods Type Project
236
Appendices.

Called Hierarchy Meth- Type Project


ods

Visit Type: Model Visitor


visit: Method Applicability: Method not declared in Anony-
mous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Project
Class
Called Inter Methods Method Project
Called Hierarchy Meth- Method Project
ods

Table 77: Message Chains Info Design Information - Def. and Comput.

Message Chains Info

The order and the methods in the chained calls the meas-
ured methods do to accessor methods (i.e., getter). A
chained call has a minimum length of two (e.g., a.getB()
Definition
is not a chained call, while a.getB ().getC() is a chained
call). We consider only the call to classes belonging to
the system.
We traverse the AST and each time we encounter a call
to a getter method, we save it into a stack to track the
context of visit (i.e., the parent of the node representing
the call to a getter method). Each time we end a visit of
Computation
a sub tree we pop from the top of the stack the context
Details
and if we have identified a chained call we save them
along with the order representing the position in the
method where we detect them respecting to other chained
calla the method does.

237
Appendices.

Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.

B2 Design Metrics Definition and Computation


In Table 78 to Table 121, we presents all the design metrics we compute on
the source code (refers to Section 4.2.3). A design metric can depend upon
one or more other design information and design metrics, hence we report
every design metric after other design metrics and/or design information it
depends on. We organize design metrics using a structure that encapsulate
their definitions (i.e., an enum). In this way, users can ask DFMC4J for them
in a consistent way.

For each design metric, we report:

 The Name and the Acronym: that is the identifier name and label we
assign to the design metric;
 Definition;
 References: the references where the metric is defined, the first is
the one where we took the definition. For some well-known and
widely used or straightforward metric the reference is not available ;
 Worse: for metrics directly measuring a design quality characteris-
tics (e.g., size and complexity of a method), we denote how to eval-
uate the metric values and understand when the metric gets worse;
 Discussion: optionally we discuss some details concerning the met-
ric evaluation and usefulness for software quality assessment;
 Computation Details: we report all the important details about the
computation, if needed;
 Visitor Type: the visitor type as defined in Section 3.2.2, one of AST
Visitor, Model Visitor or Hybrid Visitor;
 Implementation details for each entity the visitor can visit:
238
Appendices.

o visit: the visited entity, according to Table 4 where we refer


to Class, Nested Class, Anonymous Class, Interface, Enumer-
ation, Annotation with Class and to Method and Member of
an Annotation with Method. The Applicability indicates
which among the set are considered. When we refer specifi-
cally to Annotation, we use Annotation;
o Type of the visited entity: AST from source code or a
DFMC4J model element (refers to Section 3.2.2);
o Applicability: the entities of the source code where we apply
the measure implemented by the design metric;
o Dependencies Information: the information from which the
defined design metric depends on, as described in Section
3.2.2. We use the Dep-Entities element from Table 6 to de-
scribe Dep-entity and Dep-level fields.

In the following, we refer to getter and setter in two ways:

 with the name of “Accessor and Mutator” used by us for the sake of
clarity (i.e., getter is an accessor, setter is a mutator),
 with the name “accessor” referred to either getter that setter, which
is the terminology we often find in the literature.

Table 78: LOC Design Metric - Definition and Computation

Lines of Codes (LOC)

The number of lines of code of an operation or of a class,


Definition
including blank lines and comments.

References [81]

Worse For greater values.

For method: we count the LOC from the method signa-


Computation ture to the last curly bracket.
Details For class: we count the LOC from the class declaration
to the last curly bracket.

239
Appendices.

For package: we sum the LOC of the classes declared in


the package.
For project: we sum the LOC of all packages.
Visitor Type Hybrid Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Method Applicability: Method, Member of an Anno-
tation

Visit Type: AST Visitor


Applicability: Class, Nested Class, Anony-
visit: Class
mous Class, Interface, Enumeration, Annota-
tion

Visit Type: Model Visitor


visit: Package
Applicability: Package
Dependencies Information:

Dep-visitor Dep-entity Dep-level


LOC Type Type

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


LOC Package Package

240
Appendices.

Table 79: LOCNAMM Design Metric - Definition and Computation

Lines of Codes Without Accessor or Mutator Methods (LOCNAMM)

The number of lines of code of a class, including blank


Definition lines and comments and excluding accessor and mutator
methods and corresponding comments.

References Defined in this work.

Worse For greater values.

We define this metric because getter and setter methods


Discussion are usually generated by the IDE. Refer to God Class
code smell in Section 6.3.1 for more details.
Computation We count the LOC from the class declaration to the last
Details curly bracket.
Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


Applicability: Class, Nested Class, Anony-
visit: Class
mous Class, Interface, Enumeration, Annota-
tion

Table 80: NOPK Design Metric - Definition and Computation

Number of Packages (NOPK)

Definition Total number of packages in a system.

References -

Worse -

We declare a dependency to Declared Classes on the en-


Computation
tire project. In this way, we save on the DFMC4J Model
Details
all the packages that contain the classes.

241
Appendices.

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Declared Classes CompilationUnit Project

Table 81: NOCS Design Metric - Definition and Computation

Number of Classes (NOCS)

Total number of classes in a system, in a package or in a


Definition
class.

References -

Worse -

For class: we sum up the number of nested classes.


For package: we sum up the NOCS for all the classes in
Computation
the package.
Details
For project: we sum up the NOCS for all the packages
in the project.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Declared Classes CompilationUnit Project

visit: Package Visit Type: Model Visitor

242
Appendices.

Applicability: Package
Dependencies Information:

Dep-visitor Dep-entity Dep-level


NOCS Type Package

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


NOCS Package Project

Table 82: NOM Design Metric - Definition and Computation

Number of Methods (NOM)

NOM represents the number of methods defined lo-


cally in a class, counting public as well as private
Definition
methods. Overridden methods are not taken into ac-
count.

References [41][81]

Worse -

For class: we sum up the number of Methods Declared


In Class.
Computation For package: we sum up the NOM for all the classes
Details in the package.
For project: we sum up the NOM for all the packages
in the project.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
243
Appendices.

Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Class Type Type

Visit Type: Model Visitor


visit: Package
Applicability: Package
Dependencies Information:

Dep-visitor Dep-entity Dep-level


NOM Type Package

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


NOM Package Project

Table 83: NOMNAMM Design Metric - Definition and Computation

Number of Not Accessor or Mutator Methods (NOMNAMM)

NOMNAMM represents the number of methods de-


Definition fined locally in a class, counting public as well as pri-
vate methods, excluding accessor or mutator methods.

References Defined in this work.

Worse -

Discussion Refer to Data Class code smell in Section 6.3.2

For class: we sum up the number of not accessor or


mutator Methods Declared In Class.
Computation For package: we sum up the NOMNAMM for all the
Details classes in the package.
For project: we sum up the NOMNAMM for all the
packages in the project.

244
Appendices.

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Class ComplexType ComplexType

Visit Type: Model Visitor


visit: Package
Applicability: Package
Dependencies Information:

Dep-visitor Dep-entity Dep-level


NOMNAMM Type Package

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


NOMNAMM Package Project

Table 84: NOA Design Metric - Definition and Computation

Number of Attributes (NOA)

Definition Number of attributes of a class.

References -

Worse -

Visitor Type Model Visitor

245
Appendices.

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Attributes of Class Type Type

Table 85: CYCLO Design Metric - Definition and Computation

Cyclomatic Complexity (CYCLO)

Cyclomatic Complexity is the maximum number of


linearly independent paths in a method. A path is linear
Definition
if there is no branch in the execution flow of the cor-
responding code.

References [41][96]

Worse For greater values.

This metric is an indicator of the degree of structu-


ration of the code, which has effects on maintenance
and modularization efforts. Code with lots of "break",
Discussion
"continue", "goto" or "return" clauses is more complex
to understand and more difficult to simplify and divide
into simpler routines [41].
We compute the strict Cyclomatic Complexity: the Cy-
clomatic Complexity with logical conjunction and log-
ical and in conditional expressions also adding 1 to the
Computation complexity for each of their occurrences. i.e., The
Details statement if (a && b || c) would have a Cyclomatic
Complexity of one but a strict Cyclomatic Complexity
of three.
The minimum Cyclomatic Complexity is one.

246
Appendices.

Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Method Applicability: not Abstract Method, not be-
longing to Annotation nor Interface

Table 86: WMC Design Metric - Definition and Computation

Weighted Methods Count (WMC)

WMC is the sum of complexity of the methods that are


Definition defined in the class. We compute the complexity with
the Cyclomatic Complexity metric (CYCLO).

References [41][22]

Worse -

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Annotation nor Interface
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Type
Class
CYCLO Method Type

247
Appendices.

Table 87: WMCNAMM Design Metric - Definition and Computation

Weighted Methods Count of Not Accessor or Mutator Methods


(WMCNAMM)
WMCNAMM is the sum of complexity of the methods
that are defined in the class, and are not accessor or mu-
Definition
tator methods. We compute the complexity with the Cy-
clomatic Complexity metric (CYCLO).

References Defined in this work.

Worse -

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Annotation nor Interface
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Type
Class
CYCLO Method Type

Table 88: AMW Design Metric - Definition and Computation

Average Methods Weight (AMW)

The average static complexity of all methods in a class.


Definition We compute the complexity with the Cyclomatic Com-
plexity metric (CYCLO).

References [89]

Worse -
248
Appendices.

𝑊𝑀𝐶
𝑓(𝑥) = {𝐴𝑀𝑊 = 𝑁𝑂𝑀 , 𝑁𝑂𝑀 ≠ 0
Computation
Details 𝐴𝑀𝑊 = 0, 𝑁𝑂𝑀 = 0
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Annotation nor Interface
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


WMC Type Type
NOM Type Type

Table 89: AMWNAMM Design Metric - Definition and Computation

Average Methods Weight of Not Accessor or Mutator Methods (AM-


WNAMM)
The average static complexity of all methods in a
class, which are not accessor or mutator. We compute
Definition
the complexity with the Cyclomatic Complexity met-
ric (CYCLO).

References Defined in this work.

Worse -
𝑊𝑀𝐶𝑁𝐴𝑀𝑀
Computation
𝑓(𝑥) = {𝐴𝑀𝑊𝑁𝐴𝑀𝑀 = 𝑁𝑂𝑀𝑁𝐴𝑀𝑀 , 𝑁𝑂𝑀𝑁𝐴𝑀𝑀 ≠ 0
Details 𝐴𝑀𝑊𝑁𝐴𝑀𝑀 = 0, 𝑁𝑂𝑀𝑁𝐴𝑀𝑀 = 0

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Annotation nor Interface
ComplexType

249
Appendices.

Dependencies Information:

Dep-visitor Dep-entity Dep-level


WMCNAMM Type Type
NOMNAMM Type Type

Table 90: MAXNESTING Design Metric - Definition and Computation

Maximum Nesting Level (MAXNESTING)

The maximum nesting level of control structures within


Definition
an operation.

References [75]

Worse For greater values.

Visitor Type AST Visitor

Implementation details for each entity the visitor can visit

Visit Type: AST Visitor


visit: Method Applicability: not Abstract Method, not be-
longing to Annotation nor Interface

Table 91: WOC Design Metric - Definition and Computation

Weight of Class (WOC)

The number of “functional” public methods divided by


Definition
the total number of public members.

References [89]

Worse For lower values.

This metric measure the weight of functionalities offered


Discussion
by a class through its public interface.

250
Appendices.

We compute this metrics as:

Computation 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑁𝑜𝑛 𝐴𝑏𝑠𝑡𝑟𝑎𝑐𝑡 𝑃𝑢𝑏𝑙𝑖𝑐 𝑁𝑜𝑛 𝐴𝑐𝑐𝑒𝑠𝑠𝑜𝑟 𝑜𝑟 𝑀𝑢𝑡𝑎𝑡𝑜𝑟 𝑀𝑒𝑡ℎ𝑜𝑑𝑠


𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑃𝑢𝑏𝑙𝑖𝑐 𝑀𝑒𝑡ℎ𝑜𝑑𝑠 𝑎𝑛𝑑 𝐴𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒
Details
If 𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑃𝑢𝑏𝑙𝑖𝑐 𝑀𝑒𝑡ℎ𝑜𝑑𝑠 𝑎𝑛𝑑 𝐴𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 is
zero, WOC is zero.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: Not Abstract ComplexType that
are not Interface nor Annotation
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Type
Class
Attributes of Class Type Type

Table 92: CLNAMM Design Metric - Definition and Computation

Called Local Not Accessor or Mutator Methods (CLNAMM)

The number of called not accessor or mutator methods


Definition
declared in the same class of the measured method.

References Defined in this work.

Worse -

Discussion Refer to Brain Method code smell in Section 6.3.3

Computation We sum up the number of not accessor or mutator Called


Details Intra Methods.
Visitor Type Model Visitor

251
Appendices.

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Intra Methods Method Method

Table 93: NOP Design Metric - Definition and Computation

Number of Parameters (NOP)

Definition Number of parameters of a method.

References -

Worse For greater values.

Greater the number of parameter, more method signature


Discussion
is difficult to understand.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method
Applicability: Method
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared in Type Type
Class

252
Appendices.

Table 94: NOAV Design Metric - Definition and Computation

Number of Accessed Variables (NOAV)

The total number of variables accessed directly or


through accessor methods from the measured operation.
Definition Variables include parameters, local variables, but also
instance variables and global variables declared in clas-
ses belonging to the system.

References [75]

Worse For greater values.

We count the Used Variables defined within the system


and not in external libraries. The context we consider
are: MethodDeclarationParameter, CatchClause,
EnumConstantDeclaration, VariableDeclarationEx-
pression, VariableDeclarationStatement, SingleVaria-
Computation bleDeclaration, VariableDeclarationFragment [140].
Details To count the variable accessed through accessor methods
we get the list of Called Methods and we count the Used
Intra Variables by each accessor method in the set of
Called Methods.
We count also the variable access through static meth-
ods.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


Applicability: not Abstract Method, not be-
visit: Method
longing to Annotation nor Interface Com-
plextype
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Variables Method Method
Used Intra Variables Method Project

253
Appendices.

Called Methods Method Method

Table 95: ATLD Design Metric - Definition and Computation

Access to Local Data (ATLD)

The number of attributes declared by the current classes


Definition accessed by the measured method directly or by invoking
accessor methods.

References Defined in this work.

Worse For greater values.

We count the Used Intra Variables defined within the


system and not in external libraries.
Computation To count the variable accessed through accessor methods
Details we get the list of Called Intra Methods and we count the
Used Intra Variables by each accessor method in the set
of Called Methods.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables Method Project
Used Hierarchy Varia- Method Project
bles
Called Intra Methods Method Method

254
Appendices.

Table 96: NOLV Design Metric - Definition and Computation

Number of Local Variable (NOLV)

Number of local variable declared in a method. The


Definition
method’s parameter are considered local variable.

References [89]

Worse For greater values.

We count the number of Used Intra Variable in contexts


that represent variable declaration (e.g., MethodDecla-
Computation rationParameter, CatchClause, EnumConstantDeclara-
Details tion, VariableDeclarationExpression, VariableDeclara-
tionStatement, SingleVariableDeclaration, Variable-
DeclarationFragment [140])
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Intra Variables Method Method

Table 97: TCC Design Metric - Definition and Computation

Tight Class Cohesion (TCC)

TCC is the normalized ratio between the number of


methods directly connected with other methods
Definition through an instance variable and the total number of
possible connections between methods. A direct con-
nection between two methods exists if both access the

255
Appendices.

same instance variable directly or indirectly through


a method call. TCC takes its value in the range [0,1].

References [41][17][18]

Worse For lower values.

Given:
Maximum number of possible connections:
Where N is the number of visible methods.

𝑁 ∗ (𝑁 − 1)
𝑁𝑃 =
2

Number of direct connections: NDC, computed using


a connectivity matrix that records all direct connected
methods, making attention to cyclic calls among
methods.

Computation
Details We compute:

𝑁𝐷𝐶
{𝑇𝐶𝐶 = 𝑁𝑃 𝑁𝑃 ≠ 0
𝑇𝐶𝐶 = 1 𝑁𝑃 = 0

For TCC only visible methods are considered, i.e.,


they are not private, implement an interface, or handle
an event. Constructors are ignored. Constructors are a
problem, because of indirect connections with attrib-
utes. They create indirect connections between meth-
ods which use different attributes, and increase cohe-
sion, which is not real [41].
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: Not Abstract ComplexType
that are not Interface nor Annotation

256
Appendices.

Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Class Type Type
Attributes of Class Type Type
Called Intra Methods Type Type
Used Intra Variables Type Type

Table 98: LCOM5 Design Metric - Definition and Computation

Lack of Cohesion in Methods (LCOM5)

∑𝑚𝜖𝑀 𝑁𝑂𝐴𝑐𝑐(𝑚)
𝑁𝑂𝑀 −
𝐿𝐶𝑂𝑀5 = 𝑁𝑂𝐴
𝑁𝑂𝑀 − 1

Definition
where 𝑀 is the set of methods of the class, 𝑁𝑂𝑀 the
number of methods, 𝑁𝑂𝐴 the number of attributes,
and 𝑁𝑂𝐴𝑐𝑐(𝑚) is the number of attributes of the class
accessed by method 𝑚.

References [41][17]

Worse For lower values.

LCOM5 varies in the range [0,1]. However, LCOM5


can return a measure up to two when there are for ex-
ample only two methods and no attribute accesses.
Discussion
This metric considers that each method should access
all attributes in a completely cohesive class, which is
not a good design [41].
For ∑𝑚𝜖𝑀 𝑁𝑂𝐴𝑐𝑐(𝑚) we sum up Used Intra Variables
by not constructor methods of the measured class.
Computation
Details Then we compute:

257
Appendices.

∑𝑚𝜖𝑀 𝑁𝑂𝐴𝑐𝑐(𝑚)
𝑁𝑂𝑀 −
{𝐿𝐶𝑂𝑀5 = 𝑁𝑂𝐴 𝑁𝑂𝑀 > 1 ∧ 𝑁𝑂𝐴 > 0
𝑁𝑂𝑀 − 1
𝐿𝐶𝑂𝑀5 = 0 𝑁𝑂𝑀 ≤ 1 ∨ NOA ≤ 0

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Class Type Type
Used Intra Variables Type Type
NOM Type Type
NOA Type Type

Table 99: FANOUT Design Metric - Definition and Computation

FANOUT

Definition Number of called classes.

References [75]

Worse For greater values.

Computation
We sum up the Called Classes belonging to the system.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
258
Appendices.

Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Classes Method Method

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Classes Type Type

Table 100: FANIN Design Metric - Definition and Computation

FANIN

Definition Number of calling classes.

References -

Worse For greater values.

Computation
We sum up the Calling Classes.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: Not Anonymous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Calling Classes Type Type

259
Appendices.

Table 101: ATFD Design Metric - Definition and Computation

Access to Foreign Data (ATFD)

The number of attributes from unrelated classes belong-


Definition ing to the system, accessed directly or by invoking ac-
cessor methods.

References [89]

Worse For greater values.

For methods: we sum up the Used Inter Variables be-


longing to the system, also through not Contructor, Pub-
lic, and not Abstract Called Inter Methods of the system.
For class: we sum up the Used Inter Variable belonging
to the system, also through not Constructor, Public and
not Abstract Called Inter Methods from the field decla-
Computation ration class of the methods and from all the not Con-
Details structor and not Abstract Methods Declared In Class.
We do not declare a dependency to ATFD on method be-
cause we have to count each accessed variable only once.

When we check for used variable in Called Inter Meth-


ods, we have to know the Used Intra Variables the meth-
ods use, hence the dependency to Used Intra Variables.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


Applicability: Not Abstract nor Constructor
visit: Method
Method, not from Interface and Annotation
ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Variables Method Method
Called Inter Methods Method Method

260
Appendices.

Used Intra Variables Method Project

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Variables Type Type
Called Inter Methods Type Type
Used Intra Variables Type Project
Methods Declared In Type Type
Class

Table 102: FDP Design Metric - Definition and Computation

Foreign Data Providers (FDP)

The number of classes in which the attributes accessed -


Definition
in conformity with the ATFD metric - are defined.

References [75]

Worse For greater values.

Computation We sum up the classes where foreign data are defines,


Details counting each class only once.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Variables Method Method
Called Inter Methods Method Method
Used Intra Variables Method Project
261
Appendices.

Table 103: RFC Design Metric - Definition and Computation

Response for a Class (RFC)

RFC is the size of the response set of a class. The re-


sponse set of a class includes “all methods that can be
Definition invoked in response to a message to an object of the
class”. It includes local methods (also the inherited
ones) as well as methods in other classes.

References [41][22]

Worse For greater values.

This metric reflects the class complexity and the


amount of communication with other classes. The
Discussion larger the number of methods that may be invoked
from a class through messages, the greater the com-
plexity of the class is [41].
We sum up also the Called Inter Methods and Called
Computation Hierarchy Methods by the Inherited Methods count-
Details ing each method only one time. We consider only call
to classes belonging to the system.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Inter Methods Type Project
Called Hierarchy Methods Type Project
Methods Declared In Class Type Type
Inherited Methods Type Type

262
Appendices.

Table 104: CBO Design Metric - Definition and Computation

Coupling Between Objects classes (CBO)

Two classes are coupled if one of them uses the other,


i.e., one class calls a method or accesses an attribute
of the other class. Coupling involving inheritance and
Definition
methods polymorphically called are taken into ac-
count. CBO for a class is the number of classes to
which it is coupled.

References [41][22][45]

Worse For greater values.

We sum up all the unrelated classes belonging to the


system that define the Used Inter Variables, Used Hi-
erarchy Variables, Used Inter Types, Used Hierarchy
Computation
Types, Called Inter Methods, and Called Hierarchy
Details
Methods by the measured class and its Ancestor Clas-
ses and by methods the measured class methods de-
clare and inherit. We count each class once.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Annotation nor Interface
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Inter Variables Type Project
Used Hierarchy Variables Type Project
Used Inter Types Type Project
Used Hierarchy Types Type Project
Called Inter Methods Type Project
Called Hierarchy Methods Type Project
Methods Declared In Class Type Type

263
Appendices.

Ancestor Classes Type Type


Inherited Methods Type Project

Table 105: CFNAMM Design Metric - Definition and Computation

Called Foreign Not Accessor or Mutator Methods (CFNAMM)

For method: the number of called not accessor or muta-


tor methods declared in unrelated classes respect to the
one that declares the measured method.
For class: the number of called not accessor or mutator
Definition
methods declared in unrelated classes respect to the
measured one.

We consider only call to classes belonging to the system.

References Defined in this work.

Worse -

We sum up the number of not accessor or mutator Called


Computation Inter Methods and Called Hierarchy Methods of the sys-
Details tem.
We do not count the call to default constructor of classes.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Inter Methods Method Method
Called Hierarchy Meth- Method Method
ods

264
Appendices.

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Type
Class
Called Inter Methods Type Type
Called Hierarchy Meth- Type Type
ods

Table 106: CINT Design Metric - Definition and Computation

Coupling Intensity (CINT)

The number of distinct operations called by the meas-


Definition
ured operation.

References [89]

Worse For greater values.

Computation We sum up Called Inter Methods belonging to system


Details classes.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Called Inter Methods Method Method

265
Appendices.

Table 107: CDISP Design Metric - Definition and Computation

Coupling Dispersion (CDISP)

The number of classes in which the operations called


Definition from the measured operation are defined, divided by
CINT.

References [89]

Worse For greater values.

The definition does not explicitly indicate if to consider


or not the call to the current class (i.e., the class that
contains the measured method) has to be counted or not.
We choice to count only call to unrelated classes, be-
Discussion
cause the coupling is to unrelated classes.

Refer to Dispersed Coupling code smell in Section 6.3.5


for other details about how we use this metric
𝐹𝐴𝑁𝑂𝑈𝑇
{𝐶𝐷𝐼𝑆𝑃 = 𝐶𝐼𝑁𝑇 𝐶𝐼𝑁𝑇 ≠ 0
Computation
Details 𝐶𝐷𝐼𝑆𝑃 = 0 𝐶𝐼𝑁𝑇 = 0
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


FANOUT Method Method
CINT Method Method

266
Appendices.

Table 108: MaMCL Design Metric - Definition and Computation

Maximum Message Chain Length (MaMCL)

Definition The maximum length of chained calls in a method.

References Defined in this work.

Worse For greater values.

Discussion Refer to Message Chain code smell in Section 6.3.6

Computation We compute the maximum length of a chain in Message


Details Chains Info
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not
from Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Message Chains Info Method Method

Table 109: NMCS Design Metric - Definition and Computation

Number of Message Chain Statements (NMCS)

Definition The number of different chained calls in a method.

References Defined in this work.

Worse For greater values.

Discussion Refer to Message Chain code smell in Section 6.3.6

Computation We compute the number of chains in Message Chains


Details Info

267
Appendices.

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not
from Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Message Chains Info Method Method

Table 110: MeMCL Design Metric - Definition and Computation

Mean Message Chain Length (MeMCL)

Definition The average length of chained calls in a method.

References Defined in this work.

Worse For greater values.

Discussion Refer to Message Chain code smell in Section 6.3.6

We compute the rounded average length of a chain in


Computation
Message Chains Info. If NMCS is zero, then MeMCL is
Details
zero too.
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not
from Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Message Chains Info Method Method
NMCS Method Method
268
Appendices.

Table 111: CC Design Metric - Definition and Computation

Changing Classes (CC)

The number of classes in which the methods that call the


Definition
measured method are defined in.

References [89]

Worse For greater values.

Computation
We sum up the number of Calling Classes.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not private Method not de-
clared in Anonymous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Calling Classes Method Method

Table 112: CM Design Metric - Definition and Computation

Changing Methods (CM)

The number of distinct methods that call the measured


Definition
method.

References [89]

Worse For greater values.

Computation
We sum up the number of Calling Methods.
Details

269
Appendices.

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not private Method not de-
clared in Anonymous ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Calling Methods Method Method

Table 113: NOAM Design Metric - Definition and Computation

Number of Accessor Methods (NOAM)

The number of accessor (getter and setter) methods of a


Definition
class.

References [75]

Worse -

Computation We sum up the number of getter and setter Methods De-


Details clared In Class
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: not Interface nor Annotation
ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Methods Declared In Type Type
Class

270
Appendices.

Table 114: NOPA Design Metric - Definition and Computation

Number of Public Attributes (NOPA)

Definition The number of public attributes of a class.

References [75]

Worse For greater values.

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Attributes Of Class Type Type

Table 115: LAA Design Metric - Definition and Computation

Locality of Attribute Accesses (LAA)

The number of attributes from the method’s definition


class, divided by the total number of variables accessed
(including attributes used via accessor methods, see
Definition ATFD), whereby the number of local attributes accessed
is computed in conformity with the ATLD specifica-
tions. We consider only variables declared in system
classes.

References [75]

Worse For lower values.

Each attribute count only one, independently from the


Computation
ways the class accesses it (e.g., directly or through ac-
Details
cessor and/or mutator) and how many times accesses it.
271
Appendices.

Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Method Applicability: not Abstract Method, not from
Interface and Annotation ComplexType.
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Used Variables Method Project
Called Methods Method Method

Table 116: DIT Design Metric - Definition and Computation

Depth of Inheritance Tree (DIT)

The depth of a class, measured by DIT, within the in-


heritance hierarchy is the maximum length from the
Definition class node to the root of the tree, measured by the
number of ancestor classes. DIT has a minimum value
of one, for classes that do not have ancestors.

References [41][22]

Worse For greater values.

The deeper a class within the hierarchy, the greater


Discussion the number of methods it is likely to inherit, making
it more complex to predict its behaviour.
We consider only hierarchy classes belonging to the
Computation system: we visit the Ancestor Classes in a bottom up
Details order and we stop counter at the first class that does
not belong to the system.
Visitor Type Model Visitor

272
Appendices.

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: Not Interface nor Enumera-
tion ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Ancestor Classes Type Type

Table 117: NOI Design Metric - Definition and Computation

Number of Interfaces (NOI)

Number of interfaces declared in a package or in a sys-


Definition
tem.

References -

Worse -

Computation
We sum up the Interface Declared Classes.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Package
Applicability: Package
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Declared Classes Package Package

Visit Type: Model Visitor


visit: Project
Applicability: Project
Dependencies Information:

Dep-visitor Dep-entity Dep-level


273
Appendices.

NOI Package Project

Table 118: NOC Design Metric - Definition and Computation

Number of Children (NOC)

Number of children counts the immediate subclasses


Definition
subordinated to a class in the class hierarchy.

References [41][22]

Worse For greater values.

Computation
We sum up the Children Classes.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class Applicability: Not Anonymous Com-
plexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Children Classes Type Type

Table 119: NMO Design Metric - Definition and Computation

Number of Methods Overridden (NMO)

NMO represents the number of methods that have


been overridden i.e., defined in the superclass and re-
Definition defined in the class. This metric includes methods do-
ing super invocation to their parent method. NMO is
not defined for classes that have not superclass.

274
Appendices.

References [41][81]

Worse For low values.

Computation
We sum up the Overridden Methods.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


Applicability: Not abstract ComplexType,
visit: Class
Nested ComplexType, Anonymous Com-
plexType, Enumeration ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Overridden Methods Type Type

Table 120: NIM Design Metric - Definition and Computation

Number of Inherited Methods (NIM)

NIM is a simple measure showing the amount of be-


haviour that a given class can reuse. It counts the
Definition number of methods that a class can access in its su-
perclasses. NIM is not defined for classes that have
not superclass.

References [41][81]

Worse For high values.

Computation
We sum up the Inherited Methods.
Details
Visitor Type Model Visitor

275
Appendices.

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


Applicability: Not abstract ComplexType,
visit: Class
Nested ComplexType, Anonymous Com-
plexType, Enumeration ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Inherited Methods Type Type

Table 121: NOII Design Metric - Definition and Computation

Number of Implemented Interfaces (NOII)

Definition Number of implemented interfaces by a class.

References -

Worse -

Computation
We sum up the Implemented Interfaces.
Details
Visitor Type Model Visitor

Implementation details for each entity the visitor can visit

Visit Type: Model Visitor


visit: Class
Applicability: ComplexType
Dependencies Information:

Dep-visitor Dep-entity Dep-level


Implemented Interfaces Type Type

276
Appendices.

C1 Systems of Qualitas Corpus Used as Benchmark


Table 122 presents the list of the 74 systems from the Qualitas Cor-
pus we use as benchmark for Benchmark-Based Thresholds derivation (Sec-
tion 5.2.3 ), and for code smells detection evaluation (Section 7.1 ). We re-
port the systems along with some additional information:

 System: the name of the system plus the version;


 Domain: an indication of the purpose of the system. according to
[125];
 Releasedate: the release date of the System.

277
Table 122: 74 Selected Systems from the Qualitas Corpus

System LOC NOPK NOCS NOM Domain Releasedate


aoi-2.8.1 136,533 22 799 6,880 3D/graphics/media 1/3/2010
argouml-0.34 284,934 125 2,361 18,015 diagram generator/data visualization 12/15/2011
axion-1.0-M2 28,583 13 223 2,989 database 7/11/2003
castor-1.3.1 213,479 149 1,542 11,967 middleware 1/3/2010
cobertura-1.9.4.1 58,364 19 107 3,309 testing 3/3/2010
colt-1.2.0 75,688 24 525 4,143 SDK 9/10/2004
columba-1.0 109,035 183 1,188 6,818 tool 9/18/2005
displaytag-1.2 20,892 18 128 1,064 diagram generator/data visualization 12/27/2008
drawswf-1.2.9 38,451 33 297 2,742 3D/graphics/media 6/8/2004
drJava-stable-20100913-r5387 130,132 29 2,250 10,364 IDE 9/13/2010
emma-2.0.5312 34,404 26 262 1,805 testing 6/12/2005
exoportal-v1.0.2 102,803 382 1,855 11,709 diagram generator/data visualization 5/16/2006
findbugs-1.3.9 146,551 54 1,631 10,153 testing 8/21/2009
fitJava-1.1 2,453 2 60 254 testing 4/7/2004
fitlibraryforfitnesse-20100806 25,691 108 795 4,165 testing 8/6/2010
freecol-0.10.3 163,595 36 1,244 8,322 games 9/27/2011
freecs-1.3.20100406 25,747 12 131 1,404 tool 4/6/2010
freemind-0.9.0 65,687 43 849 5,788 diagram generator/data visualization 2/19/2011
galleon-2.3.0 120,720 35 764 4,305 3D/graphics/media 4/15/2006
ganttproject-2.0.9 58,718 54 959 5,518 tool 3/31/2009
heritrix-1.14.4 94,240 45 649 5,366 tool 5/10/2010
hsqldb-2.0.0 171,667 22 465 7,652 database 6/7/2010
itext-5.0.3 117,757 24 497 5,768 diagram generator/data visualization 7/22/2010
jag-6.1 24,112 15 255 1,450 tool 5/25/2006
jasml-0.10 6,694 4 48 245 tool 5/23/2006
jasperreports-3.7.3 260,912 66 1,571 17,113 diagram generator/data visualization 7/20/2010
Javacc-5.0 19,045 7 102 808 parsers/generators/make 10/20/2009
jedit-4.3.2 138,536 28 1,037 6,560 tool 5/9/2010
jena-2.6.3 117,117 48 1,196 9,900 middleware 6/1/2010
jext-5.0 34,855 37 485 2,169 diagram generator/data visualization 7/7/2004
jFin_DateMath-R1.0.1 7,842 11 58 541 SDK 2/19/2010
jfreechart-1.0.13 247,421 69 960 11,810 tool 4/20/2009
jgraph-5.13.0.0 53,577 32 399 2,996 tool 9/28/2009
jgraphpad-5.10.0.2 33,431 22 426 1,879 tool 11/9/2006
jgrapht-0.8.1 28,493 19 299 1,475 tool 7/4/2009
jgroups-2.10.0 126,255 21 1,093 8,798 tool 7/12/2010
jhotdraw-7.5.1 104,357 64 968 7,232 3D/graphics/media 8/1/2010
jmeter-2.5.1 113,375 110 909 8,059 testing 9/29/2011
jmoney-0.4.4 9,457 4 190 713 tool 9/29/2003
jparse-0.96 16,524 3 65 780 parsers/generators/make 7/17/2004
jpf-1.0.2 18,172 10 121 1,271 SDK 5/19/2007
jruby-1.5.2 199,533 77 2,023 17,693 programming language 8/20/2010
jspwiki-2.8.4 69,144 40 405 2,714 middleware 5/8/2010
jsXe-04_beta 14,480 7 100 703 tool 4/25/2006
jung-2.0.1 53,617 40 786 3,884 diagram generator/data visualization 1/25/2010
junit-4.10 9,065 28 204 1,031 testing 9/29/2011
log4j-1.2.16 34,617 22 296 2,118 testing 3/30/2010
lucene-3.5.0 214,819 133 1,908 12,486 tool 11/20/2011
marauroa-3.8.1 26,472 30 208 1,593 games 7/25/2010
megamek-0.35.18 315,953 37 2,096 13,676 games 8/31/2010
mvnforum-1.2.2-ga 92,696 29 338 5,983 tool 8/17/2010
nekohtml-1.9.14 10,835 4 56 502 parsers/generators/make 2/2/2010
openjms-0.7.7-beta-1 68,929 48 515 3,790 middleware 3/14/2007
oscache-2.4.1 11,929 13 66 629 middleware 7/7/2007
picocontainer-2.10.2 12,103 15 208 1,302 middleware 2/25/2010
pmd-4.2.5 71,486 88 862 5,959 testing 2/8/2009
poi-3.6 299,402 133 2,330 19,618 tool 12/15/2009
pooka-3.0-080505 68,127 28 813 4,551 tool 5/5/2008
proguard-4.5.1 82,661 33 604 5,154 tool 7/8/2010
quartz-1.8.3 52,319 44 280 2,923 middleware 6/22/2010
quickserver-1.4.7 18,243 16 132 1,278 middleware 3/1/2006
quilt-0.6-a-5 8,425 14 66 641 testing 10/20/2003
roller-4.0.1 78,591 80 567 5,715 tool 1/13/2009
squirrel_sql-3.1.2 8,378 3 153 689 database 6/15/2010
sunflow-0.07.2 24,319 21 191 1,447 3D/graphics/media 2/8/2007
tomcat-7.0.2 283,829 106 1,538 15,627 middleware 8/11/2010
trove-2.1.0 8,432 3 91 585 SDK 8/14/2009
velocity-1.6.4 55,590 33 388 2,957 diagram generator/data visualization 5/10/2010
wct-1.5.2 69,698 85 606 5,527 tool 8/22/2011
webmail-0.7.10 14,175 16 118 1,092 tool 10/7/2002
weka-3.7.5 390,008 75 2,045 17,321 tool 10/28/2011
xalan-2.7.1 312,068 42 1,171 10,384 parsers/generators/make 11/27/2007
xerces-2.10.0 188,289 40 789 9,246 parsers/generators/make 6/18/2010
xmojo-5.0.0 31,037 9 110 1,199 middleware 7/17/2003
Appendices.

C2 Aggregated Metrics Distribution Statistics


Table 123 to Table 132 reports some statistics that describe the ag-
gregated distribution of the metrics we use for our code smells detection
approach (refers to Section 5.2.3). The metrics are subdivided in the metrics
that are part of the detection strategies (refers to Section 6.2.1), and the
metrics used on the views we offer for each code smell (refers to Section
6.2.5). The statistics we report are:

 Number of values: the number of values that are part of the distri-
bution;
 Min: the minimum value in the distribution;
 Max: the maximum value in the distribution;
 Q1: the first quartile or lower quartile or 25 th percentile. Splits off
the lowest 25% of samples from the highest 75%;
 Q2: the median or second quartile or 50 th percentile. Cuts samples
dataset in half;
 Q3: the third quartile or upper quartile or 75 th percentile. Splits off
the highest 25% of samples from the lowest 75%.

God Class
Detection Strategy Metrics

Table 123: God Class Detection Strategy Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


LOCNAMM 51,264 1 25,706 14 40 116
WMCNAMM 51,264 0 4,691 2 5 14
NOMNAMM 51,264 0 657 1 3 6
ATFD 51,264 0 799 0 0 3

Views Metrics

Table 124: God Class Views Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


NOPA 51,264 0 730 0 0 0
FANIN 41,738 0 1,012 0 1 2

282
Appendices.

Data Class
Detection Strategy Metrics

Table 125: Data Class Detection Strategy Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


WMCNAMM 48,706 0 4,691 2 5 14
NOAM 48,706 0 228 0 0 1
NOPA 48,706 0 730 0 0 0

Views Metrics

Table 126: Data Class Views Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


NOMNAMM 48,706 0 657 1 3 6
FANIN 39,180 0 1,012 0 1 2
FANOUT 48,706 0 756 1 2 5

Brain Method
Detection Strategy Metrics

Table 127: Brain Method Detection Strategy Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


LOC 374,638 1 2,256 3 5 12
CYCLO 374,638 1 1,245 1 1 2
MAXNESTING 374,638 0 22 1 1 2
NOLV 374,638 0 164 0 1 3
ATLD 374,638 0 274 0 1 1

Views Metrics

Table 128: Brain Method Views Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


NOP 374,638 0 67 0 1 1
CLNAMM 374,638 0 389 0 0 0
ATFD 374,638 0 202 0 0 0

283
Appendices.

Shotgun Surgery
Detection Strategy Metrics

Table 129: Shotgun Surgery Detection Strategy Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


CC 287,119 0 854 0 0 1
CM 287,119 0 1,877 0 0 1
FANOUT 321,813 0 753 0 0 1

Views Metrics

Table 130: Shotgun Surgery Views Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


CFNAMM 321,813 0 753 0 0 1

Dispersed Coupling
Detection Strategy Metrics

Table 131: Dispersed Coupling Detection Strategy Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


CINT 374,638 0 753 0 0 2

Message Chains
Detection Strategy Metrics

Table 132: Message Chains Detection Strategy Metrics Distribution

Metric Number of values Min Max Q1 Q2 Q3


MaMCL 374,638 0 7 0 0 0
MeMCL 374,638 0 5 0 0 0
NMCS 374,638 0 41 0 0 0

284
Appendices.

C3 Benchmark-Based Derived Thresholds


Table 133 to Table 160 reports the threshold of the metrics we use
for our code smells detection approach (refers to Section 5.2.3), for which
we derive thresholds using the Benchmark-Based Thresholds derivation
method discussed in Section 5.2.3. The metrics are subdivided in the metrics
that are part of the detection strategies (refers to Section 6.2.1) and the met-
rics used on the views we offer for each code smell (refers to Section 6.2.5).
We describe the structure we use to report the thresholds in Section 5.2.1.
We mark with * the thresholds that are recalibrated (refers to Section 5.2.3).

God Class
Detection Strategy Metrics

LOCNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 26 38 78 176 393

Type: Harden

ThPoint 10 30 60 80 90

ThValue 26 44 105 218 393

Type: Soften

ThPoint 10 20 40 70 90

ThValue 26 34 58 146 393

Table 133: God Class LOCNAMM Metric Thresholds

285
Appendices.

WMCNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 11 14 22 41 81

Type: Harden

ThPoint 10 30 60 80 90

ThValue 11 15 27 49 81

Type: Soften

ThPoint 10 20 40 70 90

ThValue 11 13 18 35 81

Table 134: God Class WMCNAMM Metric Thresholds

NOMNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 7 8 11 18 30

Type: Harden

ThPoint 10 30 60 80 90

ThValue 7 9 13 21 30

Type: Soften

ThPoint 10 20 40 70 90

286
Appendices.

ThValue 7 8 10 16 30

Table 135: God Class NOMNAMM Metric Thresholds

ATFD
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 3 4 6 11 21

Type: Harden

ThPoint 10 30 60 80 90

ThValue 3 4 7 13 21

Type: Soften *

ThPoint 10 22 40 70 90

ThValue 3 4 5 9 21

Table 136: God Class ATFD Metric Thresholds

Views Metrics

NOPA
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 36 54 75 90

ThValue 1 2 3 5 12

287
Appendices.

Type: Harden

ThPoint 10 41 64 80 90

ThValue 1 2 3 6 12

Type: Soften *

ThPoint 10 37 54 70 90

ThValue 1 2 3 4 12

Table 137: God Class NOPA Metric Thresholds

FANIN
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 4 5 7 14 29

Type: Harden *

ThPoint 10 30 60 80 90

ThValue 4 5 9 17 29

Type: Soften

ThPoint 10 21 40 70 90

ThValue 4 5 6 12 29

Table 138: God Class FANIN Metric Thresholds

288
Appendices.

Data Class
Detection Strategy Metrics

WMCNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 11 14 21 40 81

Type: Harden

ThPoint 10 20 40 70 90

ThValue 11 13 18 35 81

Type: Soften

ThPoint 10 30 60 80 90

ThValue 11 15 27 49 81

Table 139: Data Class WMCNAMM Metric Thresholds

NOAM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 32 50 75 90

ThValue 2 3 4 7 13

Type: Harden

ThPoint 10 37 60 80 90

289
Appendices.

ThValue 2 3 4 8 13

Type: Soften *

ThPoint 10 32 49 70 90

ThValue 2 3 4 6 13

Table 140: Data Class NOAM Metric Thresholds

NOPA
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 36 54 75 90

ThValue 1 2 3 5 12

Type: Harden

ThPoint 10 41 64 80 90

ThValue 1 2 3 6 12

Type: Soften *

ThPoint 10 36 54 70 90

ThValue 1 2 3 4 12

Table 141: Data Class NOPA Metric Thresholds

290
Appendices.

Views Metrics

NOMNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 7 8 11 18 29

Type: Harden

ThPoint 10 20 40 70 90

ThValue 7 8 10 16 29

Type: Soften

ThPoint 10 30 60 80 90

ThValue 7 9 13 20 29

Table 142: Data Class NOMNAMM Metric Thresholds

FANIN
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 26 50 75 90

ThValue 3 4 5 10 22

Type: Harden

ThPoint 10 31 60 80 90

291
Appendices.

ThValue 3 4 7 12 22

Type: Soften *

ThPoint 10 26 42 70 90

ThValue 3 4 5 9 22

Table 143: Data Class FANIN Metric Thresholds

FANOUT
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 6 7 9 13 20

Type: Harden

ThPoint 10 20 40 70 90

ThValue 6 7 8 12 20

Type: Soften

ThPoint 10 30 60 80 90

ThValue 6 7 10 14 20

Table 144: Data Class FANOUT Metric Thresholds

292
Appendices.

Brain Method
Detection Strategy Metrics

LOC
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default

ThPoint 10 25 50 75 90

ThValue 11 13 19 33 59

Type: Harden

ThPoint 10 30 60 80 90

ThValue 11 14 23 38 59

Type: Soften

ThPoint 10 20 40 70 90

ThValue 11 12 16 29 59

Table 145: Brain Method LOC Metric Thresholds

CYCLO
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 33 51 75 90

ThValue 3 4 5 7 13

Type: Harden

ThPoint 10 38 61 80 90

293
Appendices.

ThValue 3 4 5 8 13

Type: Soften *

ThPoint 10 33 51 70 90

ThValue 3 4 5 6 13

Table 146: Brain Method CYCLO Metric Thresholds

MAXNESTING
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 59 84 93 98

ThValue 3 4 5 6 7

Type: Harden

ThPoint 10 64 85 94 98

ThValue 3 4 5 6 7

Type: Soften *

ThPoint 10 59 84 93 98

ThValue 3 4 5 6 7

Table 147: Brain Method MAXNESTING Metric Thresholds

294
Appendices.

NOLV
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 30 50 75 90

ThValue 4 5 6 8 12

Type: Harden

ThPoint 10 35 60 80 90

ThValue 4 5 6 9 12

Type: Soften *

ThPoint 10 30 50 70 90

ThValue 4 5 6 7 12

Table 148: Brain Method NOLV Metric Thresholds

ATLD
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 37 58 75 90

ThValue 3 4 5 6 11

Type: Harden

ThPoint 10 42 68 80 90

ThValue 3 4 5 7 11

Type: Soften *

ThPoint 10 37 58 70 90

295
Appendices.

ThValue 3 4 5 6 11

Table 149: Brain Method ATLD Metric Thresholds

Views Metrics

NOP
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 54 77 90 95

ThValue 3 4 5 6 7

Type: Harden

ThPoint 10 59 87 95 97

ThValue 3 4 5 7 8

Type: Soften *

ThPoint 10 54 77 90 95

ThValue 3 4 5 6 7

Table 150: Brain Method NOP Metric Thresholds

CLNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 60 80 88 93

ThValue 2 3 4 5 6

296
Appendices.

Type: Harden *

ThPoint 10 60 80 88 93

ThValue 2 3 4 5 6

Type: Soften

ThPoint 10 65 90 93 96

ThValue 2 3 5 6 7

Table 151: Brain Method CLNAMM Metric Thresholds

ATFD
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 48 68 79 90

ThValue 1 2 3 4 6

Type: Harden

ThPoint 10 53 78 84 90

ThValue 1 2 3 4 6

Type: Soften *

ThPoint 10 48 68 79 90

ThValue 1 2 3 4 6

Table 152: Brain Method ATFD Metric Thresholds

297
Appendices.

Shotgun Surgery
Detection Strategy Metrics

CC
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 45 64 75 90

ThValue 2 3 4 5 10

Type: Harden

ThPoint 10 50 74 80 90

ThValue 2 3 5 6 10

Type: Soften *

ThPoint 10 45 64 74 90

ThValue 2 3 4 5 10

Table 153: Shotgun Surgery CC Metric Thresholds

CM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 39 57 75 90

ThValue 2 3 4 6 13

Type: Harden

ThPoint 10 44 67 80 90

298
Appendices.

ThValue 2 3 5 7 13

Type: Soften *

ThPoint 10 39 57 70 90

ThValue 2 3 4 5 13

Table 154: Shotgun Surgery CM Metric Thresholds

FANOUT
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 46 68 80 90

ThValue 2 3 4 5 6

Type: Harden

ThPoint 10 51 78 85 90

ThValue 2 3 4 5 6

Type: Soften *

ThPoint 10 46 68 80 90

ThValue 2 3 4 5 6

Table 155: Shotgun Surgery FANOUT Metric Thresholds

299
Appendices.

Views Metrics

CFNAMM
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 37 57 75 90

ThValue 2 3 4 5 9

Type: Harden

ThPoint 10 42 67 80 90

ThValue 2 3 4 6 9

Type: Soften *

ThPoint 10 37 57 70 90

ThValue 2 3 4 5 9

Table 156: Shotgun Surgery CFNAMM Metric Thresholds

Dispersed Coupling
Detection Strategy Metrics

CINT
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 30 50 75 90

ThValue 3 4 5 8 12

Type: Harden

ThPoint 10 35 60 80 90

300
Appendices.

ThValue 3 4 6 9 12

Type: Soften *

ThPoint 10 30 48 70 90

ThValue 3 4 5 7 12

Table 157: Dispersed Coupling CINT Metric Thresholds

Message Chains
Detection Strategy Metrics

MaMCL
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 92 98 99 100

ThValue 2 3 3 4 7

Type: Harden *

ThPoint 10 97 98 99 100

ThValue 2 3 3 4 7

Type: Soften *

ThPoint 10 92 98 99 100

ThValue 2 3 3 4 7

Table 158: Message Chains MaMCL Metric Thresholds

301
Appendices.

MeMCL
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 93 98 99 100

ThValue 2 2 3 4 5

Type: Harden *

ThPoint 10 93 98 99 100

ThValue 2 2 3 4 5

Type: Soften *

ThPoint 10 88 95 99 100

ThValue 2 2 3 4 5

Table 159: Message Chains MeMCL Metric Thresholds

NMCS
VERY- VERY-
LOW MEAN HIGH
LOW HIGH

Type: Default *

ThPoint 10 74 90 94 97

ThValue 1 2 3 4 5

Type: Harden *

ThPoint 10 79 93 96 97

ThValue 1 2 3 4 5

Type: Soften *

302
Appendices.

ThPoint 10 74 90 94 97

ThValue 1 2 3 4 5

Table 160: Message Chains NMCS Metric Thresholds

D1 Fowler’s Code Smells Definition


We report all the 22 code smells defined by Fowler in [51] to have a
quick reference. Table 161 presents the list of code smells along with a short
description that summarize the Fowler definitions.

Table 161: Description of the 22 Fowler Code Smells

Code Smell Description


Two classes appear different on the
Alternative classes with different
outside, but are similar on the in-
interfaces
side
Comments should describe why the
Comments
code is there not what it does
Classes should not contain just
Data class data, they should contain methods
as well
Data that belong together should
Data clumps be amalgamated rather than remain
separated
Changes to code should be kept lo-
Divergent change cal; too many diverse changes in-
dicate poor structure
Eradicate duplicated code when-
Duplicated code
ever possible
Class features that use other class
Feature Envy features should be moved those
other classes
Classes should not associate with
Inappropriate intimacy
other classes excessively

303
Appendices.

Avoid adding a method you need


Incomplete library class (and which does not exist in a li-
brary class) to a random class
Large class A class has too many methods
A class is doing too little to justify
Lazy class
its existence
A method is too large; it should be
Long method
decomposed
Long parameter list A method has too many parameters
Message chains Avoid long chains of message calls
If a class is delegating too much
Middle man
responsibility, should it exist?
When you make a subclass of one
Parallel inheritance hierarchies class, you need to make a subclass
of another
Overuse of primitive types in a
Primitive obsession
class
If inherited behaviour is not being
Refused bequest
used, is inheritance necessary?
Avoid cascading changes; limit the
Shotgun surgery number of classes that need to be
changed
Code should not be added for “just
Speculative generality in case” scenarios, it should solve
current problems
Polymorphism should be used in-
Switch statements
stead of large switch statements
Classes should not contain unnec-
Temporary field
essary fields

304
Appendices.

D2 Code Smells Impact on Software Quality


Table 162 shows all the references and the information we use to
evaluate code smells impact of software, particularly to presence of fault
and change-proneness. We use code smells impact as first parameter to se-
lect six code smells from the list of 22 presented by Fowler in [51], as de-
scribed in Section 6.1 . We start our investigation from a survey published
by Zhang [136] in 2011. This survey explores most of the literature related
to code smells. We also take into account the known literature from our
previous study related to code smells [7] and the top ten pages of results
sorted by relevance, returned by the following search query by Google
Scholar [141] at the date of 2013-03-07:

(“code smell” OR “bad smell”) AND (impact OR prediction OR prone OR


maintainability OR evolution OR severity OR fault OR defect OR harm-
ful)

From the identified empirical studies, it is possible to observe that that the
code smells are not equally harmful. In addition, they are not consistently
harmful across studies. The most harmful code smells are:

1. God Class;
2. Brain Method;
3. Shotgun Surgery;
4. Message Chains;
5. Dispersed Coupling;
6. Intensive Coupling;
7. Feature Envy

We are not able to find any study that investigates the impact on system
quality for the following four code smells:

1. Speculative Generality;
2. Tradition Breaker;
3. Divergent Change;
4. Long Parameter List.

305
Table 162: Code Smells Impact on Software Quality

Code Smell Impacts on Other Relevant Tool/Case Study References


Properties
God Class or Large Statistically associated with - One open source [78] in
Class software faults system [136]
- One open source [117] in
system [136]
Statistically associated with - Azureus, Eclipse [66]
change-prone More Two commercial [134]
change/defect application
prone if LOC
normalized
- Lucene, Xerces [107]
Statistically associated with change- However, when Three open source [108]
prone and defect we normalized systems
the measured ef-
fects with respect
306
to size, then God
Classes were less
subject to change
and had fewer de-
fects than other
classes.
More related to architectural degeneration - ? [16]
Brain Method or Statistically associated with - One open source [78] in
Long Method software faults system [136]
- One open source [117] in
system [136]
- Rhino [38]
Statistically associated with - ArgoUML, [67]
software faults Eclipse, Mylyn,
Rhino
307
Design flaws correlate with post release soft- - More version [30]
ware defects, but not strongly in all the ana- of: Lucene,
lysed systems. There is no design flaw that Maven, Mina,
consistently correlates more than others do in Eclipse PDE UI,
all the systems. In some systems, there is no Equinox, Eclipse
design flaw that strongly correlates with de- CDT
fects.
The presence of the problem implies - JFlex, [21]
that it might be difficult in terms of JFreeChart
effort and time to perform maintenance tasks
on this method
More related to architectural degeneration - ? [16]
Shotgun Surgery Statistically associated with software faults - One open source [78] in
system [136]
- One open source [117] in
system [136]
- Rhino [38]
Statistically associated with change- - Lucene, Xerces [107]
prone
Design flaws correlate with post release soft- - More version of: [30]
ware defects, but not strongly in all the ana- Lucene, Maven,
lysed systems. There is no design flaw that Mina, Eclipse
consistently correlates more than others do in PDE UI, Equinox
all the systems. In some systems, there is no Eclipse CDT
design flaw that strongly correlates with de-
fects.
More related to architectural degeneration - ? [16]
Message Chains Statistically associated with change- - Azureus, Eclipse [66]
prone (Eclipse)
Statistically associated with change- - ArgoUML, [67]
prone and faults Eclipse, Mylyn,
Rhino
Statistically associated with faults - Eclipse, Apache [135]
Data Class No significant relationship with software - One open source [78] in
fault system [136]
309
- One open source [117] in
system [136]
Refused Bequest No significant relationship with software - One open source [78] in
fault system [136]
- One open source [117] in
system [136]
Feature Envy No significant relationship with software - One open source [78] in
fault system [136]
- One open source [117] in
system [136]
Design flaws correlate with post release soft- - More version [30]
ware defects, but not strongly in all the ana- of: Lucene,
lysed systems. There is no design flaw that Maven, Mina,
consistently correlates more than others do in Eclipse PDE UI,
all the systems. In some systems, there is no Equinox, Eclipse
design flaw that strongly correlates with de- CDT
fects.
Intensive Coupling Design flaws correlate with post release soft- - More version [30]
ware defects, but not strongly in all the ana- of: Lucene,
lysed systems. There is no design flaw that Maven, Mina,
consistently correlates more than others do in Eclipse PDE UI,
all the systems. In some systems, there is no Equinox, Eclipse
design flaw that strongly correlates with de- CDT
fects.
Dispersed Coupling Design flaws correlate with post release soft- - More version [30]
ware defects, but not strongly in all the ana- of: Lucene,
lysed systems. There is no design flaw that Maven, Mina,
consistently correlates more than others do in Eclipse PDE UI,
all the systems. In some systems, there is no Equinox, Eclipse
design flaw that strongly correlates with de- CDT
fects.
311
Appendices.

D3 Code Smells Numerosity


Table 163 shows all the references and the information we use to
evaluate code smells numerosity. The most numerous code smells are:

1. Data Class;
2. God Class;
3. Shotgun Surgery;
4. Feature Envy;
5. Brain Method;
6. Refused Parent Bequest;
7. Dispersed Coupling;
8. Intensive Coupling;
9. Tradition Breaker;
10. Speculative Generality.

312
Table 163: Code Smells Numerosity

Considered Code Smell Most Numerous Code Smell Case Study References

Brain Method, Feature Envy, 1. Feature Envy More version of: Lucene, Maven, [30]
Intensive Coupling, 2. Shotgun Surgery Mina, Eclipse PDE UI, Equinox,
Dispersed Coupling, Shotgun 3. Dispersed Coupling and Brain Eclipse CDT
Surgery Methods vary
4. Intensive Coupling is relatively
low for all systems
Data Class, God Class or 1. Data Class 68 Open Source Systems [46]
Large Class or Brain Class, 2. God Class or Large Class or Brain
Shotgun Surgery, Brain Class
Method or Long 3. Shotgun Surgery
Method, Feature Envy, Inten- 4. Brain Method or Long Method
sive 5. Feature Envy
Coupling, Refused Parent Be- 6. Intensive Coupling
quest, Extensive Coupling or 7. Refused Parent Bequest
313
Dispersed Coupling, Tradi- 8. Extensive Coupling or Dispersed
tion Breaker, Coupling
Speculative Generality 9. Tradition Breaker
10. Speculative Generality
Appendices.

D4 Code Smells Impact on Quality Dimensions


Table 164 shows the impact of code smells on object-oriented soft-
ware quality dimension we discuss in Chapter 4. To evaluate the impact we
refer to a work published by R. Marinescu in [90], extended by us for the
relevant code smells he does not considered.

Table 164: Code Smells Impact on Quality Dimensions

Impacts on
Code Smell Encap- Data Ab-
Coupling Cohesion Complexity Size
sulation straction

God Class or
X X X X
Large Class

Data Class X X
Brain Method or
X X X X
Long Method

Shotgun Surgery X
Dispersed Cou-
X X X
pling

Message Chains X

E1 Code Smell Detection Results on Qualitas Corpus


Table 165 to Table 170 report all the information regarding the de-
tection results for each code smell and systems. The information we report
are:
 Number and percentage of affected entity;
 Number and percentage of strong filtered code smells. The
percentage is respect to the initial number of code smells,
before applying strong filters;
 Number and percentage of weak filtered code smells;
 Distribution of the detected code smells among harmfulness
levels;
 Percentage of code smells that has at least one related code
smell.
315
Table 165: God Class Detection Results on the Qualitas Corpus

Code Smell: God Class


Affected Classes Strong Filtered Weak Filtered
At Least
Harm Problem Trouble Warning Bother
System # % # % # % One Re-
(%) (%) (%) (%) (%) lated (%)
aoi-2.8.1 20 2.41% 0 0.00% 0 0.00% 3 12 4 1 0 100.00%
argouml-0.34 29 1.14% 0 0.00% 3 10.34% 2 18 7 1 1 93.10%
axion-1.0-M2 3 1.15% 0 0.00% 0 0.00% 0 3 0 0 0 100.00%
castor-1.3.1 22 1.32% 0 0.00% 2 9.09% 3 10 7 2 0 95.45%
cobertura-1.9.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
colt-1.2.0 7 1.18% 0 0.00% 0 0.00% 0 5 2 0 0 71.43%
columba-1.0 6 0.46% 0 0.00% 0 0.00% 0 2 3 1 0 100.00%
displaytag-1.2 2 1.39% 0 0.00% 0 0.00% 0 1 1 0 0 50.00%
drawswf-1.2.9 4 1.24% 0 0.00% 0 0.00% 1 3 0 0 0 75.00%
drJava-stable-
17 0.72% 1 5.56% 0 0.00% 2 12 2 1 0 94.12%
20100913-r5387
emma-2.0.5312 2 0.63% 0 0.00% 0 0.00% 0 1 1 0 0 100.00%
exoportal-v1.0.2 3 0.15% 0 0.00% 0 0.00% 0 1 1 1 0 66.67%
findbugs-1.3.9 13 0.74% 0 0.00% 0 0.00% 2 7 3 1 0 100.00%
fitJava-1.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
fitlibraryforfit-
1 0.11% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
nesse-20100806
freecol-0.10.3 25 1.96% 2 7.41% 0 0.00% 6 14 3 2 0 96.00%
freecs-
7 4.76% 0 0.00% 0 0.00% 3 3 1 0 0 100.00%
1.3.20100406
freemind-0.9.0 10 1.08% 0 0.00% 0 0.00% 2 8 0 0 0 100.00%
galleon-2.3.0 2 0.25% 0 0.00% 1 50.00% 0 2 0 0 0 100.00%
ganttproject-
15 1.40% 1 6.25% 0 0.00% 3 8 4 0 0 93.33%
2.0.9
heritrix-1.14.4 15 2.15% 1 6.25% 1 6.67% 5 8 1 1 0 93.33%
hsqldb-2.0.0 45 8.67% 0 0.00% 3 6.67% 17 19 7 2 0 84.44%
itext-5.0.3 24 4.49% 0 0.00% 0 0.00% 4 14 6 0 0 87.50%
jag-6.1 2 0.76% 0 0.00% 0 0.00% 1 1 0 0 0 100.00%
jasml-0.10 1 2.04% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
jasperreports-
52 2.79% 0 0.00% 2 3.85% 17 21 10 4 0 88.46%
3.7.3
Javacc-5.0 3 2.88% 0 0.00% 1 33.33% 0 1 2 0 0 100.00%
jedit-4.3.2 16 1.46% 0 0.00% 1 6.25% 2 11 3 0 0 93.75%
jena-2.6.3 16 1.15% 0 0.00% 1 6.25% 0 11 5 0 0 75.00%
jext-5.0 3 0.60% 0 0.00% 0 0.00% 1 2 0 0 0 100.00%
jFin_DateMath-
1 1.67% 0 0.00% 0 0.00% 0 0 1 0 0 100.00%
R1.0.1
jfreechart-1.0.13 19 1.79% 6 24.00% 0 0.00% 2 13 4 0 0 73.68%
jgraph-5.13.0.0 10 2.37% 0 0.00% 0 0.00% 1 5 4 0 0 90.00%
jgraphpad-
2 0.45% 0 0.00% 0 0.00% 1 1 0 0 0 100.00%
5.10.0.2
jgrapht-0.8.1 5 1.51% 0 0.00% 0 0.00% 0 2 3 0 0 100.00%
jgroups-2.10.0 31 2.64% 0 0.00% 2 6.45% 6 13 11 1 0 61.29%
jhotdraw-7.5.1 13 1.27% 0 0.00% 0 0.00% 2 7 4 0 0 84.62%
jmeter-2.5.1 21 2.13% 1 4.55% 1 4.76% 2 10 5 3 1 71.43%
jmoney-0.4.4 1 0.52% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
jparse-0.96 1 1.45% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
jpf-1.0.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
jruby-1.5.2 43 2.01% 0 0.00% 5 11.63% 14 21 7 1 0 88.37%
jspwiki-2.8.4 4 0.91% 0 0.00% 0 0.00% 1 1 1 1 0 100.00%
jsXe-04_beta 1 0.95% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
jung-2.0.1 6 0.71% 0 0.00% 0 0.00% 0 4 2 0 0 100.00%
junit-4.10 0 0.00% 1 100.00% 0 - 0 0 0 0 0 -
log4j-1.2.16 2 0.63% 0 0.00% 0 0.00% 0 1 1 0 0 50.00%
lucene-3.5.0 15 0.74% 0 0.00% 3 20.00% 0 12 3 0 0 93.33%
marauroa-3.8.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
megamek-
42 1.94% 0 0.00% 1 2.38% 23 13 6 0 0 95.24%
0.35.18
mvnforum-1.2.2-
12 2.80% 0 0.00% 0 0.00% 3 7 2 0 0 33.33%
ga
nekohtml-1.9.14 1 1.64% 0 0.00% 0 0.00% 0 0 1 0 0 100.00%
openjms-0.7.7-
0 0.00% 0 - 0 - 0 0 0 0 0 -
beta-1
oscache-2.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
picocontainer-
1 0.42% 0 0.00% 0 0.00% 0 0 1 0 0 100.00%
2.10.2
pmd-4.2.5 0 0.00% 4 100.00% 0 - 0 0 0 0 0 -
poi-3.6 12 0.49% 10 45.45% 2 16.67% 1 6 5 0 0 91.67%
pooka-3.0-
16 1.88% 0 0.00% 0 0.00% 0 8 7 1 0 87.50%
080505
proguard-4.5.1 10 1.55% 0 0.00% 6 60.00% 1 9 0 0 0 40.00%
quartz-1.8.3 2 0.63% 0 0.00% 0 0.00% 1 1 0 0 0 50.00%
quickserver-1.4.7 3 1.94% 0 0.00% 0 0.00% 1 2 0 0 0 100.00%
quilt-0.6-a-5 0 0.00% 0 - 0 - 0 0 0 0 0 -
roller-4.0.1 4 0.62% 0 0.00% 0 0.00% 0 3 1 0 0 100.00%
squirrel_sql-3.1.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
sunflow-0.07.2 2 0.95% 0 0.00% 0 0.00% 0 1 1 0 0 100.00%
tomcat-7.0.2 31 1.80% 0 0.00% 1 3.23% 4 18 5 4 0 80.65%
trove-2.1.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
velocity-1.6.4 0 0.00% 0 - 0 - 0 0 0 0 0 -
wct-1.5.2 2 0.30% 0 0.00% 2 100.00% 0 2 0 0 0 100.00%
webmail-0.7.10 1 0.78% 0 0.00% 0 0.00% 0 0 1 0 0 100.00%
weka-3.7.5 72 3.28% 1 1.37% 1 1.39% 4 41 27 0 0 63.89%
xalan-2.7.1 30 2.43% 0 0.00% 6 20.00% 8 19 3 0 0 93.33%
xerces-2.10.0 27 2.86% 0 0.00% 3 11.11% 6 16 5 0 0 81.48%
xmojo-5.0.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
Table 166: Data Class Detection Results on the Qualitas Corpus

Code Smell: Data Class


Affected Classes Strong Filtered Weak Filtered
At Least
Harm Problem Trouble Warning Bother
System # % # % # % One Re-
(%) (%) (%) (%) (%) lated (%)
aoi-2.8.1 28 3.37% 0 0.00% 0 0.00% 5 21 2 0 0 28.57%
argouml-0.34 54 2.12% 0 0.00% 0 0.00% 12 37 5 0 0 18.52%
axion-1.0-M2 3 1.15% 0 0.00% 0 0.00% 0 2 0 1 0 66.67%
castor-1.3.1 89 5.32% 2 2.20% 1 1.12% 16 67 5 1 0 16.85%
cobertura-1.9.4.1 4 3.42% 0 0.00% 0 0.00% 0 2 1 1 0 0.00%
colt-1.2.0 3 0.51% 0 0.00% 0 0.00% 2 1 0 0 0 33.33%
columba-1.0 24 1.84% 0 0.00% 0 0.00% 5 16 3 0 0 12.50%
displaytag-1.2 5 3.47% 0 0.00% 0 0.00% 2 3 0 0 0 0.00%
drawswf-1.2.9 20 6.21% 1 4.76% 0 0.00% 0 16 2 2 0 15.00%
drJava-stable- 11 0.47% 1 8.33% 0 0.00% 0 8 1 2 0 0.00%
20100913-r5387
emma-2.0.5312 7 2.19% 0 0.00% 0 0.00% 2 3 2 0 0 0.00%
exoportal-v1.0.2 161 7.79% 4 2.42% 5 3.11% 27 115 16 3 0 12.42%
findbugs-1.3.9 20 1.14% 0 0.00% 0 0.00% 2 17 1 0 0 5.00%
fitJava-1.1 2 3.33% 0 0.00% 0 0.00% 0 2 0 0 0 0.00%
fitlibraryforfit- 25 2.83% 0 0.00% 0 0.00% 2 21 2 0 0 4.00%
nesse-20100806
freecol-0.10.3 13 1.02% 0 0.00% 0 0.00% 3 6 3 1 0 46.15%
freecs- 5 3.40% 0 0.00% 0 0.00% 0 3 2 0 0 60.00%
1.3.20100406
freemind-0.9.0 7 0.76% 0 0.00% 0 0.00% 0 4 3 0 0 28.57%
galleon-2.3.0 23 2.90% 15 39.47% 0 0.00% 0 15 7 1 0 4.35%
ganttproject- 31 2.89% 0 0.00% 0 0.00% 4 22 4 1 0 38.71%
2.0.9
heritrix-1.14.4 5 0.72% 1 16.67% 0 0.00% 1 3 1 0 0 0.00%
hsqldb-2.0.0 6 1.16% 0 0.00% 0 0.00% 1 4 1 0 0 50.00%
itext-5.0.3 36 6.73% 1 2.70% 0 0.00% 9 21 4 2 0 27.78%
jag-6.1 8 3.05% 0 0.00% 1 12.50% 1 7 0 0 0 12.50%
jasml-0.10 10 20.41% 0 0.00% 0 0.00% 3 6 1 0 0 10.00%
jasperreports- 87 4.67% 30 25.64% 0 0.00% 17 58 11 1 0 37.93%
3.7.3
Javacc-5.0 11 10.58% 0 0.00% 0 0.00% 1 10 0 0 0 9.09%
jedit-4.3.2 15 1.36% 2 11.76% 0 0.00% 2 9 3 1 0 33.33%
jena-2.6.3 32 2.31% 0 0.00% 0 0.00% 23 8 1 0 0 9.38%
jext-5.0 8 1.59% 0 0.00% 0 0.00% 3 5 0 0 0 25.00%
jFin_DateMath- 2 3.33% 0 0.00% 0 0.00% 1 0 1 0 0 50.00%
R1.0.1
jfreechart-1.0.13 1 0.09% 1 50.00% 0 0.00% 1 0 0 0 0 0.00%
jgraph-5.13.0.0 10 2.37% 0 0.00% 0 0.00% 1 7 1 1 0 20.00%
jgraphpad- 6 1.36% 0 0.00% 0 0.00% 0 3 1 2 0 0.00%
5.10.0.2
jgrapht-0.8.1 5 1.51% 0 0.00% 0 0.00% 1 4 0 0 0 0.00%
jgroups-2.10.0 8 0.68% 1 11.11% 0 0.00% 2 6 0 0 0 0.00%
jhotdraw-7.5.1 10 0.98% 0 0.00% 0 0.00% 1 8 1 0 0 20.00%
jmeter-2.5.1 10 1.01% 1 9.09% 0 0.00% 3 4 2 1 0 20.00%
jmoney-0.4.4 4 2.07% 1 20.00% 0 0.00% 0 2 1 1 0 50.00%
jparse-0.96 0 0.00% 0 - 0 - 0 0 0 0 0 -
jpf-1.0.2 14 9.21% 0 0.00% 0 0.00% 2 10 2 0 0 0.00%
jruby-1.5.2 22 1.03% 0 0.00% 0 0.00% 2 18 2 0 0 9.09%
jspwiki-2.8.4 18 4.08% 1 5.26% 0 0.00% 4 10 2 2 0 5.56%
jsXe-04_beta 4 3.81% 0 0.00% 0 0.00% 0 0 4 0 0 0.00%
jung-2.0.1 12 1.41% 0 0.00% 0 0.00% 2 9 1 0 0 16.67%
junit-4.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
log4j-1.2.16 3 0.95% 0 0.00% 0 0.00% 0 3 0 0 0 0.00%
lucene-3.5.0 44 2.17% 3 6.38% 0 0.00% 7 34 3 0 0 4.55%
marauroa-3.8.1 4 1.80% 0 0.00% 0 0.00% 1 3 0 0 0 0.00%
megamek- 33 1.53% 7 17.50% 0 0.00% 6 27 0 0 0 18.18%
0.35.18
mvnforum-1.2.2- 34 7.94% 0 0.00% 0 0.00% 16 15 2 1 0 8.82%
ga
nekohtml-1.9.14 3 4.92% 0 0.00% 0 0.00% 1 1 1 0 0 66.67%
openjms-0.7.7- 5 0.84% 0 0.00% 0 0.00% 0 4 1 0 0 0.00%
beta-1
oscache-2.4.1 3 3.95% 1 25.00% 0 0.00% 0 3 0 0 0 0.00%
picocontainer- 1 0.42% 0 0.00% 0 0.00% 1 0 0 0 0 0.00%
2.10.2
pmd-4.2.5 10 1.09% 2 16.67% 0 0.00% 0 7 2 1 0 0.00%
poi-3.6 169 6.87% 0 0.00% 0 0.00% 18 124 23 4 0 11.24%
pooka-3.0- 5 0.59% 1 16.67% 0 0.00% 1 3 1 0 0 40.00%
080505
proguard-4.5.1 9 1.40% 0 0.00% 0 0.00% 5 1 2 1 0 33.33%
quartz-1.8.3 7 2.22% 4 36.36% 0 0.00% 3 2 2 0 0 14.29%
quickserver-1.4.7 6 3.87% 10 62.50% 1 16.67% 1 5 0 0 0 33.33%
quilt-0.6-a-5 3 4.05% 0 0.00% 0 0.00% 0 3 0 0 0 0.00%
roller-4.0.1 33 5.14% 7 17.50% 3 9.09% 10 20 3 0 0 3.03%
squirrel_sql-3.1.2 8 4.73% 0 0.00% 0 0.00% 2 6 0 0 0 0.00%
sunflow-0.07.2 1 0.48% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
tomcat-7.0.2 58 3.37% 3 4.92% 2 3.45% 15 34 7 1 1 17.24%
trove-2.1.0 1 1.00% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
velocity-1.6.4 5 1.15% 1 16.67% 0 0.00% 0 4 0 1 0 0.00%
wct-1.5.2 129 19.23% 4 3.01% 5 3.88% 36 83 8 2 0 20.93%
webmail-0.7.10 0 0.00% 1 100.00% 0 - 0 0 0 0 0 -
weka-3.7.5 19 0.87% 5 20.83% 0 0.00% 1 17 1 0 0 31.58%
xalan-2.7.1 86 6.95% 2 2.27% 0 0.00% 65 16 4 1 0 9.30%
xerces-2.10.0 42 4.45% 4 8.70% 0 0.00% 8 28 4 2 0 35.71%
xmojo-5.0.0 5 3.70% 1 16.67% 0 0.00% 1 4 0 0 0 0.00%
Table 167: Brain Method Detection Results on the Qualitas Corpus

Code Smell: Brain Method


Affected Methods Strong Filtered Weak Filtered
At Least
Harm Problem Trouble Warning Bother
System # % # % # % One Re-
(%) (%) (%) (%) (%) lated (%)
aoi-2.8.1 47 0.68% 0 0.00% 0 0.00% 5 35 7 0 0 25.53%
argouml-0.34 128 0.71% 0 0.00% 0 0.00% 12 71 36 9 0 18.75%
axion-1.0-M2 8 0.27% 0 0.00% 0 0.00% 0 5 2 1 0 50.00%
castor-1.3.1 88 0.74% 0 0.00% 0 0.00% 12 59 17 0 0 51.14%
cobertura-1.9.4.1 11 0.33% 0 0.00% 0 0.00% 0 10 0 1 0 0.00%
colt-1.2.0 11 0.27% 0 0.00% 0 0.00% 0 11 0 0 0 18.18%
columba-1.0 9 0.13% 0 0.00% 0 0.00% 0 8 0 1 0 22.22%
displaytag-1.2 3 0.28% 0 0.00% 0 0.00% 0 1 1 1 0 0.00%
drawswf-1.2.9 5 0.18% 0 0.00% 0 0.00% 0 5 0 0 0 40.00%
drJava-stable-
68 0.66% 0 0.00% 0 0.00% 8 36 18 6 0 36.76%
20100913-r5387
emma-2.0.5312 30 1.66% 0 0.00% 0 0.00% 8 18 3 1 0 26.67%
exoportal-v1.0.2 16 0.14% 0 0.00% 0 0.00% 0 10 4 2 0 18.75%
findbugs-1.3.9 69 0.68% 0 0.00% 0 0.00% 4 54 8 3 0 24.64%
fitJava-1.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
fitlibraryforfit-
8 0.19% 0 0.00% 0 0.00% 1 7 0 0 0 0.00%
nesse-20100806
freecol-0.10.3 88 1.06% 0 0.00% 0 0.00% 5 63 16 4 0 46.59%
freecs-
22 1.57% 0 0.00% 0 0.00% 4 15 3 0 0 18.18%
1.3.20100406
freemind-0.9.0 16 0.28% 0 0.00% 0 0.00% 0 8 8 0 0 25.00%
galleon-2.3.0 114 2.65% 0 0.00% 0 0.00% 25 53 32 4 0 15.79%
ganttproject-
12 0.22% 0 0.00% 0 0.00% 1 6 4 1 0 25.00%
2.0.9
heritrix-1.14.4 24 0.45% 0 0.00% 0 0.00% 0 15 7 2 0 37.50%
hsqldb-2.0.0 62 0.81% 0 0.00% 0 0.00% 2 49 11 0 0 64.52%
itext-5.0.3 62 1.07% 0 0.00% 0 0.00% 9 44 8 1 0 35.48%
jag-6.1 22 1.52% 0 0.00% 0 0.00% 4 10 7 1 0 18.18%
jasml-0.10 4 1.63% 0 0.00% 0 0.00% 1 3 0 0 0 0.00%
jasperreports-
99 0.58% 0 0.00% 0 0.00% 2 78 16 3 0 27.27%
3.7.3
Javacc-5.0 22 2.72% 0 0.00% 0 0.00% 2 10 5 5 0 13.64%
jedit-4.3.2 29 0.44% 0 0.00% 0 0.00% 1 21 5 2 0 20.69%
jena-2.6.3 16 0.16% 0 0.00% 0 0.00% 0 12 3 1 0 18.75%
jext-5.0 15 0.69% 0 0.00% 0 0.00% 0 12 3 0 0 20.00%
jFin_DateMath-
0 0.00% 0 - 0 - 0 0 0 0 0 -
R1.0.1
jfreechart-1.0.13 26 0.22% 0 0.00% 0 0.00% 0 22 2 2 0 30.77%
jgraph-5.13.0.0 45 1.50% 0 0.00% 0 0.00% 5 24 14 2 0 22.22%
jgraphpad-
18 0.96% 0 0.00% 0 0.00% 0 12 6 0 0 11.11%
5.10.0.2
jgrapht-0.8.1 7 0.47% 0 0.00% 0 0.00% 0 3 1 3 0 14.29%
jgroups-2.10.0 49 0.56% 0 0.00% 0 0.00% 4 21 19 5 0 30.61%
jhotdraw-7.5.1 33 0.46% 0 0.00% 0 0.00% 2 17 12 2 0 39.39%
jmeter-2.5.1 41 0.51% 0 0.00% 0 0.00% 1 18 20 2 0 34.15%
jmoney-0.4.4 1 0.14% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
jparse-0.96 30 3.85% 0 0.00% 0 0.00% 3 16 10 1 0 6.67%
jpf-1.0.2 6 0.47% 0 0.00% 0 0.00% 0 4 2 0 0 33.33%
jruby-1.5.2 62 0.35% 0 0.00% 0 0.00% 2 34 22 4 0 33.87%
jspwiki-2.8.4 27 0.99% 0 0.00% 0 0.00% 1 15 10 1 0 7.41%
jsXe-04_beta 14 1.99% 0 0.00% 0 0.00% 2 5 6 1 0 28.57%
jung-2.0.1 18 0.46% 0 0.00% 0 0.00% 0 9 8 1 0 11.11%
junit-4.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
log4j-1.2.16 11 0.52% 0 0.00% 0 0.00% 1 5 5 0 0 0.00%
lucene-3.5.0 130 1.04% 0 0.00% 0 0.00% 6 84 33 7 0 6.92%
marauroa-3.8.1 5 0.31% 0 0.00% 0 0.00% 0 3 1 1 0 0.00%
megamek-
144 1.05% 0 0.00% 0 0.00% 18 97 26 3 0 38.19%
0.35.18
mvnforum-1.2.2-
11 0.18% 0 0.00% 0 0.00% 1 10 0 0 0 9.09%
ga
nekohtml-1.9.14 8 1.59% 0 0.00% 0 0.00% 0 7 1 0 0 50.00%
openjms-0.7.7-
9 0.24% 0 0.00% 0 0.00% 0 2 6 1 0 0.00%
beta-1
oscache-2.4.1 9 1.43% 0 0.00% 0 0.00% 0 8 1 0 0 0.00%
picocontainer-
0 0.00% 0 - 0 - 0 0 0 0 0 -
2.10.2
pmd-4.2.5 25 0.42% 0 0.00% 0 0.00% 4 13 6 2 0 0.00%
poi-3.6 35 0.18% 0 0.00% 0 0.00% 2 23 7 3 0 14.29%
pooka-3.0-
63 1.38% 0 0.00% 0 0.00% 4 38 15 6 0 26.98%
080505
proguard-4.5.1 11 0.21% 0 0.00% 0 0.00% 0 6 4 1 0 27.27%
quartz-1.8.3 12 0.41% 0 0.00% 0 0.00% 1 10 1 0 0 8.33%
quickserver-1.4.7 7 0.55% 0 0.00% 0 0.00% 0 7 0 0 0 71.43%
quilt-0.6-a-5 4 0.62% 0 0.00% 0 0.00% 1 2 1 0 0 0.00%
roller-4.0.1 21 0.37% 0 0.00% 0 0.00% 0 13 8 0 0 19.05%
squirrel_sql-3.1.2 2 0.29% 0 0.00% 0 0.00% 0 0 2 0 0 0.00%
sunflow-0.07.2 11 0.76% 0 0.00% 0 0.00% 0 9 2 0 0 0.00%
tomcat-7.0.2 140 0.90% 0 0.00% 0 0.00% 6 88 35 11 0 21.43%
trove-2.1.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
velocity-1.6.4 11 0.37% 0 0.00% 0 0.00% 0 8 3 0 0 18.18%
wct-1.5.2 22 0.40% 0 0.00% 0 0.00% 0 15 7 0 0 36.36%
webmail-0.7.10 10 0.92% 0 0.00% 0 0.00% 0 8 2 0 0 10.00%
weka-3.7.5 263 1.52% 0 0.00% 0 0.00% 27 171 56 9 0 35.74%
xalan-2.7.1 114 1.10% 0 0.00% 0 0.00% 10 78 22 3 1 22.81%
xerces-2.10.0 118 1.28% 0 0.00% 0 0.00% 10 85 20 3 0 33.05%
xmojo-5.0.0 20 1.67% 0 0.00% 0 0.00% 2 13 4 1 0 35.00%
Table 168: Shotgun Surgery Detection Results on the Qualitas Corpus

Code Smell: Shotgun Surgery


Affected Methods Strong Filtered Weak Filtered
At Least
Harm Problem Trouble Warning Bother
System # % # % # % One Re-
(%) (%) (%) (%) (%) lated (%)
aoi-2.8.1 18 0.26% 0 0.00% 7 38.89% 0 14 3 0 1 83.33%
argouml-0.34 20 0.11% 0 0.00% 6 30.00% 0 8 6 6 0 55.00%
axion-1.0-M2 0 0.00% 0 - 0 - 0 0 0 0 0 -
castor-1.3.1 7 0.06% 0 0.00% 3 42.86% 0 2 4 1 0 71.43%
cobertura-1.9.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
colt-1.2.0 1 0.02% 0 0.00% 0 0.00% 0 0 0 1 0 100.00%
columba-1.0 15 0.22% 0 0.00% 9 60.00% 0 7 5 3 0 33.33%
displaytag-1.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
drawswf-1.2.9 0 0.00% 0 - 0 - 0 0 0 0 0 -
drJava-stable-
10 0.10% 3 23.08% 5 50.00% 0 4 5 1 0 70.00%
20100913-r5387
emma-2.0.5312 1 0.06% 0 0.00% 0 0.00% 0 0 1 0 0 100.00%
100.00
exoportal-v1.0.2 7 0.06% 2 22.22% 7 1 3 3 0 0 28.57%
%
findbugs-1.3.9 17 0.17% 0 0.00% 4 23.53% 1 8 6 1 1 70.59%
fitJava-1.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
fitlibraryforfit-
1 0.02% 0 0.00% 0 0.00% 0 0 0 0 1 0.00%
nesse-20100806
freecol-0.10.3 45 0.54% 3 6.25% 19 42.22% 6 18 15 5 1 84.44%
freecs-
3 0.21% 0 0.00% 0 0.00% 0 1 1 1 0 100.00%
1.3.20100406
freemind-0.9.0 9 0.16% 0 0.00% 2 22.22% 0 3 4 2 0 77.78%
galleon-2.3.0 7 0.16% 0 0.00% 3 42.86% 2 2 3 0 0 85.71%
ganttproject-
4 0.07% 0 0.00% 3 75.00% 0 0 2 2 0 100.00%
2.0.9
heritrix-1.14.4 3 0.06% 0 0.00% 2 66.67% 0 2 1 0 0 66.67%
hsqldb-2.0.0 15 0.20% 0 0.00% 5 33.33% 0 7 5 2 1 86.67%
itext-5.0.3 13 0.23% 0 0.00% 7 53.85% 3 6 2 2 0 92.31%
jag-6.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
jasml-0.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
jasperreports-
17 0.10% 0 0.00% 14 82.35% 1 3 6 7 0 64.71%
3.7.3
Javacc-5.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
jedit-4.3.2 10 0.15% 0 0.00% 3 30.00% 0 5 4 1 0 90.00%
jena-2.6.3 7 0.07% 1 12.50% 3 42.86% 0 1 4 1 1 71.43%
jext-5.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
jFin_DateMath-
0 0.00% 0 - 0 - 0 0 0 0 0 -
R1.0.1
jfreechart-1.0.13 13 0.11% 0 0.00% 1 7.69% 3 7 2 1 0 76.92%
jgraph-5.13.0.0 3 0.10% 0 0.00% 2 66.67% 0 0 3 0 0 100.00%
jgraphpad-
0 0.00% 0 - 0 - 0 0 0 0 0 -
5.10.0.2
jgrapht-0.8.1 1 0.07% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
jgroups-2.10.0 15 0.17% 0 0.00% 0 0.00% 0 6 3 6 0 73.33%
jhotdraw-7.5.1 7 0.10% 0 0.00% 2 28.57% 0 1 4 2 0 42.86%
jmeter-2.5.1 8 0.10% 0 0.00% 2 25.00% 0 3 4 1 0 62.50%
jmoney-0.4.4 0 0.00% 0 - 0 - 0 0 0 0 0 -
jparse-0.96 1 0.13% 0 0.00% 0 0.00% 0 0 0 1 0 100.00%
jpf-1.0.2 1 0.08% 0 0.00% 0 0.00% 0 0 1 0 0 100.00%
jruby-1.5.2 28 0.16% 0 0.00% 6 21.43% 0 19 6 3 0 92.86%
jspwiki-2.8.4 8 0.29% 0 0.00% 4 50.00% 0 3 3 2 0 75.00%
jsXe-04_beta 0 0.00% 0 - 0 - 0 0 0 0 0 -
jung-2.0.1 4 0.10% 0 0.00% 3 75.00% 0 1 1 2 0 0.00%
junit-4.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
log4j-1.2.16 3 0.14% 0 0.00% 2 66.67% 0 2 1 0 0 33.33%
lucene-3.5.0 5 0.04% 0 0.00% 2 40.00% 0 2 3 0 0 80.00%
marauroa-3.8.1 1 0.06% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
megamek-
51 0.37% 0 0.00% 13 25.49% 2 33 13 3 0 82.35%
0.35.18
mvnforum-1.2.2- 100.00
2 0.03% 0 0.00% 2 2 0 0 0 0 100.00%
ga %
nekohtml-1.9.14 0 0.00% 0 - 0 - 0 0 0 0 0 -
openjms-0.7.7-
2 0.05% 0 0.00% 0 0.00% 0 1 1 0 0 0.00%
beta-1
oscache-2.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
picocontainer-
1 0.08% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
2.10.2
pmd-4.2.5 4 0.07% 1 20.00% 0 0.00% 0 3 1 0 0 0.00%
poi-3.6 39 0.20% 0 0.00% 18 46.15% 3 22 11 2 1 33.33%
pooka-3.0-
3 0.07% 0 0.00% 0 0.00% 0 1 1 1 0 100.00%
080505
proguard-4.5.1 3 0.06% 0 0.00% 0 0.00% 1 0 1 1 0 33.33%
quartz-1.8.3 0 0.00% 0 - 0 - 0 0 0 0 0 -
quickserver-1.4.7 0 0.00% 0 - 0 - 0 0 0 0 0 -
quilt-0.6-a-5 0 0.00% 0 - 0 - 0 0 0 0 0 -
roller-4.0.1 10 0.17% 0 0.00% 9 90.00% 0 4 1 5 0 40.00%
squirrel_sql-3.1.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
sunflow-0.07.2 8 0.55% 0 0.00% 0 0.00% 0 4 2 2 0 75.00%
tomcat-7.0.2 4 0.03% 0 0.00% 1 25.00% 1 0 2 1 0 75.00%
trove-2.1.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
velocity-1.6.4 0 0.00% 1 100.00% 1 - 0 0 0 0 0 -
wct-1.5.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
webmail-0.7.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
weka-3.7.5 26 0.15% 0 0.00% 8 30.77% 1 10 11 3 1 80.77%
xalan-2.7.1 9 0.09% 0 0.00% 2 22.22% 0 6 2 1 0 88.89%
xerces-2.10.0 7 0.08% 0 0.00% 2 28.57% 2 2 3 0 0 57.14%
xmojo-5.0.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
Table 169: Dispersed Coupling Detection Results on the Qualitas Corpus

Code Smell: Dispersed Coupling


Affected Methods Strong Filtered Weak Filtered
At Least
Harm Problem Trouble Warning Bother
System # % # % # % One Re-
(%) (%) (%) (%) (%) lated (%)
aoi-2.8.1 117 1.70% 0 0.00% 0 0.00% 13 18 52 34 0 94.02%
argouml-0.34 126 0.70% 0 0.00% 0 0.00% 26 23 44 33 0 44.44%
axion-1.0-M2 22 0.74% 0 0.00% 0 0.00% 2 7 6 7 0 54.55%
castor-1.3.1 70 0.58% 12 14.63% 0 0.00% 6 20 22 22 0 67.14%
cobertura-1.9.4.1 2 0.06% 0 0.00% 0 0.00% 0 0 0 2 0 0.00%
colt-1.2.0 12 0.29% 0 0.00% 0 0.00% 0 4 4 4 0 58.33%
columba-1.0 110 1.61% 12 9.84% 0 0.00% 15 27 37 31 0 33.64%
displaytag-1.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
drawswf-1.2.9 5 0.18% 0 0.00% 0 0.00% 1 3 0 1 0 80.00%
drJava-stable-
70 0.68% 35 33.33% 0 0.00% 15 17 26 12 0 70.00%
20100913-r5387
emma-2.0.5312 23 1.27% 0 0.00% 0 0.00% 5 12 3 3 0 65.22%
exoportal-v1.0.2 91 0.78% 36 28.35% 0 0.00% 14 24 30 23 0 60.44%
findbugs-1.3.9 119 1.17% 0 0.00% 0 0.00% 14 27 48 30 0 58.82%
fitJava-1.1 1 0.39% 0 0.00% 0 0.00% 1 0 0 0 0 0.00%
fitlibraryforfit-
29 0.70% 0 0.00% 0 0.00% 1 8 9 11 0 20.69%
nesse-20100806
freecol-0.10.3 216 2.60% 90 29.41% 0 0.00% 31 39 92 54 0 96.30%
freecs-
7 0.50% 0 0.00% 0 0.00% 0 1 3 3 0 85.71%
1.3.20100406
freemind-0.9.0 57 0.98% 1 1.72% 0 0.00% 12 17 18 10 0 82.46%
galleon-2.3.0 86 2.00% 0 0.00% 0 0.00% 8 14 39 25 0 72.09%
ganttproject-
77 1.40% 7 8.33% 0 0.00% 8 22 29 18 0 81.82%
2.0.9
heritrix-1.14.4 26 0.48% 10 27.78% 0 0.00% 1 8 8 9 0 88.46%
hsqldb-2.0.0 85 1.11% 0 0.00% 0 0.00% 4 16 39 26 0 96.47%
itext-5.0.3 42 0.73% 0 0.00% 0 0.00% 6 6 14 16 0 76.19%
jag-6.1 5 0.34% 0 0.00% 0 0.00% 3 1 1 0 0 40.00%
jasml-0.10 2 0.82% 0 0.00% 0 0.00% 1 1 0 0 0 50.00%
jasperreports-
59 0.34% 0 0.00% 0 0.00% 10 22 17 10 0 52.54%
3.7.3
Javacc-5.0 2 0.25% 0 0.00% 0 0.00% 1 0 0 1 0 50.00%
jedit-4.3.2 76 1.16% 0 0.00% 0 0.00% 11 21 22 22 0 84.21%
jena-2.6.3 45 0.45% 0 0.00% 0 0.00% 2 10 19 14 0 53.33%
jext-5.0 15 0.69% 0 0.00% 0 0.00% 4 4 4 3 0 93.33%
jFin_DateMath-
0 0.00% 0 - 0 - 0 0 0 0 0 -
R1.0.1
jfreechart-1.0.13 44 0.37% 58 56.86% 0 0.00% 7 14 13 10 0 95.45%
jgraph-5.13.0.0 13 0.43% 0 0.00% 0 0.00% 2 1 6 4 0 92.31%
jgraphpad-
6 0.32% 0 0.00% 0 0.00% 0 3 0 3 0 50.00%
5.10.0.2
jgrapht-0.8.1 1 0.07% 2 66.67% 0 0.00% 0 0 0 1 0 100.00%
jgroups-2.10.0 51 0.58% 0 0.00% 0 0.00% 1 10 19 21 0 70.59%
jhotdraw-7.5.1 69 0.95% 0 0.00% 0 0.00% 17 12 29 11 0 50.72%
jmeter-2.5.1 34 0.42% 0 0.00% 0 0.00% 2 6 20 6 0 41.18%
jmoney-0.4.4 6 0.84% 0 0.00% 0 0.00% 2 1 2 1 0 33.33%
jparse-0.96 0 0.00% 0 - 0 - 0 0 0 0 0 -
jpf-1.0.2 11 0.87% 0 0.00% 0 0.00% 0 0 7 4 0 27.27%
jruby-1.5.2 237 1.34% 0 0.00% 0 0.00% 23 42 106 66 0 85.65%
jspwiki-2.8.4 19 0.70% 0 0.00% 0 0.00% 1 0 7 11 0 89.47%
jsXe-04_beta 5 0.71% 0 0.00% 0 0.00% 2 0 1 2 0 100.00%
jung-2.0.1 53 1.36% 0 0.00% 0 0.00% 11 14 16 12 0 79.25%
junit-4.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
log4j-1.2.16 4 0.19% 0 0.00% 0 0.00% 1 0 3 0 0 25.00%
lucene-3.5.0 63 0.50% 0 0.00% 0 0.00% 10 15 20 18 0 22.22%
marauroa-3.8.1 15 0.94% 1 6.25% 0 0.00% 1 6 5 3 0 40.00%
megamek-
236 1.73% 0 0.00% 0 0.00% 28 50 102 56 0 91.53%
0.35.18
mvnforum-1.2.2-
90 1.50% 0 0.00% 0 0.00% 14 18 43 15 0 76.67%
ga
nekohtml-1.9.14 0 0.00% 0 - 0 - 0 0 0 0 0 -
openjms-0.7.7-
11 0.29% 0 0.00% 0 0.00% 3 1 5 2 0 9.09%
beta-1
oscache-2.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
picocontainer-
3 0.23% 0 0.00% 0 0.00% 0 1 1 1 0 0.00%
2.10.2
pmd-4.2.5 15 0.25% 7 31.82% 0 0.00% 0 2 7 6 0 6.67%
poi-3.6 94 0.48% 92 49.46% 0 0.00% 10 15 40 29 0 63.83%
pooka-3.0-
48 1.05% 0 0.00% 0 0.00% 5 12 19 12 0 85.42%
080505
proguard-4.5.1 37 0.72% 0 0.00% 0 0.00% 9 9 12 7 0 37.84%
quartz-1.8.3 3 0.10% 1 25.00% 0 0.00% 0 0 2 1 0 33.33%
quickserver-1.4.7 2 0.16% 0 0.00% 0 0.00% 0 0 1 1 0 100.00%
quilt-0.6-a-5 3 0.47% 0 0.00% 0 0.00% 0 1 1 1 0 0.00%
roller-4.0.1 51 0.89% 0 0.00% 0 0.00% 1 10 22 18 0 54.90%
squirrel_sql-3.1.2 5 0.73% 0 0.00% 0 0.00% 1 4 0 0 0 0.00%
sunflow-0.07.2 7 0.48% 0 0.00% 0 0.00% 1 2 3 1 0 42.86%
tomcat-7.0.2 111 0.71% 0 0.00% 0 0.00% 15 20 37 39 0 54.95%
trove-2.1.0 1 0.17% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
velocity-1.6.4 8 0.27% 3 27.27% 0 0.00% 0 4 2 2 0 25.00%
wct-1.5.2 58 1.05% 0 0.00% 0 0.00% 9 8 28 13 0 91.38%
webmail-0.7.10 3 0.27% 0 0.00% 0 0.00% 0 0 1 2 0 0.00%
weka-3.7.5 71 0.41% 0 0.00% 0 0.00% 12 10 28 21 0 52.11%
xalan-2.7.1 51 0.49% 0 0.00% 0 0.00% 7 6 23 15 0 84.31%
xerces-2.10.0 37 0.40% 0 0.00% 0 0.00% 4 4 20 9 0 72.97%
xmojo-5.0.0 15 1.25% 0 0.00% 0 0.00% 2 5 7 1 0 40.00%
Table 170: Message Chains Detection Results on the Qualitas Corpus

Code Smell: Message Chains


Affected Methods Strong Filtered Weak Filtered
At Least
Harm Problem Trouble Warning Bother
System # % # % # % One Re-
(%) (%) (%) (%) (%) lated (%)
aoi-2.8.1 51 0.74% 0 0.00% 0 0.00% 0 12 20 19 0 37.25%
argouml-0.34 12 0.07% 0 0.00% 0 0.00% 0 10 0 2 0 33.33%
axion-1.0-M2 4 0.13% 0 0.00% 0 0.00% 0 0 1 3 0 25.00%
castor-1.3.1 19 0.16% 0 0.00% 0 0.00% 0 2 8 9 0 57.89%
cobertura-1.9.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
colt-1.2.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
columba-1.0 22 0.32% 2 8.33% 0 0.00% 0 7 7 8 0 45.45%
displaytag-1.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
drawswf-1.2.9 0 0.00% 0 - 0 - 0 0 0 0 0 -
drJava-stable-
0 0.00% 0 - 0 - 0 0 0 0 0 -
20100913-r5387
emma-2.0.5312 0 0.00% 0 - 0 - 0 0 0 0 0 -
exoportal-v1.0.2 2 0.02% 0 0.00% 0 0.00% 0 1 0 1 0 0.00%
findbugs-1.3.9 4 0.04% 0 0.00% 0 0.00% 0 1 1 2 0 25.00%
fitJava-1.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
fitlibraryforfit-
0 0.00% 0 - 0 - 0 0 0 0 0 -
nesse-20100806
freecol-0.10.3 135 1.62% 7 4.93% 0 0.00% 0 62 27 46 0 45.19%
freecs-
3 0.21% 0 0.00% 0 0.00% 0 0 0 3 0 33.33%
1.3.20100406
freemind-0.9.0 4 0.07% 0 0.00% 0 0.00% 0 1 1 2 0 50.00%
galleon-2.3.0 8 0.19% 0 0.00% 0 0.00% 0 2 2 4 0 37.50%
ganttproject-
20 0.36% 0 0.00% 0 0.00% 0 5 7 8 0 45.00%
2.0.9
heritrix-1.14.4 17 0.32% 0 0.00% 0 0.00% 0 15 2 0 0 47.06%
hsqldb-2.0.0 8 0.10% 0 0.00% 0 0.00% 0 0 0 8 0 87.50%
itext-5.0.3 3 0.05% 0 0.00% 0 0.00% 0 3 0 0 0 100.00%
jag-6.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
jasml-0.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
jasperreports-
7 0.04% 0 0.00% 0 0.00% 0 5 1 1 0 57.14%
3.7.3
Javacc-5.0 1 0.12% 0 0.00% 0 0.00% 0 0 0 1 0 0.00%
jedit-4.3.2 1 0.02% 0 0.00% 0 0.00% 0 0 0 1 0 0.00%
jena-2.6.3 1 0.01% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
jext-5.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
jFin_DateMath-
0 0.00% 0 - 0 - 0 0 0 0 0 -
R1.0.1
jfreechart-1.0.13 0 0.00% 0 - 0 - 0 0 0 0 0 -
jgraph-5.13.0.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
jgraphpad-
2 0.11% 0 0.00% 0 0.00% 0 1 0 1 0 0.00%
5.10.0.2
jgrapht-0.8.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
jgroups-2.10.0 4 0.05% 0 0.00% 0 0.00% 0 1 2 1 0 25.00%
jhotdraw-7.5.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
jmeter-2.5.1 1 0.01% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
jmoney-0.4.4 0 0.00% 0 - 0 - 0 0 0 0 0 -
jparse-0.96 0 0.00% 0 - 0 - 0 0 0 0 0 -
jpf-1.0.2 8 0.63% 0 0.00% 0 0.00% 0 8 0 0 0 0.00%
jruby-1.5.2 36 0.20% 0 0.00% 0 0.00% 0 18 1 17 0 50.00%
jspwiki-2.8.4 7 0.26% 0 0.00% 0 0.00% 0 3 1 3 0 14.29%
jsXe-04_beta 0 0.00% 0 - 0 - 0 0 0 0 0 -
jung-2.0.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
junit-4.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
log4j-1.2.16 0 0.00% 0 - 0 - 0 0 0 0 0 -
lucene-3.5.0 7 0.06% 0 0.00% 0 0.00% 0 5 0 2 0 42.86%
marauroa-3.8.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
megamek-
90 0.66% 0 0.00% 0 0.00% 0 14 40 36 0 47.78%
0.35.18
mvnforum-1.2.2-
0 0.00% 0 - 0 - 0 0 0 0 0 -
ga
nekohtml-1.9.14 0 0.00% 0 - 0 - 0 0 0 0 0 -
openjms-0.7.7-
0 0.00% 0 - 0 - 0 0 0 0 0 -
beta-1
oscache-2.4.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
picocontainer-
0 0.00% 0 - 0 - 0 0 0 0 0 -
2.10.2
pmd-4.2.5 0 0.00% 0 - 0 - 0 0 0 0 0 -
poi-3.6 18 0.09% 31 63.27% 0 0.00% 0 10 1 7 0 55.56%
pooka-3.0-
13 0.29% 0 0.00% 0 0.00% 0 5 5 3 0 53.85%
080505
proguard-4.5.1 0 0.00% 0 - 0 - 0 0 0 0 0 -
quartz-1.8.3 1 0.03% 0 0.00% 0 0.00% 0 0 0 1 0 0.00%
quickserver-1.4.7 16 1.25% 0 0.00% 0 0.00% 0 15 0 1 0 87.50%
quilt-0.6-a-5 2 0.31% 0 0.00% 0 0.00% 0 1 0 1 0 0.00%
roller-4.0.1 25 0.44% 0 0.00% 0 0.00% 0 2 11 12 0 16.00%
squirrel_sql-3.1.2 0 0.00% 0 - 0 - 0 0 0 0 0 -
sunflow-0.07.2 1 0.07% 0 0.00% 0 0.00% 0 1 0 0 0 0.00%
tomcat-7.0.2 8 0.05% 0 0.00% 0 0.00% 0 5 1 2 0 25.00%
trove-2.1.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
velocity-1.6.4 0 0.00% 0 - 0 - 0 0 0 0 0 -
wct-1.5.2 38 0.69% 0 0.00% 0 0.00% 0 15 10 13 0 34.21%
webmail-0.7.10 0 0.00% 0 - 0 - 0 0 0 0 0 -
weka-3.7.5 32 0.18% 0 0.00% 0 0.00% 0 24 4 4 0 21.88%
xalan-2.7.1 1 0.01% 0 0.00% 0 0.00% 0 1 0 0 0 100.00%
xerces-2.10.0 0 0.00% 0 - 0 - 0 0 0 0 0 -
xmojo-5.0.0 2 0.17% 0 0.00% 0 0.00% 0 1 1 0 0 100.00%
Appendices.

E2 JCodeOdor Detection Results on Heritrix


Table 171 to Table 175 show the detection results of JCodeOdor on
the Heritrix system, used to compare the detection results with inFusion
[143] in Section 7.2.1. The structure of the presentation is described in Sec-
tion 6.2.4.

God Class 1 Filtered / 1 Possibly Filtered

Possibly
Affected Entity Harmfulness Visualizations
Filtered

10/10
CrawlController - [Visualizations]
(Harm)
10/10
CachedBdbMap - [Visualizations]
(Harm)
10/10
CrawlJobHandler - [Visualizations]
(Harm)
10/10
AbstractFrontier - [Visualizations]
(Harm)
10/10
StatisticsTracker - [Visualizations]
(Harm)
9.55/10
Heritrix - [Visualizations]
(Problem)
9.55/10
FetchHTTP - [Visualizations]
(Problem)
9.10/10
WriterPoolProcessor - [Visualizations]
(Problem)
7.75/10
CrawlSettingsSAXSource Parser Class [Visualizations]
(Problem)
7.75/10
AdaptiveRevisitFrontier - [Visualizations]
(Problem)
7.75/10
WorkQueueFrontier - [Visualizations]
(Problem)
7.75/10
SettingsHandler - [Visualizations]
(Problem)
7.75/10
ToeThread - [Visualizations]
(Problem)
5.95/10
WARCWriterProcessor - [Visualizations]
(Trouble)
3.70/10
Processor - [Visualizations]
(Warning)

Table 171: JCodeOdor God Class on Heritrix

340
Appendices.

Data Class 1 Filtered / 0 Possibly Filtered

Possibly
Affected Entity Harmfulness Visualizations
Filtered

MatchesFilePatternDecid- 10/10
- [Visualizations]
eRule (Harm)
9.25/10
LowDiskPauseProcessor - [Visualizations]
(Problem)
8.50/10
RegexpLineIterator - [Visualizations]
(Problem)
7.75/10
StringIntPair - [Visualizations]
(Problem)
7.00/10
DomainScope - [Visualizations]
(Trouble)

Table 172: JCodeOdor Data Class on Heritrix

Brain Method 0 Filtered / 0 Possibly Filtered

Possibly
Affected Entity Harmfulness Visualizations
Filtered

importQueuesFrom-
9.44/10
Log(File,CrawlControl- [Visualizations]
(Problem)
ler,int,CountDownLatch)
processGen-
9.10/10
eralTag(CrawlURI,CharSe- [Visualizations]
(Problem)
quence,CharSequence)
uriToFile(String,CrawlURI 9.10/10
[Visualizations]
) (Problem)
handleJobAc-
tion(CrawlJob-
Handler,HttpS- 9.10/10
[Visualizations]
ervletRequest,HttpS- (Problem)
ervletResponse,String,Strin
g,String)
processGen-
9.10/10
eralTag(CharSe- [Visualizations]
(Problem)
quence,CharSequence)
8.88/10
tail(RandomAccessFile,int) [Visualizations]
(Problem)

341
Appendices.

checkAttribute(ModuleAt-
tributeInfo,Com-
8.88/10
plexType,CrawlerSet- [Visualizations]
(Problem)
tings,HttpS-
ervletRequest,boolean)
getByRegExpr(In-
8.88/10
putStreamReader,String,int [Visualizations]
(Problem)
,boolean,int,int,long)
getByRegExpr(In-
8.88/10
putStreamReader,String,St [Visualizations]
(Problem)
ring,boolean,int,int,long)
importCompletionInfo-
8.88/10
FromLog(File,CrawlCon- [Visualizations]
(Problem)
troller,boolean)
8.31/10
extract(CrawlURI) [Visualizations]
(Problem)
for-
8.31/10
mat(Matcher,String,String- [Visualizations]
(Problem)
Buffer)
processBd- 8.31/10
[Visualizations]
bLogs(File,String) (Problem)
7.75/10
load(String) [Visualizations]
(Problem)
buildRegex(String,String- 7.75/10
[Visualizations]
Builder,SortedSet) (Problem)
7.30/10
next() [Visualizations]
(Trouble)
6.63/10
initialize(CrawlController) [Visualizations]
(Trouble)
replaceCom-
6.40/10
plexType(CrawlerSet- [Visualizations]
(Trouble)
tings,ComplexType)
6.06/10
loadProfiles() [Visualizations]
(Trouble)
6.06/10
loadCookies(String) [Visualizations]
(Trouble)
getFrom(Fron- 5.50/10
[Visualizations]
tierMarker,int) (Trouble)
5.50/10
filesFoundInArc() [Visualizations]
(Trouble)
enforceBandwidthThrot- 4.60/10
[Visualizations]
tle(long) (Warning)
4.38/10
_getDisk(Object) [Visualizations]
(Warning)

Table 173: JCodeOdor Brain Method on Heritrix


342
Appendices.

Shotgun Surgery 1 Filtered / 2 Possibly Filtered

Possibly
Affected Entity Harmfulness Visualizations
Filtered

setAttribute(CrawlerSet- 8.50/10 Getter/Set-


[Visualizations]
tings,Attribute) (Problem) ter Method
7.75/10 Getter/Set-
getController() [Visualizations]
(Problem) ter Method
addLabel- 5.50/10
[Visualizations]
Value(String,String) (Trouble)

Table 174: JCodeOdor Shotgun Surgery on Heritrix

Message Chains 0 Filtered / 0 Possibly Filtered

Possibly
Affected Entity Harmfulness Visualizations
Filtered

ClassKeyMatch-
7.75/10
esRegExpDecid- [Visualizations]
(Problem)
eRule:evaluate(Object)
ExternalGeoLocationDe-
7.75/10
cideRule:evaluate(Ob- [Visualizations]
(Problem)
ject)
7.75/10
buildSurtPrefixSet() [Visualizations]
(Problem)
7.75/10
dumpSurtPrefixSet() [Visualizations]
(Problem)
7.75/10
getSeedfile() [Visualizations]
(Problem)
7.75/10
readPrefixes() [Visualizations]
(Problem)
7.75/10
kickUpdate() [Visualizations]
(Problem)
importRecover- 7.75/10
[Visualizations]
Log(String,boolean) (Problem)
7.75/10
getDiversionLog(String) [Visualizations]
(Problem)
7.75/10
loadMap() [Visualizations]
(Problem)

343
Appendices.

7.75/10
readPrefixes() [Visualizations]
(Problem)
DecideRule:getControl- 7.75/10
[Visualizations]
ler() (Problem)
7.75/10
initialTasks() [Visualizations]
(Problem)
loadCheckpointSerial- 7.75/10
[Visualizations]
Number() (Problem)
Processor:getControl- 7.75/10
[Visualizations]
ler() (Problem)
5.50/10
execute(Object) [Visualizations]
(Trouble)
writeHostsRe- 5.50/10
[Visualizations]
portTo(PrintWriter) (Trouble)

Table 175: JCodeOdor Message Chains on Heritrix

E3 Effectiveness of JCodeOdor, inFusion and MLCS

Table 176 to Table 178 show the comparison in terms of agreements


and Cohen’s kappa among JCodeOdor, inFusion and a Machine Learning
Approach (MLCS) for code smells detection by Marino [95]. Table 179 to
Table 181 show the comparison of the three approaches in terms of preci-
sion, recall, F-Measure and accuracy [65] versus an oracle of manually de-
tected code smells on Jasml [144]. The considered code smells differ based
on the tool / approach, because each of them considers some code smells
and does not consider other.

Table 176: Agreement and Cohen’s kappa between JCodeOdor and MLCS
JCodeOdor

Learning
Machine
None

Both

Code Smell Agreement Kappa

God Class 43 0 5 1 0.90 0.26


Data Class 39 10 0 0 0.80 0.00
Brain
236 0 5 4 0.98 0.61
Method

344
Appendices.

Table 177: Agreement and Cohen’s kappa between JCodeOdor and inFu-
sion

JCodeOdor

inFusion
None

Both
Code Smell Agreement Kappa

God Class 48 1 0 0 0.98 0.00


Data Class 39 4 0 6 0.92 0.70
Brain
236 4 5 0 0.96 -0.02
Method
Shotgun
245 0 0 0 1.00 -
Surgery
Message
245 0 0 0 1.00 -
Chains

Table 178: Agreement and Cohen’s kappa between MLCS and inFusion
Learning

inFusion
Machine
None

Both

Code Smell Agreement Kappa

God Class 43 6 0 0 0.88 0.00


Data Class 43 0 6 0 0.88 0.00
Brain
231 9 5 0 0.94 -0.03
Method

Table 179: Precision ad Recall of JCodeOdor versus a Manual Oracle

JCodeOdor VS. Manual Oracle

Code Smell TP FP TN FN Precision Recall F-Measure Accuracy

God Class 1 0 47 1 100% 50% 67% 98%

Data Class 10 0 37 2 100% 83% 91% 96%

345
Appendices.

Brain
4 0 236 5 100% 44% 62% 98%
Method

Shotgun
0 0 245 0 - - - 100%
Surgery

Dispersed
1 1 240 3 50% 25% 33% 98%
Coupling

Message
0 0 245 0 - - - 100%
Chains

Table 180: Precision ad Recall of MLCS versus a Manual Oracle

Machine Learning VS. Manual Oracle

Code Smell TP FP TN FN Precision Recall F-Measure Accuracy

God Class 2 4 43 0 33% 100% 50% 92%

Data Class 0 0 37 12 - 0% - 76%

Brain
8 1 235 1 89% 89% 89% 99%
Method

Table 181: Precision ad Recall of inFusion versus a Manual Oracle

inFusion VS. Manual Oracle

Code Smell TP FP TN FN Precision Recall F-Measure Accuracy

God Class 0 0 47 2 - 0% - 96%

Data Class 6 0 37 6 100% 50% 67% 88%

Brain
0 5 231 9 0% 0% - 94%
Method

Shotgun
0 0 245 0 - - - 100%
Surgery

Message
0 0 245 0 - - - 100%
Chains

346
References
References
[1] A. Abuasad and I. M. Alsmadi, “Evaluating the correlation between
software defect and design coupling metrics,” in 2012 International
Conference on Computer, Information and Telecommunication Systems
(CITS), 2012, IEEE, pp. 1–5. doi:10.1109/CITS.2012.6220374.

[2] K. K. Aggarwal, Y. Singh, A. Kaur, and R. Malhotra, “Empirical study of


object-oriented metrics,” Journal of Object Technology, vol. 5, no. 8, p.
149, 2006. doi:10.5381/jot.2006.5.8.a5.

[3] T. L. Alves, C. Ypma, and J. Visser, “Deriving metric thresholds from


benchmark data,” in 2010 IEEE International Conference on Software
Maintenance, 2010, Timisoara: IEEE, pp. 1–10.
doi:10.1109/ICSM.2010.5609747.

[4] P. Antonellis, D. Antoniou, Y. Kanellopoulos, C. Makris, E. Theodoridis,


C. Tjortjis, and N. Tsirakis, “Clustering for Monitoring Software Systems
Maintainability Evolution,” Electronic Notes in Theoretical Computer
Science, vol. 233, pp. 43–57, Mar. 2009, Elsevier B.V.
doi:10.1016/j.entcs.2009.02.060.

[5] F. Arcelli Fontana, P. Braione, and M. Zanoni, “Automatic detection of bad


smells in code: An experimental assessment.,” Journal of Object
Technology, vol. 11, no. 2, pp. 1–32, 2012. doi:10.5381/jot.201Y.VV.N.aN.

[6] F. Arcelli Fontana, V. Ferme, A. Marino, B. Walter, and P. Martenka,


“Investigating the Impact of Code Smells on System’s Quality: An
Empirical Study on Systems of Different Application Domains,” in 29th
IEEE International Conference on Software Maintenance (ICSM 2013),
2013, Eindhoven: IEEE, p. 10.

[7] F. Arcelli Fontana, V. Ferme, and S. Spinelli, “Investigating the Impact of


Code Smells Debt on Quality Code Evaluation,” in Third International
Workshop on Managing Technical Debt (MTD), 2012, Zurich: IEEE, pp.
15–22. doi:10.1109/MTD.2012.6225993.

[8] F. Arcelli Fontana, M. Mäntylä, A. Marino, and M. Zanoni, “Code Smell


Detection: towards a Machine Learning-based Approach,” in International
Conference on Software Maintenance ERA Track (ICSM 2013), 2013,
Eindhoven: IEEE.

347
References.

[9] F. Arcelli Fontana and M. Zanoni, “On investigating code smells


correlations,” in 2011 IEEE Fourth International Conference on Software
Testing, Verification and Validation Workshops (ICSTW 2011), 2011,
Berlin, Germany: IEEE, pp. 474–475. doi:10.1016/j.ins.2010.F.Arcelli.

[10] F. Arcelli Fontana, M. Zanoni, A. Ranchetti, and D. Ranchetti, “Software


Clone Detection and Refactoring,” ISRN Software Engineering, vol. 2013,
pp. 1–8, 2013. doi:10.1155/2013/129437.

[11] F. Balmas, F. Bellingard, S. Denier, S. Ducasse, B. Francher, J. Laval, K.


Mordal-Manet, and P. Vaillergues, “The Squale Quality Model,” 2010.

[12] J. Bansiya and C. G. Davis, “A hierarchical model for object-oriented


design quality assessment,” IEEE Transactions on Software Engineering,
vol. 28, no. 1, pp. 4–17, 2002. doi:10.1109/32.979986.

[13] V. Basili, L. Briand, and W. Melo, “A validation of object-oriented design


metrics as quality indicators,” IEEE Transactions on Software Engineering,
vol. 22, no. 10, pp. 751–761, 1996. doi:10.1109/32.544352.

[14] M. Bastian, S. Heymann, and M. Jacomy, “Gephi: an open source software


for exploring and manipulating networks,” in ICWSM, 2009.

[15] S. Benlarbi, K. El Emam, N. Goel, and S. Rai, “Thresholds for object-


oriented measures,” in Proceedings 11th International Symposium on
Software Reliability Engineering. ISSRE 2000, 2000, no. March, IEEE, pp.
24–38. doi:10.1109/ISSRE.2000.885858.

[16] I. M. Bertran, “Detecting architecturally-relevant code smells in evolving


software systems,” in Proceeding of the 33rd international conference on
Software engineering - ICSE ’11, 2011, New York, New York, USA:
ACM Press, p. 1090. doi:10.1145/1985793.1986003.

[17] L. C. Briand, J. W. Daly, and J. Wust, “A unified framework for cohesion


measurement in object-oriented systems,” in Proceedings Fourth
International Software Metrics Symposium, 1998, IEEE Comput. Soc, pp.
43–53. doi:10.1109/METRIC.1997.637164.

[18] L. C. Briand, J. W. Daly, and J. Wust, “A unified framework for coupling


measurement in object-oriented systems,” IEEE Transactions on Software
Engineering, vol. 25, no. 1, pp. 91–121, 1999. doi:10.1109/32.748920.

[19] W. Brown, R. Malveau, and T. Mowbray, AntiPatterns: refactoring


software, architectures, and projects in crisis. 1998.

[20] D. Campbell, J. Stanley, and N. Gage, Experimental and quasi-


experimental designs for research. Boston: Houghton Mifflin, 1963.

348
References.

[21] A. Chatzigeorgiou and A. Manakos, “Investigating the evolution of code


smells in object-oriented systems,” Innovations in Systems and Software
Engineering, Apr. 2013. doi:10.1007/s11334-013-0205-z.

[22] S. Chidamber and C. Kemerer, “A metrics suite for object oriented design,”
IEEE Transactions on Software Engineering, vol. 20, no. 6, pp. 476–493,
Jun. 1994. doi:10.1109/32.295895.

[23] P. Coad and E. Yourdon, Object-oriented design. Prentice Hall, Ed.


Yourdon Press, 1991.

[24] J. Cohen, “A Coefficient of Agreement for Nominal Scales,” Educational


and Psychological Measurement, vol. 20, no. 1, pp. 37–46, Apr. 1960.
doi:10.1177/001316446002000104.

[25] D. Coleman, B. Lowther, and P. Oman, “The application of software


maintainability models in industrial software systems,” Journal of Systems
and Software, vol. 29, no. 1, pp. 3–16, Apr. 1995. doi:10.1016/0164-
1212(94)00125-7.

[26] C. Collberg, S. Kobourov, J. Pitts, K. Wampler, and J. Nagra, “A System


for Graph-Based Visualization of the Evolution of Software Visualization
of Large Evolving Graphs,” Proceedings of the 2003 ACM symposium on
Software visualization - SoftVis ’03, pp. 77–87, 2003, ACM Press, New
York, New York, USA. doi:10.1145/774841.774844.

[27] G. Concas, M. Marchesi, S. Pinna, and N. Serra, “Power-Laws in a Large


Object-Oriented Software System,” IEEE Transactions on Software
Engineering, vol. 33, no. 10, pp. 687–708, Oct. 2007.
doi:10.1109/TSE.2007.1019.

[28] S. Counsell, R. M. Hierons, H. Hamza, S. Black, and M. Durrand,


“Exploring the Eradication of Code Smells: An Empirical and Theoretical
Perspective,” Advances in Software Engineering, vol. 2010, pp. 1–12,
2010. doi:10.1155/2010/820103.

[29] Y. Crespo and L. Carlos, “Relative Thresholds : Case Study to Incorporate


Metrics in the Detection of Bad Smells,” in QAOOSE 2006, pp. 109–118.

[30] M. D’Ambros, A. Bacchelli, and M. Lanza, “On the Impact of Design


Flaws on Software Defects,” 2010 10th International Conference on
Quality Software, pp. 23–31, Jul. 2010, Ieee. doi:10.1109/QSIC.2010.58.

[31] M. Dagpinar and J. H. Jahnke, “Predicting maintainability with object-


oriented metrics -an empirical comparison,” in 10th Working Conference
on Reverse Engineering, 2003. WCRE 2003. Proceedings., 2003, IEEE, pp.
155–164. doi:10.1109/WCRE.2003.1287246.

349
References.

[32] A. Dan, K. Michele, and M. Gordon, “An Introduction to Heritrix: An


Open Source Archival Quality Web Crawler,” 4th International Web
Archiving Workshop, no. 2004, 2004.

[33] R. Daniel and T. Gîrba, “Evolution Enriched Detection of God Classes,” in


2nd CAVIS, 2004, no. C, pp. 3–7.

[34] P. Danphitsanuphan and T. Suwantada, “Code Smell Detecting Tool and


Code Smell-Structure Bug Relationship,” 2012 Spring Congress on
Engineering and Technology, pp. 1–5, May 2012, Ieee.
doi:10.1109/SCET.2012.6342082.

[35] T. DeMarco, Controlling software projects: Management, measurement,


and estimates. Prentice Hall PTR, 1986.

[36] G. Denaro, S. Morasca, and M. Pezzè, “Deriving models of software fault-


proneness,” Proceedings of the 14th international conference on Software
engineering and knowledge engineering - SEKE ’02, p. 361, 2002, ACM
Press, New York, New York, USA. doi:10.1145/568823.568824.

[37] B. M. Dexter, “Eclipse And Java For Total Beginners Companion Tutorial
Document.” p. 45, 2007.

[38] P. K. Dhillon and G. Sidhu, “Can Software Faults be Analyzed using Bad
Code Smells ? : An Empirical Study,” International Journal of Scientific
and Research Publications, vol. 2, no. 10, pp. 1–7, 2012.

[39] S. K. Dubey, A. Sharma, and A. Rana, “Comparison of Software Quality


Metrics for Object-Oriented System,” International Journal of Computer
Science, vol. 12, no. June, pp. 12–24, 2012.

[40] S. Ducasse, N. Anquetil, M. Bhatti, and A. Hora, “MSE and FAMIX 3.0:
an interexchange format and source code model family,” 2011.

[41] S. Ducasse, S. Denier, F. Balmas, and A. Bergel, “Software metrics for


Java and C ++ practices,” Squale project, no. March, 2010.

[42] E. van Emden and L. Moonen, “Java quality assurance by detecting code
smells,” in Ninth Working Conference on Reverse Engineering, 2002.
Proceedings., 2002, no. October, IEEE Comput. Soc, pp. 97–106.
doi:10.1109/WCRE.2002.1173068.

[43] U. Erdemir, U. Tekin, and F. Buzluca, “E-Quality: A graph based object


oriented software quality visualization tool,” 2011 6th International
Workshop on Visualizing Software for Understanding and Analysis
(VISSOFT), pp. 1–8, Sep. 2011, Ieee. doi:10.1109/VISSOF.2011.6069454.

[44] K. Erni and C. Lewerentz, “Applying design-metrics to object-oriented


frameworks,” in Proceedings of the 3rd International Software Metrics
350
References.

Symposium, 1996, IEEE Comput. Soc. Press, pp. 64–74.


doi:10.1109/METRIC.1996.492444.

[45] N. E. Fenton and S. L. Pfleeger, Software Metrics - A Rigorous And


Practical Approach. PWS Publishing Co., 1998.

[46] V. Ferme and A. Marino, “Metrics and Smells Correlation,” 2012.


[Online]. Available:
http://essere.disco.unimib.it/reverse/MetricSmellCorrelations.html.
[Accessed: 08-Mar-2013].

[47] V. Ferme, A. Marino, and F. Arcelli Fontana, “Is it a Real Code Smell to be
Removed or not?,” in International Workshop on Refactoring & Testing
(RefTest), co-located event with XP 2013 Conference, 2013, Wien.

[48] M. Fokaefs, N. Tsantalis, and A. Chatzigeorgiou, “JDeodorant:


Identification and Removal of Feature Envy Bad Smells,” 2007 IEEE
International Conference on Software Maintenance, pp. 519–520, Oct.
2007, Ieee. doi:10.1109/ICSM.2007.4362679.

[49] M. Fokaefs, N. Tsantalis, E. Stroulia, and A. Chatzigeorgiou, “JDeodorant:


Identification and Application of Extract Class Refactorings,” in
Proceeding of the 33rd international conference on Software engineering -
ICSE ’11, 2011, New York: ACM Press, p. 1037.
doi:10.1145/1985793.1985989.

[50] M. Fowler, Patterns of enterprise application architecture. Addison-


Wesley Longman Publishing Co., Inc., 2002.

[51] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring:


improving the design of existing code. Addison-Wesley, 1999.

[52] E. Gansner and S. North, “An open graph visualization system and its
applications to software engineering,” Software Practice and Experience,
vol. 30, no. 11, pp. 203–1233, 2000.

[53] J. Gibbons and S. Chakraborti, Nonparametric statistical inference, 4th ed.


CRC press, 2003.

[54] J. (Yossi) Gil and I. Maman, “Micro patterns in Java code,” ACM
SIGPLAN Notices, vol. 40, no. 10, p. 97, Oct. 2005.
doi:10.1145/1103845.1094819.

[55] W. Gilchrist, Statistical modelling with quantile functions. CRC Press,


2002.

[56] J. Gosling, B. Joy, G. Steele, G. Bracha, and A. Buckley, “The Java ®


Language Specification Java SE 7 Edition.” [Online]. Available:
http://docs.oracle.com/javase/specs/jls/se7/html/index.html. [Accessed: 16-
Jun-2013].
351
References.

[57] T. Gyimothy, R. Ferenc, and I. Siket, “Empirical validation of object-


oriented metrics on open source software for fault prediction,” IEEE
Transactions on Software Engineering, vol. 31, no. 10, pp. 897–910, Oct.
2005. doi:10.1109/TSE.2005.112.

[58] J. E. Halse and M. Stack, “Heritrix developer documentation.” [Online].


Available: http://crawler.archive.org/articles/developer_manual/index.html.
[Accessed: 08-Aug-2013].

[59] S. Hassaine, F. Khomh, Y.-G. Guéhéneuc, and S. Hamel, “IDS: An


Immune-Inspired Approach for the Detection of Software Design Smells,”
2010 Seventh International Conference on the Quality of Information and
Communications Technology, pp. 343–348, Sep. 2010, Ieee.
doi:10.1109/QUATIC.2010.61.

[60] B. Henderson-Sellers, “Object-Oriented Metrics: Measures of


Complexity,” 1996.

[61] A. Hora, N. Anquetil, S. Ducasse, and S. Allier, “Domain specific


warnings: Are they any better?,” 2012 28th IEEE International Conference
on Software Maintenance (ICSM), pp. 441–450, Sep. 2012, Ieee.
doi:10.1109/ICSM.2012.6405305.

[62] S. Jancke and D. Speicher, “Smell Detection in Context,” University of


Bonn, 2010.

[63] F. M. Jr, “The Kolmogorov-Smirnov test for goodness of fit,” Journal of


the American Statistical Association, vol. 46, no. 253, pp. 68–78, 1951.

[64] Y. Kanellopoulos and T. Dimopulos, “Mining source code elements for


comprehending object-oriented systems and evaluating their
maintainability,” ACM SIGKDD Explorations Newsletter, pp. 33–40, 2006.

[65] M. A. Keith Van Rijsbergen, Information Retrieval, 2nd ed. B.-H. Newton,
Ed, 1979.

[66] F. Khomh, M. Di Penta, and Y.-G. Guéhéneuc, “An Exploratory Study of


the Impact of Code Smells on Software Change-proneness,” in 16th
Working Conference on Reverse Engineering, 2009, Ieee, pp. 75–84.
doi:10.1109/WCRE.2009.28.

[67] F. Khomh, M. Di Penta, Y.-G. Guéhéneuc, and G. Antoniol, “An


exploratory study of the impact of antipatterns on class change- and fault-
proneness,” Empirical Software Engineering, vol. 17, no. 3, pp. 243–275,
Aug. 2011. doi:10.1007/s10664-011-9171-y.

[68] S. Kim, K. Pan, and E. J. Whitehead, “Micro pattern evolution,”


Proceedings of the 2006 international workshop on Mining software

352
References.

repositories - MSR ’06, p. 40, 2006, ACM Press, New York, New York,
USA. doi:10.1145/1137983.1137995.

[69] B. Kitchenham, “What’s up with software metrics? – A preliminary


mapping study,” Journal of Systems and Software, vol. 83, no. 1, pp. 37–
51, Jan. 2010, Elsevier Inc. doi:10.1016/j.jss.2009.06.041.

[70] R. M. Kline, “Library Example.” [Online]. Available:


http://www.cs.wcupa.edu/~rkline/java/library.html.

[71] R. Koschke, “Identifying and Removing Software Clones,” in in Software


Evolution, Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp. 15–
36. doi:10.1007/978-3-540-76440-3.

[72] P. Kuchana, Software architecture design patterns in Java. CRC Press,


2004. doi:10.1201/9780203496213.ch1.

[73] M. Lanza and S. Ducasse, “The Class Blueprint-A Visualization of the


Internal Structure of Classes,” Proc. International Conference of Object-
Oriented Programming, Systems, Languages, and Applications (OOPSLA),
2001.

[74] M. Lanza and S. Ducasse, “Polymetric views - A lightweight visual


approach to reverse engineering,” IEEE Transactions on Software
Engineering, vol. 29, no. 9, pp. 782–795, Sep. 2003.
doi:10.1109/TSE.2003.1232284.

[75] M. Lanza and R. Marinescu, Object-Oriented Metrics in Practice. Springer,


2006.

[76] J. Lee, D. Lee, D. Kim, and S. Park, “A Semantic-Based Approach for


Detecting and Decomposing God Classes,” Apr. 2012.

[77] W. Li and S. Henry, “Maintenance metrics for the object oriented


paradigm,” in [1993] Proceedings First International Software Metrics
Symposium, 1993, IEEE Comput. Soc. Press, pp. 52–60.
doi:10.1109/METRIC.1993.263801.

[78] W. Li and R. Shatnawi, “An empirical study of the bad smells and class
error probability in the post-release object-oriented system evolution,”
Journal of Systems and Software, vol. 80, no. 7, pp. 1120–1128, Jul. 2007.
doi:10.1016/j.jss.2006.10.018.

[79] R. Lincke, J. Lundberg, and W. Löwe, “Comparing software metrics tools,”


Proceedings of the 2008 international symposium on Software testing and
analysis - ISSTA ’08, p. 131, 2008, ACM Press, New York, New York,
USA. doi:10.1145/1390630.1390648.

[80] H. Liu, Z. Ma, W. Shao, and Z. Niu, “Schedule of Bad Smell Detection and
Resolution: A New Way to Save Effort,” IEEE Transactions on Software
353
References.

Engineering, vol. 38, no. 1, pp. 220–235, Jan. 2012.


doi:10.1109/TSE.2011.9.

[81] M. Lorenz and J. Kidd, Object-oriented software metrics: a practical


guide. Prentice-Hall, Inc., 1994.

[82] P. Louridas, D. Spinellis, and V. Vlachos, “Power laws in software,” ACM


Transactions on Software Engineering and Methodology, vol. 18, no. 1, pp.
1–26, Sep. 2008. doi:10.1145/1391984.1391986.

[83] I. Macia, R. Arcoverde, E. Cirilo, A. Garcia, and A. Von Staa, “Supporting


the identification of architecturally-relevant code anomalies,” 2012 28th
IEEE International Conference on Software Maintenance (ICSM), pp. 662–
665, Sep. 2012, Ieee. doi:10.1109/ICSM.2012.6405348.

[84] A. Maiga, N. Ali, N. Bhattacharya, A. Sabane, Y.-G. Guéhéneuc, and E.


Aimeur, “SMURF: A SVM-based Incremental Anti-pattern Detection
Approach,” 2012 19th Working Conference on Reverse Engineering, pp.
466–475, Oct. 2012, Ieee. doi:10.1109/WCRE.2012.56.

[85] N. Maneerat and P. Muenchaisri, “Bad-smell prediction from software


design model using machine learning techniques,” 2011 Eighth
International Joint Conference on Computer Science and Software
Engineering (JCSSE), pp. 331–336, May 2011, Ieee.
doi:10.1109/JCSSE.2011.5930143.

[86] M. V. Mäntylä, J. Vanhanen, and C. Lassenius, “Bad smells -humans as


code critics,” in 20th IEEE International Conference on Software
Maintenance, 2004. Proceedings., 2004, IEEE, pp. 399–408.
doi:10.1109/ICSM.2004.1357825.

[87] C. Marinescu, “Identification of Design Roles for the Assessment of


Design Quality in Enterprise Applications,” in 14th IEEE International
Conference on Program Comprehension (ICPC’06), 2006, IEEE, pp. 169–
180. doi:10.1109/ICPC.2006.27.

[88] C. Marinescu and R. Marinescu, “iPlasma: An integrated platform for


quality assessment of object-oriented design,” ICSM, 2005.

[89] R. Marinescu, “Measurement and Quality in Object-Oriented Design,”


2002.

[90] R. Marinescu, “Measurement and quality in object-oriented design,” in 21st


IEEE International Conference on Software Maintenance (ICSM’05),
2005, IEEE, pp. 701–704. doi:10.1109/ICSM.2005.63.

[91] R. Marinescu, “Assessing and Improving Object-Oriented Design,”


Timisoara, 2012.

354
References.

[92] R. Marinescu, “Assessing technical debt by identifying design flaws in


software systems,” IBM Journal of Research and Development, vol. 56, no.
5, p. 6261578, Sep. 2012. doi:10.1147/JRD.2012.2204512.

[93] R. Marinescu, G. Ganea, and I. Verebi, “InCode: Continuous Quality


Assessment and Improvement,” 2010 14th European Conference on
Software Maintenance and Reengineering, pp. 274–275, Mar. 2010, Ieee.
doi:10.1109/CSMR.2010.44.

[94] R. Marinescu and D. Ratiu, “Quantifying the quality of object-oriented


design: the factor-strategy model,” in 11th Working Conference on Reverse
Engineering, IEEE Comput. Soc, pp. 192–201.
doi:10.1109/WCRE.2004.31.

[95] A. Marino, “Code smell detection through machine learning techniques and
metrics analysis,” Università degli Studi di Milano-Bicocca, 2013.

[96] T. McCabe, “A complexity measure,” Software Engineering, IEEE


Transactions on, no. 4, pp. 308–320, 1976.

[97] J. McCall, P. Richards, and G. Walters, “Factors in software quality,” vol.


I, no. November, 1977.

[98] M. Media, I. Roger, and R. Joseph, Mass Media Research: An Introduction.


Cengage Learning, 1983.

[99] T. Mens and T. Tourwe, “A survey of software refactoring,” IEEE


Transactions on Software Engineering, vol. 30, no. 2, pp. 126–139, Feb.
2004. doi:10.1109/TSE.2004.1265817.

[100] P. F. Mihancea and R. Marinescu, “Towards the Optimization of Automatic


Detection of Design Flaws in Object-Oriented Software Systems,” in Ninth
European Conference on Software Maintenance and Reengineering, 2005,
IEEE, pp. 92–101. doi:10.1109/CSMR.2005.53.

[101] N. Moha, Y.-G. Guéhéneuc, L. Duchien, and A.-F. Le Meur, “DECOR: A


Method for the Specification and Detection of Code and Design Smells,”
IEEE Transactions on Software Engineering, vol. 36, no. 1, pp. 20–36, Jan.
2010. doi:10.1109/TSE.2009.50.

[102] M. J. Munro, “Product Metrics for Automatic Identification of ‘Bad Smell’


Design Problems in Java Source-Code,” in 11th IEEE International
Software Metrics Symposium (METRICS’05), 2005, no. Metrics, IEEE, pp.
15–15. doi:10.1109/METRICS.2005.38.

[103] E. Murphy-Hill and A. P. Black, “Seven habits of a highly effective smell


detector,” in Proceedings of the 2008 international workshop on
Recommendation systems for software engineering - RSSE ’08, 2008, New
York: ACM Press, p. 36. doi:10.1145/1454247.1454261.

355
References.

[104] E. Murphy-Hill, N. Carolina, and A. P. Black, “An Interactive Ambient


Visualization for Code Smells,” in 5th international symposium on
Software visualization, 2010, ACM, pp. 5–14.

[105] B. Nejmeh, “NPATH: a measure of execution path complexity and its


applications,” Communications of the ACM, vol. 31, no. 2, 1988.

[106] K. Nongpong, “Integrating ‘ Code Smells ’ Detection with Refactoring


Tool Support,” The University of Wisconsin, 2012.

[107] S. M. Olbrich, D. S. Cruzes, V. Basili, and N. Zazworka, “The evolution


and impact of code smells: A case study of two open source systems,” in
2009 3rd International Symposium on Empirical Software Engineering and
Measurement, 2009, IEEE, pp. 390–400.
doi:10.1109/ESEM.2009.5314231.

[108] S. M. Olbrich, D. S. Cruzes, and D. I. K. Sjoberg, “Are all code smells


harmful? A study of God Classes and Brain Classes in the evolution of
three open source systems,” in 2010 IEEE International Conference on
Software Maintenance, 2010, IEEE, pp. 1–10.
doi:10.1109/ICSM.2010.5609564.

[109] C. Parnin, C. Görg, and O. Nnadi, “A catalogue of lightweight


visualizations to support code smell inspection,” ACM symposium on
Software visualization, p. 77, 2008, ACM Press, New York, New York,
USA. doi:10.1145/1409720.1409733.

[110] B. Pietrzak and B. Walter, “Leveraging code smell detection with inter-
smell relations,” Extreme Programming and Agile Processes in Software
Engineering, pp. 75–84, 2006.

[111] D. Ratiu, S. Ducasse, T. Girba, and R. Marinescu, “Using history


information to improve design flaws detection,” in Eighth European
Conference on Software Maintenance and Reengineering, 2004. CSMR
2004. Proceedings., 2004, vol. 2004, IEEE, pp. 223–232.
doi:10.1109/CSMR.2004.1281423.

[112] N. M. Razali, Y. B. Wah, and M. Sciences, “Power comparisons of


Shapiro-Wilk , Kolmogorov-Smirnov , Lilliefors and Anderson-Darling
tests,” Journal of Statistical Modeling and Analytics, vol. 2, no. 1, pp. 21–
33, 2011.

[113] C. K. Roy and J. R. Cordy, “A Survey on Software Clone Detection


Research,” Queen’s University at Kingston, 2007.

[114] J. Royston, “An extension of Shapiro and Wilk’s W test for normality to
large samples,” Applied Statistics, vol. 31, no. 2, pp. 115–124, 1982.

356
References.

[115] J. Schumacher, N. Zazworka, F. Shull, C. Seaman, and M. Shaw, “Building


empirical support for automated code smell detection,” Proceedings of the
2010 ACM-IEEE International Symposium on Empirical Software
Engineering and Measurement - ESEM ’10, p. 1, 2010, ACM Press, New
York, New York, USA. doi:10.1145/1852786.1852797.

[116] S. Shapiro and M. Wilk, “An analysis of variance test for normality
(complete samples),” Biometrika, vol. 52, no. 3, pp. 591–611, 1965.

[117] R. Shatnawi and W. Li, “An investigation of bad smells in object-oriented


design,” Third Conference on Information Technology: New Generations
(ITNG 2006), pp. 161–165, 2006, Ieee. doi:10.1109/ITNG.2006.31.

[118] R. Shatnawi and W. Li, “Finding software metrics threshold values using
ROC curves,” Journal of Software Maintenance and Evolution: Research
and Practice, no. April 2009, pp. 1–16, 2010. doi:10.1002/smr.

[119] S. Singh and K. S. Kahlon, “Effectiveness of encapsulation and object-


oriented metrics to refactor code and identify error prone classes using bad
smells,” ACM SIGSOFT Software Engineering Notes, vol. 36, no. 5, p. 1,
Sep. 2011. doi:10.1145/2020976.2020994.

[120] S. Slinger, “Code Smell Detection in Eclipse Code Smell Detection in


Eclipse,” Delft University of Technology, 2005.

[121] D. Steinberg, F. Budinsky, E. Merks, and M. Paternostro, EMF: eclipse


modeling framework, 2nd ed. Addison, 2008.

[122] R. Subramanyam and M. S. Krishnan, “Empirical analysis of CK metrics


for object-oriented design complexity: implications for software defects,”
IEEE Transactions on Software Engineering, vol. 29, no. 4, pp. 297–310,
Apr. 2003. doi:10.1109/TSE.2003.1191795.

[123] J. Tappolet, C. Kiefer, and A. Bernstein, “Semantic web enabled software


analysis,” Web Semantics: Science, Services and Agents on the World Wide
Web, vol. 8, no. 2, pp. 225–240, 2010.

[124] A. Tarski, “On the calculus of relations,” The Journal of Symbolic Logic,
vol. 6, no. 3, pp. 73–89, 1941.

[125] E. Tempero, C. Anslow, J. Dietrich, T. Han, J. Li, M. Lumpe, H. Melton,


and J. Noble, “The Qualitas Corpus: A Curated Collection of Java Code for
Empirical Studies,” in 2010 Asia Pacific Software Engineering Conference,
2010, IEEE, pp. 336–345. doi:10.1109/APSEC.2010.46.

[126] A. Trifu, Towards Automated Restructuring of Object Oriented Systems.


2008.

357
References.

[127] A. Trifu and R. Marinescu, “Diagnosing Design Problems in Object


Oriented Systems,” in 12th Working Conference on Reverse Engineering
(WCRE’05), 2005, IEEE, pp. 155–164. doi:10.1109/WCRE.2005.15.

[128] N. Tsantalis, T. Chaikalis, and A. Chatzigeorgiou, “JDeodorant:


Identification and Removal of Type-Checking Bad Smells,” in 2008 12th
European Conference on Software Maintenance and Reengineering, 2008,
IEEE, pp. 329–331. doi:10.1109/CSMR.2008.4493342.

[129] A. J. Viera and J. M. Garrett, “Understanding interobserver agreement: the


kappa statistic.,” Family medicine, vol. 37, no. 5, pp. 360–3, May 2005.

[130] J. Vlissides, R. Helm, R. Johnson, and E. Gamma, Design patterns:


Elements of reusable object-oriented software. Reading: Addison-Wesley,
1995.

[131] R. Wheeldon and S. Counsell, “Power law distributions in class


relationships,” Proceedings Third IEEE International Workshop on Source
Code Analysis and Manipulation, pp. 45–54, 2005, IEEE Comput. Soc.
doi:10.1109/SCAM.2003.1238030.

[132] R. Wieman, “Anti-Pattern Scanner: An Approach to Detect Anti-Patterns


and Design Violations,” Delft University of Technology, 2011.

[133] M. Zanoni, “Data mining techniques for design pattern detection.,”


Università degli Studi di Milano-Bicocca, 2012.

[134] N. Zazworka, M. a. Shaw, F. Shull, and C. Seaman, “Investigating the


impact of design debt on software quality,” Proceeding of the 2nd working
on Managing technical debt - MTD ’11, p. 17, 2011, ACM Press, New
York, New York, USA. doi:10.1145/1985362.1985366.

[135] M. Zhang, N. Baddoo, P. Wernick, and T. Hall, “Prioritising Refactoring


using Code Bad Smells,” in Fourth International Conference on Software
Testing, Verification and Validation Workshops, 2011.
doi:10.1109/ICSTW.2011.69.

[136] M. Zhang, T. Hall, and N. Baddoo, “Code bad smells: a review of current
knowledge,” Journal of Software Maintenance and Evolution: Research
and Practice, no. October 2010, pp. 179–202, 2011. doi:10.1002/smr.

[137] Engineering statistics handbook. NIST/SEMATECH e-Handbook of


Statistical Methods, 2012.

[138] “Checkstyle.” [Online]. Available:


http://checkstyle.sourceforge.net/index.html. [Accessed: 15-Nov-2012].

[139] “Eclipse.” [Online]. Available: http://www.eclipse.org/. [Accessed: 11-


Nov-2012].
358
References.

[140] “Eclipse JDT Programmer’s Guide.” [Online]. Available:


http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%
2Fguide%2Fjdt_int.htm. [Accessed: 05-Dec-2012].

[141] “Google Scholar.” [Online]. Available: scholar.google.com. [Accessed: 07-


Mar-2013].

[142] “Hibernate.” [Online]. Available: http://www.hibernate.org/. [Accessed:


06-Dec-2012].

[143] “InFusion.” [Online]. Available:


http://www.intooitus.com/products/infusion. [Accessed: 15-Nov-2012].

[144] “Jasml The Java Assembling Language.” [Online]. Available:


http://jasml.sourceforge.net/. [Accessed: 08-Jul-2013].

[145] “Java Language Best Practices.” [Online]. Available:


http://docs.oracle.com/cd/A97688_16/generic.903/bp/java.htm. [Accessed:
26-Nov-2012].

[146] “JDeodorant.” [Online]. Available: http://www.jdeodorant.com/.


[Accessed: 16-Nov-2012].

[147] “PMD.” [Online]. Available: http://pmd.sourceforge.net/. [Accessed: 15-


Nov-2012].

[148] “ReentrantReadWriteLock.” [Online]. Available:


http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Reentra
ntReadWriteLock.html. [Accessed: 16-Jan-2013].

[149] “SAX.” [Online]. Available: http://www.saxproject.org/. [Accessed: 09-


Jul-2013].

[150] “SuanShu.” [Online]. Available: http://numericalmethod.com/suanshu/.


[Accessed: 16-May-2013].

[151] “Teneo.” [Online]. Available: http://wiki.eclipse.org/Teneo. [Accessed: 05-


Dec-2012].

[152] “The Apache Commons Mathematics Library.” [Online]. Available:


http://commons.apache.org/proper/commons-math/. [Accessed: 06-May-
2013].

359

View publication stats