reverse engineering of jasperreports with various tools

5/9/2018 Reverse Engineering of JasperReports with various tools - slidepdf.com

http://slidepdf.com/reader/full/reverse-engineering-of-jasperreports-with-various-tools 1/194

Università degli Studi di Milano–Bicocca

Facoltà di Scienze Matematiche, Fisiche e Naturali.corso di laurea in informatica

R E L A Z I O N E D I P R O G E T T O E S V I L U P P O S O F T W A R E

tool: CodeCity, Manhattan, Bauhaus, Lattix, SA4 J, X-Ray, Analyst4 j, Dude

software: JasperReports (0.x.x, 1.0.0, 2.0.0, 3.0.0, 4.0.2), Crisp

docente supervisore

Prof.ssa Francesca Arcelli

gruppo b7

Leonardo Di Donato – 744739

Francesco Sacchi – 708641

Niccolò Nobile – 709621

Riccardo Vincelli – 709588

anno accademico 2010–2011



I N T R O D U Z I O N E

Il lavoro presentato in questa relazione, nasce dall’esigenza di approfondire ilpanorama attuale dei software di reverse engineering disponibili, in particolare cisiamo concentrati su un nutrito subset formato dai seguenti otto tool: CodeCity,Manhattan, Bauhaus, Lattix, SA4 J, X-Ray, Analyst4 j e Dude .

Per valutare la qualità dei tool sotto diversi aspetti, li abbiamo usati per analiz-zare due progetti di diverse dimensioni: JasperReports, di grandi dimensioni eCrisp, una piccola applicazione mobile.

Attraverso il confronto delle conclusioni tratte singolarmente con ogni tool,siamo riusciti a dare una valutazione qualitativa e quantitativa dei softwareanalizzati oltre ad aver inquadrato pregi e difetti dei tool stessi.

Per quanto riguarda la valutazione dei tool, la loro sperimentazione ci hapermesso di evidenziarne le funzionalità e l’usabilità, ma ha anche fatto emergeremancanze e criticità.

Per una approfondita analisi del software invece, oltre ad analizzare appro-fonditamente l’ultima versione rilasciata, nel caso di JasperReports, sono stateconfrontate le cinque principali release al fine di acquisire una visione evolutivaglobale.

Le diverse analisi sono tra loro indipendenti e hanno una loro consistenza anchelette singolarmente. Trarremo infine delle conclusioni complessive sul softwaree sui tool utilizzati prendendo posizione circa i risultati forniti da ognuno e

le discrepanze emerse, considerando anche altri tool non presentati in questarelazione.

ii



I N D I C E

i analisi di jasperreports 1

1 c od ec it y 2

1.1 Analisi progettuale e programmativa 3

1.1.1 Introduzione 3

1.1.2 Livello di coesione delle classi 4

1.1.3 Analisi delle interfacce 8

1.1.4 Classi influenti 11

1.1.5 Anti-Pattern 12

1.1.6 Code Smell 24

1.1.7 Crosscutting Concerns 27

1.2 Analisi evolutiva 31

1.3 Suggerimenti per migliorare CodeCity 41

1.4 Suggerimenti per migliorare JasperReports 42

1.5 Considerazioni finali su JasperReports 43

1.6 Considerazioni finali su CodeCity 44

1.7 Dettagli tecnici 44

1.7.1 Configurazioni macchine utilizzate 44

1.7.2 Tempistiche di analisi 45

1.7.3 Installazione 46

1.7.4 Bug 46

1.7.5 Documentazione 462 ma nhatta n 48

2.1 Analisi 48

2.1.1 Analisi progettuale - Anti-Pattern 48

2.1.2 Analisi programmativa - Code Smell 50


2.3 Forward Engineering 54

2.4 Suggerimenti per migliorare Manhattan 56



2.6

.1

Tramite Manhattan59

2.7 Considerazioni finali su Manhattan 59


2.8.1 Configurazione macchina utilizzata 61



2.8.4 Bug 63

2.8.5 Documentazione 64

iii



Indice iv

3 bau hau s 65

3.1 Analisi 65



3.2 Analisi evolutiva 723.3 Suggerimenti per migliorare Bauhaus 75


3.5 Considerazioni finali Bauhaus 77






3.7.4 Analisi software java 81

3.7

.5

Bug82


4 l at ti x 85

4.1 Analisi 86

4.1.1 Premessa 86

4.1.2 Panoramica quantitativa 87

4.1.3 Il DSM del progetto JasperReports 87




4.2.1 Metriche architetturali 90

4.2.2 Metriche OO 934.3 Miglioramenti possibili 94

4.3.1 Suggerimenti per migliorare il tool 94

4.3.2 Suggerimenti per migliorare JasperReports 95


4.4.1 Tempistiche d’analisi 95


4.4.3 Bug 96


5 sa4j 97

5.1 Analisi 975.1.1 Analisi progettuale - Anti-Pattern 97



5.3 Suggerimenti per migliorare SA4 J 108



5.5.1 Tramite SA4 J 110



Indice v

5.6 Considerazioni finali su SA4 J 110




5.7.3 Installazione 1125.7.4 Bug 113


6 x-ray 115

6.1 Analisi 115




6.3 Suggerimenti per migliorare il tool 124


6.5 Considerazioni finali su JasperReports 1296.5.1 Tramite X-Ray 129

6.6 Considerazioni finali su X-Ray 130





6.7.4 Bug 134


7 dude 136

7.1 Analisi 136

7.1.1 Analisi code clones 136




7.5 Considerazioni finali su Dude 138





7.6.4 Requisiti 139

7.6.5 Bug 1397.6.6 Documentazione 140

ii analisi di crisp 141

8 a na lys t4j 142

8.1 Analisi 142





indice vi


8.3 Suggerimenti per migliorare Crisp 157

8.4 Considerazioni finali su Crisp 158

8.4.1 Tramite Analyst4 j 158

8.5 Considerazioni finali su Analyst4 j 1588.6 Dettagli tecnici 160




8.6.4 Bug 161


iii conclusioni finali 164

9 c o nc lus i oni 165

9.1 Tool analizzati 165


9.2.1 Peggioramento globale non implica peggioramenti locali 167

9.3 Considerazioni finali su Crisp 167

9.4 Considerazioni finali sui tool 167

9.4.1 Reverse: Analist4 j, X-Ray 168

9.4.2 Forward: Manhattan, Lattix 168

9.4.3 La coerenza dell’analisi: punti discordanti tra i risultati 169

9.4.4 Da rivedere: SA4 J 169

9.5 Riferimenti a tool non analizzati 170

9.6 La stesura di questo documento 171

iv appendice 172

a a ppend ic e 173

bibliography 179



E L E N CO D E L L E F I G U R E

Figura 1 LOC, NOC e NOP di JasperReports 3

Figura 2 GenericChartTheme 4

Figura 3 Bassissimo livello di coesione della classe JRViewer 5

Figura 4 Bassissimo livello di coesione delle classi JRXhtmlExporter, JRHtmlExporter, JRPdfExporter 5

Figura 5 Bassissimo livello di coesione della classe JRFillElement 6

Figura 6 Classi di dimensioni intermedie del package net.sf.jasperreports.engine

con basso livello di coesione 7

Figura 7 Altre classi di dimensioni intermedie del package net.sf.jasperreports.engine

con basso livello di coesione 7

Figura 8 Le interfacce presenti in JasperReports 8

Figura 9 Swiss Army Knife in JRStyle (CodeCity) 9

Figura 10 Una vista fine-grained di JRStyle 10

Figura 11 Analisi WNOC e NOM: classi influenti 12

Figura 12 Analisi NOAM e NLOC per Spaghetti Code 13

Figura 13 Menù “Disharmony Map” in CodeCity 14

Figura 14 God Class in CodeCity 15

Figura 15 Brain Class in CodeCity 16

Figura 16 Both God & Brain Class in CodeCity 17

Figura 17 Complessità della “Both God & Brain Class” JRApiWriter,

considerata anche una standalone class da CodeCity 18Figura 18 Complessità della “Both God & Brain Class” JRVerifier 19

Figura 19 Complessità delle “Both God & Brain Classes” del packageengine.fill 20

Figura 20 Complessità delle “Both God & Brain classes” del packageengine.fill 21

Figura 21 Complessità delle “Both God & Brain Classes” del packageengine.base 22

Figura 22 Data Class rilevate da CodeCity 23

Figura 23 God (in fucsia), Brain (in giallo), “Both God & Brain” (in

arancione) e Data Class (in viola) rilevate da CodeCity 24Figura 24 Brain Methods del package engine 25

Figura 25 Shotgun Surgery e Feature Envy rilevati da CodeCity 26

Figura 26 Analisi code smell Too Need Comments in CodeCity 27

Figura 27 Analisi FANIN per i “crosscutting concerns” e rilevazionedell’ anti-pattern Hub 29

Figura 28 Analisi FANIN per i “crosscutting concerns” e rilevazionedell’ anti-pattern Hub 30

vii



Elenco delle figure viii

Figura 29 JasperReports 0.x.x e 1.0.0 con CodeCity 32

Figura 30 Rilevazione degli anti-pattern in JasperReports con CodeCi-ty, release 0.x.x 33

Figura 31 Rilevazione degli anti-pattern in JasperReports, release 1.0.0 34

Figura 32 Data Class in JasperReports, release 1.0.0 35Figura 33 Invocazioni entranti e uscenti di JRXmlWriter in JasperRe-

ports, release 1.0.0 36


Figura 35 Anti-pattern individuati da CodeCity nel package engine.filldi JasperReports, release 2.0.0 38

Figura 36 Anti-pattern individuati da CodeCity nel package engi-ne.export di JasperReports, release 2.0.0 39


Figura 38 Nuovi package contenenti molte Data Class in JasperRe-

ports, release3

.0

.0 40

Figura 39 Interfaccia sospetta - JRStyle 49

Figura 40 Package “engine” on Orbital View 50

Figura 41 JRXmlConstants on First Person View 51

Figura 42 Evoluzione tra JasperReports versione 0.x.x e 1.0.0 52

Figura 43 JasperReports tramite Orbital View 52

Figura 44 Confronto versioni tramiter Orbital View 53

Figura 45 Evoluzione tra JasperReports versione 2.0.0 e 3.0.0 54

Figura 46 Evoluzione JasperReports versione 4.0.2 54

Figura 47 Reacting to changes 55

Figura 48 Team Activity Awareness 56

Figura 49 Tutorial di installazione 63Figura 50 Schermata di errore (n°2) 63

Figura 51 Sito ufficiale di Manhattan 64

Figura 52 Principali cicli evidenziati nel sistema 66

Figura 53 Complessità ciclomatica significativa tipica di una BrainClass 66

Figura 54 Complessità ciclomatica bassa a fronte del numero di ri-ghe 67

Figura 55 JRApiWriter 67

Figura 56 JRApiWriter Fish view 68

Figura 57 Disarmonia nella classe JRStyle 68Figura 58 Vista Element Count di JasperReports generata con Bau-haus 69

Figura 59 Metodi con più di 100 linee di codice 69

Figura 60 Metriche del metodo addChartRoules 70

Figura 61 Linee di commento rispetto a linee di codice in Bauhaus 70



Elenco delle figure ix

Figura 62 Schermata di gravis con tutti i cloni individuati ordinati pernumero di linee duplicate. Da notare la presenza di clonilunghi più di 500 linee e il numero totale di cloni elevatocome si può notare dalla barra laterale 71

Figura 63 Esempio di codice contenente definizioni di costanti dupli-cate 71

Figura 64 Conteggio degli elementi delle prime tre versioni di Jasper-Reports. Da sinistra JasperReports 1.0.0, JasperReports 2.0.0e JasperReports 3.0.0. Si nota un incremento quasi propor-zionale su tutti gli elementi: package, classi, interfacce. 72

Figura 65 Confronto del numero di linee di codice. Dall’alto JasperRe-ports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0. Non sinota una significativa variazione tra le tre versioni. 73

Figura 66 Confronto della complessità ciclomatica assoluta e rispetto

al numero di linee di codice eseguibili. Per ogni riga dall’al-to JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports3.0.0. 74

Figura 67 Confronto della presenza di cicli nelle varie versioni di JasperReports. Dall’alto JasperReports 1.0.0, JasperReports2.0.0 e JasperReports 3.0.0 75

Figura 68 Vista comparativa della correlazione tra numero di lineedi commento e numero di linee di codice di JasperRe-ports. Dall’alto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0 76

Figura 69 Errore che si presenta alla richiesta di riordinare i nodi

secondo uno specifico layout e porta alla terminazione delprogramma 83

Figura 70 Quando si cerca di aprire un package con doppio click vienemostrato questo errore perché non c’è, evidentemente, unfile di codice di definizione del package 83

Figura 71 Bauhaus fornisce un ottimo supporto alla selezione di nodie archi: permette ad esempio di aggiungere alla selezionei discendenti, archi entranti e uscenti e molte altre varianti.Si verifica però questo errore quando si sceglie l’opzioneDeselect nodes; bisogna invece scegliere Deselect all 83

Figura 72 Nei plot per la rappresentazione di informazioni metriche,impostando come assi alcuni criteri si ottiene un grafico vuo-to con gli elementi tutti spostati nella parte superiore dellafinestra. In figura il riquadro rosso segna dove dovrebbeessere il plot, notiamo che manca anche il riquadro, mentretutti gli elementi si condensano in quella riga grigia nellaparte superiore della schermata. 83

Figura 73 Focus sulla classe JRBaseFactory 89



Elenco delle figure x

Figura 74 La root DSM per ciascuna delle cinque release in ordi-ne 90

Figura 75 Metriche assortite. Si può chiedere al sistema di generaretre distinti tipi di metriche, di sistema, d’architettura ed

orientate agli oggetti 91Figura 76 La Knowledge Base ufficiale Lattix LDM - http://kb.lattix.com 96

Figura 77 Anti-pattern Summary 98

Figura 78 Tangle 99

Figura 79 Tangle 99

Figura 80 Global Hub 100

Figura 81 JasperDesign 101

Figura 82 Skeleton view 101

Figura 83 What if view 102

Figura 84 What if view- Dependency 103

Figura85

JRBaseFactory104

Figura 86 Statistics 104

Figura 87 JRApiWriter 105

Figura 88 JRExpression 105

Figura 89 JasperReports 0.x.x 106

Figura 90 JasperReports 1.0.0 106

Figura 91 JasperReports 2.0.0 & 3.0.0 107

Figura 92 JasperReports 4.0.2 108

Figura 93 Sito ufficiale di SA4 J 114

Figura 94 JRBaseFactory on System Complexity view 115

Figura 95 Anti-pattern: Swiss Army Knife / Codesmell: mancanza di

commenti 116Figura 96 Dimensioni del software target 117

Figura 97 Classe JRVerifier 118

Figura 98 Empty Catch Clause on JRClassGenerator 119

Figura 99 Package Dependency on JasperReports 0.x.x 120

Figura 100 Class Dependency on JasperReports 0.x.x 121

Figura 101 System Complexity View on JasperReports 0.x.x 122

Figura 102 Class Dependency on JasperReports 0.x.x e 1.0.0 123

Figura 103 Package Dependency on JasperReports 0.x.x & 1.0.0 124

Figura 104 Evoluzione Class Dependency 0.x.x, 1.0.0, 2.0.0, 3.0.0, 4.0.2 125

Figura 105 Evoluzione Package Dependency View 0.x.x, 1.0.0, 2.0.0,3.0.0, 4.0.2 126

Figura 106 Sito ufficiale di X-Ray 135

Figura 107 Statistics in Dude 137

Figura 108 Dude view 137

Figura 109 Sito ufficiale di Dude 140

Figura 110 Anti-pattern in Analyst4 j 143

Figura 111 Zero Encapsulation Classes 143



Figura 112 Procedure Oriented Design 144

Figura 113 Query - Analyst4 j Searches 144

Figura 114 Candidate Data Classes 144

Figura 115 Data Classes 145

Figura 116 Analysis Report 146Figura 117 QA Scope View 147

Figura 118 Metrics - Peer Comparison 147

Figura 119 Swat Index - Descendants Comparison 148

Figura 120 Too Much Documentation 148

Figura 121 Empty catch clauses 149

Figura 122 Swat Index - Descendants Comparison 150

Figura 123 Comparison Report 151

Figura 124 Notes view 151

Figura 125 Comparison Analysis 152

Figura126

NLOC vs CC152

Figura 127 Unstructuredness vs Documentation 153

Figura 128 NLOC vs NOCL 153

Figura 129 Metodo refreshDir 153

Figura 130 NLOC Vs Halstead Volume 154

Figura 131 Distribution Analysis 154

Figura 132 Cyclomatic Complexity 155

Figura 133 Essential Complexity 155

Figura 134 Lack of cohesion of methods 156

Figura 135 Inner Class 156

Figura 136 Packages Instability 157

Figura 137 Tutorial di installazione 162Figura 138 Sito ufficiale di Analyst4 j 163

Figure 139 Feature tools comparison 1 174

Figure 140 Feature tools comparison 2 175

Figure 141 Output of the tools comparison 176

Figure 142 Application field comparison 1 177

Figure 143 Application field comparison 2 178

E L E N C O D E L L E T A B E L L E

Tabella 1 Evoluzione del LOC, NOC, NOP e numero di elementi perrelease di JasperReports 31

Tabella 2 Variazioni quantitative degli anti-pattern durante l’evoluzio-ne di JasperReports 37

xi



Tabella 3 Configurazioni C-1 e C-2 su cui si è utilizzato CodeCity45

Tabella 4 Tempistiche (creazione modello e sua importazione) relativea CodeCity per la configurazione C-1 45

Tabella 5 Tempistiche (creazione modello e sua importazione) relativea CodeCity per la configurazione C-2 45

Tabella 6 Configurazione macchina utilizzata 61

Tabella 7 Tempistiche di analisi con Manhattan su JasperReports62

Tabella 8 Panoramica quantitativa 87

Tabella 9 Peso sotto-package 90

Tabella 10 Panoramica dipendenze 90

Tabella 11 Metriche Architetturali 92

Tabella 12 Metriche OO su JasperReports 93

Tabella13

Configurazione macchina utilizzata112

Tabella 14 Tempistiche di analisi con SA4 J su JasperReports 112

Tabella 15 Configurazioni macchine utilizzate 132

Tabella 16 Tabella delle tempistiche di analisi con X-Ray su JasperRe-ports con la configurazione S-1 132

Tabella 17 Tabella con le tempistiche di analisi con X-Ray su JasperRe-ports con la configurazione S-2 133



Tabella 20 Configurazione macchina utilizzata per l’utilizzo di Du-de 139

Tabella 21 Configurazione S-1 macchina utilizzata per Analyst4 j 160

Tabella 22 Tempistiche di analisi con Analyst4 J su Crisp 160

A C R O N I M I

NOM Numero di metodi

NOA Numero di attributi

LOC Numero di linee di codice

ELOC Numero di linee di codice eseguibili

NOP Numero di package

xii



acronimi xiii

NOC Numero di classi

FAMIX Famiglia di meta modelli. Il cuore di FAMIX è un meta modelloindipendente dal linguaggio che descrive la struttura statica di un sistema

software orientato agli oggettiMSE Formato di file, simile all’XML, utile a specificare modelli generali

riguardati ogni tipo di dati, indipendentemente dal meta modello. Èadottato dal software Moose come standard per l’import e l’export dimodelli

LCOM Quantifica la mancanza di coesione nei metodi

WOC Weight of class

WNOC Weighted number of children

TCC Tight class cohesion

DIT Depth of inheritance tree

NOAM Number of accesses methods

WMC Weighted methods per class

FANIN Numero di invocazioni verso un metodo (entranti)

FANOUT Numero di invocazioni da un metodo (uscenti)

WNOCmts Numero pesato di commentiWLOC Numero pesato di linee di codice



Parte IA N A L I S I D I J A S P E R R E PO R T S



1C O D E C I T Y

CodeCity è un software standalone (disponibile per tutte le piattaforme) il cui fineprincipale è l’analisi del software. Tale fine è espletato visualizzando il softwarein analisi come una città rappresentata (e navigabile) in 3 dimensioni.

Nello specifico, la metafora software - città è composta dalle seguenti conven-zioni:

• i package sono rappresentati come distretti (o quartieri) della città;

• le classi sono rappresentate come edifici (parallelepipedi con base quadrata);

più dettagliatamente:– ad un maggiore numero di metodi della classe1 corrisponde una

maggiore altezza del relativo edificio;

– ad un maggiore numero di attributi della classe2 corrisponde unamaggiore base (quadrato di area maggiore) dell’edificio;

– ad un maggiore numero di linee di codice3 della classe corrispondeuna maggiore intensità del colore del relativo edificio.

Ulteriori convenzioni sui colori vengono infine utilizzate per attirate l’attenzionesulla presenza di determinati anti-pattern nel codice del software in analisi.

CodeCity supporta l’analisi di software scritti in Java, C, C++, C# e SmallTalk.Tuttavia è necessario generare per ogni progetto il relativo modello FAMIX4

2.1, un file MSE5 creato da inFusion (versione 7.2.5, release di ottobre 2009), daimportare in CodeCity [Wettel, a].

1 Metrica: Numero di metodi (NOM)2 Metrica: Numero di attributi (NOA)3 Metrica: Numero di linee di codice (LOC)4 Famiglia di meta modelli. Il cuore di FAMIX è un meta modello indipendente dal linguaggio che

descrive la struttura statica di un sistema software orientato agli oggetti (FAMIX)5 Formato di file, simile all’XML, utile a specificare modelli generali riguardati ogni tipo di dati,

indipendentemente dal meta modello. È adottato dal software Moose come standard per l’import el’export di modelli (MSE)

2



1.1 an al i si pr og e tt ua l e e pr og r am m at i va 3

1.1 analisi progettuale e programmativa

L’analisi verrà applicata soltanto all’ultima versione di JasperReports, per riuscirea trarre delle conclusioni sul progetto.

Nella sezione 1.2, invece, verranno analizzate tutte le versioni ed evidenziato,tramite le metriche disponibili, lo svilupparsi di design issues nel progetto.

1.1.1 Introduzione

Importato il file MSE della versione 4.0.2 di JasperReports ed attesa la sua elabo-razione, CodeCity riporta 3 metriche generali sul software in analisi: LOC, NOC6,NOP7.

L’immagine seguente certifica come, nel caso di JasperReports esso possegga168.840 linee di codice, 3185 classi e 325 package.

Figura 1: LOC, NOC e NOP di JasperReports

Selezionando il sistema importato e cliccando sul pulsante “City” generiamola visualizzazione del software come città in base alla configurazione base diCodeCity: la vista “magnitude”, una vista coarse-grained, le cui caratteristichesono già state descritte nella pagina precedente.

Poichè CodeCity è molto intuitivo si procede in questo senso analizzando gli

edifici dal colore blu più intenso e quelli che spiccano per altezza. Seguendoquesto criterio è abbastanza facile individuare le classi potenzialmente affette daanti-pattern e/o code smell.

Ad esempio, nel package net.sf.jasperreports.chatthemes.spring spicca la classeGenericChartTheme, che con le sue 2289 linee di codice (LOC) e i suoi 66 metodi(NOM) è di gran lunga la classe più consistente del rispettivo package, comemostra l’immagine 2 nella pagina successiva.

6 Metrica: Numero di classi (NOC)7 Metrica: Numero di package (NOP)




Figura 2: GenericChartTheme

Passando con il mouse su questa classe, il pannello di informazioni ci avverteche essa ha un valore di NOA pari a 5: anche se CodeCity non calcola una metricamolto utile come la LCOM [Chidamber and Kemerer, 1994, Henderson-Sellers,1996] (Lack of Cohesion of Methods)8 è relativamente facile stimarla intuitivamen-te. Infatti, avendo questa classe molti metodi e pochi attributi, necessariamente,molte coppie di metodi condivideranno gli stessi attributi, portando così la LCOMad avere un valore basso, il ché significa un buon (o ottimo) livello di coesionedella classe. Questa classe, quindi, almeno a prima vista non presenta lampantiproblemi di progettazione.

Dalla sua analisi abbiamo però appreso che gli edifici che più assomigliano aun cubo (la cui base e altezza sono valori numericamente vicini) sono imputaticome rappresentativi di classi con scarsa o bassa coesione.

1.1.2 Livello di coesione delle classi

Procedendo seguendo questa direttiva si nota la classe JRViewer del packagenet.sf.jasperreports.view che ha un valore di LOC pari a 1579, NOM pari a 74 e NOApari a 66. Come appena spiegato, una situazione del genere porta inevitabilmentea sospettare che questa classe sia, con ogni probabilità, poco coesa: è infatti pocoprobabile che tutti i 74 metodi che possiede (o molti di essi) condividano tutti e66 gli attributi (o molti di essi); di conseguenza la metrica LCOM avrà un valorealto, sintomo di bassa coesione della classe. L’immagine 3 nella pagina seguenteillustra questa classe che viene rappresentata come un parallelepipedo moltovicino ad essere un cubo.

8 Metrica: Quantifica la mancanza di coesione nei metodi (LCOM)




Figura 3: Bassissimo livello di coesione della classe JRViewer

Seguendo sempre questo ragionamento procediamo individuando le ulterioriclassi affette da bassa coesione per le quali sarebbe necessario un refactoring(preceduto da una loro ristrutturazione in termini di astrazione).

Nel package net.sf.jasperreports.engine.export si rilevano ben 3 classi imputated’essere vittima di una progettazione disattenta:

1. JRXhtmlExporter, LOC: 1880, NOM: 43, NOA: 39

2. JRHtmlExporter, LOC: 2030, NOM: 47, NOA: 52

3. JRPdfExporter, LOC: 2179, NOM: 36, NOA: 32

L’immagine seguente le mostra.

Figura 4: Bassissimo livello di coesione delle classi JRXhtmlExporter, JRHtmlExporter, JRPdfExporter




Lo stesso identico discorso (riguardante la bassissima coesione) è possibilefare per la classe JRFillElement (si veda l’immagine seguente), poiché possiede 98

metodi e 85 attributi.

Figura 5: Bassissimo livello di coesione della classe JRFillElement

Relativamente a quest’argomento va detto che la versione 4.0.2 di JasperReportscontiene molte altre classi con basso livello di coesione che tuttavia hanno unvalore di LOC medio di 600, quindi relativamente basso e comunque moltominore rispetto a LOC delle classi analizzate fino ad ora. La maggior parte diesse, comunque, appartiene al package net.sf.jasperreports.engine (nello specifico isottopackage fill, design e export) ed essendo questo il package con più dipendenzeentranti, tutte queste classi si candidano a presentare anti-pattern di vario tipo.

Tramite l’utilizzo di una metrica, la TCC9, unitamente alla NOM, andiamo

ora a verificare la coesione delle altre classi di dimensioni minori presenti innet.sf.jasperreports.engine.

Come prima cosa va detto che un valore della TCC inferiore a 0.50 segnalauna classe che è stata progettata singolarmente e include comportamenti noncorrelati tra di loro e in generale eterogenei [Kang and Biemann, 1995]. Unaclasse con queste caratteristiche non modella quindi una sola entità (come invecedovrebbe sempre fare una classe) ma più concetti. Di conseguenza essa avrà moltoprobabilmente bassa coesione e anche un grado di coupling (accoppiamento)superiore al dovuto perché possiederà più gruppi di connessione in se stessa.Il caso estremo, cioè TCC = 0, indica che la maggior parte dei metodi sono

disconnessi tra di loro. In generale quindi la TCC indica la percentuale di metodiappartenenti ad una classe che sono direttamente correlati.Riguardo la coesione è bene precisare, comunque, che esistono classi ben fatte

che tuttavia hanno bassa coesione [Aivosto.com]. Considerando questo fattore ela grandezza della classe (quelle con un LOC piccolo e bassa coesione non sonoconsiderate rischiose), tramite una vista con granularità package, è stato quindi

9 Metrica: Tight class cohesion (TCC)




analizzato net.sf.jasperreports.engine. Le immagini (6 e 7) evidenziano alcune classiper cui è auspicabile un refactoring.

Figura 6: Classi di dimensioni intermedie del package net.sf.jasperreports.engine con bassolivello di coesione

Figura 7: Altre classi di dimensioni intermedie del package net.sf.jasperreports.engine con basso livello di coesione




Il fatto che una classe come JasperManager, composta da 64 metodi abbia unaTCC pari a zero sta a significare che tutti (o quasi) i suoi metodi non sonocorrelati: ciò è chiaramente dovuto ad una progettazione carente ed è necessarioprovvedere a risolvere i design issues come questo (si veda, per esempio, anche

JRExpressionCollector, con i suoi 80 metodi e TCC = 0).Partendo dal suddetto package, e in particolare dalle classi presentate più

in dettaglio, andrebbe rivista la strutturazione e dove possibile adoperato unrefactoring mirato alla loro suddivisione in classi più astratte e coerenti, affinchécorrispondano meglio ai rispettivi concetti di entità.

In ottica complessiva, comunque, il numero di classi con problemi di coesionenon è elevato, visto che JasperReports contiene totalmente oltre 3000 entità.

1.1.3 Analisi delle interfacce

Prima di passare all’analisi e alla rilevazione degli anti-pattern riconosciuti (più omeno automaticamente) da CodeCity ci soffermiamo sull’analisi delle interfacce,che rileva già il coding style degli sviluppatori di JasperReports.

Utilizzando la funzione di selezione per tipologia offertaci da CodeCity, abbia-mo quindi filtrato le classi di tipo interfaccia (il risultato è riportato evidenziatoin verde gli edifici corrispondenti a interfacce nell’immagine 8).

Figura 8: Le interfacce presenti in JasperReports

Da quest’analisi è emerso che molte interfacce, come era già facilmente intuibile,risiedono nel package net.sf.jasperreports.engine. Tuttavia è emersa anche una ten-




denza abbastanza marcata degli sviluppatori (probabilmente con una conoscenzanon aggiornata di Java [Hirondelle]) ad utilizzare le interfacce come contenitoridi costanti.

È il caso della classe ChartThemesConstant del package net.sf.jasperreports.chartthemes.spring,

corrispondente all’edifico quasi piatto nell’angolo in basso a sinistra.Un tale utilizzo delle interfacce (molto diffuso in JasperReports) è catalogabile

come una “bad practice”; esso è da evitare poiché le costanti non fanno partein alcun modo dell’interfaccia pubblica di un modulo software e quindi deiservizi che espone, mentre l’unico vantaggio che tale tecnica apporta consistenell’incorporazione delle costanti (definite nell’interfaccia) nello scope delle classiche la implementano.

Una situazione anomala si individua anche osservando l’immagine 9.

Figura 9: Swiss Army Knife in JRStyle (CodeCity)

L’edificio cerchiato corrisponde all’interfaccia JRStyle, del package net.sf.jasperreports.engine,la quale dispone di 170 metodi astratti (di cui ben 169 introdotti da lei e 1 sovra-scritto dalle sue superclassi, come mostra l’immagine 10 nella pagina seguente).Questo numero di metodi è sicuramente eccessivo e potenzialmente molto etero-geneo. In questa situazione possiamo riconoscere l’anti-pattern detto Swiss ArmyKnife (o Kitchen Sink) le cui principali conseguenze consistono in un aumentoconsiderevole della complessità, della documentazione, della difficoltà di utilizzo(le 11 classi che implementano questa interfaccia definiscono l’implementazione



1.1 analis i progettuale e programmativa 10

di 170 metodi ...), di debugging e di manutenzione. Suggeriamo perciò alcunesoluzioni (tra loro alternative) adoperabili a tal riguardo:

1. divisione dell’interfaccia per gruppi di operazioni omogenee;

2. creazione profili di utilizzo (sotto-insiemi di operazioni limitati da condizio-ni e convenzioni da soddisfare);

3. generic programming.

Figura 10: Una vista fine-grained di JRStyle

Soffermandoci su JRStyle tramite una vista fine-grained (riportata in figura10) si nota inoltre come da essa dipendano 326 classi. Questa situazione, che èchiaramente un anti-pattern, è descritta solitamente con un nome: Butterfly, cioè

un componente da cui dipendono molti altri componenti (dove la definizione dicomponente può essere intesa con diversa granularità, da package fino a classe).Si suppone, in base al nome dell’interfaccia in questione e alla sua elevatissimaeterogeneità che, nello specifico, essa sia una Global Butterfly, poiché correlata aclassi disperse in tutto il progetto e non solo nel suo package d’appartenenza.

La metrica WOC10 per JRStyle ha a un valore prossimo a 1 (valore che indica latotale dipendenza delle progetto dalla classe in questione [vedi Lanza et al., 2006,

10 Metrica: Weight of class (WOC)




pag. 89]) e ciò supporta quanto appena detto, confermando quindi che il “peso”della classe non è solo grande ma eccessivo.

Alla luce di tutto ciò è auspicabile operare, qualora possibile, la prima soluzionedi refactoring proposta in precedenza, cioè la separazione in più interfacce in

base a criteri di omogeneità.

1.1.4 Classi influenti

Per continuità con l’analisi appena eseguita su JRStyle si affronta ora un’analisi, basata sulle metriche WNOC11 e NOM offerte da CodeCity, finalizzata allavalutazione del “peso” delle classi, cioè della loro complessità.

La metrica WNOC, che calcola il numero totale di figli di una classe (in profon-dità) in modo pesato, non è sufficiente, da sola, a segnalare eventuali anomalieprogettuali: va infatti coordinata con il numero di metodi (NOM); le classi le cui

metriche rispettano la condizione WNOC 10 ∧ NOM 20 sono consideratepotenzialmente influenti [Meyer and Niere]. Seguendo questo criterio le classicandidate come influenti sono JRCloneable con WNOC 392, JRStyleContainer conWNOC 143, JRPropertiesHolder con WNOC 137 e JRCommonElement con WNOC111.

Come detto la metrica WNOC da sola non è sufficiente a identificare le classiinfluenti, perciò si è proceduto analizzando in dettaglio queste e altre classi conWNOC minore. Così facendo si è scoperto che la più influente, e quindi quellache con più urgenza va sottoposta a refactoring, è sicuramente JRCommonElement,perché oltre ad avere WNOC pari a 111 ha ben 302 sottoclassi e 70 invocazioniuscenti. A seguire, come mostra l’immagine 11 nella pagina successiva, ci sono:

• JRElement con WNOC 66, 132 sottoclassi (le quali ereditano 26 metodiciascuna, il ché comporta un’altissima influenza di JRElement su una vastagerarchia di classi) e 30 invocazioni uscenti;

• JRChartPlot con WNOC 58, 101 sottoclassi e 35 invocazioni uscenti;

JRBox con WNOC 40, 47 sottoclassi e 5 invocazioni uscenti.

11 Metrica: WOC




Figura 11: Analisi WNOC e NOM: classi influenti

Premesso che per approfondire ulteriormente quest’analisi servirebbe che Code-City fornisca la DIT12 (cosa che purtroppo non fa) per valutare la profondità dellegerarchie di classi, bisogna dire che classi come JRCommonElement, JRElementetc. etc. con un numero di classi figlie troppo elevate e un più o meno elevatonumero di metodi vanno sottoposte a refactoring in quanto al crescere del WNOCcresce il livello di riuso ma tende purtroppo ad “evaporare” l’astrazione che essedovrebbero operare. Inoltre in queste condizioni aumenta considerevolmente lapossibilità che una classe figlia non sia membro appropriato della madre. Sarebbeperciò preferibile diminuire i figli di queste classi, mantenendo soltanto quelliconsiderati legittimi, dato che al crescere del WNOC, cresce ance la quantità di

test case necessari a testare ogni classe figlia.

1.1.5 Anti-Pattern

Al fine di rilevare anomalie di tipo progettuale (anti-pattern), in particolare God,Brain e Data Class, CodeCity fornisce una vista (di tipo coarse-grained) chiamata“Disarmonies”.

Prima di utilizzare tale vista per rilevare gli anti-pattern presenti nel codicesvolgiamo una analisi basata su metrica finalizzata all’identificazione del piùcomune tra i design issues: Spaghetti Code.

La metrica utilizzata a tale scopo è la NOAM13

in congiunzione alla NLOC. LaNOAM quantifica il numero di metodi d’accesso get e set utilizzati per usare emanipolare le variabili d’istanza delle classi.

Utilizzando la configurazione di base di tipo fine-grained per il packagenet.sf.jasperreports.engine, che appare essere quello più affetto da problemi proget-

12 Metrica: Depth of inheritance tree (DIT)13 Metrica: Number of accesses methods (NOAM)




tuali, abbiamo individuato in esso principalmente 3 classi che potenzialmentecontengono Spaghetti Code, come mostra l’immagine 12:

1. JasperManager, con NOAM uguale a zero e NLOC uguale a 387

2. JRResultSetDataSource, con NOAM uguale a zero e NLOC uguale a 397

3. JRExpressionCollector, con NOAM = 2 e NLOC = 828

Figura 12: Analisi NOAM e NLOC per Spaghetti Code

Uno dei fattori indicanti la presenza di Spaghetti Code è appunto la mancanzadi metodi d’accesso get e set. Le classi individuate sono addirittura sprovvistecompletamente o quasi di tali metodi: emerge un coding style poco attento amantenere il flusso di controllo il più semplice possibile; si noti infatti tutte leclassi hanno un valore di NOAM uguale a 0 o in un suo intorno destro moltopiccolo.

Oltre al mancato utilizzo dei metodi d’accesso citati lo Spaghetti Code ha altrecaratteristiche: classi contenenti pochi metodi con vaste implementazioni e un sin-golo flusso di processo, metodi orientati ai processi spesso senza parametri, vastoutilizzo di variabili globali, scarso utilizzo dell’ereditarietà e del polimorfismo.




Esso è causato da un lavoro isolato, frettoloso e spesso senza un’accurata fasedi progettazione e revisione.

Tutto ciò si traduce in un codice con un flusso di controllo molto complesso checrea problemi di manutenibilità, estendibilità e riuso. Le soluzioni da adottare

in merito a questo anti-pattern sono: modularizzazione in base a funzionalitàe consistenza, utilizzo dei metodi d’accesso ( get e set) per le variabili d’istanza,rimozione codice inaccessibile e, più generalmente, prevenzione.

Per quanto riguarda le classi individuate, comunque, la mancanza dei metodid’accesso è un buon indizio riguardo la presenza di Spaghetti Code ma non èsufficiente per poterlo asserire con certezza. Purtroppo, mancando la possibilitàdi verificare la maggior parte delle ulteriori cause in CodeCity siamo costretti aconcludere qui quest’analisi e dedicarci alla fase successiva anticipata all’iniziodella sezione.

Ora ci dedichiamo, come anticipato, all’analisi delle disarmonie presenti in

JasperReports tramite la vista (coarse-grained) “Disarmonies” di CodeCity che,oltre a essere molto intuitiva, è molto utile: tramite un menù è possibile selezionare(e filtrare) quali anti-pattern rilevare e con quale colore segnalarli.

Figura 13: Menù “Disharmony Map” in CodeCity

Una volta selezionato l’anti-pattern da rilevare CodeCity lo identifica e notificail numero di design issues trovati.




Nel caso in analisi esso rileva 38 God Class (si veda la figura 13 nella pagina pre-cedente), la maggior parte delle quali risiede nel package net.sf.jasperreports.engine

(ma non solo) come mostrato dalla figura 14.

Figura 14: God Class in CodeCity

Riportiamo qui sotto i i package maggiormente le relative God Class (dimaggiori dimensioni):

• net.sf.jasperreports.engine: JRAbstractExplorer, JasperPrint;

• net.sf.jasperreports.engine.fill: JRBaseFiller, JRTemplatePrintText, JRTemplatePrin-

tImage, JRFillElement, JRFillFrame;

• net.sf.jasperreports.engine.design: JasperDesign, JRDesignDataset;

• net.sf.jasperreports.crosstabs.design: JRDesignCrosstab;

• net.sf.jasperreports.components.table.fill: TableReport.

Come è facile intuire anche dai nomi delle classi, molte di esse sono nate conl’intento (probabilmente non sviluppato in fase di progettazione) di implementareil pattern Mediator che è poi stato applicato male. Questa situazione è moltocomune infatti nei software sviluppati con un processo iterativo con scarsa pro-gettazione architetturale; famosa infatti è la frase con cui si identifica il (puntuale)verificarsi di anti-pattern di questo tipo: “Una classe per domarli tutti, e nel buioincatenarli” [Cunningham].

La soluzione principale da adottare in merito a queste disarmonie consistenell’identificare e raggruppare (in una nuova classe o nella loro “casa naturale”,se già esistente) le operazioni con coesione alta e ridurre l’accoppiamento.




Per quanto riguarda invece le Brain Class, che ricordiamo essere delle classi cheincorporano e accorpano moltissime funzionalità risultando avere una quantitàeccessiva “intelligenza” (che risiede nei cosiddetti Brain Methods), la quale sitraduce infine in una complessità molto elevata (caratteristica che è auspicabile

evitare se possibile); CodeCity ne identifica solo 2: JRXMLExporter, del packagenet.sf.jasperreports.engine.export, che vedremo essere molto coinvolto negli anti-pattern rilevati, e net.sf.jasperreports.swing.JRViewerPanel , evidenziate in giallonell’immagine 15.

Figura 15: Brain Class in CodeCity

Una caratteristica molto utile (chiamata “Both God & Brain Class”) di CodeCityè quella di identificare le classi catalogabili sia come God Class sia come BrainClass. Delle 38 God Class rilevate in JasperReports, 23 di esse risultano classifica-

bili anche come Brain Class (si vedano edifici arancioni presenti in figura 16 nellapagina seguente).




Figura 16: Both God & Brain Class in CodeCity

Per alcune di queste classi si è scelto di approfondire l’analisi utilizzando unaulteriore vista di CodeCity, la “Complexity View”: essa, sempre seguendo la meta-fora alla base di CodeCity, mostra gli edifici correlando la loro intensità di colorealla complessità (e la loro altezza al LOC come di consueto). Le classi imputate

sono, come sembra ormai chiaro, concentrate nel package net.sf.jasperreports.engine

e nei relativi sotto-package:

• net.sf.jasperreports.chartthemes.spring.GenericChartTheme

• net.sf.jasperreports.engine.util.JRApiWriter, la quale è considerata essere ancheuna standalone class da CodeCity (tramite lo strumento di selezione: “selectstandalone classes”); è evidenziata in figura 17 nella pagina successiva;




Figura 17: Complessità della “Both God & Brain Class” JRApiWriter, considerata anche

una standalone class da CodeCity

• net.sf.jasperreports.engine.design.JRVerifier , mostrata nella figura 18 nella pa-gina seguente, che possiede un NOM (numero di metodi) pari a 93 masoprattutto un WMC14 pari a 635. Poiché WMC è una media, questo valoreindica che, non potendo essere tutti (o comunque la maggior parte) deimetodi mediamente così complessi, essa possiede uno (o pochi) metodi concomplessità spropositata (che causano l’innalzarsi a tale livello della WMC).Pare palese che questa classe vada immediatamente riprogettata dividendoe proceduralizzando i metodi complessi o adoperando soluzioni alternative

che ne diminuiscano la complessità totale risultante.

14 Metrica: Weighted methods per class (WMC)




Figura 18: Complessità della “Both God & Brain Class” JRVerifier

• il package net.sf.jasperreports.engine.util.fill , come a questo punto era imma-ginabile, contiene molte classi catalogate come “Both & God Classes” daCodeCity; l’immagine 19 nella pagina successiva conferma quanto appena

asserito;




Figura 19: Complessità delle “Both God & Brain Classes” del package engine.fill

• il package net.sf.jasperreports.engine.util.export, come il precedente, risultaessere critico dal punto di vista della complessità; esso contiene infattimolte classi con elevata complessità ( JRHtmlExporter, JRXHtmlExporter, JR-

DocExporter, JRPptxExporter, JRExecApiExporter, JRPdfExporter) come mostral’immagine 20 nella pagina seguente che, inoltre, hanno tutte un bassolivello di coesione;




Figura 20: Complessità delle “Both God & Brain classes” del package engine.fill

• anche il package net.sf.jasperreports.engine.base infine, come mostrato dallafigura 21 nella pagina successiva, presenta “Both God & Brain Class” chechiaramente hanno complessità elevatissima.




Figura 21: Complessità delle “Both God & Brain Classes” del package engine.base

Per quanto riguarda le Data Class, invece, CodeCity rileva ben 83 classi (non

di grosse dimensioni) che presentano quest’anomalia (l’immagine 22 nella pa-gina seguente presenta una panoramica sulle Data Class rilevate da CodeCityevidenziandole in rosso).




Figura 22: Data Class rilevate da CodeCity

Esse sono classi composte principalmente da attributi, metodi get e set ad essirelativi e nulla o poco altro; tali classi sono dei contenitori stupidi di dati che nellamaggior parte dei casi sono manipolate (in dettaglio) da tantissime altre classi.Infatti esse hanno il solo compito di aggregare dati (o metodi di accesso ai dati)senza effettuare alcuna operazione; ciò fa sì che vengano “sfruttate” da molte altreclassi che dipendono così da essa. Tale situazione presenta una similitudine conquella causata dall’anti-pattern Butterfly: tutte le classi che la utilizzano, infatti,dovranno essere riviste in uno scenario di refactoring in cui si cambi la Data Class.Questa situazione è accettabile solo nel caso in cui la classe da cui dipendono

molte altre classi è una semplice classe di utility o un’interfaccia (e non è questoil caso).Relativamente a questo argomento bisogna notare infine che la classe Chart-

ThemesConstants, di cui abbiamo già parlato in precedenza a pagina 8, non vienerilevata come una Data Class da CodeCity poiché essa è un’interfaccia. In realtà,essa possiede molte delle caratteristiche utili ad essere definita una Data Class.

L’immagine nella pagina seguente presenta infine una visione completa di JasperReports e di tutti le God, Brain, God & Brain e Data Class rilevate. Ad onordel vero va notato infine, che il progetto in analisi contiene piccole percentuali(inferiori allo 0,5%) di classi affette da questi anti-pattern e, per quanto alcune diesse possano essere considerate meritevoli di un refactoring urgente, la situazionecomplessivamente non è affatto grave.




Figura 23: God (in fucsia), Brain (in giallo), “Both God & Brain” (in arancione) e DataClass (in viola) rilevate da CodeCity

1.1.6 Code Smell

CodeCity fornisce inoltre la possibilità di rilevare varie disarmonie presenti alivello dei metodi delle classi focalizzando la vista “Disarmonies Map” sui metodi.Utilizzando questa feature abbiamo potuto effettuare un’analisi finalizzata allarilevazione di vari code smell: Brain Methods, Feature Envy, Shotgun Surgery,Intensive e Dispersed Coupling.

Si è proceduto, per dare continuità all’analisi, focalizzando l’attenzione sui BrainMethods, i quali sono strettamente correlati con le Brain Class (e le “Both God &Brain Class”) poiché sono metodi che tendono a raccogliere tutte le funzionalitàdella classe. L’analisi in questione ha confermato quanto osservato fin’ora, cioèche il package net.sf.jasperreports.engine.base (si veda la discussione sulle relative

classi catalogate come “Both God & Brain Class” a pagina 20) contiene moltiBrain Methods rispetto agli altri package come mostra l’immagine 24 nella paginaseguente.




Figura 24: Brain Methods del package engine

In ottica globale bisogna comunque osservare, come già sottolineato, che, datala dimensione di JasperReports essi non sono in quantità troppo elevata.

Stesso discorso è possibile fare sia per i 70 metodi etichettati come IntensiveCoupling, cioè i metodi legati a molte altre operazioni localizzate tuttavia inpoche classi del sistema, sia per i 65 metodi etichettati come Dispersed Coupling,cioè i metodi legati a molte operazioni relative a molte classi disperse nel sistema(si vedano quadratini rosa nell’immagine 32).

CodeCity rileva, invece, ben 458 metodi catalogabili come Shotgun Surgery,cioè metodi che, se modificati, comportano un propagarsi vasto delle modificheche porta a dover modificare molte altre porzioni di codice disperse nel progetto:

essi risiedono principalmente nel package net.sf.jasperreports.engine.fill, e particolar-mente nella classe JRLineBox come mostra l’immagine 25 nella pagina successivaevidenziandoli in marrone.




Questa appena descritta è chiaramente una situazione che andrebbe evitata perquestioni di manutenibilità del sistema (ne consegue che il suddetto package èpoco manutenibile) e perciò andrebbe operato un refactoring spostando i metodiin questione e gli attributi ad essi relativi. Si ricorda inoltre che la presenza di

questo code smell è spesso correlata alla presenza anche al cosiddetto ParallelInheritance Hierarchies, un code smell che descrive la spiacevole situazionein cui, ogni volta che si specializza una classe, si è costretti, parallelamente, aspecializzarne un’altra.

Figura 25: Shotgun Surgery e Feature Envy rilevati da CodeCity

Per quanto riguarda le Feature Envy, cioè metodi che effettuano troppe chiama-te verso altre classi al fine di ottenere dati o funzionalità, CodeCity rileva 1191

metodi che presentano tale code smell; essi risiedono principalmente nel packagenet.sf.jasperreports.engine.fill e secondariamente in net.sf.jasperreports.engine.export ,come immaginabile. L’immagine 25 evidenzia in viola i metodi affetti da Feature

Envy. Essendo essi in quantità elevata andrebbe adoperato un refactoring prin-cipalmente estraendo i metodi (e i relativi attributi) che chiamano, spostandolinella classe del metodo affetto da Feature Envy.

Infine, si è utilizzata una metrica, WNOCmts15, per valutare la presenza o l’as-senza di code smell quali Too Need Comments tramite una vista delle metrichea livello di package. Utilizzando tale metrica (si veda figura 26) in congiunzio-

15 Metrica: Numero pesato di commenti (WNOCmts)




ne con WLOC16 ci si individuano alcune classi affette da questo code smell:ElementDecorator, con WNOCmts pari a 1 e WLOC pari a 161, del packagenet.sf.jasperreports.engine e JRAbstractExporter.ParameterOverrideResolver e JRAbstrac-

tExporter.ParameterOverriddenResolver entrambi con WNOCmts uguale a 0 e WLOC

rispettivamente 136 e 164. Bisogna notare che queste 2 classi sono inner class equindi il code smell è meno significativo in quanto si suppone che i commentisiano presenti nella classe che li contenere, JRAbstractExporter.

Figura 26: Analisi code smell Too Need Comments in CodeCity

1.1.7 Crosscutting Concerns

Una importante e attuale direzione di ricerca nel campo dell’ingegneria del soft-ware è la cosiddetta “crosscutting concerns” (letteralmente “problemi trasversali”),cioè un area a cui afferiscono aspetti come la gestione degli errori o come il tracing;aspetti intrinsecamente difficili da modularizzare.

Solo per completezza si fa presente che la ricerca in questo campo ha dato luogo,come soluzione, all’utilizzo di paradigmi di programmazione aspect-oriented incui le tecniche di generazione del codice sono utilizzate per affrontare questioniche interessano trasversalmente il codice.

Relativamente a tale ambito, una configurazione poco esplorata (ma molto utile)di CodeCity è la vista chiamata “fanInOut”. Questa vista prende il nome dalle2 principali metriche, FANIN17 e FANOUT18 appunto, tramite le quali presenta(sempre secondo la famosa metafora della città) le classi del progetto con criticitàtrasversali (che causano relazioni entranti e/o uscenti fra classi).

16 Metrica: Numero pesato di linee di codice (WLOC)17 Metrica: Numero di invocazioni verso un metodo (entranti) (FANIN)18 Metrica: Numero di invocazioni da un metodo (uscenti) (FANOUT)




L’analisi FANIN è appunto finalizzata a individuare i “crosscutting concerns”,la cui implementazione, che consiste in (molte) chiamate di metodi si sparge suun gran numero di elementi. I “crosscutting concerns” si verificano spesso inmoduli di tracing e/o logging, così come in moduli che usano e abusano della

notifica di eventi, della gestione degli errori e di wrapping. In tutti questi casi(e altri non citati) la funzionalità trasversale è tipicamente implementata da unmetodo che viene poi invocato da un gran numero di classi esterne (si configuraquindi la presenza di un anti-pattern).

La metrica FANIN per un metodo (o una classe, aggregando i vari FANIN deisingoli metodi) corrisponde quindi al numero di invocazioni verso un metodo.I metodi che realizzano funzionalità trasversali quindi (dette anche “seeds”)posseggono un alto valore della metrica FANIN poiché vengono chiamati damolte classi, spesso sparse, alle quali in letteratura ci si riferisce anche con iltermine “candidate-seeds”.

L’analisi, brevemente, consiste nell’indagare i “candidati-seeds” usando comelinea guida le relazioni fra le classi e accettarle o meno come tali. La situazionedesiderabile, in generale, è che una classe che possieda un alto FANIN possiedanecessariamente, allo stesso tempo, un basso FANOUT cosicché non presentiun anti-pattern di tipo Hub (situazione che si verifica se il FANOUT, in questocontesto, ha un valore medio) [vedi Caserta and Zendra, 2010]. Si noti comunqueche le classi con un alto FANIN sono candidate a presentare un anti-pattern ditipo Butterfly, mentre quelle con alto FANOUT sono candidate a presentare unanti-pattern di tipo Breakable.

Riguardo questa analisi, la suddetta vista di CodeCity è d’aiuto grazie all’intui-tività con la quale riesce a rendere e far percepire i concetti appena esposti e le

conseguenti situazioni che presentano design issues: i parallelepipedi molto strettiche si sviluppano in verticale (e hanno un colore rosso) identificano la presenzadi un FANOUT elevato mentre quelli più sviluppati in larghezza (che hannocolore blu) identificano la presenza di un FANIN elevato. Combinando le dueinformazioni ne deriva che i parallelepipedi (con colore più o meno tendente alviola) che tendono ad una forma cubitale segnalano la presenza di un anti-patterndi tipo Hub.




Figura 27: Analisi FANIN per i “crosscutting concerns” e rilevazione dell’ anti-patternHub

Per quanto riguarda l’anti-pattern Breakable, l’immagine 27 evidenzia cometali le seguenti classi (in verde):

• JRApiWriter, JRXmlWriter (del package net.sf.jasperreports.engine.fill) avendoesse rispettivamente FANOUT pari a 129 e 111 con FANIN pari rispettiva-mente a 2 e 13;

• net.sf.jasperreports.view.JRViewer (di cui abbiamo parlato a pagina 4) conFANOUT pari a 84 e FANIN pari a 5;

• net.sf.jasperreports.chatthemes.spring.GenericChartTheme (di cui abbiamo parla-to a pagina 17) con FANOUT pari a 192 e FANIN pari a 2.




Figura 28: Analisi FANIN per i “crosscutting concerns” e rilevazione dell’ anti-patternHub

Per quanto riguarda invece l’anti-pattern Hub, l’immagine 28 evidenzia cometali le seguenti classi (in verde):

• net.sf.jasperreports.engine.design.JRVerifier (di cui abbiamo già parlato a pagi-na 18) con FANIN = 32 e FANOUT = 84;

• net.sf.jasperreports.engine.JRExpressionCollector (della quale abbiamo già di-scusso in merito all’anti-pattern Spaghetti Code a pagina 12) con FANIN =92 e FANOUT = 72;

• JRBaseObjectFactory con FANIN = 45 e FANOUT = 85;

• net.sf.jasperreports.engine.JRAbstractExplorer (a cui ci siamo già riferiti comeGod Class a pagina 15) con FANIN = 94 e FANOUT = 45.

I valori delle metriche analizzate ci dicono che gli Hub JRVerifier e JRExpressionCol-

lector esigono un refactoring chiaramente più urgente rispetto a JRBaseObjectFacto-

ry e JRAbstractExplorer (che hanno un FANIN minore ma un altissimo FANOUT,indice della loro tendenza a essere Breakable).

Va notato infine che, complessivamente, ad esclusione di una classe (si notiil parallelepipedo blu che si estende in larghezza, più o meno al centro delleimmagini), JasperReports non presenta classi con elevatissimi valori di FANIN:questo, come è facilmente intuibile, è un buon segnale riguardo la presenza dipochi anti-pattern di tipo Butterfly.



1.2 a na li si e vo lu ti va 31

1.2 a na lis i evo luti va

CodeCity permette la visualizzazione incrementale dell’evoluzione del softwarenelle sue varie release (si noti comunque che per far ciò è necessario creare un

modello FAMIX 2.1 per ognuna delle release), feature molto utile per valutare co-me il software è stato progettato e sviluppato iterativamente, e a quali operazionidi refactoring è stato sottoposto.

La tabella 1 mostra innanzitutto l’evoluzione dal punto di vista quantitativodel numero di linee di codice, di classi, di package e di elementi parallelamenteal rilascio delle versioni 0.x.x, 1.0.0, 2.0.0, 3.0.0 e 4.0.2 di JasperReports. Da essasi nota come la maggior evoluzione del software target è avvenuta al rilasciodella release 1.0.0 dove le dimensioni LOC, NOC e NOP di JasperReports, prece-dentemente molto modeste, si sono quasi settuplicate; con la successiva releaseinvece l’incremento è consistito approssimativamente in un raddoppiamento delle

linee di codice, del numero di elementi e del numero di classi e un incrementosostanziale del numero di packages; tra la release 2.0.0 e la 3.0.0 non si segnalanoincrementi di tali entità, contrariamente invece a quanto si può riscontrare con larelease 4.0.2 dove le dimensioni sono nuovamente raddoppiate.

release loc noc nop numero elementi

0.x.x 7.659 235 37 6.929

1.0.0 48.556 1.163 146 44.290

2.0.0 94.875 1.962 203 98.535

3.0.0 107.795 2.161 226 113.409

4.0.2 168.840 3.185 325 187.793

Tabella 1: Evoluzione del LOC, NOC, NOP e numero di elementi per release di JasperReports




Si procede ora all’analisi dell’evoluzione del software fra la versione 0.x.x e la1.0.0.

L’immagine 29 mostra come CodeCity rappresenta, tramite la nota metafora,gli elementi di JasperReports in queste 2 release.

Figura 29: JasperReports 0.x.x e 1.0.0 con CodeCity

L’immagine relativa alla versione 0.x.x mostra la presenza di una classe, Jasper-

Report, del package net.sf.jasperreports.engine molto più consistente rispetto allealtre presenti. Si suppone da ciò che essa presenti qualche anomalia.

Infatti tale supposizione viene confermata dalla successiva analisi sugli anti-

pattern la quale (come è possibile notare nell’immagine 30 nella pagina seguente)la identifica come una God Class, insieme a altre 3 God Class (parallelepipediarancioni) che sono tuttavia di dimensioni (LOC) modestissime. Inoltre tale analisinotifica la mancanza di Brain Class (informazione prevedibile viste le dimensionidi JasperReports nella versione 0.x.x) ma, al tempo stesso, la presenza, precisa-mente nel package net.sf.jasperreports.engine, di ben 10 Data Class (parallelepipediviola).




Figura 30: Rilevazione degli anti-pattern in JasperReports con CodeCity, release 0.x.x

Ciò significa che in generale, almeno in questa fase, il software in analisi hatendenzialmente un altissimo accoppiamento poiché molte classi (ad esclusionechiaramente delle God Class suddette) sono classi che non forniscono alcunafunzionalità concreta ma fungono esclusivamente da contenitori di dati chevengono utilizzati da poche altre classi (presumibilmente le God Class).

Nella release successiva, la 1.0.0, JasperReports oltre a subire un incremento




notevolissimo delle dimensioni è stato sicuramente sottoposto ad un primorefactoring mirato esclusivamente alla classe JasperReport. Essa infatti risulta nonessere più identificata come una God Class e risulta possedere un valore di LOCminore nonché una maggiore coesione.

Complessivamente, JasperReports 1.0.0, dal punto di vista delle anomalieprogettuali sembra essere rimasto quantitativamente costante, ad esclusione delleData Class.

Figura 31: Rilevazione degli anti-pattern in JasperReports, release 1.0.0

Quanto appena affermato è supportato dai seguenti dati (nonché dall’immaginenella pagina successiva); CodeCity rileva:

• 14 God Class (1,20% sul totale delle classi) rispetto alle 4 rilevate allarelease precedente (corrispondenti al 1,73% sul totale delle classi), tra lequali JRBaseFont del package net.sf.jasperreports.engine.base, JRFillChart e JRFillText del package net.sf.jasperreports.engine.fill;

• 1 Brain Class rispetto alle 0 rilevate precedentemente;




• 3 “Both God & Brain Class” rispetto alle 0 rilevate precedentemente: JRPd-

fExporter, del package net.sf.jasperreports.engine.export, JasperDesign, JRViewere JRDesignViewer del package net.sf.jasperreports.view;

• ben 64 Data Class (corrispondenti al 5,50% delle classi) rispetto alle 10 (il4,25% delle classi) rilevate nella versione precedente, come mostra l’immagi-ne 32.

Figura 32: Data Class in JasperReports, release 1.0.0

Il lieve peggioramento relativo esclusivamente al leggero incremento del nu-mero di Data Class fa intuire che, tendenzialmente, il team di sviluppo, oltre asvolgere una fase di progettazione probabilmente frettolosa, ha un coding style cheabitualmente fa un utilizzo marcato di classi “stupide” che fungano da semplicicontenitori di dati non tenendo in considerazione i risvolti negativi che ciò com-porta (ad esempio: il forte accoppiamento). Un esempio palese di quanto appena

detto è la Data Class JRXmlWriter (di dimensioni notevoli, LOC = 2230). Essapresenta un gran numero (che non è stato possibile identificare poiché non fornitoda CodeCity) di invocazioni sia entranti che uscenti da e verso praticamente tuttoil progetto attuale ad esclusione del package net.sf.jasperreports.view come attestal’immagine 33 nella pagina seguente.




Figura 33: Invocazioni entranti e uscenti di JRXmlWriter in JasperReports, release 1.0.0

Procedendo come fatto per l’evoluzione di JasperReports dalla release 0.x.xalla release 1.0.0 si affronta ora l’analisi dell’evoluzione del software in questionerelativamente alle successive release. La tabella 2 riporta tutti i dati relativi aglianti-pattern rilevati da CodeCity nelle release analizzate sintetizzando quantomostreremo di seguito.




r el ea se g od c la ss b ra in c la ss b ot h g od & br ai n c la ss d ata c las s

0.x.x 4 (1.73%) 0 0 10 (4.25%)

1.0.0 14 (1.20%) 1 (0.09%) 3 (0.26%) 64 (5.50%)

2.0.0 34 (2.92%) 0 14 (0.71%) 98 (4.99%)3.0.0 22 (1.01%) 0 16 (0.74%) 80 (3.70%)

4.0.2 38 (1.19%) 2 (0.06%) 23 (0.72%) 83 (2.61%)

Tabella 2: Variazioni quantitative degli anti-pattern durante l’evoluzione di JasperReports

La release 2.0.0 del software in analisi, che si riporta graficamente in figura 34,presenta un aumento consistente rispetto alla release precedente sia del numerodi God Class sia del numero “Both God & Brain Class”, per quanto esse sianocomplessivamente poche (si vedano percentuali in tabella 2); al tempo stessoquesta release presenta una leggera diminuzione, in percentuale, del numero diData Class.





Figura 35: Anti-pattern individuati da CodeCity nel package engine.fill di JasperReports,release 2.0.0

Con il rilascio di questa versione di JasperReports vediamo quindi comparirenuove classi affette da anti-pattern, quali, ad esempio:

• JRDesignCrosstab del package net.sf.jasperreports.crosstabs.design , classificatacome una nuova God Class;

• JRVerifier del package net.sf.jasperreports.engine.design, classificata come “BothGod & Brain Class”;

• JRXmlWriter del package net.sf.jasperreports.engine.xml, che da essere catalo-gata come Data Class nella release precedente viene ora catalogata come“Both God & Brain Class”;

• CrossTabFiller e JRFillChart (NOM = 150, NOA = 17, LOC = 1919) del packagenet.sf.jasperreports.engine.fill , nel quale si registra, in generale una prolifera-zione di God Class, come mostrato in figura 35;

• JRRtfExporter, JExcelApiExporter e JRHtmlExporter del nuovo packagenet.sf.jasperreports.engine.export relativamente al quale si registra una proli-ferazione di “Both God & Brain Class”, come mostrato in figura 36 nellapagina seguente. Si noti comunque che questo package è appena nato e di-venterà ben presto, come abbiamo visto per l’ultima release, la 4.0.2, quello,insieme al suddetto, maggiormente affetto da design issues.




Figura 36: Anti-pattern individuati da CodeCity nel package engine.export di JasperReports, release 2.0.0

Si noti infine che questa release presenta un livello di coesione tendenzialmente basso, tuttavia questo non costituisce motivo di preoccupazione considerando la

dimensione generalmente medio-piccola delle classi di JasperReports relase 2.0.0.Nella versione successiva di JasperReports, la 3.0.0, si nota un diminuzioneconsistente sia nel numero di God Class, sia nel numero di Data Class (si veda latabella 2 a pagina 37). Presumibilmente, a partire da questa versione del software,il team di sviluppo ha operato importanti operazioni di refactoring contempora-neamente ad una migliore progettazione e implementazione delle nuove feature.L’immagine 37 nella pagina seguente mostra la panoramica che CodeCity offrerelativamente agli anti-pattern presenti in questa release di JasperReports.

Comunque, anche nella versione 3.0.0 continuano a persistere alcune anomalieprogettative, in particolare God Class, presenti nei soliti package: è il caso dellaclassi JRFillChart, JRViewer, JRDesignCrosstab, JasperDesign, JRXmlWriter, JRVerifier

che rimangono praticamente invariate anche se necessiterebbero di un refactoring.Al contempo, in un quadro generale abbastanza buono, come già detto, emergonotuttavia nuove classi che presentano design issues: è il caso di JRAbstractExporter

e di 2 nuovi package, net.sf.jasperreports.charts.fill e net.sf.jasperreports.charts.base,composti pressappoco solo da classi catalogabili come Data Class, come mostratoin figura 38 nella pagina successiva.





Figura 38: Nuovi package contenenti molte Data Class in JasperReports, release 3.0.0

Con l’avvento dell’ultima relase di JasperReports, che è già stata oggetto diun’analisi progettuale e programmativa più approfondita, notiamo in generaleuna diminuzione consistente delle classi catalogate come Data Class (si veda la



1.3 s u gg e ri m en t i p e r m i gl i or a re c o de c it y 41

tabella 2 a pagina 37) anche se queste rimangono di gran lunga gli anti-patternpiù comuni in JasperReports.

1.3 suggerimenti per migliorare codecity

CodeCity è un tool di software analysis molto intuitivo (soprattutto per le fun-zionalità di base) e utile. La metafora che porta a rappresentare gli elementisoftware come distretti ed edifici è la chiave di CodeCity e si è rilevata essere unavisualizzazione vincente del software, almeno dal punto di vista della compren-sione iniziale e superficiale del software e della scalabilità dei dati rappresentati.La capacità inoltre di CodeCity di rilevare ed evidenziare automaticamente glianti-pattern e i code smell che individua lo rende un tool di ottimo livello.

Tuttavia, scendendo più in dettaglio e volendolo utilizzare per un’analisi delsoftware più approfondita, si incontrano alcune difficoltà, dovute principalmente

alla mancanza di reale documentazione, e la facilità di comprensione e accessoalle feature che offre diminuisce drasticamente.Elenchiamo di seguito alcune carenze individuate in CodeCity e le rispettive

misure migliorative che sarebbe possibile attuare.

• il processo per la visualizzazione del codice sorgente è molto macchinoso,infatti è necessario linkare il modello famix 2.1 al codice sorgente seguendoi seguenti passi: creare una cartella src all’interno della folder da cui siesegue CodeCity; copiare dentro la cartella appena creata quella sottomessaa inFusion per creare il file .mse; assicurarsi che il nome della cartella appenacopiata corrisponda al nome del modello importato in CodeCity

– questa carenza è dovuta a come il processo di import di un progetto inCodeCity è stato concepito, cioè basato sul modello FAMIX 2.1: questoè uno degli aspetti più fastidiosi e carenti di CodeCity, anche perché ilsoftware che va utilizzato per generare il file .mse, cioè inFusion, nonè stabile quanto lo è CodeCity. Per proporre una soluzione andrebberipensato l’intera fase di import del software poiché al momento risultadifficile identificare una soluzione alternativa e più comoda a quellaattuale stante il corrente processo di import.

• CodeCity come visto rileva automaticamente gli anti-pattern evidenziandoli

con vari colori ma non elenca i nomi delle classi coinvolte:– sarebbe utile, per progetti di medie e grosse dimensioni, presentare la

lista dei nomi delle classi per le quali CodeCity rileva la presenza diun anti-pattern.

• è difficile accedere a viste più raffinate e al pannello per l’esplorazione deivalori delle metriche relativamente alle classi di un package



1.4 s u gg e ri m en t i p e r m i gl i or a re j as pe r re p or t s 42

– questa carenza sarebbe limata se CodeCity fosse meglio documentatoe ancor di più, se il pannello per la configurazione di nuove viste e lascelta delle viste predefinite fosse più accessibile e intuitivo.

• gli edifici vengono disegnati solo in base alle correlazioni con gli elementidel loro stesso package: ciò significa che l’intensità (ma stesso discorsovale anche per le altre viste e metriche utilizzabili) di ogni edificio, cioè ilvalore di LOC, è relativo esclusivamente al package cui appartiene; questocomporta che non si possa avere una vista complessiva del sistema

– qualora venisse implementata la rappresentazione degli edifici correlataall’intero progetto e non al singolo package sarebbe ideale renderecommutabili le due rappresentazioni.

• CodeCity pecca nella rilevazione delle Brain Class poiché basa tale decisioneesclusivamente sulla complessità:

– sarebbe utile basare la rilevazione di questo anti-pattern su ulterioriparametri (ad esempio, il numero di global e local dependencies).

1.4 suggerimenti per migliorare jasperreports

Come già anticipato più volte durante la trattazione fin qui effettuata, JasperRe-ports è un software di medie dimensioni (3185 classi e 325 package) nel complesso ben progettato e sviluppato. La versione 4.0.2, in particolare, come specificatodurante l’analisi evolutiva (si veda pagina 31), mostra un netto miglioramento del

software in termini di quantità di design issues; d’altronde tale tendenza si erapercepita già analizzando la versione 3.0.0 notificando una drastica diminuzionedelle classi catalogabili come Data Class.

Ciò nonostante, come è normale che sia, in particolare i già citati packagenet.sf.jasperreports.engine.fill e net.sf.jasperreports.engine.export e altri elementi adessi correlati come, ad esempio, alcune classi del package net.sf.jasperreports.charts,net.sf.jasperreports.crosstabs, net.sf.jasperreports.engine.design e net.sf.jasperreports.view

risultano essere affette da anomalie progettuali. Queste anomalie comunque nonsuperano, tranne che per quanto riguarda le Data Class, la soglia del 3%.

Perciò, al fine di migliorare ulteriormente JasperReports, la priorità è procedereevitando di utilizzare le classi come contenitori e fornitori di metodi d’accesso

ai dati, affinché diminuiscano le classi affette da anti-pattern Data Class e, possibilmente, migliorando l’attuale coding style che fa spesso un uso improprio delleinterfacce (le quali vengono spesso utilizzate come contenitori di costanti, comegià ampiamente trattato a partire da pagina 8).

In seconda fase sarebbe auspicabile rivedere le classi (e le interfacce) con bassa coesione riprogettandole raggruppando le operazioni tra loro coerenti;documentare il codice che, come detto, risulta in alcuni casi totalmente (o quasi)sprovvisto di commenti e evitare alberi di gerarchie d’ereditarietà troppo profondi,



1.5 c o ns i de r az i on i f i na l i s u j as pe r re p or t s 43

soprattutto quando nei nodi più in alto dell’albero, come capita in un casoin JasperReports, una superclasse astratta (e/o un interfaccia) ha un numeroelevatissimo di metodi: questo è chiaramente un aspetto invalidante per il livellodi manutenibilità e estendibilità del software.

In ultima fase bisognerebbe agire sui package sopracitati adoperando un refac-toring mirato in primis sulle classi affette da anti-pattern God Class, Brain Class e“Both God & Brain Class”, per le quali va adoperato un refactoring guidato dalcompromesso tra alta coesione e basso accoppiamento, cercando anche, possi-

bilmente, di mantenere la complessità ciclomatica a livelli più bassi laddove sisono segnalati metodi affetti da code smell Brain Method. Per quanto riguardainvece le classi che si sono rivelate essere affette da anti-pattern Spaghetti Code siconsiglia una loro re-ingegnerizzazione (con maggior modularizzazione basatasu consistenza e sulle funzionalità) e l’adozione di un coding style più attento cheprevenga il verificarsi di tali situazioni.

Infine, soprattutto in ottica evolutiva, vanno tenuti d’occhio i “crosscuttingconcerns”: si è riscontrato (si veda la relativa sezione a pagina 27 per maggioridettagli) da questo punto di vista l’emergere di alcuni anti-pattern di tipo Hub oBreakable su classi rilevanti soprattutto nell’ultima versione di JasperReports; è

bene perciò che si adottino contromisure finalizzate alla riduzione (o meglio alladecentralizzazione) delle dipendenze entranti e uscenti.

1.5 considerazioni finali su jasperreports

Analizzando JasperReports con CodeCity abbiamo potuto notare come con ilpassare del tempo esso sia passato da essere un progetto “amatoriale”, sia intermini di dimensioni sia in termini di qualità del software, ad essere un progettodi medie dimensioni complessivamente ben strutturato.

Questa inversione di tendenza (o, se vogliamo, semplice cambio di rotta) lasi riscontra con il rilascio della versione 2.0.0 e 3.0.0. Precedentemente a questeversioni invece si è constatato come mancasse una fase di progettazione benfatta e le nuove feature venissero implementate in poche classi che divenivanoquindi sempre più affette da (vari) anti-pattern. Come detto, però, successiva-mente, parallelamente all’introduzione di nuove feature è stata adoperata unariorganizzazione concettuale e logica del progetto e contemporaneamente è statoadoperato un refactoring (per quanto esso non sia stato ancora completato): le

classi che nelle prime release erano il fulcro del software divengono man manodelle entità minori, seppur presenti; i package iniziali con il passare del tempovengono riposizionati e poi ampliati.

Gli anti-pattern e i code smell presenti costituiscono solo una piccola percentua-le dell’intero progetto (circa 1% ad esclusione delle Data Class che costituisconoil 3% di tutte le classi) e perciò non intaccano significativamente la qualità dellaprogettazione e implementazione sottostanti JasperReports. Alcune tendenze ri-scontrate nel software, dovute al coding style degli sviluppatori, quali ad esempio



1.6 c on si de ra zi on i f ina li s u c od ec it y 44

l’utilizzo delle interfacce come contenitori di costanti e la scarsa abitudine alladocumentazione, soprattutto in ottica evolutiva, cioè all’ulteriore crescita delledimensioni del progetto, costituiscono dei potenziali problemi per i quali vannoadottate contromisure di tipo manageriale (ad esempio l’istituzione di linee guida

aziendali da seguire durante l’implementazione).In definitiva, comunque, come ampiamente ribadito, JasperReports può consi-

derarsi un software solido e ben strutturato.

1.6 considerazioni finali su codecity

Dopo aver utilizzato CodeCity possiamo affermare che l’impressione iniziale, cioèquella che sia un buon tool per l’analisi preliminare di un sistema è confermata.Esso permette, come detto, di individuare anti-pattern e design issues in generaleper mezzo della vista “coarseGrainedDisharmonies” tramite una visualizzazione

intuitiva della struttura del sistema. Risulta inoltre molto utile anche grazie allealtre viste di default definite (ad esempio la vista “magnitude”, “complexity” etc.etc.) che tuttavia, come detto, non sono facilmente accessibili. Un’ottima featureche si segnala è quella della possibilità di generare delle viste customizzate,anch’essa è purtroppo una feature che CodeCity offre ma non è facilmenteaccessibile e individuabile.

Si è potuto inoltre constatare che CodeCity svolge un buon lavoro anche dalpunto di vista dell’analisi evolutiva del software.

Dal punto di vista della scalabilità, CodeCity funziona egregiamente sia che losi utilizzi con sistemi di grandi dimensioni, sia che si voglia analizzare un sistemapiù contenuto, aldilà dei normali rallentamenti.

In conclusione si ritiene CodeCity un buon tool, che con qualche miglioramento(ad esempio quelli proposti), a partire dalla gestione dell’import e del codicesorgente, può essere utilizzato anche per analisi più approfondite. Si consigliacomunque, in generale, di utilizzare CodeCity insieme ad altri tool, ad esempioBauhaus per svolgere analisi più dettagliate.

1.7 d ettag li tec ni c i

1.7.1 Configurazioni macchine utilizzate

La tabella 3 nella pagina seguente riporta le configurazioni sulle quali si èutilizzato CodeCity.



1.7 d et ta gl i t ec ni ci 45

c-1 c-2

Windows Vista Home Premium SP1 (32 bit) Windows XP Professional SP3 (32 bit)

Intel Core 2 Duo T7300 2.00 GHz Intel Core 2 Duo T2300 1.66 GHz

2.00 GB 1.00 GB

Tabella 3: Configurazioni C-1 e C-2 su cui si è utilizzato CodeCity

1.7.2 Tempistiche di analisi

Si riporta la tabella 4 con i tempi impiegati per generare il modello FAMIX 2.1 coninFusione e successivamente importarlo in CodeCity con la configurazione C-1.

v er si o ne d i ja s per r epo rts tempo c r eazi one mo dello tempo i mpor t

0.x.x 2.4 sec 10.1 sec

1.0.0 11.6 sec 45.5 sec

2.0.0 19.9 sec 87.2 sec

3.0.0 22.1 sec 293.4 sec

4.0.2 27.4 sec 426.3 sec

Tabella 4: Tempistiche (creazione modello e sua importazione) relative a CodeCity per la

configurazione C-1

Come fatto per la configurazione C-1, si riportano i tempi relativi alla configu-razione C-2 nella tabella 5.

v er si o ne d i ja s per r epo rts tempo c r eazi one mo dello tempo i mpor t

0.x.x 3.8 sec 11.8 sec

1.0.0 13.7 sec 53.3 sec

2.0.0 21.1 sec 102.1 sec

3.0.0 23.8 sec 391.5 sec

4.0.2 31.2 sec 523.1 sec

Tabella 5: Tempistiche (creazione modello e sua importazione) relative a CodeCity per laconfigurazione C-2




1.7.3 Installazione

L’utilizzo di CodeCity non comporta un vero e proprio processo di installazione.Infatti, non appena decompresso il file .zip scaricato dal sito web ad es-

so dedicato (pagina di download: http://www.inf.usi.ch/phd/wettel/codecity-download.html) è possibile avviare CodeCity da questa stessa cartella. Inoltrenon è imposto alcun vincolo sulla posizione della directory da cui eseguirlo; èsostanzialmente un software standalone.

1.7.4 Bug

CodeCity presenta problemi relativi principalmente alla fase di importazione delmodello .mse. In tale circostanza, infatti, nonostante si fosse generato il modelloFAMIX 2.1 di JasperReports, CodeCity è andato in crash interrompendo la propria

esecuzione.Ulteriori problemi di tipo operativo e d’efficienza si presentano quando siintende navigare, a partire da una vista coarse-grained, un elemento di grossedimensioni con viste fine-grained e quando si intendono investigare le relazionientranti e uscenti (ad esempio, incoming e outgoing invocations) di una classe digrandi dimensioni.

Si notifica inoltre, anche se questo è un bug già documentato ufficialmente (adire il vero l’unico), il crash di CodeCity quando il sistema con cui si genera il file.mse è diverso da quello con cui lo si vuole utilizzare per effettuare la softwareanalysis con CodeCity.

Infine, l’implementazione di CodeCity andrebbe migliorata gestendo le ecce-zioni poiché al momento, ogni qual volta se ne verifica una, non essendo questagestita, CodeCity va in crash.

1.7.5 Documentazione

La documentazione relativa a CodeCity risiede interamente sul relativo sito web(http://www.inf.usi.ch/phd/wettel/codecity.html) ed è composta principalmenteda:

• video tutorial disponibili ai seguenti link:

– http://www.inf.usi.ch/phd/wettel/codecity-tutorials.html

– http://www.inf.usi.ch/phd/wettel/codecity-movies.html

• FAQ, disponibile a questo link:

– http://www.inf.usi.ch/phd/wettel/codecity-faq.html

Si ritiene che essa non sia una documentazione sufficiente per un tool comeCodeCity: questa convinzione è supportata dall’esperienza affrontata nella quale




si è dovuto impiegare molto tempo ad esplorare le molte funzionalità offertedel software, alcune delle quali non sono così intuitive come la sua caratteristicaprincipale.



2M A N H A T T A N

Manhattan è un semplice plug-in di Eclipse, il quale permette di visualizzaretridimensionalmente i progetti precaricati nel workspace. La visualizzazione hadue obiettivi fondamentali:

• rappresentare i progetti in maniera tale da facilitare la comprensione dellaloro architettura;

• aumentare la consapevolezza individuale degli sviluppatori che svolgonoattività in team.

Il primo obiettivo è stato raggiunto con il porting base per Eclipse del toolCodeCity, lo strumento di visualizzazione creato da Richard Wettel [Wettel, c].

Team Activity Awareness è invece la funzionalità che permette di evidenziarein real-time l’insieme di modifiche introdotte nel codice sviluppato da ognicomponente del team. Conoscere ciò che gli altri sviluppatori del team stannoimplementando in un preciso istante, riduce drasticamente le possibilità di averedei conflitti su modifiche introdotte e consente inoltre una migliore comprensionedell’evoluzione del progetto.

Tramite l’utilizzo di Syde1, all’utente vengono notificate, tramite viste dinamicheSWT, le modifiche introdotte nel codice implementato da altri membri del team

[Hattori and Lanza, 2010]. Attraverso alcune semplici tecniche di visualizzazione,Manhattan evidenzia le variazioni rilevate da Syde e le mostra all’utente.

2.1 a na l is i

In questa sezione l’analisi verrà effettuata soltanto sull’ultima versione del soft-ware target, per riuscire a trarre delle conclusioni sullo stato corrente del progetto.Invece nella sezione “analisi evolutiva” verranno analizzate tutte le versioni conogni metrica disponibile. Essendo Manhattan un plug-in in stato embrionale(ancora in fase di sviluppo), le analisi non saranno complete come per gli altri

tool, dato che le metriche forniteci da Manhattan sono ancora “acerbe”.

2.1.1 Analisi progettuale - Anti-Pattern

Per quanto riguarda l’analisi progettuale e dunque la ricerca di anti-pattern,Manhattan non fornisce funzionalità che avvertono l’utente riguardo la presenzadi questo tipo di disarmonie. Però mette a disposizione dell’utente una vista

1 Tool per lo sviluppo collaborativo del software

48



2.1 analisi 49

che permette di individuare facilmente anti-pattern comunemente presenti nelcodice. Infatti basta utilizzare la vista First Person e “passeggiare” per qualchesecondo tra gli elementi della vista, per accorgerci di disarmonie del codice.Come possiamo vedere in figura 39, le classi più grandi del progetto vengono

rappresentate come palazzi blu, mentre le interfacce come silos viola.

Figura 39: Interfaccia sospetta - JRStyle

Notiamo subito che un’interfaccia ha un aspetto differente rispetto agli elementidel suo stesso tipo: questa interfaccia, come notiamo dalla info-box, si chiama

JRStyle e fa parte del pakage engine. Notiamo inoltre che la sua forma è stretta eallungata. Queste informazioni denotano che l’interfaccia in questione possiedemolti metodi e poche variabili. Infatti possiamo leggere dalla info-box che l’inter-faccia possiede soltanto una variabile e ben 170 metodi. Capiamo subito di esseredi fronte ad un anti-pattern chiamato Swiss Army Knife (coltellino svizzero) le cuiprincipali conseguenze sono la difficoltà di utilizzare e manutenere l’interfaccia.Sarebbe preferibile risolvere o minimizzare questo problema dividendo l’interfac-cia in ulteriori interfacce più semplici, ognuna con un compito specifico. Oppure,se non fosse possibile dividerla, si potrebbe pensare di creare dei profili di uti-lizzo, cioè dei sottoinsiemi di operazioni dell’interfaccia, limitati da convenzioni

e condizioni da soddisfare. Se nemmeno i profili fossero applicabili, si potrebbepensare di considerare politiche di utilizzo in ambito generic programming.



2.1 analisi 50

Figura 40: Package “engine” on Orbital View

Dalla figura 40 possiamo notare che la distribuzione delle classi è abbastanzaomogenea per ogni package e non ci sono forti disarmonie che balzano subitoall’occhio.

Una caratteristica che ci può insospettire è il fatto che la gran parte dei packagesfanno parte del package padre engine (evidenziato in verde). Questa è una sceltaprogettuale che può essere corretta o meno in base alle funzionalità delle classi edelle interfacce.

Tramite questo tool non possiamo dire nulla di più di quello appena citato.

2.1.2 Analisi programmativa - Code Smell

Per quanto riguarda l’analisi programmativa, Manhattan fornisce due funzionalità basilari che ci permettono di avere un quadro generale delle dimensioni delsoftware target. Queste due funzionalità sono la First Person View e la OrbitalView.

Navigando con la vista First Person View, notiamo subito un edificio blu (infigura 41 è evidenziato di verde per distinguerlo) molto esteso e basso. Questavista ci fornisce due informazioni importanti: la prima si riferisce al fatto che laclasse in questione possiede un grande numero di variabili, mentre la seconda si




riferisce alla scarsità di metodi posseduti. Tramite l’ info-box appuriamo che laclasse, chiamata JRXmlCostants, possiede 611 variabili e soltanto 46 metodi.

Figura 41: JRXmlConstants on First Person View

Questa classe soddisfa gran parte dei requisiti per essere una Data Class,ovvero una classe contenente soltanto parametri e variabili con i metodi permodificarli (setter e getter). Queste classi solitamente sono utilizzate da ulteriorientità (diverse da Data Class) per effettuare manipolazioni o letture sui parametricontenuti. Una soluzione per ovviare a questa disarmonia potrebbe essere quella

di ridistribuire meglio le variabili in diverse classi, in maniera tale da diminuireanche il numero di metodi presenti nella Data Class ed il numero di entità chehanno bisogno di accedervi.


Manhattan risulta inoltre molto utile per l’analisi evolutiva del software, dato chefornisce una vista tridimensionale chiara che ci permette di avere una visionecompleta del progetto target. Infatti utilizzando la vista First Person possiamonotare come il progetto si popoli e si ridistribuisca col tempo.




Figura 42: Evoluzione tra JasperReports versione 0.x.x e 1.0.0

Inizialmente, nella versione 0.x.x, possiamo notare l’esistenza di una classevisibilmente più grande delle altre, che guardando poi nelle versioni successivesembra scomparire. Si tratta della classe JasperReport che, come possiamo notarenell’immagine della versione 1.0.0, viene ridistribuita in diverse classi del package“engine”. Infatti notiamo come il pakage engine sia aumentato di dimensioni e

quindi di numero di elementi contenuti. Nella info-box notiamo che la suddettaclasse ha 65 metodi, che in confronto alle altre classi del progetto di quella versionesono senza dubbio eccessive.

Figura 43: JasperReports tramite Orbital View

Continuando a visionare la figura 45 notiamo inoltre una forte presenza di in-terfacce che nella prima versione non erano erano così evidenti. Infatti indagandotramite la vista Orbital possiamo facilmente vedere che con il passare del tempo(e quindi delle versioni), le interfacce sono cresciute linearmente con la crescitadel codice sorgente del progetto.

Vediamo che ad ogni versione le interfacce vengono giustamente ridistribuitein maniera tale da non incorrere in anti-pattern tipo lo Swiss Army Knife.




Figura 44: Confronto versioni tramiter Orbital View

Avendo una buona distribuzione di classi e interfacce per package ci riteniamosoddisfatti del software e ritorniamo ad analizzare il codice tramite la vista FirstPerson.

Notiamo che dalla versione 1.0.0 alla versione 2.0.0, una classe ( JRDesignViewer)con molti parametri e pochi metodi è stata “demolita” e riassorbita da una classevicina chiamata JRViewer. Notiamo che questo assorbimento continuerà anchenelle versioni successive (dalla 2.0.0 alle 3.0.0) con altri classi simili, facendodivenire sempre più imponente la suddetta classe (si può notare la classe JRViewer

dal riquadro giallo in figura 45). Pensiamo di essere difronte ad una God Classma non ne siamo completamente certi data la mancanza di metriche. Si potrebbecomunque pensare di suddividere la classe anche se bisognerebbe investigaremeglio sulle sue funzionalità. Non capiamo il perchè tutte le sottoclassi dellaclasse JRViewer siano state inglobate nella classe madre. Supponiamo che sianostate funzionalità talmente secondarie da non necessitare ulteriore spazio nel



2.3 f or wa rd e ng in ee ri ng 54

progetto.

Figura 45: Evoluzione tra JasperReports versione 2.0.0 e 3.0.0

Figura 46: Evoluzione JasperReports versione 4.0.2

2.3 f o rwa r d eng ineeri ng

Questo tool possiede un elevato potenziale nel campo del forward engineering.Infatti utilizzando il tool per qualche minuto ci si accorge subito che modificandoil codice del progetto, quindi creando packages, classi o soltanto modificando at-tributi o metodi di una classe, il software, in real time senza tempi di caricamento,aggiorna la vista tridimensionale del progetto. Questo tipo di funzione chiamata“Reacting to changes” permette subito di notificare allo sviluppatore eventualidisarmonie nel codice che sta scrivendo.



2.3 f or wa rd e ng in ee ri ng 55

Figura 47: Reacting to changes

Ulteriore funzionalità presente nel tool, di forte aiuto per il forward engineering,è la funzione Team Activity Awareness, la quale permette di segnalare all’interodi un team di sviluppo, quale programmatore sta lavornado su quale entità delprogetto in realtime. Inoltre permette di differenziare il colore dell’entità in basealle azioni che il programmatore sta svolgendo su di essa. Infatti l’entità verrà

colorata di giallo se l’azione è introduttiva (ovvero inserimento di un nuovavariabile, di un nuovo metodo, classe o package) altrimenti verrà colorata diarancio se l’azione compiutà è ritenuta essere una estromissione o eliminazionedi un elemento.



2.4 su g ge r im en t i p e r m i gl i or a re ma n ha tt an 56

Figura 48: Team Activity Awareness

2.4 suggerimenti per migliorare manhattan

Similmente a X-Ray, anche questo tool può essere considerato come una buona base su cui creare un ottimo software di reverse e forward engineering. Sarebbelimitativo giudicare un tool in questo momento dato che è tuttora in fase disviluppo. Ci limiteremo dunque a giudicare soltanto le funzionalità complete e adare dei consigli per migliorare o introdurre funzionalità.

Le carenze più evideni che abbiamo riscontrato utilizzando il tool sono:

• carenza di funzionalità: mancanza di autoidentificazione di alcun genere dicode smell o anti-pattern;



2.4 su g ge r im en t i p e r m i gl i or a re ma n ha tt an 57

– introdurre una checkbox per l’auto identificazione di anti-pattern, comequella di CodeCity.

• carenza di chiarezza: le funzionalità di selezione e di navigazione della vista

First Person e della vista Orbital sono inizialmente difficili da trovare datoche non esistono bottoni ma soltanto short-cut tramite tastiera.

– si potrebbe pensare di introdurre una semplice interfaccia grafica perpermettere i movimenti;

– si potrebbe pensare di implementare lo spostamento della visualetramite il movimento del mouse.

• carenza di completezza: una possibile ulteriore feature potrebbe essere unasemplice info-box che fornisca informazioni di carattere generale sul numerodi packages, classi, metodi, linee di codice dell’intero progetto.

– a questo proposito possiamo far riferimento alla info-box di X-Ray.

• carenza di visibilità: nelle viste Orbital e First Person la scala e le metricheutilizzate per la rappresentazione degli elementi del progetto non è chiara apriori senza una previa lettura della documentazione.

– si consiglia di inserire nella vista una piccola legenda che definiscai colori e le caratteristiche degli elementi rappresentati (altezza cor-risponde al numero di metodi, larghezza corrisponde al numero dicampi, etc.).

• carenza di fruibilità: dal punto di vista attuale viene visualizzato in unasingola vista un unico layout di lavoro, quindi l’utente può cimentarsi inuna sola vista per volta senza poter effettuare confronti tra viste;

– sarebbe utile avere nelle prossime versioni di Manhattan un layout chepossa contenere più viste, per offrire una completa rappresentazionedel sistema.

• produzione di report e documentazione: questa funzionalità potrebbe di-venire utile dato che Manhattan produce diverse informazioni di caratteretecnico che poi vengono rappresentate mediante una vista tridimensionale.

– si potrebbe pensare di far produrre a Manhattan dei report in formatopdf o xml contenente tutte le informazioni rappresentate nelle info-boxdelle viste Orbital e First Person.

– si potrebbe pensare di far produrre a Manhattan delle immaginicontenenti le due viste polimetriche.

• carenza di visibilità delle dipendenze: Manhattan non permette in alcunmodo di visualizzare le dipendenze tra gli elementi del progetto.




– sarebbe utile poter visualizzare le dipendenze tra classi e interfacce;

– sarebbe utile poter visualizzare le dipendenze tra packages;


Essendo JasperReports un software ben strutturato, il compito di migliorarlorisulta complesso.

Tramite questo tool possiamo di certo affermare che:

• La mancanza di commenti nel codice sorgente scritto nella versione 0.x.x,rende di difficile comprensione le classi fondamentali del progetto. I com-menti presenti seguono formattazioni Doxygen ma non il buonsenso dellalimitazione ad 80 caratteri per linea.

– si può pensare di introdurre almeno un commento nell’intestazione di

ogni classe, o ancor meglio nell’intestazione di ogni metodo.– si può pensare di introdurre commenti utilizzando la formattazione

Doxygen in maniera tale da avere allo stesso tempo senza sforzo una buona documentazione dettagliata.

• La classe JRXmlCostants è una Data Class, ovvero una classe contenentesoltanto parametri/variabili e metodi per modificarli (setter e getter). Questeclassi solitamente sono utilizzate da ulteriori entità (diverse da Data Class)per effettuare manipolazioni o letture sui parametri contenuti.

– una soluzione per ovviare a questa disarmonia potrebbe essere quelladi ridistribuire meglio le variabili in diverse classi, in maniera tale dadiminuire anche il numero di metodi presenti nella Data Class ed ilnumero di entità che hanno bisogno di accederci.

• L’interfaccia JRStyle è un anti-patter chiamato Swiss Army Knife (coltellinosvizzero). Le principali conseguenze di questo anti-pattern, sono la difficoltàdi utilizzare e manutenere l’interfaccia.

– Sarebbe preferibile risolvere o minimizzare questo problema dividen-do l’interfaccia in ulteriori interfacce più semplici, ognuna con uncompito specifico. Oppure, se non fosse possibile dividerla, si potreb-

be pensare di creare dei profili di utilizzo, cioè dei sottoinsiemi dioperazioni dell’interfaccia, limitati da convenzioni e condizioni da sod-disfare. Se nemmeno i profili fossero applicabili, si potrebbe pensare diconsiderare politiche di utilizzo in ambito generic programming.

• La classe JRViewer ha le carte in regola per essere una God Class ma non nesiamo completamente certi data la mancanza di metriche.




– Si potrebbe comunque pensare di suddividere la classe in diverse sotto-classi o smistare i suoi metodi in classi differenti, anche se bisognerebbeinvestigare meglio sulle sue funzionalità. Non capiamo il perchè tuttele sottoclassi della classe JRViewer siano state inglobate nella classe

madre. Supponiamo che siano state funzionalità talmente secondarieda non necessitare ulteriore spazio nel progetto.


2.6.1 Tramite Manhattan

Analizzando il progetto con Manhattan possiamo notare come, con il tempo (econ il passare delle versioni), sia stato profondamente modificato e notevolmentemigliorato. La progettazione iniziale della versione 0.x.x sembra essere stata

modificata pesantemente. Le classi che una volta erano il fulcro del software, orasono delle entità minori, seppur presenti.I package iniziali non sono stati eliminati, ma con il passare del tempo sono

stati incrementati e ampliati.È da notare inoltre che vari gruppi di classi sono accomunati da dimensioni

rilevanti; questo però non costituisce un problema perché le classi dell’applicationlogic sono ben strutturate.

Durante l’analisi del software abbiamo incontrato un solo anti-pattern, lo SwissArmy Knife e alcuni code smell che anche se presenti non compromettono lasolida progettazione ed implementazione alla base di JasperReports.

Un difetto riscontrato anche con altri software di analisi è la scarsità di commen-ti nel codice sorgente; infatti tutte le classi “anziane”, ovvero create nella primaversione del software, non presentano commenti nel codice. Per un software diqueste dimensioni e di questa importanza risulta essere un forte fattore negativoche va ad intaccare la comprensione e la riusabilità del codice. Inoltre evitando discrivere commenti si aumenta persino il tempo di debugging e di manutenzionedel codice.

In definitiva, utilizzando Manhattan possiamo affermare che JasperReports èun software solido e ben strutturato.

2.7 considerazioni finali su manhattan

È difficile giudicare un tool “emergente”, cercheremo però di evidenziare i puntia favore e a sfavore.

Innanzi tutto va chiarito che il tool non possiede assolutamente abbastanzametriche per effettuare una analisi di un software del calibro di JasperReports.

I pregi sostanziali sono:

• presenza di funzionalità molto utili ed innovative per il forward engineering;



2.7 c o ns i de r az i on i f i na l i s u m a nh at ta n 60

• la sua natura open-source che permette una sua maggiore diffusione (multi-piattaforma) e possibilità di miglioramento;

• funzioni che permettono di avere un’ottima scalabilità;

• non richiede di meta-files per eseguire le analisi, ma soltanto del codicesorgente;

• non è stand-alone ma si basa sul Framework di Eclipse;

• possibilità di modificare il codice sorgente mentre si utillizzano viste tridi-mensionali;

• le metriche disponibili seppur poche sono utili;

• presenza di un sistema di caching per mantenere in memoria le viste giàanalizzate dei progetti non modificati.

Mentre i suoi difetti sono:

• mancanza di metriche utili a riconoscere code smell e anti-pattern;

• fortemente legato ad altre librerie sia grafiche che di analisi;

• enormi difficoltà nell’installazione;

• mancanza completa di icone;

• mancanza completa di legende che spiegano le metriche;

• presenza di bug in alcune funzionalità;

• leggera instabilità del tool in alcune condizioni;

• mancanza di documentazione;

• utilizzabile soltanto su progetti Java;

• utilizzabile soltanto su progetti open-source o di cui si possiede il sorgente;

• mancanza di poter memorizzare alcune viste modificate dall’utente;

• mancanza di esportazione dei grafici creati;• mancanza di info-box più dettagliate e persistenti;

• mancanza di report;

• poca personalizzazione delle viste;

• non è stand-alone ma si basa sul Framework di Eclipse.




Il dettaglio che Manhattan non è un software stand-alone è stato inserito sianei pregi che nei difetti, questo perché per alcuni sviluppatori che utilizzanogià Eclipse può essere un vantaggio avere in un unico ambiente sia l’editor cheun software di analisi. È anche per questo che Manhattan può anche essere

utilizzato per il forward engineering, dato che ci si accorge velocemente di alcunedisarmonie nel codice, vedendo la costruzione del progetto in real-time.

Questo dettaglio però può anche essere considerato come un difetto nel mo-mento in cui il programmatore non è solito utilizzare Eclipse. In questo casodiventa fastidioso dover installare più di un software.

Come possiamo notare sono più i difetti che i pregi; ma leggendo bene, lamaggior parte dei difetti sono dovuti alla mancanza di una determinata funzioneo di un determinato comportamento. Questo significa che possono essere vistepiù come feature mancanti che come difetti, dato che Manhattan è ancora in fasedi sviluppo.


2.8.1 Configurazione macchina utilizzata

Date le forti difficoltà riscontrate durante l’installazione del tool, si è deciso ditestarlo soltanto su una sola macchina.

Qui di seguito abbiamo una tabella con la configurazione del computer utiliz-zato.

s-5

MS Windows 7 x64 bit

Intel Core Duo 2.40 GHz

4.00 GB

Eclipse Indigo Versione 3.7.0

MS Windows XP Professional x32 on Vmware Player

Tabella 6: Configurazione macchina utilizzata


Segue la tabella 7 riportante i valori tempistici delle analisi sulle diverse versionidi JasperReports.




c on f ig ur az io ne v e rs io ne d i ja sp e rr e po rt s t e mp o

S-1 0.x.x 0.41 sec

S-1 1.0.0 13.06 sec

S-1 2.0.0 14.11 secS-1 3.0.0 18.12 sec

S-1 4.0.2 4.15 min

Tabella 7: Tempistiche di analisi con Manhattan su JasperReports

2.8.3 Installazione

L’installazione di Manhattan [Rigotti] è stata molto difficoltosa. In caso di mancata

installazione o di mancato download vengono esposti errori poco comprensibili enon risolvibili in maniera intuitiva.

È stato rieseguito il processo di installazione per 4 volte su due sistemi operatividifferenti prima di riuscire a far funzionare il tool.

Bisogna tenere presente che, basandosi fortemente su due librerie LWJGL e Syde,eredita i loro requisiti minimi. I requisiti minimi che limitano il funzionamentodel tool sono:

• sistema operativo a 32 bit;

• almeno 512 Mb di ram (1 Gb consigliato);

• Eclipse correttamente aggiornato all’ultima versione disponibile (Indigo 3.7o superiori) [Coorporation];

• SDK Java aggiornata all’ultima versione (versione 6 - u26 o superiori) [Oracle,a];

Appurato di avere i requisiti minimi possiamo procedere con l’installazione:

1. aprire Eclipse e selezionare il menù “Help”;

2. selezionare il sottomenù “install new software”;

3. installare la libreria grafica LWJGL inserendo il link “http://lwjgl.org/update/”;

4. installare il plug-in Syde inserendo il link “http://syde.inf.usi.ch/update/”;

5. installare il plug-in Manhattan inserendo il link “http://atelier.inf.usi.ch/~rigottifr/manhattan/




Figura 49: Tutorial di installazione

2.8.4 Bug

Durante l’installazione del tool si sono verificati problemi che hanno comportatola reinstallazione del framework di Eclipse e la reinstallazione di Manhattan.

Esistono due piccoli bug, se così si possono definire:

1. il primo fa persistere la schermata di attesa di elaborazione, anche se inrealtà il tool ha già finito di analizzare il progetto target;

2. il secondo (capitato una sola volta), fa si che quando noi andiamo a riana-lizzare un progetto già analizzato, compaia un errore che non permetta dicompletare l’operazione richiesta.

Figura 50: Schermata di errore (n°2)

Questi due malfunzionamenti possono essere attribuiti alle scarse performancedel computer, dato che il tool è stato testato su una macchina virtuale con soli 512Mb.

Sostanzialmente il software risulta privo di bug evidenti che compromettono ilsuo utilizzo.





La documentazione offertaci da Manhattan è pressoché inesistente. Questo èdovuto al fatto che è tuttora in fase di sviluppo.

La documentazione disponibile è composta da:• un breve tutorial video per imparare a utilizzare tutte le funzionalità di

Manhattan [Oracle, b];

• un breve tutorial per installare Manhattan (privo di requisiti minimi);

• una breve paragrafo sul sito dello sviluppatore che spiega brevemente lametrica utilizzata.

Figura 51: Sito ufficiale di Manhattan



3B A U H A U S

Bauhaus nasce come progetto di ricerca della University of Stuttgart e la spin-off Axivion [Bauhaus]. Lo scopo del progetto si colloca nell’ambito del mantenimen-to software e del software reengineering e in particolare mira a rispondere alproblema del decadimento software.1

Il decadimento software descrive il deterioramento del codice nel tempo chetende a rendere il programma instabile, inusabile o comunque bisognoso di ma-nutenzione. Evidentemente non è un fenomeno fisico ma è dovuto alla mancanzadi aggiornamenti rispetto ai cambiamenti dell’ambiente in cui risiede.

Bauhaus fornisce una vista complessiva del sistema da analizzare tramitemetriche e permette di entrare in dettaglio per valutare gli interventi da effettuareper ristrutturare il codice.

3.1 a na l is i

In questa analisi effettuata tramite il software Bauhaus verrà valutata solo l’ultimaversione di JasperReports, la 4.0.2, per poi confrontare in modo evolutivo leprincipali release precedenti.


Bauhaus non è stato espressamente creato con l’intenzione di evidenziare leanomalie progettuali quanto piuttosto, come anticipato, per individuare i punticritici del software. Ad ogni modo gli strumenti forniti permettono di evidenziarealcuni punti di interesse.

Come prima analisi è significativo evidenziare i cicli all’interno del sistema (siveda figura 52): in tutto sono presenti 67 nodi e 75 archi coinvolti. Come possiamovedere in figura alcuni cicli sono piuttosto rilevanti arrivando a comprenderesette o otto nodi che si richiamano a vicenda, situazione tipica che identifical’anti-pattern Tangle.

1 Il progetto Bauhaus fu iniziato da Erhard Ploedereder, Ph.D. e Rainer Koschke, Ph.D. alla Universityof Stuttgart[6] nel 1996. In origine era una collaborazione tra l’Institute for Computer Science (ICS)della University of Stuttgart e il Fraunhofer-Institut für Experimentelles Software Engineering(IESE), che non è più coinvolto. La spin-off commerciale Axivion venne avviata nel 2005.Oggi, la ricerca è portata avanti presso Axivion, l’Institute of Software Technology, il Departmentof Programming Languages alla University of Stuttgart così come il Software Engineering Groupdella University of Bremen.

65



3.1 analisi 66

Figura 52: Principali cicli evidenziati nel sistema

I cicli sono sintomo di un codice con molte dipendenze dove anche una piccolamodifica si ripercuote inevitabilmente su buona parte del sistema: questo rende ilcodice difficile da mantenere.

Figura 53: Complessità ciclomatica significativa tipica di una Brain Class

Altro indice utile per individuare disarmonie è dato dalla complessità cicloma-tica.

La McCabe Complexity, o complessità ciclomatica, è il numero di decisioni nelcorpo della funzione più uno; una decisione è un predicato in corrispondenzadel quale il flusso di esecuzione si divide. Più decisioni la funzione prende piùè alta la complessità della stessa: per capire una certa locazione nel codice èimportante capire quando questa può essere raggiunta e più decisioni sono postesul cammino per raggiungere la locazione, più è necessario capire il contesto perarrivare a capire la locazione.

Vediamo ad esempio che JRAbstractStyleFactory e JRStyledTextParser contengonometodi di complessità ciclomatica molto elevata rispetto alle linee di codice



3.1 analisi 67

eseguibili, portando a considerarle come Brain Class. Dal grafico si notano inquanto non rientrano nella curva caratteristica del programma.

Figura 54: Complessità ciclomatica bassa a fronte del numero di righe

Contrariamente a questo possiamo vedere come ci siano metodi dalla bassa

complessità ciclomatica: initComponents della classe JRViewer e createHighLowData-set della classe ConvertChartContext. Queste classi sono delle Data Class come sipuò notare analizzandone il codice.

Figura 55: JRApiWriter

Infine la classe JRApiWriter risulta essere una God Class a causa del numerodi righe di codice ma soprattutto analizzando il suo neighborhood mostrato infigura 56 nella pagina successiva dove si evidenziano le relazioni con metodi eclassi.

Per quanto riguarda invece le interfacce possiamo vedere la presenza di una

disarmonia nella classe JRStyle: osservando infatti nel grafico il numero di linee dicodice si nota come questo sia sproporzionato rispetto alle altre lasciando pensarea un sovraccarico di questa.



3.1 analisi 68

Figura 56: JRApiWriter Fish view

Figura 57: Disarmonia nella classe JRStyle


Ponendosi da un punto di vista più generale, e quindi più ampio, possiamo avereun’idea complessiva della struttura del progetto basandoci inizialmente su alcunemetriche globali: JasperReports contiene 69 package, 1612 classi, 295 interfacce,

numeri che ci portano a considerarlo un progetto non piccolo.Per questo motivo possiamo usare altre metriche per valutare la qualità delcodice. Innanzi tutto possiamo misurare la lunghezza di classi e metodi in terminidi numero di linee di codice, linee di codice eseguibili e rapportarle al numero dicommenti.

Possiamo vedere che il numero di linee di codice è abbastanza omogeneo sututti i nodi del progetto ma vi è qualche eccezione che si discosta molto comeriportato in figura 59 dove possiamo vedere i metodi più lunghi in assoluto.



3.1 analisi 69

Figura 58: Vista Element Count di JasperReports generata con Bauhaus

Vediamo che rispetto al numero totale di metodi sono davvero pochi quelli didimensione elevata e in particolare solo 52 superiori alle 100 linee di codice.

Figura 59: Metodi con più di 100 linee di codice

Ad ogni modo spicca il metodo addChartRoules della classe DigesterFactory che



3.1 analisi 70

pur avendo la minima complessità possibile ha il più alto numero di linee di codiceeseguibili. A prescindere dalla leggibilità del codice che sarà sicuramente più

bassa a causa della lunghezza del metodo risulta essere forse troppo complessoe potrebbe essere diviso in più metodi permettendo un maggiore riutilizzo del

codice e una granularità più fine, che aiuta a costruire un codice più ordinato,logicamente diviso e quindi più mantenibile.

Figura 60: Metriche del metodo addChartRoules

Una ulteriore informazione che si può ottenere tramite le metriche e in par-ticolare con la possibilità di vedere la correlazione tra metriche diverse, è ladistribuzione dei commenti rispetto al codice.

Figura 61: Linee di commento rispetto a linee di codice in Bauhaus

Come possiamo vedere dalla figura 61 i commenti sono distribuiti abbastanzauniformemente rispetto alle linee di codice e anche se bisognerebbe analizzarein dettaglio ogni classe per verificare che i commenti siano significativi, si puòsupporre che il codice sia quindi ben documentato.



3.1 analisi 71

Per quanto riguarda le relazioni tra classi e package Bauhaus non permettedi raggruppare per ottenere una vista sintetica. È possibile visualizzare le classidi un package alla volta ma sono generalmente in numero così elevato da nonpermettere una visualizzazione significativa.

Una funzione interessante che mette a disposizione Bauhaus è la ricerca au-tomatica di codice duplicato. Abbiamo eseguito questo tool sul codice sorgentedi JasperReports e abbiamo rilevato la presenza di moltissimo codice duplicatocome si nota in figura 62.

Figura 62: Schermata di gravis con tutti i cloni individuati ordinati per numero di linee

duplicate. Da notare la presenza di cloni lunghi più di 500 linee e il numerototale di cloni elevato come si può notare dalla barra laterale

Andando nel dettaglio si vede come molti cloni siano in realtà dati da metodideprecati, probabilmente tenuti per retro compatibilità. Sono tuttavia presentianche segmenti di codice con definizioni di costanti duplicate.

Figura 63: Esempio di codice contenente definizioni di costanti duplicate





Come già illustrato, abbiamo analizzato in dettaglio soltanto l’ultima versionedi JasperReports. Procederemo ora ad illustrare una analisi sull’evoluzione del

software in termini più generali sfruttando le numerose metriche fornite daBauhaus per tracciare i cambiamenti in modo quantitativo e in parte qualitativo.Analizzeremo in particolare le versioni 1.0.0, 2.0.0 e 3.0.0, unitamente alla 4.0.2già affrontata nel capitolo precedente.

Il primo strumento che abbiamo per valutare l’evoluzione del progetto è datodal conteggio degli elementi: in particolare possiamo notare una crescita delnumero di package e classi pressoché costante anche se vi è un notevole balzodalla 3 alla 4 di più del 50%.

Figura64

: Conteggio degli elementi delle prime tre versioni di JasperReports. Da sini-stra JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0. Si nota unincremento quasi proporzionale su tutti gli elementi: package, classi, interfacce.

Già dalla prima versione comunque il progetto è da considerarsi ampio anchese i numeri dell’ultima versione sono più importanti.

Dopo aver valutato l’incremento di classi e package risulta naturale analizzarele eventuali variazioni nel numero di righe di codice per verificare se l’incrementodi dimensione del progetto corrisponda a un incremento di funzionalità o sem-plicemente a una riorganizzazione del codice già esistente in una configurazionepiù modulare.

Questa volta invece non notiamo un sostanziale incremento o variazione: riman-gono solo dei piccoli punti di differenza e in modo particolare sembrano apparirealcuni metodi lunghi e complessi, come se fosse stata aggiunta una funzionalitàsenza una vera integrazione nel sistema ma lasciata isolata e contenuta in ununico segmento di codice.

Deduciamo quindi che con il passare del tempo e aumentando la complessitàdel codice, siano nati dei punti deboli che hanno leggermente deteriorato il pro-




Figura 65: Confronto del numero di linee di codice. Dall’alto JasperReports 1.0.0, Jasper-Reports 2.0.0 e JasperReports 3.0.0. Non si nota una significativa variazione trale tre versioni.

getto abbassandone la qualità. Ma per essere sicuri di questo bisogna analizzarealtri parametri come la complessità ciclomatica e la presenza di cicli.

Anche per quanto riguarda la complessità ciclomatica possiamo notare unincremento per alcuni elementi isolati a conferma del fatto che l’aumentare dicomplessità del codice si è ripercosso anche sulla sua mantenibilità, portando adavere alcuni agglomerati di funzioni.

Ultima considerazione sulla complessità del codice è l’analisi sulla presenza dicicli. Valutando le versioni precedenti di JasperReports è risultato che l’ultima èquella che contiene meno cicli in assoluto mentre la peggiore è la 2.0 che risultapiù intricata con cicli da decine di nodi.

Osserviamo quindi che c’è stato un miglioramento anche da questo puntodi vista nell’ultima versione in cui è stato ottimizzato il codice riducendo lacomplessità ciclomatica, il numero di cicli e mantenendo stabili gli altri parametri

a fronte di un significativo aumento di dimensioni. Si nota anche un maggiorriuso del software, sulla base dell’aumento delle relazioni interne al programma.

Ultimo parametro considerato per questa valutazione evolutiva è il numero dilinee di commento rispetto al numero di linee di codice come vediamo in figura 68

a pagina 76.Partendo dall’ultima versione, la 4.0.2, esaminata nel capitolo precedente, dove

avevamo una distribuzione quasi lineare e quindi proporzionale, osserviamo cheancora una volta le versioni precedenti mostrano una qualità più bassa: anche se




Figura 66: Confronto della complessità ciclomatica assoluta e rispetto al numero di lineedi codice eseguibili. Per ogni riga dall’alto JasperReports 1.0.0, JasperReports2.0.0 e JasperReports 3.0.0.

sono abbastanza uniformi si nota dai grafici la presenza di numerosi elementicon molte righe di codice e poche righe di commento. Per trarre delle conclusionipiù affidabili bisognerebbe analizzare direttamente il codice ma non offrendoBauhaus strumenti sintetici per questa analisi non è stato fatto, vista la mole didati che si dovrebbe affrontare.

Ultima singolarità è il grafico della prima versione dove si notano elementi conmolte righe e nessun commento e vice versa elementi con nessuna riga di codicee soltanto commenti. Da questa informazione possiamo dedurre che la 1.0.0 èstata una versione di passaggio dove l’implementazione non era ancora terminatae molte classi e metodi erano soltanto commenti. D’altra parte non è chiaro comemai una release sia stata pubblicata con questa strana configurazione, se noncome versione provvisoria. Non avendo però analizzato le release successive alla1.0.0 non sappiamo se le classi di soli commenti siano state implementate o se sisia aspettata la versione 2.0.0 dove queste disarmonie non si verificano.



3.3 s u gg e ri m en t i p e r m i gl i or a re b au h au s 75

Figura 67: Confronto della presenza di cicli nelle varie versioni di JasperReports. Dall’alto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0

3.3 suggerimenti per migliorare bauhaus

Dopo un primo periodo di utilizzo il tool risulta comprensibile e funzionale,ma presenta una curva di apprendimento piuttosto lenta. Un modo per aiutaregli utenti alle prime armi ad avvicinarsi a questo tool è aggiungere una guidarapida che spieghi i concetti essenziali per analizzare subito un progetto. Sicu-ramente anche il fatto che l’analisi debba essere fatta da riga di comando nonaiuta l’apprendimento dello strumento e quindi aggiungere un’interfaccia gra-



3.3 s u gg e ri m en t i p e r m i gl i or a re b au h au s 76

Figura 68: Vista comparativa della correlazione tra numero di linee di commento enumero di linee di codice di JasperReports. Dall’alto JasperReports 1.0.0,

JasperReports 2.0.0 e JasperReports 3.0.0

fica per la parte di estrazione delle informazioni da sorgenti e class file facilital’utente nell’imparare a usare il tool senza dover leggere quattrocento pagine didocumentazione.

Le viste e i grafi sono piuttosto chiari e ben fatti, anche gli strumenti di selezionesono funzionali e completi, ma anche in questo caso si può migliorare qualchepunto: per quanto riguarda l’interfaccia grafica è necessario aggiungere delleinformazioni al passaggio del mouse, o quando il puntatore si ferma in unpunto, che spieghino i singoli componenti. Ad esempio il significato dei seicampi che caratterizzano ogni vista, che corrispondo a numero di nodi e archirispettivamente totali, selezionati e marcati, è stato dedotto dopo qualche tentativo




e confermato da una lettura della documentazione. Per quanto riguarda invece levoci dei menù sarebbe utile filtrare a seconda del linguaggio del progetto che sista analizzando: non tutte le opzioni infatti sono abilitate per ogni linguaggio masono tutte ugualmente presenti. Questo devia l’utente che non capisce se sia il

programma a non funzionare o sia una funzionalità non pertinente con l’ambientedi analisi.

Automatizzare inoltre funzioni di ricerca, come anti-pattern e code smell sem-plificherebbe la vita a chi deve invece districarsi tra un numero elevato di classi epackage, con la difficoltà di scegliere le query giuste da eseguire per individuare iproblemi del codice.

In ultimo bisogna menzionare che risolvere i bug riportati nell’apposita sezionerenderebbe Bauhaus più utilizzabile.


Come abbiamo potuto notare tramite l’analisi evolutiva, JasperReports 4.0.2 è giàstato migliorato rispetto alle versioni precedenti. Analizzando il codice non sonoemerse delle disarmonie sorprendenti e se anche è presente qualche punto chepotrebbe essere ristrutturato nel complesso possiamo dire che è ben progettatoma soprattutto che è già stato ristrutturato.

3.5 considerazioni finali bauhaus

Nonostante i problemi riscontrati, Bauhaus è risultato un tool potente che lascia

l’utente libero di maneggiare il codice agilmente. Gli strumenti che mette adisposizione rispondono bene agli obiettivi posti dagli sviluppatori e mantieneeffettivamente le promesse fatte. Non risulta comunque un tool completo maè ottimo se affiancato da strumenti di individuazione automatica di anomalieperché, una volta focalizzato un punto d’interesse permette di entrare in dettagliopiù e meglio di altri tool.


A prescindere dall’effettivo funzionamento di JasperReports, che non è statoconsiderato, l’analisi attraverso Bauhaus ha portato all’idea che sia già stato fattoun buon lavoro di refactoring. Il codice è strutturato bene e le disarmonie presentisono poche rispetto alla mole del progetto. Bisogna comunque analizzare altriaspetti con altri tool per confermare questa ipotesi.






Bauhaus è stato utilizzato su due differenti calcolatori per generare i file “.rfg”,mentre la visualizzazione grafica è stata usata soltanto in uno dei due per alcunedifficoltà di supporto delle librerie gtk su piattaforma a 64 bit.

Configurazione 1 (Old Iralab):

Ubuntu 10.10 Maverick, 2GB RAMLinux 2.6.35-30-generic i686 GNU/LinuxIntel(R) Pentium(R) 4 CPU 3.00GHz (1 core)

Configurazione 2 (Personal Notebook):

Ubuntu 11.04 Natty, 4GB RAMLinux 2.6.38-8-generic x86_64 GNU/LinuxIntel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2 core)

Configurazione 3 (New Iralab):

Ubuntu 10.04 Lucid, 8GB RAMLinux 2.6.32-32-generic-pae i686 GNU/LinuxIntel(R) Core(TM) i7 CPU 950 @ 3.07GHz (8 core)

Configurazione 4 (Essere):

Gentoo Base System release 1.12.14, 4GB RAMLinux 2.6.36-gentoo-r8 x86_64 GNU/LinuxIntel(R) Xeon(R) CPU E5320 @ 1.86GHz (8 core)


Configurazione 1

Output dello script di analisi per le quattro versioni di JasperReports:

jasperreports-1.0.0real 0m0.007s user 0m0.004s sys 0m0.004s

real 0m34.830s user 0m15.041s sys 0m11.713s

jasperreports-2.0.0



jasperreports-3.0.0






jasperreports-4.0.2



Configurazione 2


jasperreports-1.0.0



jasperreports-2.0.0



jasperreports-3.0.0


real 1m1.632s user 0m31.270s sys 0m30.120sjasperreports-4.0.2



Configurazione 3


jasperreports-1.0.0



jasperreports-2.0.0real 0m0.017s user 0m0.008s sys 0m0.000s


jasperreports-3.0.0



jasperreports-4.0.2



Configurazione 4


jasperreports-1.0.0



jasperreports-2.0.0



jasperreports-3.0.0






jasperreports-4.0.2



3.7.3 Installazione

Nell’ambito dell’analisi del software non è stato possibile testare e sperimentarel’installazione di Bauhaus poiché richiede una chiave di licenza apposita. Abbiamoinvece utilizzato una versione precedentemente installata su server remoto. Laversione utilizzata è Axivion Bauhaus Suite Version 5.6.6 Built on 2009-03-23 byAxivion GmbH con licenza di tipo “Academic”.

Bisogna notare che è sufficiente copiare la cartella contenente Bauhaus per

poterlo utilizzare su altre macchine: con questo sistema è stato possibile valutarele diverse performances su più calcolatori.Da quanto si evince dalla guida di Bauhaus sono supportati sistemi GNU/-

Linux, Solaris e Windows XP/2000. Per tutte queste piattaforme è fornita ladocumentazione adeguata circa l’installazione. Riportiamo per completezza ipassaggi fondamentali per la versione GNU/Linux.

Requisiti di sistema

• Processore compatibile Intel x86

• Linux kernel 2.6.8 o superiore

• Almeno 1GB RAM (consigliati 4)

• Circa 100MB di spazio su disco fisso

• Python versione 2.4.x

• GTK+ versione compresa tra 2.2 e 2.10 (raccomandata 2.8.20)

Decompressione

Il pacchetto fornito comprende uno script che si occupa delle operazioni di

decompressione; basta dunque eseguire tale script, bauhaus-tools-<version>.sh,specificando quando richiesto la cartella di destinazione.

Licenza

Il file di licenza acquisito insieme a Bauhaus deve essere posto nella cartella$HOME/.bauhaus/ per singolo utente o BAUHAUS/config/ per licenze multi utente.




Personalizzazione setup

Tramite lo script setup.sh il software personalizza i link simbolici alle librerienecessarie al programma e configura i compilatori da utilizzare.

Avviare Bauhaus

Per prima cosa è necessario importare il contenuto del file bauhaus-kshrc in mododa aggiungere le variabili d’ambiente necessarie. Infine è sufficiente invocaregravis da terminale per avviare il visualizzatore grafico.

3.7.4 Analisi software java

Per analizzare i software java Bauhaus mette a disposizione un tool da riga dicomando che a partire dal bytecode crea un file “.rfg”, ovvero il formato che

descrive in termini di grafo tutto il progetto, memorizzando per ogni elementoalcune informazioni caratteristiche.La creazione di questo file è facilitata se il progetto è sotto forma di archivio

JAR, in quanto il comando da eseguire accetta un unico file come elemento daanalizzare. Se non si è in presenza di un unico file JAR ma si hanno tutti i fileclass vi sono due alternative:

• Creare un file JAR

• Creare un file project

La soluzione adottata è stata quella meno comune di creare un file project, persperimentare il funzionamento di Bauhaus anche in questa condizione. Un fileproject, come illustrato dalla main page di java2rfg, è un file dove per ogni riga èspecificato il path di un diverso file class. Per generare questo file è sufficienteutilizzare il comando unix find.

Un altro parametro interessante da impostare è il path del codice sorgente.Questo permette a Bauhaus di collegare il codice ai singoli elementi del graficoin modo da permettere una navigazione del codice a partire dagli elemtenti delgrafo.

Dovendo analizzare più versioni del progetto, strutturate con la stessa archi-tettura di cartelle è stato preparato uno script che genera automaticamente i file

“.rfg”, vedi Algoritmo 3.1, per tutti i progetti calcolando il tempo di esecuzionedella computazione. Gli output dello script sono stati riportati per mostrare itempi di esecuzione su diverse macchine.

L’analisi per la ricerca di cloni è piuttosto semplice anche se fornisce un’altapersonalizzabilità. L’esecuzione è rapida come si evince dai risultati sperimentalidove i tempi di calcolo sono stati di soli cinque secondi sulla configurazione menoperformante.




Algorithm 3.1 Script per estrarre un file project di descrizione del programma

#!/bin/bash

source /opt/bauhaus/bauhaus-tools/bauhaus-kshrc

for file in *;

do if [ -d $file ];then

echo $file;

cd $file/build;

time find -name *.class > jasper.prj;

time java2rfg -project -B ../src jasper.prj jasper.rfg;

cd ../..;

fi

done

Il tool è clones e come parametri minimi per un corretto funzionamento richiede

di specificare il linguaggio dei sorgenti, un pattern per i file da includere, ilformato di output e la cartella in cui cercare ricorsivamente i sorgenti.

Un esempio di comando è il seguente: clones -lang java -file_patterns *.java

-outformat cpf src >> clones.cpf.

3.7.5 Bug

In questa sezione riportiamo alcuni problemi riscontrati nell’utilizzo di Bauhaus.Il primo è dato dall’impossibilità di avviare e utilizzare l’interfaccia grafica su

sistema a 64 bit. Non è stato possibile verificare se con una versione adeguata

all’architettura si risolvano questi problemi ma si suppone di si: è stata infattiusata l’unica versione a noi disponibile che supportava architetture a 32 bit.Nell’utilizzo del programma invece si sono verificate delle schermate di errore

nell’utilizzo di alcune funzioni. Questo in genere non è un problema ma loabbiamo riportato per due motivi:

• in alcuni casi l’errore portava alla chiusura del programma

• spesso l’errore dipendeva dal fatto che la funzionalità richiesta non eradisponibile per il linguaggio supportato

Per queste ragioni riteniamo che sarebbe meglio evitare questi errori in modo da

rendere il lavoro dell’utente più fluido.Questi sono alcuni degli errori riscontrati durante l’utilizzo del programma.

Non sono errori gravi in quanto non compromettono il corretto funzionamentodel programma ma riducono l’usabilità per l’utente.




Figura 69: Errore che si presenta alla richiesta di riordinare i nodi secondo uno specificolayout e porta alla terminazione del programma

Figura 70: Quando si cerca di aprire un package con doppio click viene mostrato questoerrore perché non c’è, evidentemente, un file di codice di definizione delpackage

Figura 71: Bauhaus fornisce un ottimo supporto alla selezione di nodi e archi: permette

ad esempio di aggiungere alla selezione i discendenti, archi entranti e uscentie molte altre varianti. Si verifica però questo errore quando si sceglie l’opzioneDeselect nodes; bisogna invece scegliere Deselect all

Figura 72: Nei plot per la rappresentazione di informazioni metriche, impostando comeassi alcuni criteri si ottiene un grafico vuoto con gli elementi tutti spostati nellaparte superiore della finestra. In figura il riquadro rosso segna dove dovrebbeessere il plot, notiamo che manca anche il riquadro, mentre tutti gli elementi sicondensano in quella riga grigia nella parte superiore della schermata.





La documentazione disponibile online è scarsa o pressoché inesistente ma questacarenza è compensata da una guida completa fornita assieme alla suite. Per gli

utenti registrati, ovvero quelli in possesso di una licenza, è disponibile accedere aun servizio di supporto [Axivion].

Nella guida sono spiegati in dettaglio tutti i passaggi relativi all’installazione,un tour dell’applicazione che introduce alle tecniche e alle funzionalità, una guidaai comandi utilizzabili da linea di comando, una guida all’analisi dei linguaggisupportati, una parte sul visualizzatore grafico, una guida allo scripting e infineuna appendice su alcuni argomenti minori.

La densità e il livello di dettaglio forniti sono tali da coprire abbondantemente lenecessità dell’utente che utilizza per la prima volta Bauhaus. Si rimanda pertantoa quest’ultima per qualsiasi dubbio e approfondimento necessario.



4L A T T I X

Lattix LDM (Lattix Dependency Models) è un software parte di una più ampiasuite, cui scopo è la generazione di DSM, dependency/design structure matrix,struttura molto usata in ambito gestionale-organizzativo, e la definizione di DR,design rules, a partire da tali matrici, da usare come strumento di guida alla stesuradell’architettura software [Sangal, 2007].

Il programma può analizzare progetti software in vari linguaggi, ed il supportoa Java è nativo e non richiede tool esterni. I progetti Java sono preferibilmenteforniti al programma come file .class, forniamo quindi la cartella build tipicamente.

Una DSM si presenta come una matrice quadrata, e la lettura è la seguente:

• M[m, j ] = # reference di moduli che usano il modulo m

• M[i,n ] = # reference a moduli usati dal modulo n

• M[k, k ] = % del progetto rappresentata dal modulo

La prima fase dell’approccio d’analisi proposto dai creatori del software è ovvia-mente la generazione della matrice per l’intero progetto; il passo successivo èl’individuazione di gerarchie tra i moduli software: per esempio, un modulo chenon ha alcuna dipendenza uscente, ma molte entranti, è probabilmente vicino laradice della gerarchia.Il workflow di analisi prevede poi l’ordinamento ed il raggruppamento di mo-duli secondo le gerarchie individuate: ciò permette di individuare anomalie inmodo diretto, ed è il punto di partenza, se desiderato, per l’individuazione dianti-pattern.Una funzionalità molto interessante del software è la gestione delle design rules,che assieme al modello DSM costituisce il modello di dipendenza nella sua inte-rezza. Una DR è un vincolo di dipendenza impostato dall’architetto che guida ilprocesso di sviluppo, ed è di supporto nella prevenzione di anti-pattern.

Infine, come molti tool di analisi software, anche Lattix LDM è in grado dimostrare all’utente varie metriche tipicamente OO.

Completa il quadro delle funzionalità principali una funzionalità di reporting, convari possibili formati di output (.xls, .csv, .xml...).

Il software è multipiattaforma e di facile installazione, il sistema di DSM per-mette l’individuazione di anti-pattern comuni a colpo d’occhio e l’approccio DRè un valido sistema di “paletti” per ripararsi da uno sviluppo controproducente.D’altro canto, il software assume che la divisione in moduli del progetto da analiz-zare sia stata fatta con perizia, e la visione d’azione è sì “glocale” ma rilevante soloquando ci atteniamo alla granularità package, cioè non svolgendo il package per

85



4.1 analisi 86

avere gli score classe per classe: infatti in questo secondo caso la vista è dispersivaed inefficace (la matrice diviene sparsa). Ciò si dovrebbe attenuare adoperandoLattix LDM come plugin di Eclipse, avendo in tal modo una corrispondenzaimmedita con il codice. Notiamo anche che la versione standalone è comunque

necessaria a tal proposito, per la creazione dei progetti di lavoro.

4.1 a na l is i

Nota: con il termine classe intenderemo da qui in avanti un qualsiasi tipo distruttura del linguaggio Java (classi, interfacce, enum . . . ).

4.1.1 Premessa

Una limitazione, anche se ragionevole, è che la versione di valutazione, gratuita,

non può analizzare progetti con più di 1000 file: in Java quindi questo è il numeromassimo di file caricabili di tipo classe (atomi).Vista tale limitazione, non è stato possibile valutare l’orizzonte evolutivo delprogetto su tutte e cinque le release principali nella loro interezza, e si è staticostretti a selezionare un sottosistema, individuato come cuore dell’applicativo, equindi presente in tutte le release, ma allo stesso tempo di dimensione inferioreal limite. In particolare sono stati individuati i package:

• engine

• view

• xml

Il codice non è ben commentato, ma da quanto si può intuire:

• l’engine come previsto fornisce funzionalità di supporto base, dalle classiper definire la struttura di un report fino a quelle necessarie a riempirlo condati

• anche per il package view non ci sono sorprese diciamo, troviamo le classiper la GUI; nota: sono state generate automaticamente con un tool grafico, JForge, certificato da Novell, la cui ultima release data 1999

• è quasi scontato che un’applicazione moderna di reporting si basi su questolinguaggio, nel package xml troviamo classi di servizio per la scrittura di xmle l’import di questi file, ogni elemento del documento testuale è mappatoin un elemento base componente del report

Solo nella prima versione questi tre package sono separati; nelle successive xml èsottopackage di engine.



4.1 analisi 87

4.1.2 Panoramica quantitativa

Ecco una panoramica quantitativa di questo sottosistema, focalizzandoci sulnumero di classi nel tempo e mettendo in evidenza il loro peso rispetto al numero

totale di classi nelle release:

r el ea se c la ss i a lt re t ota le t ota le p ro ge tt o p es o

0 76 1 77 77 100%

1 300 59 359 566 63.4%

2 509 104 613 925 66.3%

3 579 131 710 1039 68.3%

4 805 195 1000 1526 65.5%

Tabella 8: Panoramica quantitativa

L’ultima versione è stata rilasciata lo scorso aprile, mentre la prima è datata2001, e questi numeri sono testimoni di quel che è la storia di questo progetto: natocome progetto individuale, cui nome originale era già JasperReports, è stato poiacquisito da una società, la Jaspersoft, nel 2004, ed è tuttoggi uno dei prodotti dipunta di tipo free di questa: i package application core sono rimasti e l’architetturaprogettuale si è arricchita attorno ad essi.

4.1.3 Il DSM del progetto JasperReports

In questa sezione vogliamo investigare i pesi dei vari package componenti edisolare casi di dipendenze tra essi.

Come possiamo vedere, il package dedicato alla gestione dell’interfaccia graficaè poca cosa rispetto al motore applicativo, la componente di modello.

Addentrandoci quindi nel package engine, si hanno una serie di classi e varialtri package; tra di essi anche il package xml, originariamente indipendente, chenon è però il più rilevante, giacchè maggiori sono i package fill ed export: parteimportante del codice è allora concentrata nelle classi delegate alla creazione direport da fonti di dati lette ed al loro export in formati standard.

La scacchiera delle dipendenze non segna eccessivi picchi, ma si nota l’altonumero di dipendenze che lega le classi dei sottopackage fill, export, type ed engine

a quelle presenti in engine: non è necessariamente una situazione grave, o megliouna valutazione più chiara richiederebbe ulteriori approfondimenti; tutto quel chesi può dire è che l’accoppiamento ha anche difetti, come per esempio la necessitàdi cambiamenti a cascata in caso di modifiche a classi molto puntate.



4.1 analisi 88


Lattix LDM non è stato concepito per svolgere individuazione di anti-pattern,ma similmente ad altri tool le metriche e le strutture fornite possono aiutare ad

individuare alcuni anti-pattern piuttosto che altri.Anzitutto, la struttura del sistema è ben riconoscibile, e con ciò intendiamo,

essendo un progetto Java, che la architettura dei package è stata ben definita; inrealtà essa è chiara già fin dalla release 0, nella corrente è più composita per lamaggior maturità del progetto non solo in termini di funzionalità: non siamoquindi in presenza di un big ball of mud project, anche se era quasi certo nonsarebbe stato questo il caso.

Il sistema appare fondato su di un paradigma MV , Model-View, infatti le logichedi controllo non paiono esplicitamente isolate, almeno ad una prima analisi. Ilcodice necessario alla gestione della GUI, il package view è separato, seppureformi solo il 2% del sottosistema preso: non è allora nemmeno il caso di Magic

pushbotton pare.L’analisi con X-Ray ad esempio suggerisce la classe JRBaseFactory avere un

numero NOC (Number of children) troppo alto. Concentrandoci su questa classein Lattix salta subito all’occhio il numero di dipendenze singole che essa ha neiconfronti di altre classi nello stesso package: 70; ciò può o meno essere un effettivoproblema da risolvere, e nel caso lo sia, è possibile aiutarsi impostando una regola.


Nell’investigare la presenza di eventuali code smell, facciamo affidamento esplicitoalle metriche fornite oltre che alla struttura DSM.

L’autore ha, per propria curiosità, aperto delle classi del progetto, a campione,una ventina. Il numero è assai esiguo viste le dimensioni del progetto, ma circa lametà sono risultate classi esclusivamente di comodo, che fanno poco, rivelando ilcode smell denominato Freeloader, che vuole intendere quegli elementi che sono sìcaricati in uso al programma, ma che hanno compito marginale e potenzialmenteassimilabile altrove.

D’altro canto, ben più noto è il problema duale, quello dei cosiddetti God objects,elementi contraddistinti sostanzialmente dall’essere troppo estesi e troppo ricchidi funzionalità.

Volendo sfruttare appieno le funzionalità offerte dal programma una proceduraeuristica manuale per l’individuazione del code smell God class (Freeloader)potrebbe essere la seguente:

1. espandere la metrica di sistema Line Count dalla radice (caso base)

2. individuare la classe ed il package a LOC massimo (minimo)

3. se è più alto (basso) il LOC della classe ed il valore è davvero significativo,esaminarla in quanto potenziale God class




Figura 73: Focus sulla classe JRBaseFactory

4. se è più alto (basso) il LOC del package

5. ripetere dal punto 1

L’individuazione di questi due particolari code smell non è comunque troppoagevole in Lattix LDM: non è obiettivo del software.


Forniamo un’analisi dell’evoluzione del progetto integrando alle matrici DSMl’applicazione delle metriche a disposizione su ognuna delle cinque versioni sottoesame.

Come visto in tabella 8 il sottosistema preso in esame, composto dai duepackage view ed engine, infatti xml è al momento sottopackage di engine, costituiscegran parte dell’applicativo. Volendo, si potrebbe assimilare al solo package engine

il progetto: questo ha senso anche perchè, in prima istanza, JasperReports sipresenta come una libreria.

Può essere ora di qualche interesse, avendo le DSM di tutte e cinque le versioni,osservare il peso di alcuni sottopackage di engine che abbiamo visto essere rilevantinell’ultima release; essi sono presenti dalla release 1.0.0 in poi.




Figura 74: La root DSM per ciascuna delle cinque release in ordine

r el ea se x ml f il l e xp or t t otal e

1 13% 25% 4% 42%

2 12% 25% 10% 47%

3 11% 22% 12% 45%

4 10% 18% 18% 47%

Tabella 9: Peso sotto-package

Da questa tabella vediamo che le cose non sono cambiate poi tanto durante glianni e che il gruppo applicativo formato da questi package ammonta sempre al45% circa dell’applicazione.

Controlliamo ora quanto queste componenti siano sfruttate dall’applicazione:se vogliamo contare le dipendenze nella vista corrente, basta semplicementesommare i valori della riga d’interesse; le dipendenze che contiamo saranno

quelle entranti al package e provenienti dalle altre classi nel package engine edagli altri sottopackage di questo (cfr tab Information, Usage).

4.2.1 Metriche architetturali

È ora il momento di confrontare le differenti release rispetto a metriche piùparticolari [Fenton and Pfleeger, 1998], sempre offerte da Lattix LDM e riferiteall’architettura nel suo complesso; per ognuna ricordiamo brevemente qual è il

r el ea se x ml f il l e xp or t t otal e

1 34 9 106 149

2 43 24 26 93

3 10 28 31 79

4 9 33 39 81

Tabella 10: Panoramica dipendenze




suo significato.

Figura 75: Metriche assortite. Si può chiedere al sistema di generare tre distinti tipi dimetriche, di sistema, d’architettura ed orientate agli oggetti

1. Stabilità: una misura di quanto sia sensibile il sistema al cambiamento,poiché indica la percentuale di elementi che, nel caso medio, non è toccatada una modifica del sistema

2. Impatto medio: l’impatto per il cambiamento di una classe è il numero dialtre classi che potenzialmente andrebbero modificate, questo è il valore dimedia su ogni classe

3. Numero dipendenze: la somma di tutte le dipendenze interne

4. Complessità: una delle possibili metriche per definire quanto sia “intricato”un sistema

5. Connettività: la percentuale di elementi che direttamente od indirettamentesono in dipendenza da altri, quindi quelle classi per le quali, nel grafo delle

dipendenze, esiste un cammino che parte da esse e termina in un’altra classe

6. Accoppiamento: percentuale delle componenti fortemente connesse nel grafodelle dipendenze; una componente fortemente connessa nel grafo rappre-senta una cricca interdipendente

Il calcolo di tutte le metriche supportate è illustrato con chiarezza nella KB.Abbiamo quindi i seguenti valori:

Analisi dei risultati.




m et ri ca o.x .x 1.0 .0 2 .0.0 3 .0 .0 4.0 .2

1 86% 76% 77% 78% 65%

2 11 98 145 153 351

3 221 2191 3393 4260 6576

4 0.002 0.089 0.208 0.302 0.658

5 14% 24% 23% 22% 35%

6 1% 5% 6& 4% 16%

Tabella 11: Metriche Architetturali

1. una successione della stabilità non crescente ci suggerisce che l’interdipen-denza del sistema è cresciuta nel tempo; non ci sentiamo di vedere questa

situazione come negativa, anche perché i valori non sono così bassi

2. rapportando questi valori al numero totale di classi per ciascun progetto,deduciamo che cambiando una classe a caso, nella prima release signifi-cherebbe cambiare, al peggio, il 14%, nell’ultima il 35%; riteniamo ancorauna volta accettabile questa situazione, figlia di una maggiore ricchezza difunzionalità, anche ancillari

3. il numero di dipendenze va contestualizzato rispetto alle altre metriche,per esempio il numero totale di classi o l’impatto; la statistica è cresciu-ta enormemente nel tempo: maturità del programma od organizzazione

povera?

4. la complessità del sistema rimane bassa, ed essendo calcolata come pro-dotto tra atomi ed archi normalizzato, i valori sono ragionevoli: un pro-gramma con numero di dipendenze non esorbitante, tipico di una libreriasostanzialmente automatica

5. la connettività, come tutti gli altri valori, trova il suo picco nell’ultima release;essa è il duale della stabilità, e quindi le considerazioni da farsi sono daricondurre alla stabilità

6. il valore di coupling ha un vero e proprio balzo nell’ultima release; questa in-dicazione è da non sottovalutare, anche nell’ottica di un’eventuale refactoring

del progetto: vengono ad individuarsi cluster di componenti interdipendenti,ed una volta individuati, se già non lo sono, si potrebbe riunirle in unmedesimo package




m et ri ca o.x .x 1.0 .0 2 .0.0 3 .0 .0 4.0 .2

1 0.067 0.273 0.255 0.292 0.316

2 0.791 0.803 0.739 0.781 0.930

3 0.175 0.203 0.156 0.172 0.200

Tabella 12: Metriche OO su JasperReports

4.2.2 Metriche OO

Un altro gruppo di metriche molto interessanti fornite da Lattix è quello dellemetriche object-oriented, dalle quali possiamo trarre grande vantaggio dato chestiamo lavorando in Java.

Di quelle fornite, scegliamo le tre principali:1. Astrattezza: è appunto la misura di quanto sia astratta un’architettura, ossia

il numero di classi dichiarate abstract; si calcola come semplice rapporto

2. Instabilità: questa metrica OO è di semantica abbastanza differente dallaStabilità di sopra; valuta quanto un sistema sia da ritenersi stabile, prescin-dendo da eventuali modifiche a classi ma concentrandosi sul tessuto diinterdipendenze tra classi

3. Distanza: la metrica è funzione diretta delle precedenti, è la distanza dallaretta di sequenza principale nel piano Astrattezza X Instabilità; basta po-

sizionarsi in un punto (astrattezza, instabilità), argomento, e calcolare ladistanza tra esso e la retta passante per (1,0) e (0,1)

Queste metriche devono essere valutate a livello di package, non di singolarelease nella sua totalità; un’idea è allora valutarle sul package principe, engine,confrontando attraverso il cammino evolutivo. Per la 0, dovremo considerare disommare il contributo di xml anche, perché nelle successive è contenuto in engine,se vogliamo essere omogenei.

Abbiamo quindi i seguenti valori:Analisi dei risultati:

1. partiamo con la release iniziale, dove l’uso dell’astrazione è molto basso, percrescere poi, anche se non monotòni, fino all’ultima release dove circa il 30%delle classi è astratto. Intendiamo ciò come una maturazione del gruppo disviluppo, che peraltro sappiamo anche essere cambiato, nel tempo: maggiorepadronanza dei concetti OO

2. l’instabilità si mantiene sostanzialmente costante fino all’ultima release,dove cresce e non di poco. Lo spirito di questa metrica è accostare un assettonon troppo affidabile ad un’implementazione ricca di dipendenze, specie



4.3 m i gl i or a me n ti p o ss i bi l i 94

dirette. Quel che emerge è che, in media, per ogni dipendenza uscente ce n’èquasi una entrante, in ogni classe; la soluzione può essere talvolta adoperareancora l’astrazione

3. possiamo sostenere che la distanza è ragionevolmente costante durante tuttol’arco di vita del progetto. Questo è sicuramente assai positivo perché denotauno sviluppo lineare nel tempo, grazie al quale la qualità del progetto intermini di affidabilità rimane la stessa, ed è un dato importante considerandoi cambiamenti vissuti dal progetto

4.3 mi gli or a menti po s si bili

4.3.1 Suggerimenti per migliorare il tool

Lattix LDM è sicuramente un buon tool nell’unire una struttura formale mavisivamente interessante come la matrice DSM e le più importanti metriched’analisi, ad un sistema di gestione delle regole per uno sviluppo guidato econtrollato. Analizzando un progetto già esistente il nostro sforzo in questasezione è evidenziare in modo oggettivo i punti di debolezza di questo toolsoprattutto nell’ambito della prima componente, quella di analisi quantitativa.

• Scalabilità: la struttura DSM è di per se orientata a fornire una valutazionechiara del sistema in una prospettiva globale, anche se come detto si puòpassare arbitrariamente dalla visione d’insieme ad una granularità di classe.Infatti, continuando ad estendere la matrice espandendo i package, si arriva

presto ad una struttura troppo estesa e di bassa significatività date propriole sue dimensioni. Un’idea potrebbe essere trovare una rappresentazionepiù conveniente della matrice una volta raggiunta una certa dimensione conle espansioni

• Acquisizione: Lattix LDM per Java può leggere progetti da file .zip, .jar edalberi cartelle. Lavora con file .class, richiedendo quindi il build del progetto,e questo è raramente un problema, se supportati da un ambiente di sviluppo(es. Eclipse). Dovrebbe però essere possibile analizzare un progetto partendodirettamente dal codice non compilato

• Anti-pattern triggering: una funzionalità che si potrebbe pensare come esten-sione al programma è il suggerire alcuni possibili anti-pattern a partire dafunzioni sulle metriche calcolate; come abbiamo osservato nella relazionealcuni anti-pattern sono rintracciabili da un’analisi quasi esclusivamentequantitativa del codice, non semantica, e quindi questo è il caso

• Interfaccia: la quantità d’informazione fornita dal programma è davvero alta, bisognerebbe forse lavorare sull’interazione utente, per evitargli ogni voltadi andare a fare mining per trovare quel che gli serve




Il giudizio personale è comunque sia positivo, e queste debolezze sono in realtàtrascurabili od alleviate una volta che si diventa pratici del tool.

4.3.2 Suggerimenti per migliorare JasperReports

Nonostante sia nato come un progetto gestito da un unico programmatore, ilsoftware ha saputo mantenere negli anni una medesima linea architetturale ed ècomunque da promuovere, anche per la notorietà che ha raggiunto. Dando una

breve analisi al diagramma package con la DSM, i nomi ed i contenuti delle classipotrebbero suggerire sia stato adottato il DP Abstract factory. Considerando ildominio e lo scopo dell’applicazione, una soluzione potrebbe essere integrare conil DP Facade.

I successivi sviluppi potrebbero dover tener conto di metriche di valutazione,anche come quelle discusse sopra, per salvaguardare la salute del sistema; in

particolare si ritiene che ci si debba sforzare di mantenere la stabilità non inferioreal 55-60%.


4.4.1 Tempistiche d’analisi

La release più estesa è la 4.1.2, e per essa, che rappresenta il caso peggiore, laperformance media è stata più che sufficiente:

• creazione progetto: 11s

• popolazione DSM: istantanea

• calcolo metriche: 9s

Una metrica è calcolata o meno dal tool in base alla grandezza del parametro adessa in input, per evitare di affaticare il processo: infatti qualche metrica è cubicanel numero di classi, ed un progetto medio-grande può arrivare a contarne ancheun paio di migliaia. Questa impostazione può essere cambiata modificando il filedelle preferenze del programma.

4.4.2 Installazione

L’installazione non è standard, poiché l’eseguibile si può scaricare liberamente,ma la chiave di licenza per poterlo utilizzare in modalità trial è inviata manual-mente dal team Lattix LDM previa lettura di una richiesta mail dell’utente; salvoquesto dettaglio, la modalità d’installazione non presenta altre particolarità. Ilprogramma è distribuito sia per Windows sia per Linux, sia standalone sia comeplugin Eclipse.




4.4.3 Bug

Non sono stati scoperti bachi durante l’utilizzo del sistema.


A ricercare sul web, Lattix LDM non sembra un software estremamente famoso,ma è abbastanza usato come tool di analisi quantitativa statica.

La documentazione non-ufficiale è scarsa, ma in compenso, anche con la ver-sione di prova, si ha accesso ad una Knowledge Base privata (http://kb.lattix.com).La KB è esaustiva, copre tutti gli argomenti di utilizzo, e con precisione: non sidilunga eccessivamente su ogni aspetto ma è scritta per essere chiara e di rapidaconsultazione. Da notare il manuale utente, aggiornato all’ultima branch, ed unostudio di caso sul noto software di build Ant.

Figura 76: La Knowledge Base ufficiale Lattix LDM - http://kb.lattix.com



5S A 4 J

Structural Analysis for Java (SA4 J) è un tool che analizza le dipendenze strut-turali delle applicazioni Java, per misurare la loro stabilità. Rileva anti-patternstrutturali e fornisce strumenti per effettuare la navigazione delle dipendenze perl’esplorazione dettagliata di anti-pattern. SA4 J permette anche l’analisi "what if"per valutare l’impatto del cambiamento sulle funzionalità oltre ad offrire lineeguida per il re-factoring dei packages.

5.1 a na l is i

L’analisi dettagliata verrà applicata soltanto all’ultima versione del software targetper riuscire a trarre delle conclusioni sul progetto. Nella sezione analisi evolutivaverranno analizzate tutte le versioni con ogni metrica disponibile.


SA4 J mette a disposizione dell’utente una buona quantità di anti-pattern struttu-rali riconoscibili automaticamente.

Gli anti-pattern riconoscibili tramite SA4 J sono:

• Local butterfly: oggetti con molti dipendenti diretti;

– possono essere interfacce di base, classi di base astratte e utilities;

• Global butterfly: oggetti con un gran numero di dipendenti globali;

– possono essere interfacce di base, classi di base astratte e utilities;

• Local breakable: oggetto con molte dipendenze locali;

• Global breakable: oggetti con molte dipendenze globali;

– sono indice di una perdita di modularità nel sistema ;

• Local hub: oggetti con molti dipendenti e dipendenze dirette;

• Global hub: sono degli anti-pattern ibridi tra i breakable globali e le global butterfly;

– sono spesso interessati quando qualcosa nel sistema viene modificato;

– interessano una percentuale significativa del sistema;

97



5.1 analisi 98

– indicano che il sistema non è ben concettualizzato ed ha un’altainstabilità;

• Tangle: dipendenze circolari interfacciate;

– se un oggetto in un tangle viene modificato, tutti gli oggetti nel tanglesono interessati.

Notiamo nella figura 77 come il software target sia in possesso di alcuni anti-pattern.

Figura 77: Anti-pattern Summary

Iniziamo ad indagare dai 34 Tangle, che sembrano essere gli anti-pattern piùcritici che potrebbero compromettere la stabilità del software.

Vediamo come vista “Explorer” non ci fornisce molte informazioni, a causadella numerosità delle classi appartenenti al tangle.

La stessa vista però ci fornisce più informazioni quando andiamo ad investigaresu un secondo tangle.



5.1 analisi 99

Figura 78: Tangle

Figura 79: Tangle

In questo caso possiamo subito notare come il package engine e il package util

sono le principali cause di questo forte tangle di 163 dipendenze. Un possibilerimedio potrebbe essere quello di diminuire le dipendenze verso questi due



5.1 anal isi 100

package suddividendoli ulteriormente per limitare le loro interazioni con altripackages.

Gli altri tangle presenti nel codice non risultano abbastanza significativi daessere riportati.

Passiamo ora a visionare i Global Hub presenti nel codice. La vista “Summary”definisce che nel codice sono presenti 423 Global Hub, ovvero il 13% degli oggettiin totale. Vediamo come la vista “Explorer”, anche in questo caso, non ci aiutiabbastanza a causa delle dimensioni del software target. Inoltre non permette divisionare i Global Hub più significativi in base al numero di entità coinvolte.

Analizzando dunque tutti i 423 Global Hub, notiamo quello che a vista pare ilpiù significativo (vedi figura 80).

Figura 80: Global Hub

JasperDesign sembra essere la classe che con più probabilità necessità di refacto-ring per diminuire le dipendenze con tutte le altre entità.



5.1 anal isi 101

Figura 81: JasperDesign

Da questa info-box notiamo come la classe JasperDesign sia affetta da qualsiasitipo di anti-pattern riconoscibile dal software. Questo ci fa pensare ad una scorretaprogettazione di questo modulo. Sarebbe stato interessante vedere che tipi dimetodi fossero presenti nella classe per capire se fosse stato legittimo questo altolivello di dipendenza con altre classi e interfacce ma purtroppo il tool non cipermette di visionare il codice mentre si utilizzano le viste.

Passiamo poi ad un vista caratteristica di SA4 J chiamata Skeleton. Questa vistaci permette di vedere in maniera concisa la mappa delle dipendenze del sistema,oltre agli anti-pattern riconosciuti (Butterflies, Breakables, Hubs and Tangles) e

all’impatto ai cambiamenti di codice.

Figura 82: Skeleton view

La guida presente nel software ci informa che un buon skeleton di un progettodovrebbe assomigliare il più possibile ad un triangolo rettangolo. In realtà questoskeleton ne ha solo una leggera parvenza, infatti l’ultima riga di oggetti continuaper circa 8 lunghezze della riga superiore.



5.1 anal isi 102

Possiamo notare la presenza di svariati Tangle nella parte alta del “triangolo”.Cliccando su uno dei primi scopriamo che il Tangle in questione ha un sacco diclassi e di ulteriori Tangle che gli dipendono. Gli oggetti colorati di giallo sonoquelli che verrebbero modificati se il Tangle cerchiato di rosso venisse alterato.

Continuando l’analisi progettuale passiamo alla vista “What if” che rappresentatutti i packages in una sola vista, permettendo di visualizzare le dipendendzedelle classi. Questa funzionalità risulta utile per vedere la distribuzione delleclassi nei vari packages, ma sostanzialmente poco d’aiuto per visualizzare ledipendenze dato che la vista diventa molto confusionaria in un progetto di grandidimensioni.

Figura 83: What if view

Notiamo che alcuni packages hanno soltanto una classe al loro interno, mentrealtri superano le 160 classi. Questo può risultare strano e forse anche scorretto,ma spesso accade che alcuni packages vengano creati soltanto per una classe.Accade quando la funzionalità implementata è una funzionalità secondaria al

goal del progetto, ma che comunque risulta indispesabile (ad esempio downloadaggiornamenti, stampa, etc..).Quando invece i packages diventano di dimensioni troppo elevate, è più pro-

babile che sia una scorretta progettazione architetturale. Infatti notiamo che ilpackage fill è quello con più classi/interfacce (176). Notiamo come la gran partedegli anti-pattern siano compresi proprio in questo package e nel package engine,anchesso di elevate dimensioni (133 entità). Dunque possiamo trovare una relazio-ne tra il numero di classi nello stesso package e il numero di anti-pattern rilevabili.



5.1 anal isi 103

È per questo che sarebbe preferibile ridurre le dimensioni dei packages in manierasensata, lasciando soltanto le classi con funzionalità puramente intrinseche alpackage padre.

La funzionalità della vista “What if” per visualizzare le dipendenze risulta

invece abbastanza incomprensibile, come si puo’ notare nella figura 84.

Figura 84: What if view- Dependency

Ulteriore vista che ci permette di trarre informazioni utili riguardo l’analisiprogettuale è la “Inheritance view”, che a differenza di altre viste, è molto “userfriendly”, infatti mette a disposizione un pratico menù a scorrimento che permettedi notare in maniera veloce possibili disarmonie nel codice. In questo caso sitrattano di disarmonie relative ad ereditarietà troppo elevate.

Infatti, spesso è utile avere classi con alta ereditarità dato che aumenta illivello di riuso del codice, però a volte si perde il senso e si cade in errore.Spesso si cerca di inserire nelle classi figlie legittime, anche alcuni classi che per“comodità” potrebbero risultare utili, anche se magari fanno parte di un dominio

completamente diverso.Questo pensavamo fosse il caso della classe JRBaseFactory con le sue 147 classi“figlie”, ma in realtà ci siamo accorti che attraverso la lettura dei nomi delle classi,queste risultavano più che legittime.



5.1 anal isi 104

Figura 85: JRBaseFactory


Partiamo subito con l’identificazione delle dimensioni del progetto in questione.Tramite la vista “Summary” possiamo accorgerci che JasperReports può esseredefinito come un software di grandi dimensioni dato che possiede 69 packages.

Purtroppo SA4 J non offre una funzionalità che conti il numero di classi, di metodio di linee di codice. Offre soltanto il conteggio degli oggetti, che però non èsignificativo dato che il tool non specifica cosa si intende per oggetti.

Figura 86: Statistics

Per quanto riguarda l’identificazione di code smell possiamo basarci sulla pre-senza di funzionalità che ci permettono di avere una buona quantità di metricheda poter consultare.

Partiamo con la vista Local Dependencies che ci permette di visualizzare ledipendenze entranti e uscenti, oltre a informazioni di carattere più specifico.



5.2 a na l is i e v ol u ti va 105

Notiamo fin da subito, che la classe con più dipendenze è la JRApiWriter con285 dipendenze.

Figura 87: JRApiWriter

Notiamo invece che la classe che possiede più classi dipendenti è la JRExpression

con 434 dipendenze.

Figura 88: JRExpression

Anche la vista “Global dependency” ha sottolineato i risultati appena mostrati.


L’analisi evolutiva di JasperReports, tramite SA4 J, è stata abbastanza difficoltosa acausa della lentezza del software nel caricare i progetti, e della sua scarsa gestionedella memoria. Inizialmente avevamo pensato di confrontare i vari risultati delleviste per ogni versione del software, memorizzandole tramite la funzionalitàapposita. Ci siamo accorti pero’ che il risultato, in particolar modo quello delleimmagini, non era all’altezza, ed è per questo che abbiamo deciso di effettuaredegli Snapshot delle viste per confrontarle.

Come possiamo notare, inizialmente il progetto era composto da 3 packagessoltanto. Notiamo subito un errore prodotto da SA4 J che riporta nel summary 5

packages, anche se poi nella vista “What if” ne vediamo soltanto 3 (come è giustoche sia). Continuando vediamo che il valore degli anti-pattern Global Breakable eGlobal Butterfly è abbastanza elevato. Notiamo inoltre come la distribuzione delleclassi nei packages rispecchi anche la presenza di anti-pattern. Infatti notiamo cheil package engine è quello più popolato sia di classi che di anti-pattern. Inoltrepossiamo notare come la stabilità del software non sia propriamente positiva,dato che un software per essere stabile, deve avere un valore superiore al 90%.

Passiamo ora ad analizzare la versione 1.0.0 di JasperReports.Notiamo subito come il numero di packages sia aumentato. Bisogna tener

presente che SA4 J ha una visione un po’ distorta dei packages, infatti li considera

sia come folder/directory che come package veri e propri.Notiamo piacevolmente la diminuzione degli anti-pattern in maniera significa-tiva. Presumiamo che sia avvenuto un refactoring dalla prima versione. Infattigli anti-pattern che prima erano presenti persino al 33% (Global Butterfly) orasono quasi 1/3 (12%).nte aumentato. Questo parametro solitamente comportaun aumento degli anti-pattern, ma in questo caso tutto cio’ non avviene grazieall’ottima progettazione. Anche la stabilità del software è aumentata di moltoportandosi al 93% (valore sopra la soglia).




Figura 89: JasperReports 0.x.x

Figura 90: JasperReports 1.0.0




Passiamo ora a visionare le versioni 2.0.0 e 3.0.0 del software, le quali siassomigliano molto.

Figura 91: JasperReports 2.0.0 & 3.0.0

Infatti notiamo come i packages siano aumentati, come del resto gli oggetti(classi, interfacce) e le loro relazioni. Ma con grande stupore vediamo come ilnumero di anti-pattern raggiunga soglie bassissime. Infatti ci accorgiamo comenella versione 2.0.0 molti siano addirittura non presenti. Quelli presenti nonraggiungono percentuali che possano farci pensare a disarmonie gravi. Vediamoinoltre come nelle versioni 2.0.0 e 3.0.0 si raggiunga il valore record di stabilitàdel software (98%).



5.3 s u gg e ri m en t i p e r m i gl i or a re s a4 j 108

Passiamo ora alla versione finale del software target, la 4.0.2.

Figura 92: JasperReports 4.0.2

Il numero di packages sia diminuito, e così facendo, sia aumentato il numero dianti-pattern nel codice. Anche la stabilità del codice è diminuita, ma non è scesaa livelli che possono impensierire.

L’unico fattore, che è stato anche evidenziato nell’analisi precedente, è il numerodi Tangle che è sempre aumentato dalla prima versione fino all’ultima.

Possiamo dire che in generale JasperReports si è evoluto in maniera sensata ecostante, cercando di rimediare a problemi e disarmonie presenti nelle versioniprecedenti.

Notiamo un leggero calo nell’ultima versione, anche se le disarmonie presentinon risultano critiche.

5.3 s u gg er imenti per mi g li o ra r e s a4j

SA4 J è un tool con una buona struttura che però possiede una forte limitazione.Infatti la curva di apprendimento è molto lunga rispetto a software dello stesso

calibro, come ad esempio Analyst4 J.Le mancanze che possiamo sottolineare sono:

• carenza di ordine nelle viste polimetriche: mancanza di viste che permettanodi visualizzare in maniera semplice e comprensibile la struttura del progettoanalizzato.

– mancanza di poter spostare le entità dei diagrammi;

– mancanza di autoordinamento delle entità;




– mancanza di visibilità dei diagrammi;

• mancanza di scalabilità: SA4 J manca di scalabilità praticamente in ogni vista,fornendo una quantità di informazioni così elevata e così poco strutturata

che confondono l’utilizzatore.– mancanza di visibilità dei nomi delle entità nella vista explorer;

– mancanza di scalabilità nella vista skeleton;

• mancanza di viste polimetriche: relative alle classi ai metodi o ai packegesche mostrino in maniera intuitiva le dimensioni di ogni entità.

• debole interfaccia grafica: carenza di chiarezza e di usabilità.

– spesso non permette all’utente di visualizzare in maniera corretta leinformazioni;

• impossibilità di vedere il codice sorgente.

– spesso risulta utile poter vedere il codice per accorgerci dell’importanzae della struttura delle entità software;

• mancanza di metriche per contare le classi i metodi e le linee di codice.

– risulta difficile farsi un’idea delle dimensioni del progetto senza averequesti parametri;

• permettere di visionare i Global Hub più significativi in base al numero dientità coinvolte.

– basterebbe un algoritmo di riordinamento basato sul numero di dipen-denze;

• migliorare la qualità dei report prodotti.

– aumentare la risoluzione delle immagini;

– produrre report in formato pdf;


In definitiva JasperReports pare un software ben progettato ed implementato.Non sono emerse particolari disarmonie nel codice durante l’analisi tramite il toolSA4 J.

Gli unici suggerimenti che ci sentiamo di esprimere sono:

• di diminuire il numero di entità contenute nel package fill;

– creare ulteriori packages contenenti le classi non propriamente intrin-seche del package fill.




• di diminuire il numero di entità contenute nel package engine;

– creare ulteriori packages contenenti le classi non propriamente intrin-seche del package engine.

• tentare di eliminare il Tangle che contiene JRFont;

– questo tangle è il più evidente ed è quello che secondo noi puòcompromettere in maniera decisiva la stabilità del sistema.

• tentare di eliminare il Global Hub presente nella classe JasperDesign;

– si potrebbe pensare di delegare alcune funzionalità secondarie ad altreclassi,meglio ancora in altri packages in maniera tale da poter eliminarequesta forte dipendenza.

• tentare di eliminare i piccoli bug presenti nel codice.

Seguendo queste semplici indicazioni si potrebbe diminuire in maniera significa-tiva la quantità di anti-pattern presenti nel codice, rendendo così ancor più stabileil software.


5.5.1 Tramite SA4 J

L’analisi con il tool SA4 J ha dato un risultato leggermente differente degli altritool precedentemente analizzati.

Possiamo notare come SA4 J indichi che il software analizzato presenta diversedisarmonie più o meno gravi.

Una nota positiva dall’utilizzo del tool è la stabilità del software target cheè del 95%. Dunque tramite l’utilizzo del tool SA4 J possiamo vedere come in

JasperReports ci siano anti-pattern di tipo:Global e Local Breakable e Global e Local Butterfly.Notiamo anche la presenza di Tangle e di Global Hub che però sembrano essere

di dimensioni inferiori rispetto agli anti-pattern appena citati.

5.6 c o ns i der azi oni f i na li s u s a4j

Possiamo definire SA4 J un buon tool dato che presenta una lunga serie di me-triche e funzionalità automatiche per il riconoscimento di anti-pattern, anche se,secondo il nostro parere, tutte le funzionalità presenti, a meno del Summury, sonoquasi inutilizzabili su progetti di grandi dimensioni. Ci siamo trovati difronte agravissime difficoltà nel tentare di ridurre le viste o di capire la quantità enormedi informazioni forniteci. Crediamo fermamente che l’utilizzo di questo tool suprogetti di grandi dimensioni sia quasi controproducente. Infatti a differenza di



5.6 c o ns i de r az i on i f i na l i s u s a4 j 111

altri tool, SA4 J riconosce una disarmonia praticamente in ogni classe del progetto.La maggior parte delle viste tabellari sono pressochè insigificanti data la dispo-sizione dei dati in maniera poco comprensibile. Persino la visualizzazione delledipendenze è stata resa indecifrabile.

Comunque sia non esistono soltanto note negative, infatti come abbiamo dettoprima, la vista summary tenta di placare la disorganizzazione del resto del tool edi raccogliere tutte le informazioni utili delle altre viste, esponendole in manieracomprensibile.


• facilità di installazione;

• non richiede di meta-files per eseguire le analisi, ma soltanto del codicesorgente;

• grande quantità di metriche disponibili;

• buona quantità di anti-pattern auto-riconoscibili;

• possibilità di creare report informativi (HTML, GIF);

• ottima funzionalità che permette di stimare la stabilità del software target;

• memorizza analisi già effettuate;

• buona vista che permette di visualizzare i packages nella loro integrità;

• ottima funzionalità di Help che permette di avere una dettagliata spiegazio-

ne della metrica utilizzata.Mentre i suoi difetti sono:

• impossibilità di visualizzare e modificare il codice sorgente mentre siutillizzano le viste;

• impossibilità di creare metriche;

• impossibilità di modificare schemi o diagrammi;

• impossibilità di poter confrontare metriche differenti;

• viste poco comprensibile e spesso di dimensioni troppo elevate da essererappresentate su una schermata sola;

• poca usabilità;

• non possiede funzionalità utili per il reverse engineering;


• qualità report scadente;




• interfaccia grafica scadente e poco stabile;

• conteggio dei package poco chiaro;

• utilizzabile soltanto su progetti open-source o di cui si possiede il sorgente.



Qui di seguito abbiamo una tabella contenente la configurazione della macchinautilizzata per testare SA4 J.

s-1

MS Windows 7 x64 bitIntel Core Duo 2.40 GHz

4.00 GB

Tabella 13: Configurazione macchina utilizzata


Segue una tabella con il valore tempistico dell’analisi su tutte le versioni di

JasperReports.

c on f ig ur az io ne v e rs io ne d i ja sp e rr e po rt s t e mp o

S-1 0.x.x 2 sec

S-1 1.0.0 14.70 sec

S-1 2.0.0 54.30 sec

S-1 3.0.0 55.40 sec

S-1 4.0.2 1.23 min

Tabella 14: Tempistiche di analisi con SA4 J su JasperReports

5.7.3 Installazione

Requisiti minimi

I requisiti minimi richiesti non sono assolutamente limitativi.




Requisiti software:

• Sistema operativo:

– Windows 2000 Professional, Service Pack 2, 3, o 4;

– Windows XP Professional, Service Pack 1;

– Windows NT, Service Pack 6;

– Red Hat Linux 7.2, 7.3, 8.0, 9.0;

– Red Hat RHEL WS 2.1;

– Sun Solaris 8, 9.

Requisiti hardware:

• PROCESSORE: Pentium III - 500MHz minimo; Pentium III - 1 GHz osuperiori, raccomandati;

• RAM: 256 MB minimo - 512 MB raccomandati;

• DISK SPACE: Minimo: 100 MB per l’installazione. 200 MB raccomandati peril workspace;

Versione standalone

L’installazione non ha richiesto particolare attenzione.Basta infatti scaricare l’installer dal sito [IBM, b] e seguire la seguente procedura:

1. download della versione opportuna del sistema operativo utilizzato; on

2. lanciare l’installer StructuralAnalysisForJava_WindowsSetup.exe.

5.7.4 Bug

Durante l’installazione del tool non è stato riscontrato alcun bug.Unici eventi anomali, ma che non si possono considerare bug, sono stati i

cambiamenti di visualizzazione grafica del sistema operativo durante l’utilizzodel tool e la lentezza nell’aprire alcune viste.

Pensiamo sia dovuto ad un problema di memory leak, dato che il tool fornisce

persino una barra che visualizza la memoria da lui occupata che stranamente nondescresce mai, anzi continua a crescere finchè il programma si semiparalizza.

Ulteriori eventi anomali sono stati riscontrati nel conteggio dei packages nelprimo progetto, dove il tool in una vista contava più package che in un’altra.





SA4 J offre una documentazione leggermente carente, a differena di altri tool.L’IBM, l’azienda produttrice di SA4 J mette a disposizione [IBM, a]:

• un breve tutorial on-line per effettuare l’installazione di SA4 J StandaloneVersion;

• una breve spiegazione sugli anti-pattern riconosciuti dal tool;

• un’utile funzionalità di help che spiega in breve le metriche e gli anti-patternriconosciuti;

• un forum (poco frequentato) e delle FAQ;

In definitiva la documentazione è scadente. Questo causa un’aumento della curva

di apprendimento del software.

Figura 93: Sito ufficiale di SA4 J



6X- R A Y

X-Ray è un plug-in open-source per il framework Eclipse. Fornisce viste perdeterminare la complessità di un intero sistema, dei suoi metodi, delle sue classie dei suoi package, oltre ad offrirci viste per comprendere le loro dipendenze.

6.1 a na l is i

L’analisi verrà applicata soltanto all’ultima versione del software target, perriuscire a trarre delle conclusioni sullo stato corrente del progetto, mentre nella

sezione “analisi evolutiva” verranno analizzate tutte le versioni con ogni metricadisponibile.


Per quanto riguarda l’analisi progettuale e dunque la ricerca di anti-pattern, X-Raynon fornisce funzionalità che avvertano l’utente riguardo la presenza di questotipo di disarmonie. Però mette a disposizione dell’utente una serie di metricheche, se usate in maniera intelligente, possono fornire una serie di indizi e a voltedi certezze che ci permettono di constatare la presenza di alcuni anti-pattern.Infatti questo è proprio il caso della classe JRBaseFactory del package engine. Comepossiamo notare dalla figura 94, la classe possiede 162 classi figlie, che con i suoidue metodi e le sue 33 righe di codice, paiono eccessive: la classe ha un valoredi NOC (Number Of Children) troppo elevato. Al crescere del NOC, cresce illivello di riuso ma tende ad “evaporare” l’astrazione della classe madre, per nonparlare della possibilità che una classe figlia non sia membro appropriato dellamadre. Sarebbe preferibile diminuire i figli della classe JRBaseFactory, mantenendosoltanto i figli “legittimi” anche perché al crescere del NOC, cresce la quantità ditest case necessari a testare ogni figlia.

Figura 94: JRBaseFactory on System Complexity view

115



6.1 anal isi 116

Ulteriori classi presentano la disarmonia che possiede JRBaseFactory anche se inmaniera meno eclatante e meno evidente.

Tramite la System Complexity, mediante la funzionalità info-box, possiamofacilmente notare un’interfaccia eccessivamente complessa, con dimensioni mag-

giori rispetto alle altre interfacce presenti nel software. L’interfaccia in questioneha il nome JRStyle e fa parte del package engine (figura 95). Essa possiede unnumero di operazioni eccessivo e molto eterogeneo. Possiamo dunque riconoscerel’anti-pattern dello Swiss Army knife (coltellino svizzero chiamato anche KitchenSink ovvero «lavandino»). Le principali conseguenze di questo anti-pattern, sonola difficoltà di utilizzo, manutenzione e documentazione. Sarebbe preferibilerisolvere o minimizzare questo problema dividendo l’interfaccia in ulteriori in-terfacce più semplici, ognuna con un compito specifico. Oppure, se non fossepossibile dividerla, si potrebbe pensare di creare dei profili di utilizzo, cioè deisottoinsiemi di operazioni dell’interfaccia, limitati da convenzioni e condizionida soddisfare. Se nemmeno i profili fossero applicabili, si potrebbe pensare diconsiderare politiche di utilizzo in ambito generic programming.

Figura 95: Anti-pattern: Swiss Army Knife / Codesmell: mancanza di commenti


Per quanto riguarda l’analisi programmativa, X-Ray fornisce una funzionalità basilare che ci permette di avere un quadro generale delle dimensioni del soft-ware target. Come possiamo vedere dalla figura 96, la info-box ci avverte delledimensioni del software.

JasperReports con i suoi 62 package, le sue 1733 classi, i suoi 16745 metodi e le



6.1 anal isi 117

Figura 96: Dimensioni del software target

sue 272184 linee di codice può essere definito come un software di medie-grandidimensioni.

Continuando con l’utilizzo di diverse metriche, in particolare della SystemComplexity, scopriamo che la classe JApiWriter ha le carte in regola per essere unaBrain Class con le sue grandi dimensioni e la sua elevata complessità; anche senon possiamo esserne certi. Questa incertezza è dovuta alla scarsità di metrichedisponibili utilizzabili tramite X-Ray. Rimandiamo dunque la sua analisi a breve,dove la processeremo con tool più adeguati a questo scopo.

Continuando la nostra analisi tramite la System Complexity scopriamo un’ulte-riore disarmonia, questa volta legata alla classe JRVerifier. Come possiamo notare

in figura 97, tramite la System Complexity, la classe risulta ampiamente piùgrande (principalmente per lunghezza e quindi per numero di linee di codice)rispetto alle altre classi del software target. Inoltre ha un altissimo numero didipendenze con altre classi, soprattutto uscenti, che ci fanno pensare ad una GodClass.



F i g u r a 9 7 : C l a s s e J R V e r i fi e r

118



6.1 anal isi 119

Un ulteriore code smell spesso visibile tramite la funzione Show Classes è l’Empty Catch Clause (figura 98), ovvero la presenza nel codice di clausole di catcho final senza nessun corpo. Questa pratica è molto utilizzata per far compilareil codice in maniera veloce senza preoccuparsi delle exception che potrebbero

sorgere. Purtroppo mettendo un blocco di catch vuoto si permette si di compilarema così facendo non si gestisce l’exception che potrebbe scaturire e quindi perdecompletamente di significato l’utilizzo di un blocco try-catch.

Figura 98: Empty Catch Clause on JRClassGenerator

Ulteriore code smell percepibile tramite la funzione Show Class è quello riferitoalla mancanza di commenti nel codice sorgente appartenente al package engine e atutte le interfacce presenti nel software target. In un progetto di dimensioni medio-grandi è pressoché inaccettabile avere il package più importante del softwareprivo di commenti (vedi figura 95 a pagina 116). Spesso i commenti presentiseguono la formattazione Doxygen ma non il buonsenso della limitazione ad 80

caratteri.

Purtroppo ulteriori code smell, tramite l’utilizzo di X-Ray, non possono esserefacilmente rilevati. La gran parte di quelli appena citati sono stati trovati per casoutilizzando il tool, dato che X-Ray non fornisce funzionalità per l’autoricerca dicode smell (come del resto di anti-pattern).





Diversamente dalle sezioni precedenti, X-Ray risulta molto utile per l’analisi evo-lutiva del Software, dato che fornisce diverse viste polimetriche che ci permettono

di avere una chiara visione dell’intero progetto. Ogni metrica è stata applicatasulle diverse versioni di JasperReports per analizzare al meglio l’evoluzione delsoftware.

Procedendo utilizzando tutte le viste che ci fornisce X-Ray possiamo indagaresull’evoluzione del progetto.

Notiamo che tramite la vista Package Dependency, il package con più dipen-denze sia entrati che uscenti è engine.

In questo caso la vista polimetrica ci inferisce informazioni riguardo una possibile dipendenza restrittiva tra il package xml e quello engine. Questa dipendenza,come notiamo dalla saturazione della freccia, è molto forte. Prendiamo inizial-mente queste informazioni come un indizio per analizzare meglio i due package,per capire se questa forte dipendenza è lecita o è una disarmonia che andrebbecorretta.

Figura 99: Package Dependency on JasperReports 0.x.x

Ora che abbiamo una traccia possiamo indagare sul package engine mediantela vista Class Dependency. Notiamo subito (figura 102 a pagina 123) che unaclasse appartenente al package engine è fortemente interdipendente con altre. Ledipendenze sono sia di tipo entrante che di tipo uscente, anche se quelle uscentisono più significative.

Queste informazioni sono molto significative perché ci portano a pensare chela classe JasperReport del package engine abbia tutte le carte in regola per essereuna God Class dato che subisce un accesso intensivo ai suoi parametri da parte




Figura 100: Class Dependency on JasperReports 0.x.x

di altre classi più leggere, e possiede molti metodi non comunicativi. Inoltre ècaratterizzata da un’alta complessità ed effettua un elevato numero di operazioniautonome senza disturbare altre classi.

Investigando tramite la funzionalità Show Class scopriamo il codice sorgente,ma purtroppo non essendoci commenti significativi non capiamo ancora di precisole sue funzionalità principali.

Sospettiamo una scarsità di commenti nel codice ma purtroppo non abbiamomodo di verificarlo tramite X-Ray dato che non presenta funzionalità per contarele linee di commento e rapportarle con quelle di codice effettivo. Leggendo ilnome dei metodi della classe in questione possiamo comunque presuppore chequesta sia parte integrante del motore di reporting. Questa affermazione vieneinoltre supportata anche dall’applicazione della terza vista polimetrica disponibile:la System Complexity.

Un’ingente quantità di informazioni può essere estrapolata tramite la SystemComplexity view, dato che mette a disposizione dell’utente uno strumento perconstatare l’intera complessità del progetto.

Infatti possiamo subito notare che nella prima versione, la classe JasperReport

contenuta nel package engine, aveva un ruolo fondamentale con i suoi 65 metodie le sue 932 righe di codice (come possiamo notare in figura 101 nella paginasuccessiva).

Notiamo inoltre che le dimensioni di questa classe possono far pensare ad una




Figura 101: System Complexity View on JasperReports 0.x.x

disarmonia nel progetto.Tramite questa funzionalità notiamo subito che le dimensioni della classe non

sono per niente irrisorie, anzi possiamo affermare con certezza che è la classecon più metodi e con più linee di codice. Notiamo anche che è in collegamentocon un’ingente quantità di classi in maniera più o meno forte (notiamo tutto ciògrazie alla saturazione delle dipendenze).

Pensiamo sia utile per migliorare l’intero software riformulare questa classe,magari suddividendola in maniera tale da rendere il software più riutilizzabileper progetti futuri.

All’aumentare del numero di metodi in una classe, diminuisce la possibilità di

intuire e predire il comportamento della classe in questione.Inoltre, all’aumentare del numero di metodi di una classe aumenta anche lacomplessità della classe stessa e quindi anche il suo valore di WMC1.

Infatti andando ad analizzare la stessa classe nella seconda versione stabiledi JasperReports (1.0.0) notiamo che è stato attuato un refactoring incentratosoprattutto sulla classe in questione: nella prima versione la classe JasperReport

possedeva 65 metodi composti in tutto da 932 linee di codice; alla versione

1 Metrica: WMC




1.0.0 i metodi divengono soltanto 3 con 55 linee di codice in totale. È palesel’applicazione di una ridistribuzione dei metodi dalla versione 0.x.x alla 1.0.0,dato che la classe JasperReport conteneva funzionalità a lei non attribuibili.

Questo è confermato dalla crescita smisurata delle classi nella versione 1.0.0

(da 77 a 530) e dalla ridistribuzione del numero di metodi in ogni classe, comepossiamo vedere in figura 102.

Figura 102: Class Dependency on JasperReports 0.x.x e 1.0.0

Inoltre, da questa semplice vista notiamo che la ridistribuzione di metodi haportato ad avere una diminuzione delle dipendenze tra classi.

Ovviamente le differenze dalla prima versione alla seconda non sono sol-tanto incentrate sulla ridistribuzione dei metodi nelle diverse classi, ma bensìdall’introduzione di nuove classi e di nuove funzionalità.

Dalla semplice info-box fornitaci da X-Ray possiamo vedere che il progetto èsestuplicato nei suoi contenuti (LOC da 12k a 73k) e così anche i package, comepossiamo notare in figura 103.

Dalla figura 98 a pagina 119 notiamo anche che le dipendenze tra i packagesono scomparse. Questo è un segno di ottima progettazione ed implementazione.

La modularizzazione di un software permette di facilitare la riusabilità del codi-ce ed inoltre riduce le tempistiche collegate al debugging ed al testing. In questomodo nessun “mattoncino” risulterà indispensabile per l’intero progetto. Inoltrenon avendo evidenti dipendenze tra package diversi, si evince che ogni parte pos-siede il suo compito ben preciso che può eseguire in maniera indipendente senzadover render conto a nessuno. Questo tipo di programmazione, associato ad unacorretta documentazione, può facilitare molto il compito di reverse engineering.

Vediamo ora in maniera più generale come si evolve il sistema, senza cercare discendere nello specifico in ogni singola classe. Possiamo notare dalla figura 104

come le dimensioni del progetto siano passate da irrisorie a imponenti nel giro di3 anni.



6.3 su g ge r im e nt i p e r m i gl i or a re il t o ol 124

Figura 103: Package Dependency on JasperReports 0.x.x & 1.0.0

Infatti inizialmente il codice contava soltanto 3 package con 77 classi e 12k dilinee di codice. Invece, nell’ultima versione possiamo contare invece 64 packagecon oltre 272k linee di codice.

Questa vista ci permette inoltre di notare che le dipendenze tra le classi nel-le versioni successive alla prima e precedenti all’ultima erano evidentementeintrapackage, mentre nelle restanti versioni le dipendenze sono aumentate espo-nenzialmente divenendo interpackage. Questa supposizione è confermata dalla

Package Dependency view, come notiamo in figura 105.

6.3 s u gg er imenti per mi g li o ra r e i l to ol

Secondo il nostro parere, il X-Ray è una ottima base su cui lavorare. Le carenzepiù evidenti sono dovute alle tempistiche di sviluppo (soltanto 3 mesi):

• carenza di funzionalità: mancanza di autoidentificazione di alcun genere dicode smell o anti-pattern;

• carenza di chiarezza: una funzionalità utile ma leggermente nascosta ocomunque poco evidenziata è quella che ci permette di visualizzare ledipendenze in base al loro peso;

– questa funzionalità andrebbe modificata permettendo all’utente dipoter selezionare il numero di dipendenze limite, in maniera tale dapoter evidenziare soltanto le classi o i package che risultano fortementedipendenti;




Figura 104: Evoluzione Class Dependency 0.x.x, 1.0.0, 2.0.0, 3.0.0, 4.0.2

• carenza di completezza: una possibile ulteriore feature potrebbe essere unasemplice vista tridimensionale per dare l’idea delle reali dimensioni deipackage, dato che con le viste correnti, non risultano sempre molto chiare;

– a questo proposito è giusto ricordare un ulteriore tool basato su X-Raychiamato Citylyzer che appunto ha la funzione principale di generareuna visione 3D dei package e delle classi [Malnati];

• carenza di visibilità: nella vista Class Dependency si ha che i nomi delleclassi sono ambigui visto che non è mostrato il nome esteso ma soltantouna sua contrazione che spesso si ferma al nome del package (per vederlo

bisogna fermarsi sulla classe d’interesse);




Figura 105: Evoluzione Package Dependency View 0.x.x, 1.0.0, 2.0.0, 3.0.0, 4.0.2

– una semplice modifica grafica renderebbe il tutto molto più fruibile;

• carenza di viste polimetriche: come lavoro futuro si potrebbe pensare diprogettare e realizzare almeno una vista in più, tipo la System Hotspot[Lanza et al., 2006]. In questa vista i nodi rappresentano le classi, mentrele loro dimensioni rappresentano il numero di metodi che definiscono. Ilcolore di ogni classe andrebbe a rappresentare la loro tipologia. Questasemplice vista consentirebbe di visualizzare sia classi di grandi che dipiccole dimensioni, permettendo inoltre di scalare sistemi di dimensioni non

indifferenti. I nodi potrebbero essere ordinati in base al numero di metodiposseduti, in questo modo si renderebbe facile e veloce l’identificazione divalori anomali;

• carenza di fruibilità: dal punto di vista attuale viene visualizzato in unasingola vista un unico layout di lavoro, quindi l’utente può cimentarsi inuna sola vista per volta senza poter effettuare confronti tra viste;

– sarebbe utile avere nelle prossime versioni di X-Ray un layout che possacontenere più viste polimetriche, per offrire una completa rappresenta-zione del sistema senza costringere l’utente a cliccare manualmente ecambiare la visualizzazione;

• scalabilità: X-Ray soffre di scalabilità soprattutto nelle viste di dipendenzasulle classi e sui package;

– per risolvere questo problema bisognerebbe far si che l’utente sia ingrado di visualizzare l’intero sistema o solo una sottoinsieme, oltre apermettere di ingrandire e rimpicciolire la vista corrente, mostrandoo nascondendo i dettagli. Anche dei filtri e degli zoom semanticipotrebbero risultare utili;




• opzioni: sarebbe utile che l’utente avesse la possibilità di modificare eimpostare il colore e le metriche da utilizzare su ogni entità, oltre che la lorodimensione. Inoltre sarebbe utile regolare dinamicamente parametri mentresi analizza una vista, per mostrare, nascondere o confrontare diverse entità

o relazioni;• persistenza: come lavoro futuro, gli sviluppatori potrebbero implementare la

possibilità di spostare i nodi dalla loro posizione di default ad una indicatadall’utente. Inoltre questo cambiamento sarebbe utile poterlo memorizzareall’interno di una struttura dati richiamabile dall’utente.

– si potrebbe pensare di poter applicare delle viste di ordinamentopreimpostate, in maniera tale da poter velocizzare l’operazione dianalisi del software;

• raccolta dati incrementali: questa funzione andrebbe introdotta in manieratale da permettere all’utente di poter rianalizzare soltanto una parte modifi-cata del progetto. Ora come ora X-Ray effettua l’analisi intera del progettosenza tener traccia di elementi che sono stati analizzati precedentemente eche non sono stati modificati;

– si potrebbe introdurre una analisi parziale incentrata soltanto sulleentità modificate dall’ultima analisi complessiva.

• produzione di report e documentazione: questa funzionalità potrebbe dive-nire utile dato che X-Ray calcola una quantità di informazioni che devonoessere visualizzate soltanto tramite la info-box. Queste informazioni sono

numero di package, classi, linee di codice, metodi, dipendenze entranti euscenti, interfacce e molte altre ancora.

– si potrebbe pensare di far produrre a X-Ray dei report pdf o xmlcontenente tutte le informazioni rappresentate nelle info-box delleviste polimetriche.


Essendo JasperReports un software ben strutturato, il compito di migliorarlorisulta complesso.

Tramite questo tool possiamo di certo affermare che:

• Le relazioni tra i package nell’ultima versione sono eccessive.

– si può pensare di creare alcuni package ex-novo per diminuire le fortidipendenze che nell’ultima versione si accentuano e compromettonol’ottima progettazione alla base.




• La mancanza di commenti nel codice sorgente scritto nelle prime versioni,in un progetto di dimensioni medio-grandi è pressoché inaccettabile. Icommenti presenti seguono formattazioni Doxygen ma non il buonsensodella limitazione ad 80 caratteri.

– si può pensare di introdurre almeno un commento nell’intestazione diogni classe, o ancor meglio nell’intestazione di ogni metodo.

– si può pensare di introdurre commenti utilizzando la formattazioneDoxygen in maniera tale da avere allo stesso tempo senza sforzo una

buona documentazione dettagliata.

• La classe JApiWriter potrebbe sembrare una una Brain Class con le suegrandi dimensioni e la sua alta complessità anche se non siamo certi data lascarsità di funzionalità offerteci di X-Ray in questo ambito.

– si può pensare di suddividere questa classe in diverse sottoclassi, cosìda diminuire la complessità della classe e di diminuire il pesanteutilizzo della classe JApiWriter verso altre classi di servizio.

• La classe JasperReport del package engine ha tutte le carte in regola per essereuna God Class.

– si può pensare di smistare le funzionalità secondarie di questa classealtrove e mantenere solo i metodi intrinseci.

• La classe JRBaseFactory del package engine ha un valore di NOC troppo ele-vato. Al crescere del NOC, cresce il livello di riuso ma tende ad “evaporare”

l’astrazione della classe madre, per non parlare della possibilità che unaclasse figlia non sia membro appropriato della madre.

– sarebbe preferibile diminuire i figli della classe JRBaseFactor, mantenen-do soltanto i figli “legittimi” dato che al crescere del NOC, cresce laquantità di test case necessari a testare ogni figlia.

• L’interfaccia JRStyle del package engine ha un numero di operazioni eccessivoe molto eterogeneo. Le principali conseguenze di questo anti-pattern (SwissArmy Knife) sono la difficoltà di utilizzo, la manutenzione e la creazionedi documentazione comprensibile. Esempi di interfacce eccessivamentecomplesse sono comuni soprattutto tra i programmi commerciali.

– sarebbe preferibile risolvere o minimizzare questo problema nei se-guenti modi:

* dividendo l’interfaccia in altre interfacce più semplici, ognuna conun compito specifico;

* se non si può dividerla, creando dei profili di utilizzo, cioè deisottoinsiemi di operazioni dell’interfaccia, limitati da convenzionie condizioni da soddisfare;




* se nemmeno i profili sono applicabili, usando politiche di utilizzoin ambito generic programming.

• La presenza del code smell Empty Catch Clause, ovvero la presenza nel

codice di clausole di catch o final senza nessun corpo non permette digestire l’exception che potrebbe scaturire e quindi perde completamente disignificato l’utilizzo di un blocco try-catch.

– sarebbe preferibile introdurre il corpo di ogni blocco try-catch, inmaniera tale da poter gestire l’eventuale exception nel migliore deimodi.


6.5.1 Tramite X-Ray

Tramite l’analisi di X-Ray si evince che JasperReports è un software che è statoinizialmente progettato con poca cura, sfruttando fortemente la classe madre (checome spesso capita ha il nome del software), incapsulando il lei la gran partedelle funzionalità.

Dalla seconda versione (1.0.0) notiamo che è stata attuata una riprogettazionedell’intero sistema. La classe madre è stata smembrata e le funzionalità sonoaumentate. Pur aumentando le funzionalità, e quindi le classi e i metodi, si èmantenuto un alto livello di modularità e indipendenza tra package, come ègiusto che sia per garantire una buona riusabilità del codice.

Grazie a X-Ray ed in particolare alla sua funzionalità Show Classes ci accorgia-mo che JasperReports cambia persino proprietario; infatti inizialmente il softwareera sviluppato da un’unica persona. Questo puo’ essere uno dei motivi per cui siè deciso di riprogettare l’intero software.

Continuando con l’evoluzione del software ci accorgiamo che la linea pro-gettuale introdotta nella seconda versione (1.0.0), viene mantenuta perché benpensata.

Ad ogni versione si introducono nuovi package che però non condizionano ilnormale funzionamento del software ma sono dei moduli quasi completamenteslegati al resto del progetto (possiamo vederle come funzionalità aggiuntive).

Purtroppo nell’ultima versione disponibile le funzionalità introdotte compro-

mettono la stabilità di JasperReports a causa di un’alta dipendenza tra i packageche prima non esisteva.

Anche la modularità viene intaccata e così di seguito anche la riusabilità delcodice ne risente per non parlare della stabilità. Possiamo anche pensare adun’aumento non irrisorio dei tempi di testing e debugging.

In definitiva il codice sembra ben strutturato, esistono poche “God Classes” mache non impensieriscono molto data la loro forte necessità. Alcune classi hanno unvalore di NOC (Number Of Children) troppo elevato. Questo tende a dissolvere



6.6 considerazioni finali su x-ray 130

l’astrazione della classe madre, per non parlare della possibilità che una classefiglia non sia membro appropriato della madre.

La progettazione dopo la prima versione sembra essere quella definitiva. Forsesi può pensare di creare alcuni package ex-novo per diminuire le forti dipendenze

che nell’ultima versione si accentuano e compromettono l’ottima progettazionealla base.

È da notare inoltre che vari gruppi di classi sono accomunate da dimensionirilevanti; questo però non costituisce un problema perché le classi dell’applicationlogic sono ben strutturate.

Durante l’analisi del software abbiamo incontrato alcuni anti-pattern, tipolo Swiss Army Knife e alcuni code smell tipo l’Empty Catch Clause. Anchese presenti non compromettono la solida progettazione e implementazione di

JasperReports.Unica macchia è la completa mancanza di commenti nel codice sorgente scritto

nelle prime versioni. Su un progetto di queste dimensioni è pressoché inaccettabilenon avere nemmeno un commento che spieghi almeno il contesto e la funzione diogni classe.

6.6 c o ns i der azi oni f inali s u x-ray

Non si può giudicare male un tool di questo calibro dato che è stato sviluppatoda una sola persona in un lasso di tempo molto breve. Secondo noi le funzionalitàdi X-Ray non sono abbastanza per effettuare una completa analisi del software,ma di certo quelle implementate soddisfano a pieno i requisiti minimi.

Potremmo definire X-Ray come una sorta di tool per un’analisi breve e archi-tetturale. Infatti con i suoi brevi tempi di analisi e le sue informazioni generali,fornisce subito l’idea o almeno un indizio riguardo possibili disarmonie nel pro-getto target. È un utile tool per analizzare in maniera superficiale un progetto siadi grandi che di piccole dimensioni, dato che le sue viste sono perlopiù generali,incentrate su package, classi e sull’intero sistema.

Inoltre possiamo citare i suoi pregi, che potrebbero sembrare irrisori ma indefinitiva non lo sono per niente considerando le difficoltà riscontrate con altritool di analisi per il reverse engineering.


• facilità di installazione dovuta prevalentemente all’ambiente su cui vieneeseguito;

• la sua natura open-source che permette una sua maggiore diffusione (multi-piattaforma) e possibilità di miglioramento;

• icone molto intuitive e facilmente ricollegabili all’azione a loro attribuita;

• non richiede di meta-file per eseguire le analisi, ma soltanto del codicesorgente;




• non è stand-alone ma si basa sul Framework di Eclipse;

• possibilità di modificare il codice sorgente mentre si utilizzano viste polime-triche;

• utile anche per il forward engineering oltre che per il reverse engineering;

• ottima documentazione disponibile in rete ricca di esempi e spiegazioniutili sulle metriche implementate;

• le metriche disponibile seppur poche sono pratiche e utili.


• difficoltà nella scalabilità;

• mancanza di metriche;

• presenza di bug in funzionalità secondarie;


• utilizzabile soltanto su progetti open-source o di cui si possiede il sorgente;

• poca personalizzazione dei diagrammi;

• non è stand-alone ma si basa sul Framework di Eclipse.

Il dettaglio che X-Ray non è un software stand-alone è stato inserito sia nei pregiche nei difetti, questo perché per alcuni sviluppatori che utilizzano già Eclipsepuò essere un vantaggio avere in un unico ambiente sia l’editor che un software dianalisi. È proprio per questo che X-Ray può anche essere utilizzato per il forwardengineering, dato che ci si accorge velocemente di alcune disarmonie nel codice,facendo analizzare dal plug-in il sorgente appena scritto.

Questo dettaglio però può anche essere considerato come un difetto nel mo-mento in cui il programmatore non è solito utilizzare Eclipse. In questo casodiventa fastidioso dover installare più di un software.



Anche X-Ray, come del resto gli altri tool, sono stati testati su più macchine conconfigurazioni differenti.

Qui di seguito abbiamo una tabella con le configurazioni dei computer utilizzati.




s-1 s-2

MS Windows 7 x64 bit MS Windows XP x32 bit

Intel Core Duo 2.40 GHz Dual Core 1.66 Ghz

4.00 GB 1.00 GBEclipse helios Versione 3.5.0 Eclipse helios Versione 3.5.0

s-3 s-4

MS Windows XP x32 bit Ubuntu Natty 11.04 x64 bit

Dual Core 1.66 Ghz Intel Core Duo 2.40 Ghz

2.00 GB 4.00 GB

Eclipse helios Versione 3.5.0 Eclipse helios Versione 3.5.0

Tabella 15: Configurazioni macchine utilizzate


Segue una tabella con i valori tempistici delle analisi sulle diverse versioni di JasperReports.

Tempistiche di analisi con X-Ray su JasperReports con la configurazione S-1:

v e rs io ne d i ja sp e rr e po rt s t e mp o

0.x.x 1.49 sec1.0.0 5.31 sec

2.0.0 13.54 sec

3.0.0 17.12 sec

4.0.2 57.40 sec

Tabella 16: Tabella delle tempistiche di analisi con X-Ray su JasperReports con laconfigurazione S-1






0.x.x

3.45

sec1.0.0 9.41 sec

2.0.0 20.37 sec

3.0.0 27.58 sec

4.0.2 1.34 min

Tabella 17: Tabella con le tempistiche di analisi con X-Ray su JasperReports con laconfigurazione S-2



0.x.x 2.34 sec

1.0.0 7.10 sec

2.0.0 18.58 sec

3.0.0 24.31 sec

4.0.2 1.18 min




0.x.x 1.43 sec

1.0.0 5.34 sec

2.0.0 12.20 sec

3.0.0 15.27 sec

4.0.2 57.12 sec





6.7.3 Installazione

L’installazione di X-Ray è molto semplice, grazie al fatto che è un plug-in diEclipse [Coorporation].

Infatti seguendo la guida [Malnati] possiamo notare che basterà:• installare il GEF framework, utilizzato da X-Ray per alcune rappresentazioni

grafiche;

• inserire nella cartella plugin di Eclipse il Jar di X-Ray.

In nessuna configurazione è stato riscontrato un malfunzionamento o una mancatainstallazione.

6.7.4 Bug

Durante l’utilizzo del tool sono stati riscontrati alcuni bug che affliggevano fun-zionalità secondarie e quindi possiamo affermare che il tool è ben implementato.

I bug riscontrati sono:

• un malfunzionamento dell’esposizione della vista ClassDependency chenon permette di visualizzare la dipendenza delle classi ad alcune distanzein certe situazioni. (bug noto allo sviluppatore ma non ancora risolto);

• la funzionalità SnapshotAction che spesso scaturisce una MemoryHeapEx-ception, compromettendo il funzionamento di Eclipse. Inoltre il path disalvataggio dichiarato nella documentazione non è lo stesso dove vengonorealmente salvate le immagini.


Considerando le dimensioni di X-Ray, possiamo ritenerci soddisfatti della quantitàdi informazioni trovate nel sito ufficiale [Malnati].

Infatti lo sviluppatore mette a disposizione:

• un breve tutorial per imparare a utilizzare tutte le funzionalità di X-Ray;

• un breve tutorial per installare X-Ray;• una breve ma chiara documentazione;

• informazioni aggiuntive su ulteriori plug-in sviluppati su X-Ray;

• la tesi di laurea riferita al progetto X-Ray, che contiene la spiegazionedettagliata di ogni singola metrica.



Figura 106: Sito ufficiale di X-Ray

135



7D U D E

Dude (Duplication Detector) è uno strumento indipendente dal linguaggio perla rilevazione di codice duplicato (code clones) creato dallo sviluppatore diCodeCity[Wettel, c]. Oltre al suo impiego in sistemi per il reverse engineering,Dude è stato con successo utilizzato per rilevare plagio nel codice in progetti eincarichi di studenti universitari di informatica.

Il tool non considera soltanto semplici sequenze di codice contiguo duplicato,ma anche catene duplicate e sequenze di blocchi di codice duplicato molto vicinigli uni agli altri.

Tuttavia, spesso un blocco di codice sorgente non è solo copiato in un altro file,ma è anche leggermente modificato. Tale duplicazione sarà normalmente rilevatacome una serie di piccoli cloni apparentemente insignificanti, che però invece diessere resi noti all’utente come lievi modifiche, verranno uniti in maniera tale dapoter essere identificati come operazioni di copia e incolla seguiti da modifiche(inserimento, cancellazione, modifica di codice).

7.1 a na l is i

L’analisi verrà applicata soltanto all’ultima versione del software target date leristrette funzionalità del software.

7.1.1 Analisi code clones

Dude permette di effettuare tre tipologie di ricerche nel codice:

• Exact Matching: ovvero la corrispondenza esatta tra linee di codice;

• Levenshtein Distance: ovvero la corrispondenza di linee di codice somigliantisulla base della distanza Levenshtein (distanza di edit) superiore a unadeterminata soglia. Questo processo richiede diverso tempo ed è utile nelrilevare lievi modifiche del testo (come ridenominazioni di singoli nomi);

• Tokenized Distance: ovvero si tratta di un approccio più raffinato delExact Matching che opera a livello sintattico, che è in grado di rilevarei cambiamenti complessi come ridenominazioni di variabili.

Partiamo dunque con la funzionalità “Exact Matching“ sulla versione 4.0.2 di JasperReports.

Notiamo fin da subito che il numero di cloni “intaccano” il 34% dei file appar-tenenti dell’intero progetto. Un numero considerevole, anche se dobbiamo tenere

136



7.1 anal isi 137

Figura 107: Statistics in Dude

anche conto che JasperReports possiede classi che contengono più di duemilarighe di codice, e non è detto che tutte e duemila siano cloni di un’altra. Infattinotiamo che il numero di righe di codice duplicate (39837) rispetto a quelleanalizzate (330313) sono circa il 12%. Inoltre in questo conteggio appartengo-no anche quelle righe di codice di tipo clone modified, clone deleted e clonecomposed. Ovvero non tutte possono essere associate all’anti-pattern cut andpaste programming, dato che spesso la semantica di un programma si ripete inmaniera consistente. Ad ogni modo questo anti-pattern, prodotto della convin-zione che modificare un programma sia meglio che scriverlo da zero, e che hacome conseguenze il rischio di alti costi di manutenzione e documentazione, puòessere agilmente individuato: possiamo infatti vedere una fianco all’altra le classiincriminate.

Figura 108: Dude view

Un fattore che ci può far pensare è la presenza di 956 righe di codice cloni inuna classe di 1455. Possiamo dire che gran parte della classe è clone di un’altra.




Notiamo pero’ che anche il nome delle due classi è simile. Questo ci fa pensare chepossa essere lecito utilizzare una struttura che si ha appurato essere funzionanteed efficiente.


Una funzionalità che sarebbe interessante aggiungere a Dude è l’identificazionedella tipologia di codice clonato, per esempio dire se appartiene ad un metodo,ad istanziazioni di variabili, a commenti ecc, gestibile dall’utente attraverso unfiltro (es. si vuole cercare solo il codice clonato di metodi).

Inoltre si potrebbe potenziare il reporting, e permettere l’export in formatitabellari o .pdf, non solo testo dettagliato in .xml


Non ci sentiamo di poter dare delle indicazioni su quali metodi o classi attuareun refactoring, però ci sentiamo di affermare che sarebbe utile rivedere se le classi“copiate e incollate” non contengano metodi o attributi superflui o non del tuttoconsoni al ruolo che occupano.


Riguardo all’analisi con Dude su JasperReports, il tasso di clonazione riportato èalto: la maggior parte delle duplicazioni riscontrate appartengono alla tipologia

“modified”, poiché la gran parte delle linee di codice presentano una strutturasemantica uguale ma differente nomenclatura delle variabili.

7.5 c o ns i der azi oni f i na li s u du d e

Dude, come il nome stesso suggerisce, ha come funzionalità principale l’indivi-duazione di codice replicato. E come funzionalità, ha solo questa, anche se in tremodi differenti; pertanto non lo si può ritenere un software di reverse engineering,quanto piuttosto di code analysis.

Comunque sia, dato che abbiamo utilizzato questo tool soltanto per verificare

che i risultati degli altri tool fossero consistenti nella ricerca di cloni, ci riteniamopiù che soddisfatti del tool.






s-1

MS Windows 7 x64 bit


4.00 GB

Tabella 20: Configurazione macchina utilizzata per l’utilizzo di Dude


Dude ha impiegato 1.58 m per analizzare l’ultima versione di JasperReports.

7.6.3 Installazione

Dude non richiede installazioni dato che è un semplice eseguibile Java (JAR).

7.6.4 Requisiti

Dude, essendo un software scritto in Java, necessita della versione JRE 1.5 osuperiore[Oracle, a].

7.6.5 Bug

Non sono stati riscontrati bug durante l’utilizzo del tool.Unico difetto visibile è il mancato funzionamento dei tasti di chiusura dei

sotto-menù.





La documentazione presente nel software risulta esauriente[Wettel, b]. Descrivein maniera completa tutte le metriche e gli espedienti utilizzati per cercare cloni

nel codice. Inoltre permette di apprendere in maniera facile e veloce funzionalitàaggiuntive così da effettuare ricerche personalizzate di cloni nel codice.

Figura 109: Sito ufficiale di Dude



Parte IIA N A L I S I D I C R I S P



8A N A L Y S T 4 J

Analyst4 j offre un ambiente di analisi per verificare la qualità del codice conl’aiuto di metriche software automatizzate, grafici e documenti.

Le metriche a disposizione offrono diversi parametri di qualità del softwaretarget, che sono di grande utilità per valutare e capire la qualità del codice.

Analyst4 j garantisce un uso efficace delle metriche, fornendo uno strumento diricerca automatica tramite metriche predefinite.

Inoltre permette di cercare anti-pattern comuni in Java come: Blob Class,Spaghetti Code, Swiss Army Knife, etc. etc..

Permette di effettuare analisi ed interpretazioni personalizzate in base allemetriche software. Valuta la manutenibilità corrente del progetto e trova aree dovepoter applicare miglioramenti (refactoring) per garantire buona manutenzionefutura.

Aiuta a stimare lo sforzo della fase di testing sulla base di parametri quali lacomplessità ciclomatica e lo sforzo di Halstead.

8.1 a na l is i

Purtroppo i nostri sforzi profusi per richiedere una versione full (trial) del toolsono stati vani. Ed è per questo che abbiamo deciso di utilizzare la versione free

sul progetto Crisp, date le sue ridotte dimensioni.file analizzabili (soltanto 50 files).Analyst4 j verrà utilizzato inizialmente sulla versione di Crisp consegnataci

all’inizio del progetto di “Progettazione e Sviluppo Software”, in maniera taleda poter capire dove (se necessario) effettuare operazioni di refactoring, così dainiziare il lavoro su una applicazione ben progettata e strutturata. Così facendoinfatti non impareremo soltanto ad utilizzare il tool, ma i risultati prodotti sarannorealmente utili per un lavoro futuro di refactoring dell’applicazione la quale ètuttora in fase di progettazione.


Analyst4 j, a differenza di molti altri tool analizzati, offre un’auto analisi deglianti-pattern precaricati. dal team di Code Swat, ma permette all’utente di crear-ne dei propri. Gli anti-pattern riconosciuti in automatico sono quelli presentinell’immagine seguente.

Eseguendo l’analisi scopriamo che il codice del software Crisp possiede dueanti-pattern.

142



8.1 anal isi 143

Figura 110: Anti-pattern in Analyst4 j

Il primo è lo “Zero Encapsulation Classes” che afferma che esistono alcuneclassi nel progetto che sono affette da un anti-pattern che limita la sicurezza.Questo anti-pattern indica una situazione in cui una classe permette ad un’altraclasse di essere modificata senza passare da metodi propri (come ad esempio

setter). Il tool ci dice anche che sono presenti 9 occorenze di questo anti-patternnel codice sorgente di Crisp.

Figura 111: Zero Encapsulation Classes

Se andiamo ad investigare nel codice però scopriamo che alcuni sono più chelegittimi dato che sono classi che vengono autogenerate dal compilatore per far siche “parlino” in maniera diretta.

Ulteriore anti-pattern visibile è il “Procedure Oriented Design” che a differenzadell’Object Oriented Design (OOP), si focalizza principalmente sulle funzioni esulle procedure che operano sui dati, oltre a seguire un approccio Top Down.

Come possiamo vedere dalla figura seguente, le occorrenze di questo anti-pattern sono ridotte (soltanto 3).

Date le ridotte dimensioni dell’applicazione target decidiamo di creare unanostra metrica. Tramite la funzione Analyst Search possiamo creare delle query

basandoci persino su anti-pattern già formulati all’interno del tool.Infatti inizialmente il tool ci chiede se si vuole creare un anti-pattern basandoci

su uno gia’ esistente o meno. Inoltre possiamo selezionare lo scope generale (sesu un metodo, una classe, un package, etc. ) e persino modificare o introdurre



8.1 anal isi 144

Figura 112: Procedure Oriented Design

qualsiasi metrica presente nella viste per rilevare i code smell (Metrics-PeerComparison e Swat Index - Descendants Comparison ).

Come possiamo notare in figura decidiamo di creare un nostro anti-pattern,partendo da zero. Desideriamo vedere se esite una Data Class nel progetto,dunque vorremo una classe con pochi metodi molti attributi e bassa complessitàciclomatica. Creiamo la query come in figura sottostante.

Figura 113: Query - Analyst4 j Searches

Vediamo ora i risultati della ricerca. Come possiamo notare dalla figura sotto-stante abbiamo tre classi candidate ad essere Data classes.

Figura 114: Candidate Data Classes

Notiamo subito che tutte e tre le classi appartengono allo stesso file. Questofattore aumenta ancor di più la possibilità che siano data classes. Inoltre dal pathnotiamo che il file in questione è l’R ovvero il file che viene automaticamentegenerato dal compilatore java-Andorid. Vediamo che la complessità ciclomatica



8.1 anal isi 145

dei loro metodi è 0 e il numero di parametri supera largamenta la nostra sogliaprestabilita.

Investigando, apriamo le singole classi e scopriamo di essere difronte a dellevere e proprie data classes, come si evince dalla figura sottostante.

Figura 115: Data Classes


Analyst4 j offre una quantità di informazioni straordinaria riguardo l’analisi pro-grammativa di un software. La quantità di metriche è così elevata che la schermatainiziale mostra le informazioni in maniera diversa da altri tool.

Infatti le metriche vengono visualizzate in formato tabellare con diversi tab

e menù estendibili. Analizzeremo tutte le metriche, cercando di soffermarci suquelle più significative.Innanzitutto bisogna sapere che tutte le metriche possono essere applicate

all’intero progetto o ai singoli package. Questo permette di velocizzare la ricerca didisarmonie. Se noi inizialmente analizziamo l’intero progetto, possiamo facilmentenotare la posizione delle disarmonie per poi andarle a visionare in dettaglio.

Iniziando l’analisi con Analyst4 j ci compare subito una info-box chiamata“Analysis Report” contenente informazioni utili sull’analisi appena effettuata e



8.1 anal isi 146

sull’architettura del progetto analizzato.Come possiamo notare in figura 116, abbiamo informazioni riguardanti la

copertura dell’analisi. Nel nostro caso sono stati analizzati 12 file su 13. Laclasse ViewSetActivity inaspettatamente non è stata analizzata. Abbiamo cercato

di scoprire il motivo, ma anche andando a vedere il codice sorgente non si notauna sostanziale differenza dalle altre classi sia dello stesso package che dell’interoprogetto.

Continuando con l’analisi passiamo a visualizzare il menù Code Quality, checi permette di scoprire che il progetto analizzato ha soltanto 4 packages e 21

classi con 870 linee di codice. Possiamo affermare che il progetto è di piccolaentità. Il resto delle metriche riportate verranno successivamente analizzate perchècontenute in un’altra vista più completa.

Passiamo quindi al menù “Duration” che permette di visualizzare il tempoutilizzato dal tool per effettuare l’analisi del software. Considerando le dimensionidel software non possiamo sbilanciarci sulle performance del tool dato che ilnumero di file analizzati è soltanto 13, rispetto un software medio grande come

JasperReports che conta migliaia di files.Procediamo ora ad utilizzare le varie funzionalità del tool per cercare code

smell e disarmonie nel codice.

Figura 116: Analysis Report

Notiamo subito la vista QA Scope la quale permette di vedere la struttura basedel progetto (suddivisione in base ai packages) e di selezionare lo scope su cuivisualizzare le informazioni precedentemente prodotte.

Notiamo subito una imprecisione, che inizialmente ci insospettisce sul correttofunzionamento del tool.



8.1 anal isi 147

Figura 117: QA Scope View

Infatti come possiamo notare in figura117, il package “reports” viene riportatoper ben due volte. Analizando più in dettaglio pero’ possiamo vedere come ilcontenuto dei due package sia differente. Analyst4 j in questo caso non ha assolu-

tamente commesso un errore. Questo perchè il software che si sta analizzandopossiede un package che viene automaticamente creato dal compilatore Android,e che viene il più possibile “nascosto” allo sviluppatore. Continuando con l’analisipassiamo a visualizzare la vista Metrics-Peer Comparison la quale assomigliamolto all’Analysis Reports visto in precedenza.

Figura 118: Metrics - Peer Comparison

Queste metriche forniscono moltissime informazioni molto specifiche, le qualipossono essere utili a programmatori esperti che le utilizzano tutti i giorni. Se-condo noi questa vista possiede delle forti potenzialità poco sfruttate, dato chediviene difficoltoso accorgersi di una disarmonia a colpo d’occhio. Sarebbe prefe-ribile che il software colorasse gli indici in maniera tale da capire indicativamentese il valore è nella norma o è potenzialmente “pericoloso”.

Scandendo uno ad uno i vari valori ci accorgiamo che la maggior parte sonoperlopiù positivi, infatti notiamo che ad esempio la media della complessitàciclomaticadi ogni metodo del progetto è 1.61.



8.1 anal isi 148

Questo valore è altamente al disotto del limite ideale proposto da McCabe, ilquale raccomandava che i programmatori contassero la complessità dei moduli insviluppo, e li dividessero in moduli più piccoli, qualora tale complessita superava10, anche se in certe circostanze può essere appropriato rilassare tale restrizione

e permettere moduli con una complessità anche di 15. Essendo però una mediasarebbe utile scoprire il valore massimo per essere certi di non avere metodi nelprogetto con una complessità cicolmatica eccessiva.

Con grande stupore ci accorgiamo tramite la vista Swat Index - DescendantsComparison che un metodo contenuto nel package Reports ha complessità 11,come possiamo notare in figura 122.

Figura 119: Swat Index - Descendants Comparison

Questa metodo si chiama parseXml e fa parte della classe Parser. Notiamo chel’identificativo del metodo viene colorato di rosso da Analyst4 j per aiutarci nellaricerca del metodo con complessità massima. Con un doppio click sul metodo,appare il codice sorgente, il quale, come possiamo notare, contiene moltissimicode smell visti a lezione.

Leggendo il codice ci accorgiamo subito della presenza di linee di codice com-mentate. Questa pratica è un sottogruppo del code smell “Too Much Documenta-

tion”. Infatti in questa classe notiamo una formattazione dei commenti insolitaed inutile, per non parlare appunto delle righe di codice che non dovrebberonemmeno essere presenti sotto forma di commento (figura 120).

Figura 120: Too Much Documentation

Notiamo inoltre nel metodo parseXml il code smell Empty catch clauses, checomporta la presenza nel codice di clausole di catch o final senza nessun corpo.Questa pratica è molto utilizzata per far compilare il codice in maniera veloce



8.1 anal isi 149

senza preoccuparsi delle exception che potrebbero sorgere. Purtroppo mettendoun blocco di catch vuoto si permette certo di compilare ma così facendo nonsi gestisce l’exception che potrebbe scaturire e quindi perde completamente disignicato l’utilizzo di un blocco try-catch (riquadro verde in figura 121).

Figura 121: Empty catch clauses

Vedendo la quantità di code smell più o meno gravi posseduti da questo metodoci sentiamo di dire che sarebbe consigliato eseguire un refactoring completo sulmetodo parseXml soprattutto per la sua complessità ciclomatica. Fortunatamentequesto metodo era già previsto che venisse smantellato dato che nelle prossimeversioni di Crisp non verranno più analizzati file Xml.

Gli ulteriori valori presenti nella vista “Metrics - Peer Comparison” sono deltutto positivi, infatti il codice non possiede classi con profondità preoccupante, enemmeno variabili istanziate ma non utilizzate. Persino il livello di mantenibilitàè molto elevato. L’unica disarmonia che possiamo notare, oltre a quelle preceden-

temente citate, riguarda il rapporto tra le linee di codice e il numero di linee dicommenti. Infatti possiamo vedere che quasi il 40% delle linee scritte nel progettosiano commenti. Questa cifra però è leggermente falsata, dato che basta vederele classi per accorgersi che i commenti non sono sempre stati scritti in formatostandard e spesso occupano più righe anche se il contenuto è scarso ( riquadrorosso figura 120).

Ulteriore disarmonia potrebbe essere il numero di statement dichiarati public,infatti più del 45% degli statement presenti nel progetto è dichiarato public.Spesso è buona norma dichiarare tutto private a meno di casi particolari in cui sivoglia condividere il loro utilizzo. In questo caso, andando ad indagare, la sceltadi utilizzare public è limitata ai metodi setter e getter e a costruttori. Dunque nonpossiamo riconoscere nessun code smell, dato che si è operato in maniera nonopinabile.

Passiamo ora all’utilizzo della vista “Swat Index - Descendants Comparison”.Anche questa vista possiede un’ingente quantità di informazioni che vannoelaborate per comprendere la loro utilità a riconoscre code smell.

Possiamo subito notare che a differenza della precedente vista, questa fornisceper ogni voce, oltre al valore medio, anche quello massimo e quello minimo. Que-sta vista risulta dunque più utile a riconoscere in maniera più veloce i possibili



8.1 anal isi 150

Figura 122: Swat Index - Descendants Comparison

code smell presenti. Questa vista risulta utile una volta consultata quella prece-dente. Infatti, dopo aver trovato una possibile disarmonia, possiamo restringerelo scope e approfondire la ricerca tramite la visualizzazione dei valori specifici

mediante la vista “Swat Index - Descendants Comparison”. Infatti se notiamo bene, il tool evidenzierà sempre l’entità con il valore più alto della metrica sele-zionata. Se lo scope è riferito all’intero progetto, la vista ci permetterà di vedere ilpackage contenente l’entità con il valore più alto della metrica selezionata (comevisto precedentemente per il metodo parseXml). Possiamo persino restringere ilcampo alla singola classe o al singolo metodo. Ovviamente in base allo scopeche gli si attribuisce vengono modificate le metriche disponibili. Questa vista,come la precedente, possiede una funzionalità molto utile chiamata “ComparisonReport” che permette di creare dei report in formato Microsoft Word, contenentile informazioni mostrate nelle viste.



8.1 anal isi 151

Figura 123: Comparison Report

Queste metriche inizialmente possono sembrare poco chiare, a causa dei loronomi concisi e a volte troppo specifici. È per questo motivo che Analyst4 j possiedeuna piccola guida che spiega le metriche presenti nelle diverse viste dell’interotool (vedi figura 124).

Figura 124: Notes view

Ulteriori metriche offerte dal tool per facilitare il lavoro di riconoscimento di



8.1 anal isi 152

disarmonie sono contenute nel menù Comparison Analysis. Difatti come possiamonotare dall’immagine sottostate, questo menù permette di mettere a confrontole metriche precedentemente analizzate, in maniera tale da poter ricavare alcuneinformazioni sull’ architettura del software target.

Figura 125: Comparison Analysis

Notiamo subito che la quantità di confronti è suddivisa in base allo scope.Ognuna di queste metriche da vita ad un grafico comparativo che può esserevisualizzato in due differenti modi, in base alle preferenze dell’utente (Line Charto Scatter Plot).

Partendo dalla prima voce, notiamo che cliccando sulla metrica compare ungrafico che ci mostra il rapporto tra il numero delle linee di codice e la complessitàciclomatica. Vediamo subito che al crescere del numero di linee di codice neimetodi, aumenta anche la complessità ciclomatica. Questa vista ci informa inoltredel massimo valore di complessità ciclomatica dei metodi del progetto.

Figura 126: NLOC vs CC

Dato che da questa vista non compaiono disarmonie evidenti, possiamo passarealla Unstructuredness vs Documentation. Questa vista ci mostra il numero dirighe di commento rapportato alla complessità del metodo. Sarebbe buona normaavere più righe di commento quando i metodi sono complessi, ma come possiamonotare, in Crisp avviene l’esatto contrario. Infatti possiamo notare come i metodicon complessità 1 possiedono molte più righe di codice di metodi con complessitàanche 6 volte superiore (vedi figura sottostante).



8.1 anal isi 153

Figura 127: Unstructuredness vs Documentation

Passiamo poi ad analizzare la metrica che indaga sul numero di linee dicommento rapportato al numero di linee di codice. Qui possiamo notare comeall’aumentare del numero di linee di codice aumentano anche i commenti. Esisto-

no però dei casi anomali come ad esempio il metodo refreshDir che possiede piùlinee di commento che linee di codice (cerchio verde in figura 128).

Figura 128: NLOC vs NOCL

In questo caso scopriamo che infatti all’interno del metodo, i commenti sonoperlopiù righe di codice effettivo dismesse.

Figura 129: Metodo refreshDir

Passiamo ora ad analizzare le metriche dei File, dato che quelle per le classi



8.1 anal isi 154

sono poco significative a causa delle loro piccole dimensioni e del loro numeroridotto.

Vediamo una metrica molto utile e poco presente negli altri tool di reverseengineering. Questa metrica mette a confronto la mantenibilità del codice con

lo sforzo per crearlo. Utilizza la metrica di Maurice Halstead [Maurice] perdeterminare lo sforzo da parte di uno sviluppatore per creare il codice.

Figura 130: NLOC Vs Halstead Volume

Da questo notiamo che la maggior parte dei File si comporta in manierainaspettata, infatti più c’è voluto sforzo per creare il file e meno è mantenibile. Ineffetti, pensandoci bene, se un file ha richiesto più tempo per essere sviluppato,può essere comprensibile pensare che sia più complesso di uno che ne ha richiestodi meno. Dunque non possiamo trarre molte considerazioni solo da questa metrica.Andrebbe analizzata anche la complessità ciclomatica del file per essere sicuri diquesta supposizione.

Passiamo ora ad analizzare le metriche del menù Distribution Analysis. Comepossiamo notare nella figura sottostante, Analyst4 j, anche in questo caso, ci offreuna quantità esorbitante di metriche, anch’esse come le precedenti, esportabili inreport esplicativi.

Figura 131: Distribution Analysis



8.1 anal isi 155

Passeremo in rassegna soltanto alcune di queste metriche, quelle più significati-ve, per rimanere il più sintetici possibili.

Analizzando il primo grafico riguardante la complessità ciclomatica notiamoche le supposizioni su una elevata complessità ciclomatica in un metodo effet-

tuate prima, vengono palesemente smentite dato che l’autoriconoscimento dimetodi complessi attribuisce alla maggior parte dei metodi del progetto un bassorischio. Sono solo 11 i metodi che hanno un rischio moderato, ma che non ciimpensieriscono vedendo la scala di rischio attribuibile alle funzioni.

Figura 132: Cyclomatic Complexity

Persino la vista Essential Complexity conferma le nostre aspettative.Inoltre possiamo notare come sia facile poter modificare i bounds che de-

terminano le classi di rischio (questa funzionalità è presente in ogni chart diAnalyst4 j).

Figura 133: Essential Complexity

Cambiando scope passiamo ora ad analizzare alcune metriche relative alleclassi, in particolare alla metrica “Lack of cohesion of methods”.

Analizzando il grafico vediamo come il software autoaggiudica ad ogni classe(la quale può essere riconosciuta tramite un doppio click sulla colonna selezionata)un modello di design che racchiude l’essenza della stessa.

Anche questa vista evidenzia che una buona parte delle classi possiedonoun’impronta Procedure Oriented Design.



8.1 anal isi 156

Figura 134: Lack of cohesion of methods

Vediamo anche come la gran parte delle classi presenti nel progetto non pos-siede Inner Class. Questa volta visualizzeremo il grafico a forma di report per

sottolineare la potenza di questo tool.

Figura 135: Inner Class

Infine notiamo che la stabilità di ogni package è notevolmente positiva, comepossiamo vedere nella figura sottostante.




Figura 136: Packages Instability


Analyst4 j è senz’altro uno dei più completi tool di reverse engineering utilizzati e

visti durante le lezioni. Non ci sono particolari carenze che limitano il suo utilizzo.Le uniche mancanze che possiamo sottolineare sono:

• carenza di viste polimetriche: mancanza di viste che permettano di visua-lizzare semplicemente la struttura del progetto analizzato (con al massimoalcune informazioni riguardanti la dipendenza delle entità in questione);

– mancanza di una vista Class Dependency;

– mancanza di una vista Package Dependency;

– mancanza di una vista System Complexity.

• mancanza di autoidentificazione delle metriche con valori fuori norma. Èappurato che non esistono dei valori precisi per constatare che il valore diuna determinata metrica è normale o è anomalo. Però per alcune metricheesistono dei valori che possono portarci a delle conclusioni più o meno certesulla presenza di disarmonie nel codice

– sarebbe consigliabile far si che per quelle metriche, i valori fuori scalavenissero evidenziati di rosso in maniera tale da facilitare la ricerca didisarmonie nel software.

8.3 s u gg er imenti per mi g li o ra r e c r is p

Essendo Crisp un software di piccole dimensioni, gli anti-pattern e i code smellrilevati sono molto pochi.

Tramite l’utilizzo di Analyst4 j possiamo di certo affermare che:

• I commenti presenti non sempre seguono formattazioni standard (es. Doxygen-like). Esistono molti blocchi di codice sorgente commentati, alcuni sonopalesemente sistemi rudimentali di testing dimenticati poi nella versionefinale.



8.4 c on si de ra zi on i f ina li s u c ri sp 158

– si può pensare di introdurre almeno un commento nell’intestazione diogni classe, o ancor meglio nell’intestazione di ogni metodo.

– si può pensare di introdurre commenti utilizzando la formattazioneDoxygen in maniera tale da avere allo stesso tempo senza sforzo una

buona documentazione dettagliata;– si può pensare di eliminare le linee di codice commentate.

• La presenza del code smell Empty Catch Clause, ovvero la presenza nelcodice di clausole di catch o final senza nessun corpo non permette digestire l’exception che potrebbe scaturire e quindi perde completamente disignificato l’utilizzo di un blocco try-catch.

– sarebbe preferibile introdurre il corpo di ogni blocco try-catch, inmaniera tale da poter gestire l’eventuale exception nel migliore deimodi.

• La presenza di una complessità ciclomatica superiore a 10 potrebbe condi-zionare la manutenibilità del sistema. Inoltre esiste una relazione tra elevatacomplessità e bassi livelli di coesione la quale si basa sul fatto che un modulocon più punti decisionali generalmente implementerà più di una singolafunzione ben definita [Stein, 2005]. Alcuni studi hanno trovato una forterelazione tra la complessità ciclomatica e il numero di errori nel codice.Moduli che hanno elevata complessità tendono a contenere un numeroelevato di errori.

8.4 c o ns i der azi oni f i na li s u c ri s p

8.4.1 Tramite Analyst4 j

In definitiva l’analisi attraverso Analyst4 j ha dato buoni frutti evidenziando pochedisarmonie nel codice che non condizionano in maniera evidente il funzionamentodell’applicazione.

Possiamo dire che i maggiori difetti del software possono essere attribuibiliad una scarsa capacità da parte dello sviluppatore di commentare in manierastandard il codice e ad alcuni metodi programmativi poco consigliati ma che nonlimitano in maniera evidente l’utilizzo e il corretto funzionamento del software.

Un fattore abbastanza rilevante che può preoccupare, è la complessità cicloma-tica della classe Parser, che è al di sopra di una ipotetica soglia di accettabilità.

8.5 considerazioni finali su analyst4j

Possiamo definire Analyst4 j come uno dei pochi tool completi e autosufficienti peranalizzare in maniera efficace un progetto Java. Mette a disposizione dell’utenteun’infinità di metriche, anti-pattern, filtri, diagrammi, report che permettono in



8.5 co n si d er a zi o ni fi na l i s u a na ly s t4 j 159

breve tempo di notare le disarmonie più palesi, e di approfondire in maniera piùdettagliata quelle meno evidenti. Inoltre offre funzionalità avanzate per l’analisidella mantenibilità del codice e del version comparison.


• facilità di installazione;

• icone molto intuitive e facilmente ricollegabili all’azione a loro attribuita;

• non richiede meta-file per eseguire le analisi, ma soltanto del codice sorgente;

• è presente sia la versione stand-alone che quella basata sul Framework diEclipse;

• possibilità di modificare il codice sorgente mentre si utilizzano le viste;

• utile anche per il forward engineering oltre che per il reverse engineering;

• eccellente documentazione disponibile in rete, ricca di esempi e spiegazioniutili riguardanti metriche e funzionalità implementate;

• grande quantità di metriche disponibili;

• grande quantità di anti-pattern auto-riconoscibili;

• possibilità di memorizzare impostazioni preferenziali dell’utente;

• possibilità di creare, per qualsiasi metrica o vista, report informativi, indiversi formati (pdf, doc, ...);

• possibilità di utilizzare più filtri contemporaneamente;

• elevata facilità di utilizzo;

• possibilità di creare filtri e query su misura;

• possibilità di creare propri anti-pattern da cercare nel codice;

• possibilità di mettere a confronto più metriche differenti;

• elevata scalabilità;

• funzionalità automatica per il version comparison;• ottima documentazione disponibile gratuitamente on-line;

• ottima funzionalità di Help che permette di avere una dettagliata spiegazio-ne della metrica utilizzata.


• non è open-source, anche se il suo costo per licenza singola è di soli 137 €;




• mancanza di viste polimetriche con riferimento a dipendenza intra-entità;


• utilizzabile soltanto su progetti open-source o di cui si possiede il sorgente.



Qui di seguito abbiamo una tabella contenente la configurazione della macchinautilizzata per testare Analyst4 j.

s-1

Ms Windows 7 x64 bit


4.00 GB

Eclipse Helios Versione 3.5.0

Tabella 21: Configurazione S-1 macchina utilizzata per Analyst4 j


Segue una tabella con il valore tempistico dell’analisi sull’ultima versione diCrisp.

c o nf i gu r azi one c r is p

S-1 4 sec

Tabella 22: Tempistiche di analisi con Analyst4 J su Crisp

8.6.3 Installazione

Requisiti minimi

I requisiti minimi richiesti non sono assolutamente limitativi.Requisiti software:

• Windows NT / 2000 / 2003 / XP o superiore;

• JRE 5.0 o superiore;




• Eclipse 3.1 o superiore.

Requisiti hardware:

• Intel Pentium III 1.0 Ghz;

• 256 MB ram;

• 150 MB hard disk.

L’unica limitazione percepibile della versione standalone riguarda il sistemaoperativo che deve essere perforza Windows, ma ricordiamo esiste la versioneplug-in per Eclipse.

Versione standalone

Non esiste installazione per la versione standalone dato che è un eseguibile.

1. download;

2. decomprimere la cartella;

3. lanciare l’eseguibile analyst4 j.exe.

Versione Eclipse plug-in

L’installazione di Analyst4 j è molto semplice, grazie al fatto che è un plug-in diEclipse.

Infatti seguendo la guida [Swat, a] possiamo notare che basterà:

1. aprire Eclipse e selezionare il menù Help;

2. selezionare il sottomenù install new software;

3. installare il plug-in inserendo il link “http://www.codeswat.com/a4 j/update/“.

In nessuna configurazione è stato riscontrato un malfunzionamento o unamancata installazione.

8.6.4 Bug

Durante l’utilizzo del tool non è stato riscontrato alcun bug.Unico evento anomalo riscontrato è stato durante l’analisi, in cui un file è stato

escluso dal processo di elaborazione.




Figura 137: Tutorial di installazione


Analyst4 j offre una documentazione dettagliata, molto chiara ed approfonditacon molti esempi.

Code Swat, l’azienda produttrice di Analyst4 j mette a disposizione:

• un tutorial on-line per effettuare l’installazione di Analyst4 j StandaloneVersion;

• un tutorial on-line per effettuare l’installazione di Analyst4 j - Eclipse Plugin;

• un’ottima guida incentrata sull’utilizzo di tutte le funzionalità e metricheincorporate nel tool;

• un’ottima spiegazione sugli anti-pattern riconosciuti dal tool;

• un’ottima descrizione sulle metriche utilizzate dal tool;• un tutorial per imparare ad utilizzare il tool;

• un tutorial per imparare a riconoscere anti-pattern e sfruttare le metriche adisposizione;

• delle analisi complete già svolte su un software demo;

• dei tutorial video;




• informazioni aggiuntive su ulteriori espansioni e feature;

Tutta la documentazione è disponibile sul sito ufficiale Code Swat in formagratuita [Swat, b].

Figura 138: Sito ufficiale di Analyst4 j



Parte IIIC O N C L U S I O N I F I N A L I



9C O N C L U S I O N I

9.1 to ol anali zza ti

I tool adoperati per questa relazione sono i seguenti:

• CodeCity

• Manhattan

• Bauhaus

• Lattix

• XRay

• SA4 J

• Analyst4 j

• Dude

Oggetto principale dell’analisi è stato il software JasperReports, nelle versioni:

• 0.x.x

• 1.0.0

• 2.0.0

• 3.0.0

• 4.0.2

Inoltre si è analizzato anche Crisp con Analyst4 j.Lo stile lavoro è stato il seguente: per ogni tool, si esegue un’analisi approfondita

della versione più recente, ed un’analisi evolutiva portata su tutte le versioni

sopracitate, in ottica comparativa.


Durante la relazione, abbiamo dato un giudizio d’analisi sul software, rispettoad ogni tool adoperato. Quel che emerge, è un parere positivo. In particolare,di JasperReports si apprezza la struttura del diagramma package, specie dalla

165




release 1.0.0 alla 3.0.0, ed il fatto che il codice in generale non sia stato stravolto adogni release, ma si è evoluto con il sorgere della necessità di nuove funzionalità.

Da ciascuna singola analisi si evince che sono principalmente due le notenegative: la mancanza di commenti nel codice e il panorama delle dipendenze

nell’ultima release.La mancanza di commenti, non è una vera e propria costante lungo l’arco di

sviluppo. Infatti, se il codice della release 0.x.x e della 1.0.0 è non commentato,nelle successive il trend è diverso, perchè le classi "sopravvissute" dalla primaversione, anche se spostate in altri package, rimangono non commentate, mentre lenuove aggiunte presentano un commento minimo, nell’intestazione e nei metodi.Possiamo ipotizzare che questa situazione sia dovuta a come è nato il progetto,inizialmente un progetto personale, e che poi chi ha proseguito ha cercato dimantenersi al minimo indispensabile.

Analizzando la 4.0.2, da tre tool in particolare abbiamo campanelli d’allarme:Lattix LDM ci fa notare un balzo in avanti del coefficiente d’interdipendenza,ilCoupling, SA4 J indica un anti-pattern Tangle ed il Class Dependency Diagramfornito da X-Ray, se confrontato con i quattro precedenti, è di per se eloquente.Pur avendo mantenuto un’architettura package ordinata, con l’ultima versionesono aumentati esponenzialmente i collegamenti tra classi lontane nell’albero: il"gomitolo" che appare con X-Ray è la struttura grafica che testimonia l’anti-patternTangle individuato da SA4 J, e Tangle appunto significa groviglio in inglese. Lattixavvalla la tesi di questa situazione preoccupante sulle dipendenze fornendocila metrica Coupling, e la semantica rimane la medesima: è la percentuale dellecoppie di classe in interdipendenza.

Per chiudere, ricordiamo che è stato notato anche vario codice inutilizzato o

duplicato; esso si aggira intorno a qualche migliaio di linee di codice, che non èmolto visto le dimensioni totali del progetto comunque, sulle trecentomila lineedi codice.

Non possiamo conoscere quali siano le logiche progettuali che guiderannolo sviluppo nei prossimi anni di questo progetto, ne possiamo conoscerne ilvero stato di salute: un progetto può essere ben fatto ma non essere più ilprodotto di punta, o comunque quello su cui si vogliono concentrare gli sforzidel team. Pensiamo che dalla penultima all’ultima versione analizzata i cambi-amenti siano stati grandi, ma sarebbe da chiedersi se la situazione corrente èaccettabile: potrebbe essere, nonostante un grafo delle dipendenze molto con-

nesso, che il team sia soddisfatto della progettazione e voglia continuare su questastrada, per esempio essendo in grado di difendere la scelta giustificando conprestazioni elevate od una migliore navigabilità. Altresì è possibile che un refac-toring sia pianificato, per raggiungere un compromesso tra buone indicazionidi progettazione-programmazione e scopi pratici; notiamo che un refactoring ègià stato portato dalla versione 0.x.x alla 1.0.0; è il refactoring che ha incanalatolo sviluppo da un piano artigianale-individuale verso la prospettiva teamwork.Ultimo consiglio è quindi un’analisi anti-pattern approfondita, ad esempio con un



9.3 c o ns i de r az i on i f i na l i s u c r is p 167

tool come Analist4 j, al fine di mettersi nella condizione di proseguire lo sviluppopartendo da una base solida, per non rischiare di trascurare situazioni per oranon preoccupanti, o non molto, ma potenziali rischi alla stabilità in futuro.

9.2.1 Peggioramento globale non implica peggioramenti locali

Siamo arrivati alla conclusione, tramite X-Ray in primis, che l’ultima release, la4.0.2, registra un peggioramento in termini di grafo delle dipendenze. Detto ciò, èimportante capire che questo peggioramento, pur essendo lecito ritenerlo globaleperchè il grafo delle dipendenze interessa relazioni rispetto all’intero albero, nonimplica necessariamente peggioramenti ad altre metriche, che invece anzi possonoanche risultare migliorate. Questo è il caso, volendo fare un paio di esempi, dellaciclicità e del numero di linee di codice. Volendo partire con il secondo indicatore,si nota che è minore il numero di classi che spiccano rispetto ad esso: ciò indica

che localmente la situazione è migliorata poiché le classi che precedentementeerano entità uniche sono state successivamente partizionate in moduli più piccoli,e più gestibili.

Per quanto riguarda la ciclicità, abbiamo constatato con SA4 J che l’anti-patternTangle rimane una realtà, anche nell’ultima release; ma esaminando il progettocon Bauhaus, siamo piacevolmente sorpresi dai grafici dei cicli: la situazioneappare molto migliorata in questo senso, e quindi cresce fluidità di esecuzionenonchè la comprensibilità della strutturazione.

Da ciò giungiamo, ancora una volta, alla conclusione che non è corretto daregiudizi di massima o affrettati sui progetti che analizziamo, ma è auspicabilecontestualizzarli e renderci conto che, talvolta, la situazione può peggiorare in unsenso ma migliorare per altri.

9.3 c o ns i der azi oni f i na li s u c ri s p

Il progetto Crisp è un progetto di mobile application di piccole dimensioni,sviluppato nell’arco di un periodo di stage di tre mesi, presso il laboratorio DISCoSAL. Date le sue ridotte dimensioni il reverse engineering potrebbe essere operatoesaminando direttamente il codice. Il parere è positivo, a giudicare da quel che cisuggerisce l’ottimo Analist4 j; preoccupa solamente la classe Parser, che ha unacomplessità ciclomatica alta ed è caratterizzata da funzionalità eterogenea, non si

occupa solo di parsing ma anche per esempio della persistenza dei report.

9.4 c o ns i der azi oni f i na li s ui to o l

Premettiamo che non è corretto individuare il tool migliore in assoluto, poichè di-versi sono gli ambiti in cui uno strumento può aiutarci. Le due categorie base sonoil forward ed il reverse engineering, e seppur il corso, e di conseguenza questa



9.4 c o ns i de r az i on i f i na l i s u i t o ol 168

relazione, sono stati orientati maggiormente alla seconda, tra i tool analizzatialcuni possono ben essere utilizzati durante il processo di sviluppo. È importante,pensiamo, che uno sviluppatore abbia un parco di strumenti ben collaudato econ il quale ha confidenza per affrontare diversi task, e con le seguenti consider-

azioni vogliamo presentare una possibile squadra di lavoro: Analist4 j con X-Rayper il reverse engineering, Manhattan e possibilmente Lattix per aiutarsi con losviluppo-forward.

9.4.1 Reverse: Analist4 j, X-Ray

Analist4 j ha convinto pienamente il gruppo, che ha avuto modo di adoperarlopurtroppo solo su un progetto limitato come Crisp, per via delle restrizioni dellalicenza free, l’unica che è stato possibile ottenere. La ricetta vincente è un’altausabilità per il ricco numero di funzionalità offerte, soprattutto in riferimento

all’anti-pattern Detection, funzionalità rara perchè è sostanzialmente un task com-plesso nella maggior parte dei casi. Completano la panoramica delle funzionalitàche spiccano le metriche, anche personalizzabili con un articolato sistema diquery, un’accurata gestione dei report, ed il version comparison. Inoltre, pregidel programma sono l’elevata documentazione presente, la scalabilità, apprezz-abile analizzando un progetto esteso come ad esempio JasperReports, ed il costodella licenza che, volendo comparare a quello di altri tool anche commerciali,non è altissimo a fronte delle funzionalità offerte. È disponibile sia standalonesia come plugin per Eclipse, cosa molto importante se pensiamo alla potenzadi un ambiente di sviluppo unico, modulare e dove i tool sono a contatto colcodice. X-Ray è un tool che il gruppo ha già avuto modo di analizzare prima dellosvolgimento di questa relazione, per le slide da presentare in aula. Integrato inEclipse, poche funzionalità ma intuitive nell’interpretazione, rilevanti per valutarela salute del progetto ed immediate da utilizzare: questi sono i motivi che cihanno convinto a promuovere a pieni voti questo tool, sviluppato come progettodi laurea all’università di Lugano. Pensiamo che sia un utile completamentoal lavoro di Analist4 j, ed è stato molto utile per esempio nel far saltare subitoall’occhio la discontinuità progettuale tra la versione 3.0.0 e 4.1.2, avallata poianche dai dati quantitativi degli altri tool.

9.4.2 Forward: Manhattan, Lattix

Manhattan è un progetto giovane, anch’esso frutto di uno stage di laurea, e siispira a CodeCity. Ha sorpreso chi ha potuto utilizzarlo a fondo, soprattuttoin virtù di alcune funzionalità tanto rilevanti durante lo sviluppo quanto resein modo efficace e non ambiguo tramite l’interfaccia grafica del programma.Anch’esso è Eclipse-aware, punto sempre a favore, e tra le funzionalità interes-santi accennate è l’aggiornamento della cittadina delle classi in tempo reale, lanotifica grafica nel caso di potenziali conflitti di modifica in un progetto condi-



9.4 c o ns i de r az i on i f i na l i s u i t o ol 169

viso, funzionalità che lo proiettano anche in un’ottica forward. Altre accortezzepotenziano la user experience: non c’è necessità di adoperare metafile o strumentiesterni, ed i grafici costruiti rimangono memorizzati per evitare re-build allariapertura di un progetto. Lattix è un software da promuovere, se non altro per

la potenza e l’originalità dell’approccio DSM all’analisi ed il grande numero dimetriche calcolate per quanto riguarda il reverse, ma può volendo anche essere ad-operato per l’ottica forward. Il suo sistema di impostazione e verifica di regole puòessere utilizzato per guidare lo sviluppo in modo semplice ma anche abbastanzarigido, per evitare che il team di programmatori non si attenga alla progettazionedell’architetto. Abbiamo qualche problema con la scalabilità e l’usabilità, ma conun pò di pratica Lattix diventa un buon tool.

9.4.3 La coerenza dell’analisi: punti discordanti tra i risultati

Se consideriamo l’intero numero di funzionalità (calcolo di metriche, grafici ecc)offerte dal complesso dei tool analizzati, varie sono presenti in più di questi. E’quasi scontato dirlo, perchè alcune indicazioni sono fondamentali, per avere unaprimissima impressione del progetto in analisi, indipendentemente dallo scopeprincipale del tool.

E’ il caso di metriche architetturali come il numero di package, classi, linee dicodice: riguardo a queste, la risposta dei tool è stata omogenea, eccezion fatta perSA4 J che, nel conteggio dei package, considera anche cartelle che non lo sono (es.di sistema, con documentazione ecc). Un altro esempio di metriche discordi è ladisparità tra la percentuale di commenti che CodeCity indica e quella fornita daBauhaus: probabilmente il valore fornito dal primo non è frutto di un sempliceconteggio ma di una media pesata.

Bisogna stare attenti anche ai termini: CodeCity identifica con NOC "Numberof classes", mentre X-Ray "Number of children": un valore diverso potrebbe alloraessere letto come un errore di uno dei due, quando in realtà entrambi sonopotenzialmente corretti poichè gli acronimi hanno significato differente.

Il suggerimento per ovviare a problemi del tipo è il seguente: fissare all’iniziodell’analisi un set di tool e ricordarsi che sono gli unici che devono fare fededurante tutto il processo: infatti non siamo sostanzialmente interessati ai valoried ai grafici come statistiche di per sè, ma in quanto indicatori che guidino ilprocesso. Se all’interno dei tool scelti una o più metriche sono proposte con

risultati diversi, bisognerebbe fissarsi sul tool che pare migliore a riguardo, o peril quale la definizione della metrica, se illustrata nella documentazione, è piùconforme alle nostre esigenze o corretta rispetto alla letteratura.

9.4.4 Da rivedere: SA4 J

Questo tool sembra abbastanza famoso ed usato, ma non pochi sono i difetti, piùo meno gravi, che abbiamo individuato, e che suggeriscono di non considerarlo



9.5 ri fe r im e nt i a to o l n o n a na l iz z at i 170

una "prima scelta" quando si tratta di formare una squadra di tool. La principalepecca è l’interfaccia grafica, come sono presentati i risultati: le viste non possonoessere ridotte, e le tabelle forniscono molti dati ma dalla semantica poco chiarae difficile da contestualizzare. Di conseguenza, la scalabilità è fortemente messa

in dubbio. Inoltre, ci sono seri problemi con alcune funzionalità ritenute di base:non c’è possibilità di navigare l’albero del progetto aprendo le classi presenti,appaiono alcune classi di comodo dal significato poco chiaro e l’individuazionedegli anti-pattern insospettisce, le disarmonie difatti sono individuate ovunquenel progetto, con troppa frequenza. SA4 J bisogna anche dire che è un programmanon recente ma, essendo sviluppato da IBM ed avendo una ampia user base cisi aspetta che stia al passo con altri progetti, commerciali e non, più freschi maanche meno rinomati.

9.5 r i fer i menti a to ol no n a na lizzati

Tra tutti i tool proposti per la scelta dal docente, alcuni hanno funzioni assimilabili,e qui vogliamo brevemente citare qualche strumento non considerato nella nostrarelazione ma analogo a quelli da noi scelti, per evidenziare analogie.

Uno dei tool che abbiamo maggiormente apprezzato è X-Ray, specie per la suaclass dependency view. Codecrawler [Lanza] è il padre di X-Ray, che costituisce lacorrispettiva versione per Eclipse, sviluppato dal Prof. M. Lanza, dell’Universitàdi Lugano. Non vediamo però motivi particolari per preferire questo tool adX-Ray, se non altro perchè Codecrawler è un progetto vecchio, è proseguimentodi Moose [Unibe] infatti, e riteniamo molto importante l’integrazione con Eclipse:perchè dovremmo scegliere un tool che fa le stesse cose ma ha lo svantaggio dinon essere integrato?

Un tool che ci è parso interessante è Understand, e l’ipotesi d’utilizzo sarebbeaffiancarlo a Lattix LDM. Il motivo di questa scelta è che troviamo affinità traquesti due software:

• entrambi prestano molta attenzione al concetto di dipendenza, Lattix tramitela matrice DSM, Understand attraverso il grafico Depends on;

• sia Lattix sia Understand forniscono varie metriche di analisi, ma il secondoaggiunge anche grafici associati ad esse;

• gestione di report: in Understand però i report sono compositi e di livellosuperiore.

Siamo quindi in presenza di due tool concettualmente differenti ma progettatiper soddisfare un’esigenza comune: guidare l’esame di un progetto accostandometriche numeriche a rappresentazioni grafiche, più immediate. In questo senso,non dimentichiamoci di JDepend anche: integrato in Eclipse, fornisce metricheche anche Lattix vanta (es. distanza sequenza principale) ma con relativo graficoannesso, ed è orientato all’isolare conflitti rispetto al rischio di ciclicità, cosa che



9.6 l a s t es u ra d i q u es t o d o cu m en t o 171

in Lattix non si può fare direttamente, poichè bisogna integrare l’informazionedegli score cyclicality alla matrice DSM.

Tutti i tool che abbiamo analizzato nella relazione e citato in questa sezionesono stati pensati espressamente per analizzare progetti software, principalmente

Java, che si è imposto come il linguaggio OO per eccellenza. D’altro canto però, unsistema software è, più genericamente, un sistema definito spazio d’informazione,assimilabile in questo, per esempio, ad un’ontologia. L’unico tool di valore che siè trovato per l’analisi di questa gerarchia è SHriMP, ed esso supera i tool prece-denti non tanto nella funzionalità, ma dalla potenza che deriva dall’astrazione:analizzare un software da una prospettiva più alta dà adito a servirsi di altriconcetti e chiavi di lettura che normalmente non ci si aspetterebbe di applicare.

9.6 la s tes ur a d i qu esto d oc u mento

Scrivere una relazione lunga e complessa ad otto mani, presenta varie difficoltà:• concordare una formattazione comune;

• gestire gli aggiornamenti del documento.

Grazie soprattutto alla stesura delle nostre tesi, abbiamo imparato a conoscere edapprezzare LATEX, cui pregi sono soprattutto la grande disponibilità di componentiaggiuntivi per curare ogni singolo aspetto del documento, l’essere un linguaggiorigoroso che libera dal paradigma WYSWYG e, non ultimo, quello di avere unanumerosa base utenti essendo oramai quasi uno standard universale per la stesuradi documenti scientifici.

Una critica che si potrebbe però fare all’adottare uno strumento come LATEX è lanecessità di dover imparare un linguaggio e più in generale un certo approccioalla scrittura, e ciò, se si è stretti coi tempi, costituisce sicuramente un problema.La scelta del gruppo è stata quindi quella di una via media, rappresentata dallascelta di LYX [Lyx]: questo programma permette di scrivere un documento LATEXcon una sintassi più semplice ed aiuta fornendo un alto numero di macro dainserire automaticamente. Permette inoltre di importare file .tex cosicchè integrarecodice LATEX scritto a mano non costituisce un problema.

Quando si lavora alla stesura di documento scritto nei modi illustrati, quel chesi gestisce è un insieme di file di testo, e si esporta in formati binari solo una

volta completato il lavoro, per la presentazione. A questo proposito, un sistemadi controllo delle versioni è la scelta ideale, ed è stato adottato SVN. Un serverSVN era già disponibile e predisposto poichè fornito per il modulo della Dott.ssaMicucci, ma non avremmo comunque optato, ad esempio, per CVS se avessimopotuto: questo sistema, che è un pò il concorrente di SVN, è stato conosciuto dallamaggior parte di noi nell’esame di Ingegneria del Software alla triennale, manon ha convinto per vari motivi tra cui, ad esempio l’impossibilità di cancellarecartelle.



Parte IVA P P E N D I C E



AA P P E N D I C E

In questo capitolo riportiamo alcune tabelle comparative sui tool analizzati nellarelazione. Queste tabelle sono state aggiunte per completezza ma, viste le dimen-sioni delle stesse è stato difficile inserirle nelle singole pagine mantenendo una

buona leggibilità. Si consiglia pertanto di utilizzare i fogli di calcolo allegati allarelazione per una migliore comprensione.

Oltre alle tabelle prestrutturate fornite per riassumere la comparazione dei tool,è stata aggiunta una nuova tabella per noi significativa: il suo scopo è valutareper ogni tool il campo di applicazione in cui fornisce i migliori risultati.

Ci è sembrato valore aggiunto inserire delle voci già affrontate nelle altre tabelleper avere un quadro complessivo mirato.

Il fine ultimo di questa tabella è dare a uno sviluppatore uno strumento concretoper scegliere da quali tool farsi assistere nell’analisi e sviluppo partendo dalleproprie esigenze.

173



Figure 139: Feature tools comparison 1

174



Figure 140: Feature tools comparison 2

175



Figure 141: Output of the tools comparison

176



Figure 142: Application field comparison 1177



Figure 143: Application field comparison 2

178



B I B L I O G R A P H Y

Aivosto.com. Cohesion metrics. URL http://www.aivosto.com/project/help/

pm-oo-cohesion.html. (Citato alla pagina 6.)

Axivion. Axivion guide 5.6. URL http://www.axivion.com/ . (Citato alla pag-ina 84.)

Project Bauhaus. Bauhaus,software architecture, software reengineering, andprogram understanding. URL http://www.bauhaus-stuttgart.de/bauhaus/

index-english.html. (Citato alla pagina 65.)

Pierre Caserta and Olivier Zendra. Visualization of the static aspects of software:a survey. IEEE TRANSACTIONS ON VISUALIZATION AND COMPUTER

GRAPHICS, PP(9), 2010. (Citato alla pagina 28.)

S.R. Chidamber and C.K. Kemerer. A metrics suite for object oriented design.IEEE Trans. on Software Eng., 20(6), 1994. (Citato alla pagina 4.)

Eclipse Coorporation. Eclipse. URL http://www.eclipse.org/ . (Citato allapagina 62 e 134.)

Cunningham. Cunningham and cunningham incorporated. URL http://www.c2.

com. (Citato alla pagina 15.)

Norman E. Fenton and Shari Lawrence Pfleeger. Software Metrics: A Rigorous and

Practical Approach. PWS Publishing Co., Boston, MA, USA, 2nd edition, 1998.ISBN 0534954251. (Citato alla pagina 90.)

Lile Hattori and Michele Lanza. Syde: A tool for collaborative software develop-ment. REVEAL, 2010. (Citato alla pagina 48.)

B. Henderson-Sellers. Object-oriented metrics : measures of complexity. Prentice-Hall,1996. (Citato alla pagina 4.)

Hirondelle. Interface for constants. URL http://www.javapractices.com/topic/

TopicAction.do?Id=32. (Citato alla pagina 9.)IBM. S A4 J, a. URL http://www.alphaworks.ibm.com/tech/sa4j . (Citato alla

pagina 114.)

IBM. S A4 JDownload, b. URL http://www.alphaworks.ibm.com/tech/sa4j/

download. (Citato alla pagina 113.)

179

http://www.aivosto.com/project/help/pm-oo-cohesion.html


http://www.axivion.com/


http://www.bauhaus-stuttgart.de/bauhaus/index-english.html


http://www.eclipse.org/


http://www.c2.com/

http://www.c2.com/

http://www.c2.com/

http://www.javapractices.com/topic/TopicAction.do?Id=32



http://www.alphaworks.ibm.com/tech/sa4j

http://www.alphaworks.ibm.com/tech/sa4j/download





http://www.alphaworks.ibm.com/tech/sa4j



http://www.c2.com/

http://www.c2.com/









b ib li og ra ph y 180

B. Kang and J.M. Biemann. Cohesion and reuse in an object-oriented system.Proceedings of the 1995 Symposium on Software, pages 259–262, 1995. (Citato allapagina 6.)

Lanza. Code Crawler web-site. URLhttp://www.inf.usi.ch/faculty/lanza/

codecrawler.html. (Citato alla pagina 170.)

M. Lanza, R. Marinescu, and S. Ducasse. Object-oriented metrics in practice. Springer,2006. (Citato alla pagina 10 e 126.)

Lyx. Lyx web-site. URL http://www.lyx.org. (Citato alla pagina 171.)

Jacopo Malnati. Website x-ray. URL http://xray.inf.usi.ch/. (Citato allapagina 125 e 134.)

Halstead Maurice. Halstead effort. URL http://publib.boulder.ibm.

com/infocenter/pdthelp/v1r1/index.jsp?topic=/com.ibm.wsaa.doc_

5.1/common/chalstd.htm. (Citato alla pagina 154.)

m. Meyer and J. Niere. Calculation and visualization of software product metrics.(Citato alla pagina 11.)

Oracle. Java, a. URL http://www.java.com/it/download/ . (Citato alla pagina 62

e 139.)

Oracle. Video trial Manhattan, b. URL http://vimeo.com/25595367 . (Citato allapagina 64.)

Francesco Rigotti. Manhattan website. URL http://atelier.inf.usi.ch/~rigottifr/manhattan.php . (Citato alla pagina 62.)

Neeraj Sangal. Lightweight dependency models to manage software architecture.In WICSA, page 40, 2007. (Citato alla pagina 85.)

Glenn Etzkorn Letha Stein, Cox. Exploring the relationship between cohesion andcomplexity. Journal of Computer Science, 2(137-144), 2005. (Citato alla pagina 158.)

Code Swat. Analyst4 J guide, a. URL http://www.codeswat.com/cswat/

index.php?option=com_content&task=view&id=47&Itemid=67 . (Citato allapagina 161.)

Code Swat. CodeSwatsito, b. URL http://www.codeswat.com/cswat/index.php .(Citato alla pagina 163.)

Unibe. Moose web-site. URL http://moose.unibe.ch/. (Citato alla pagina 170.)

Richard Wettel. Code City FAQs, a. URL http://www.inf.usi.ch/phd/wettel/

codecity-faq.html. (Citato alla pagina 2.)

http://www.inf.usi.ch/faculty/lanza/codecrawler.html



http://www.lyx.org/

http://www.lyx.org/

http://xray.inf.usi.ch/

http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=/com.ibm.wsaa.doc_5.1/common/chalstd.htm






http://www.java.com/it/download/


http://vimeo.com/25595367


http://atelier.inf.usi.ch/~rigottifr/manhattan.php


http://www.codeswat.com/cswat/index.php?option=com_content&task=view&id=47&Itemid=67





http://www.codeswat.com/cswat/index.php

http://moose.unibe.ch/


http://www.inf.usi.ch/phd/wettel/codecity-faq.html






http://www.codeswat.com/cswat/index.php










http://xray.inf.usi.ch/

http://www.lyx.org/





b ib li og ra ph y 181

Richard Wettel. Dude web-site, b. URL http://www.inf.usi.ch/phd/wettel/

dude.html. (Citato alla pagina 140.)

Richard Wettel. Wettel Richard website, c. URL http://www.inf.usi.ch/phd/

wettel/index.html

. (Citato alla pagina 48 e 136.)

http://www.inf.usi.ch/phd/wettel/dude.html



http://www.inf.usi.ch/phd/wettel/index.html







reverse engineering of jasperreports with various tools

Documents