Sei sulla pagina 1di 194

Universit degli Studi di MilanoBicocca

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 WA R E

tool: CodeCity, Manhattan, Bauhaus, Lattix, SA4J, X-Ray, Analyst4j, 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 20102011

INTRODUZIONE

Il lavoro presentato in questa relazione, nasce dallesigenza di approfondire il panorama attuale dei software di reverse engineering disponibili, in particolare ci siamo concentrati su un nutrito subset formato dai seguenti otto tool: CodeCity, Manhattan, Bauhaus, Lattix, SA4J, X-Ray, Analyst4j e Dude . Per valutare la qualit dei tool sotto diversi aspetti, li abbiamo usati per analizzare due progetti di diverse dimensioni: JasperReports, di grandi dimensioni e Crisp, una piccola applicazione mobile. Attraverso il confronto delle conclusioni tratte singolarmente con ogni tool, siamo riusciti a dare una valutazione qualitativa e quantitativa dei software analizzati oltre ad aver inquadrato pregi e difetti dei tool stessi. Per quanto riguarda la valutazione dei tool, la loro sperimentazione ci ha permesso di evidenziarne le funzionalit e lusabilit, ma ha anche fatto emergere mancanze e criticit. Per una approfondita analisi del software invece, oltre ad analizzare approfonditamente lultima versione rilasciata, nel caso di JasperReports, sono state confrontate le cinque principali release al ne di acquisire una visione evolutiva globale. Le diverse analisi sono tra loro indipendenti e hanno una loro consistenza anche lette singolarmente. Trarremo inne delle conclusioni complessive sul software e sui tool utilizzati prendendo posizione circa i risultati forniti da ognuno e le discrepanze emerse, considerando anche altri tool non presentati in questa relazione.

ii

INDICE

i analisi di jasperreports 1 1 codecity 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 inuenti 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 nali su JasperReports 43 1.6 Considerazioni nali su CodeCity 44 1.7 Dettagli tecnici 44 1.7.1 Congurazioni macchine utilizzate 44 1.7.2 Tempistiche di analisi 45 1.7.3 Installazione 46 1.7.4 Bug 46 1.7.5 Documentazione 46 2 manhattan 48 2.1 Analisi 48 2.1.1 Analisi progettuale - Anti-Pattern 48 2.1.2 Analisi programmativa - Code Smell 50 2.2 Analisi evolutiva 51 2.3 Forward Engineering 54 2.4 Suggerimenti per migliorare Manhattan 56 2.5 Suggerimenti per migliorare JasperReports 58 2.6 Considerazioni nali su JasperReports 59 2.6.1 Tramite Manhattan 59 2.7 Considerazioni nali su Manhattan 59 2.8 Dettagli tecnici 61 2.8.1 Congurazione macchina utilizzata 61 2.8.2 Tempistiche di analisi 61 2.8.3 Installazione 62 2.8.4 Bug 63 2.8.5 Documentazione 64

iii

Indice

iv

3 bauhaus 65 3.1 Analisi 65 3.1.1 Analisi progettuale - Anti-Pattern 65 3.1.2 Analisi programmativa - Code Smell 68 3.2 Analisi evolutiva 72 3.3 Suggerimenti per migliorare Bauhaus 75 3.4 Suggerimenti per migliorare JasperReports 77 3.5 Considerazioni nali Bauhaus 77 3.6 Considerazioni nali su JasperReports 77 3.7 Dettagli tecnici 78 3.7.1 Congurazioni macchine utilizzate 78 3.7.2 Tempistiche di analisi 78 3.7.3 Installazione 80 3.7.4 Analisi software java 81 3.7.5 Bug 82 3.7.6 Documentazione 84 4 lattix 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.1.4 Analisi progettuale - Anti-Pattern 88 4.1.5 Analisi programmativa - Code Smell 88 4.2 Analisi evolutiva 89 4.2.1 Metriche architetturali 90 4.2.2 Metriche OO 93 4.3 Miglioramenti possibili 94 4.3.1 Suggerimenti per migliorare il tool 94 4.3.2 Suggerimenti per migliorare JasperReports 4.4 Dettagli tecnici 95 4.4.1 Tempistiche danalisi 95 4.4.2 Installazione 95 4.4.3 Bug 96 4.4.4 Documentazione 96 5 sa4j 97 5.1 Analisi 97 5.1.1 Analisi progettuale - Anti-Pattern 97 5.1.2 Analisi programmativa - Code Smell 104 5.2 Analisi evolutiva 105 5.3 Suggerimenti per migliorare SA4J 108 5.4 Suggerimenti per migliorare JasperReports 109 5.5 Considerazioni nali su JasperReports 110 5.5.1 Tramite SA4J 110

95

Indice

Considerazioni nali su SA4J 110 Dettagli tecnici 112 5.7.1 Congurazione macchina utilizzata 112 5.7.2 Tempistiche di analisi 112 5.7.3 Installazione 112 5.7.4 Bug 113 5.7.5 Documentazione 114 6 x-ray 115 6.1 Analisi 115 6.1.1 Analisi progettuale - Anti-Pattern 115 6.1.2 Analisi programmativa - Code Smell 116 6.2 Analisi evolutiva 120 6.3 Suggerimenti per migliorare il tool 124 6.4 Suggerimenti per migliorare JasperReports 127 6.5 Considerazioni nali su JasperReports 129 6.5.1 Tramite X-Ray 129 6.6 Considerazioni nali su X-Ray 130 6.7 Dettagli tecnici 131 6.7.1 Congurazioni macchine utilizzate 131 6.7.2 Tempistiche di analisi 132 6.7.3 Installazione 134 6.7.4 Bug 134 6.7.5 Documentazione 134 7 dude 136 7.1 Analisi 136 7.1.1 Analisi code clones 136 7.2 Suggerimenti per migliorare il tool 138 7.3 Suggerimenti per migliorare JasperReports 138 7.4 Considerazioni nali su JasperReports 138 7.5 Considerazioni nali su Dude 138 7.6 Dettagli tecnici 139 7.6.1 Congurazione macchina utilizzata 139 7.6.2 Tempistiche di analisi 139 7.6.3 Installazione 139 7.6.4 Requisiti 139 7.6.5 Bug 139 7.6.6 Documentazione 140 5.6 5.7 ii analisi di crisp 141 8 analyst4j 142 8.1 Analisi 142 8.1.1 Analisi progettuale - Anti-Pattern 142 8.1.2 Analisi programmativa - Code Smell 145

indice

vi

8.2 8.3 8.4 8.5 8.6

Suggerimenti per migliorare il tool 157 Suggerimenti per migliorare Crisp 157 Considerazioni nali su Crisp 158 8.4.1 Tramite Analyst4j 158 Considerazioni nali su Analyst4j 158 Dettagli tecnici 160 8.6.1 Congurazione macchina utilizzata 8.6.2 Tempistiche di analisi 160 8.6.3 Installazione 160 8.6.4 Bug 161 8.6.5 Documentazione 162

160

iii conclusioni finali 164 9 conclusioni 165 9.1 Tool analizzati 165 9.2 Considerazioni nali su JasperReports 165 9.2.1 Peggioramento globale non implica peggioramenti locali 167 9.3 Considerazioni nali su Crisp 167 9.4 Considerazioni nali sui tool 167 9.4.1 Reverse: Analist4j, X-Ray 168 9.4.2 Forward: Manhattan, Lattix 168 9.4.3 La coerenza dellanalisi: punti discordanti tra i risultati 169 9.4.4 Da rivedere: SA4J 169 9.5 Riferimenti a tool non analizzati 170 9.6 La stesura di questo documento 171 iv appendice 172 a appendice 173 bibliography 179

ELENCO DELLE FIGURE

Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21 Figura 22 Figura 23 Figura 24 Figura 25 Figura 26 Figura 27 Figura 28

LOC, NOC e NOP di JasperReports 3 GenericChartTheme 4 Bassissimo livello di coesione della classe JRViewer 5 Bassissimo livello di coesione delle classi JRXhtmlExporter, JRHtmlExporter, JRPdfExporter 5 Bassissimo livello di coesione della classe JRFillElement 6 Classi di dimensioni intermedie del package net.sf.jasperreports.engine con basso livello di coesione 7 Altre classi di dimensioni intermedie del package net.sf.jasperreports.engine con basso livello di coesione 7 Le interfacce presenti in JasperReports 8 Swiss Army Knife in JRStyle (CodeCity) 9 Una vista ne-grained di JRStyle 10 Analisi WNOC e NOM: classi inuenti 12 Analisi NOAM e NLOC per Spaghetti Code 13 Men Disharmony Map in CodeCity 14 God Class in CodeCity 15 Brain Class in CodeCity 16 Both God & Brain Class in CodeCity 17 Complessit della Both God & Brain Class JRApiWriter, considerata anche una standalone class da CodeCity 18 Complessit della Both God & Brain Class JRVerier 19 Complessit delle Both God & Brain Classes del package engine.ll 20 Complessit delle Both God & Brain classes del package engine.ll 21 Complessit delle Both God & Brain Classes del package engine.base 22 Data Class rilevate da CodeCity 23 God (in fucsia), Brain (in giallo), Both God & Brain (in arancione) e Data Class (in viola) rilevate da CodeCity 24 Brain Methods del package engine 25 Shotgun Surgery e Feature Envy rilevati da CodeCity 26 Analisi code smell Too Need Comments in CodeCity 27 Analisi FANIN per i crosscutting concerns e rilevazione dell anti-pattern Hub 29 Analisi FANIN per i crosscutting concerns e rilevazione dell anti-pattern Hub 30

vii

Elenco delle gure

viii

Figura 29 Figura 30 Figura 31 Figura 32 Figura 33 Figura 34 Figura 35 Figura 36 Figura 37 Figura 38 Figura 39 Figura 40 Figura 41 Figura 42 Figura 43 Figura 44 Figura 45 Figura 46 Figura 47 Figura 48 Figura 49 Figura 50 Figura 51 Figura 52 Figura 53 Figura 54 Figura 55 Figura 56 Figura 57 Figura 58 Figura 59 Figura 60 Figura 61

JasperReports 0.x.x e 1.0.0 con CodeCity 32 Rilevazione degli anti-pattern in JasperReports con CodeCity, release 0.x.x 33 Rilevazione degli anti-pattern in JasperReports, release 1.0.0 34 Data Class in JasperReports, release 1.0.0 35 Invocazioni entranti e uscenti di JRXmlWriter in JasperReports, release 1.0.0 36 Rilevazione degli anti-pattern in JasperReports, release 2.0.0 37 Anti-pattern individuati da CodeCity nel package engine.ll di JasperReports, release 2.0.0 38 Anti-pattern individuati da CodeCity nel package engine.export di JasperReports, release 2.0.0 39 Rilevazione degli anti-pattern in JasperReports, release 2.0.0 40 Nuovi package contenenti molte Data Class in JasperReports, release 3.0.0 40 Interfaccia sospetta - JRStyle 49 Package engine on Orbital View 50 JRXmlConstants on First Person View 51 Evoluzione tra JasperReports versione 0.x.x e 1.0.0 52 JasperReports tramite Orbital View 52 Confronto versioni tramiter Orbital View 53 Evoluzione tra JasperReports versione 2.0.0 e 3.0.0 54 Evoluzione JasperReports versione 4.0.2 54 Reacting to changes 55 Team Activity Awareness 56 Tutorial di installazione 63 Schermata di errore (n2) 63 Sito ufciale di Manhattan 64 Principali cicli evidenziati nel sistema 66 Complessit ciclomatica signicativa tipica di una Brain Class 66 Complessit ciclomatica bassa a fronte del numero di righe 67 JRApiWriter 67 JRApiWriter Fish view 68 Disarmonia nella classe JRStyle 68 Vista Element Count di JasperReports generata con Bauhaus 69 Metodi con pi di 100 linee di codice 69 Metriche del metodo addChartRoules 70 Linee di commento rispetto a linee di codice in Bauhaus 70

Elenco delle gure

ix

Figura 62

Figura 63 Figura 64

Figura 65

Figura 66

Figura 67

Figura 68

Figura 69

Figura 70

Figura 71

Figura 72

Figura 73

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 numero totale di cloni elevato come si pu notare dalla barra laterale 71 Esempio di codice contenente denizioni di costanti duplicate 71 Conteggio degli elementi delle prime tre versioni di JasperReports. Da sinistra JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0. Si nota un incremento quasi proporzionale su tutti gli elementi: package, classi, interfacce. 72 Confronto del numero di linee di codice. Dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0. Non si nota una signicativa variazione tra le tre versioni. 73 Confronto della complessit ciclomatica assoluta e rispetto al numero di linee di codice eseguibili. Per ogni riga dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0. 74 Confronto della presenza di cicli nelle varie versioni di JasperReports. Dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0 75 Vista comparativa della correlazione tra numero di linee di commento e numero di linee di codice di JasperReports. Dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0 76 Errore che si presenta alla richiesta di riordinare i nodi secondo uno specico layout e porta alla terminazione del programma 83 Quando si cerca di aprire un package con doppio click viene mostrato questo errore perch non c, evidentemente, un le di codice di denizione del package 83 Bauhaus fornisce un ottimo supporto alla selezione di nodi e archi: permette ad esempio di aggiungere alla selezione i discendenti, archi entranti e uscenti e molte altre varianti. Si verica per questo errore quando si sceglie lopzione Deselect nodes; bisogna invece scegliere Deselect all 83 Nei plot per la rappresentazione di informazioni metriche, impostando come assi alcuni criteri si ottiene un graco vuoto con gli elementi tutti spostati nella parte superiore della nestra. In gura il riquadro rosso segna dove dovrebbe essere il plot, notiamo che manca anche il riquadro, mentre tutti gli elementi si condensano in quella riga grigia nella parte superiore della schermata. 83 Focus sulla classe JRBaseFactory 89

Elenco delle gure

Figura 74 Figura 75

Figura 76 Figura 77 Figura 78 Figura 79 Figura 80 Figura 81 Figura 82 Figura 83 Figura 84 Figura 85 Figura 86 Figura 87 Figura 88 Figura 89 Figura 90 Figura 91 Figura 92 Figura 93 Figura 94 Figura 95 Figura 96 Figura 97 Figura 98 Figura 99 Figura 100 Figura 101 Figura 102 Figura 103 Figura 104 Figura 105 Figura 106 Figura 107 Figura 108 Figura 109 Figura 110 Figura 111

La root DSM per ciascuna delle cinque release in ordine 90 Metriche assortite. Si pu chiedere al sistema di generare tre distinti tipi di metriche, di sistema, darchitettura ed orientate agli oggetti 91 La Knowledge Base ufciale Lattix LDM - http://kb.lattix.com 96 Anti-pattern Summary 98 Tangle 99 Tangle 99 Global Hub 100 JasperDesign 101 Skeleton view 101 What if view 102 What if view- Dependency 103 JRBaseFactory 104 Statistics 104 JRApiWriter 105 JRExpression 105 JasperReports 0.x.x 106 JasperReports 1.0.0 106 JasperReports 2.0.0 & 3.0.0 107 JasperReports 4.0.2 108 Sito ufciale di SA4J 114 JRBaseFactory on System Complexity view 115 Anti-pattern: Swiss Army Knife / Codesmell: mancanza di commenti 116 Dimensioni del software target 117 Classe JRVerier 118 Empty Catch Clause on JRClassGenerator 119 Package Dependency on JasperReports 0.x.x 120 Class Dependency on JasperReports 0.x.x 121 System Complexity View on JasperReports 0.x.x 122 Class Dependency on JasperReports 0.x.x e 1.0.0 123 Package Dependency on JasperReports 0.x.x & 1.0.0 124 Evoluzione Class Dependency 0.x.x, 1.0.0, 2.0.0, 3.0.0, 4.0.2 125 Evoluzione Package Dependency View 0.x.x, 1.0.0, 2.0.0, 3.0.0, 4.0.2 126 Sito ufciale di X-Ray 135 Statistics in Dude 137 Dude view 137 Sito ufciale di Dude 140 Anti-pattern in Analyst4j 143 Zero Encapsulation Classes 143

Figura 112 Figura 113 Figura 114 Figura 115 Figura 116 Figura 117 Figura 118 Figura 119 Figura 120 Figura 121 Figura 122 Figura 123 Figura 124 Figura 125 Figura 126 Figura 127 Figura 128 Figura 129 Figura 130 Figura 131 Figura 132 Figura 133 Figura 134 Figura 135 Figura 136 Figura 137 Figura 138 Figure 139 Figure 140 Figure 141 Figure 142 Figure 143

Procedure Oriented Design 144 Query - Analyst4j Searches 144 Candidate Data Classes 144 Data Classes 145 Analysis Report 146 QA Scope View 147 Metrics - Peer Comparison 147 Swat Index - Descendants Comparison 148 Too Much Documentation 148 Empty catch clauses 149 Swat Index - Descendants Comparison 150 Comparison Report 151 Notes view 151 Comparison Analysis 152 NLOC vs CC 152 Unstructuredness vs Documentation 153 NLOC vs NOCL 153 Metodo refreshDir 153 NLOC Vs Halstead Volume 154 Distribution Analysis 154 Cyclomatic Complexity 155 Essential Complexity 155 Lack of cohesion of methods 156 Inner Class 156 Packages Instability 157 Tutorial di installazione 162 Sito ufciale di Analyst4j 163 Feature tools comparison 1 174 Feature tools comparison 2 175 Output of the tools comparison 176 Application eld comparison 1 177 Application eld comparison 2 178

E L E N C O D E L L E TA B E L L E

Tabella 1 Tabella 2

Evoluzione del LOC, NOC, NOP e numero di elementi per release di JasperReports 31 Variazioni quantitative degli anti-pattern durante levoluzione di JasperReports 37

xi

Tabella 3 Tabella 4 Tabella 5 Tabella 6 Tabella 7 Tabella 8 Tabella 9 Tabella 10 Tabella 11 Tabella 12 Tabella 13 Tabella 14 Tabella 15 Tabella 16 Tabella 17 Tabella 18 Tabella 19 Tabella 20 Tabella 21 Tabella 22

Congurazioni C-1 e C-2 su cui si utilizzato CodeCity 45 Tempistiche (creazione modello e sua importazione) relative a CodeCity per la congurazione C-1 45 Tempistiche (creazione modello e sua importazione) relative a CodeCity per la congurazione C-2 45 Congurazione macchina utilizzata 61 Tempistiche di analisi con Manhattan su JasperReports 62 Panoramica quantitativa 87 Peso sotto-package 90 Panoramica dipendenze 90 Metriche Architetturali 92 Metriche OO su JasperReports 93 Congurazione macchina utilizzata 112 Tempistiche di analisi con SA4J su JasperReports 112 Congurazioni macchine utilizzate 132 Tabella delle tempistiche di analisi con X-Ray su JasperReports con la congurazione S-1 132 Tabella con le tempistiche di analisi con X-Ray su JasperReports con la congurazione S-2 133 Tabella con le tempistiche di analisi con X-Ray su JasperReports con la congurazione S-3 133 Tabella con le tempistiche di analisi con X-Ray su JasperReports con la congurazione S-4 133 Congurazione macchina utilizzata per lutilizzo di Dude 139 Congurazione S-1 macchina utilizzata per Analyst4j 160 Tempistiche di analisi con Analyst4J su Crisp 160

ACRONIMI

NOM NOA LOC ELOC NOP

Numero di metodi Numero di attributi Numero di linee di codice Numero di linee di codice eseguibili Numero di package

xii

acronimi

xiii

NOC FAMIX

Numero di classi 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 Formato di le, simile allXML, utile a specicare modelli generali riguardati ogni tipo di dati, indipendentemente dal meta modello. adottato dal software Moose come standard per limport e lexport di modelli Quantica la mancanza di coesione nei metodi Weight of class Weighted number of children Tight class cohesion Depth of inheritance tree Number of accesses methods Weighted methods per class Numero di invocazioni verso un metodo (entranti) Numero di invocazioni da un metodo (uscenti) Numero pesato di commenti

MSE

LCOM WOC WNOC TCC DIT NOAM WMC FANIN

FANOUT

WNOCmts WLOC

Numero pesato di linee di codice

Parte I A N A L I S I D I J A S P E R R E P O RT S

CODECITY

CodeCity un software standalone (disponibile per tutte le piattaforme) il cui ne principale lanalisi del software. Tale ne espletato visualizzando il software in analisi come una citt rappresentata (e navigabile) in 3 dimensioni. Nello specico, la metafora software - citt composta dalle seguenti convenzioni: i package sono rappresentati come distretti (o quartieri) della citt; le classi sono rappresentate come edici (parallelepipedi con base quadrata); pi dettagliatamente: ad un maggiore numero di metodi della classe1 corrisponde una maggiore altezza del relativo edicio; ad un maggiore numero di attributi della classe2 corrisponde una maggiore base (quadrato di area maggiore) delledicio; ad un maggiore numero di linee di codice3 della classe corrisponde una maggiore intensit del colore del relativo edicio. Ulteriori convenzioni sui colori vengono inne utilizzate per attirate lattenzione sulla presenza di determinati anti-pattern nel codice del software in analisi. CodeCity supporta lanalisi di software scritti in Java, C, C++, C# e SmallTalk. Tuttavia necessario generare per ogni progetto il relativo modello FAMIX4 2.1, un le MSE5 creato da inFusion (versione 7.2.5, release di ottobre 2009), da importare in CodeCity [Wettel, a].

1 2 3 4

Metrica: Numero di metodi (NOM) Metrica: Numero di attributi (NOA) Metrica: Numero di linee di codice (LOC) 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 le, simile allXML, utile a specicare modelli generali riguardati ogni tipo di dati, indipendentemente dal meta modello. adottato dal software Moose come standard per limport e lexport di modelli (MSE)

1.1 analisi progettuale e programmativa

1.1

analisi progettuale e programmativa

Lanalisi verr applicata soltanto allultima versione di JasperReports, per riuscire a 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 le MSE della versione 4.0.2 di JasperReports ed attesa la sua elaborazione, CodeCity riporta 3 metriche generali sul software in analisi: LOC, NOC6 , NOP7 . Limmagine seguente certica come, nel caso di JasperReports esso possegga 168.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 generiamo la visualizzazione del software come citt in base alla congurazione base di CodeCity: la vista magnitude, una vista coarse-grained, le cui caratteristiche sono gi state descritte nella pagina precedente. Poich CodeCity molto intuitivo si procede in questo senso analizzando gli edici dal colore blu pi intenso e quelli che spiccano per altezza. Seguendo questo criterio abbastanza facile individuare le classi potenzialmente affette da anti-pattern e/o code smell. Ad esempio, nel package net.sf.jasperreports.chatthemes.spring spicca la classe GenericChartTheme, 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, come mostra limmagine 2 nella pagina successiva.

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

1.1 analisi progettuale e programmativa

Figura 2: GenericChartTheme

Passando con il mouse su questa classe, il pannello di informazioni ci avverte che essa ha un valore di NOA pari a 5: anche se CodeCity non calcola una metrica molto utile come la LCOM [Chidamber and Kemerer, 1994, Henderson-Sellers, 1996] (Lack of Cohesion of Methods)8 relativamente facile stimarla intuitivamente. Infatti, avendo questa classe molti metodi e pochi attributi, necessariamente, molte coppie di metodi condivideranno gli stessi attributi, portando cos la LCOM ad avere un valore basso, il ch signica un buon (o ottimo) livello di coesione della classe. Questa classe, quindi, almeno a prima vista non presenta lampanti problemi di progettazione. Dalla sua analisi abbiamo per appreso che gli edici che pi assomigliano a un cubo (la cui base e altezza sono valori numericamente vicini) sono imputati come 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 package net.sf.jasperreports.view che ha un valore di LOC pari a 1579, NOM pari a 74 e NOA pari a 66. Come appena spiegato, una situazione del genere porta inevitabilmente a sospettare che questa classe sia, con ogni probabilit, poco coesa: infatti poco probabile che tutti i 74 metodi che possiede (o molti di essi) condividano tutti e 66 gli attributi (o molti di essi); di conseguenza la metrica LCOM avr un valore alto, sintomo di bassa coesione della classe. Limmagine 3 nella pagina seguente illustra questa classe che viene rappresentata come un parallelepipedo molto vicino ad essere un cubo.

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

1.1 analisi progettuale e programmativa

Figura 3: Bassissimo livello di coesione della classe JRViewer

Seguendo sempre questo ragionamento procediamo individuando le ulteriori classi 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 imputate dessere 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 Limmagine seguente le mostra.

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

1.1 analisi progettuale e programmativa

Lo stesso identico discorso (riguardante la bassissima coesione) possibile fare per la classe JRFillElement (si veda limmagine seguente), poich possiede 98 metodi e 85 attributi.

Figura 5: Bassissimo livello di coesione della classe JRFillElement

Relativamente a questargomento va detto che la versione 4.0.2 di JasperReports contiene molte altre classi con basso livello di coesione che tuttavia hanno un valore di LOC medio di 600, quindi relativamente basso e comunque molto minore rispetto a LOC delle classi analizzate no ad ora. La maggior parte di esse, comunque, appartiene al package net.sf.jasperreports.engine (nello specico i sottopackage ll, design e export) ed essendo questo il package con pi dipendenze entranti, tutte queste classi si candidano a presentare anti-pattern di vario tipo. Tramite lutilizzo di una metrica, la TCC9 , unitamente alla NOM, andiamo ora a vericare la coesione delle altre classi di dimensioni minori presenti in net.sf.jasperreports.engine. Come prima cosa va detto che un valore della TCC inferiore a 0.50 segnala una classe che stata progettata singolarmente e include comportamenti non correlati tra di loro e in generale eterogenei [Kang and Biemann, 1995]. Una classe con queste caratteristiche non modella quindi una sola entit (come invece dovrebbe sempre fare una classe) ma pi concetti. Di conseguenza essa avr molto probabilmente 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 metodi appartenenti 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 e la grandezza della classe (quelle con un LOC piccolo e bassa coesione non sono considerate rischiose), tramite una vista con granularit package, stato quindi

9 Metrica: Tight class cohesion (TCC)

1.1 analisi progettuale e programmativa

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

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

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

1.1 analisi progettuale e programmativa

Il fatto che una classe come JasperManager, composta da 64 metodi abbia una TCC pari a zero sta a signicare che tutti (o quasi) i suoi metodi non sono correlati: ci chiaramente dovuto ad una progettazione carente ed necessario provvedere 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 un refactoring mirato alla loro suddivisione in classi pi astratte e coerenti, afnch corrispondano meglio ai rispettivi concetti di entit. In ottica complessiva, comunque, il numero di classi con problemi di coesione non elevato, visto che JasperReports contiene totalmente oltre 3000 entit. 1.1.3 Analisi delle interfacce

Prima di passare allanalisi e alla rilevazione degli anti-pattern riconosciuti (pi o meno automaticamente) da CodeCity ci soffermiamo sullanalisi delle interfacce, che rileva gi il coding style degli sviluppatori di JasperReports. Utilizzando la funzione di selezione per tipologia offertaci da CodeCity, abbiamo quindi ltrato le classi di tipo interfaccia (il risultato riportato evidenziato in verde gli edici corrispondenti a interfacce nellimmagine 8).

Figura 8: Le interfacce presenti in JasperReports

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

1.1 analisi progettuale e programmativa

denza abbastanza marcata degli sviluppatori (probabilmente con una conoscenza non aggiornata di Java [Hirondelle]) ad utilizzare le interfacce come contenitori di costanti. il caso della classe ChartThemesConstant del package net.sf.jasperreports.chartthemes.spring, corrispondente alledico quasi piatto nellangolo 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 parte in alcun modo dellinterfaccia pubblica di un modulo software e quindi dei servizi che espone, mentre lunico vantaggio che tale tecnica apporta consiste nellincorporazione delle costanti (denite nellinterfaccia) nello scope delle classi che la implementano. Una situazione anomala si individua anche osservando limmagine 9.

Figura 9: Swiss Army Knife in JRStyle (CodeCity)

Ledicio cerchiato corrisponde allinterfaccia JRStyle, del package net.sf.jasperreports.engine, la quale dispone di 170 metodi astratti (di cui ben 169 introdotti da lei e 1 sovrascritto dalle sue superclassi, come mostra limmagine 10 nella pagina seguente). Questo numero di metodi sicuramente eccessivo e potenzialmente molto eterogeneo. In questa situazione possiamo riconoscere lanti-pattern detto Swiss Army Knife (o Kitchen Sink) le cui principali conseguenze consistono in un aumento considerevole della complessit, della documentazione, della difcolt di utilizzo (le 11 classi che implementano questa interfaccia deniscono limplementazione

1.1 analisi progettuale e programmativa

10

di 170 metodi ...), di debugging e di manutenzione. Suggeriamo perci alcune soluzioni (tra loro alternative) adoperabili a tal riguardo: 1. divisione dellinterfaccia per gruppi di operazioni omogenee; 2. creazione proli di utilizzo (sotto-insiemi di operazioni limitati da condizioni e convenzioni da soddisfare); 3. generic programming.

Figura 10: Una vista ne-grained di JRStyle

Soffermandoci su JRStyle tramite una vista ne-grained (riportata in gura 10) si nota inoltre come da essa dipendano 326 classi. Questa situazione, che chiaramente un anti-pattern, descritta solitamente con un nome: Buttery, cio un componente da cui dipendono molti altri componenti (dove la denizione di componente pu essere intesa con diversa granularit, da package no a classe). Si suppone, in base al nome dellinterfaccia in questione e alla sua elevatissima eterogeneit che, nello specico, essa sia una Global Buttery, poich correlata a classi disperse in tutto il progetto e non solo nel suo package dappartenenza. La metrica WOC10 per JRStyle ha a un valore prossimo a 1 (valore che indica la totale dipendenza delle progetto dalla classe in questione [vedi Lanza et al., 2006,
10 Metrica: Weight of class (WOC)

1.1 analisi progettuale e programmativa

11

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 soluzione di refactoring proposta in precedenza, cio la separazione in pi interfacce in base a criteri di omogeneit. 1.1.4 Classi inuenti

Per continuit con lanalisi appena eseguita su JRStyle si affronta ora unanalisi, basata sulle metriche WNOC11 e NOM offerte da CodeCity, nalizzata alla valutazione del peso delle classi, cio della loro complessit. La metrica WNOC, che calcola il numero totale di gli di una classe (in profondit) in modo pesato, non sufciente, da sola, a segnalare eventuali anomalie progettuali: va infatti coordinata con il numero di metodi (NOM); le classi le cui metriche rispettano la condizione WNOC 10 NOM 20 sono considerate potenzialmente inuenti [Meyer and Niere]. Seguendo questo criterio le classi candidate come inuenti sono JRCloneable con WNOC 392, JRStyleContainer con WNOC 143, JRPropertiesHolder con WNOC 137 e JRCommonElement con WNOC 111. Come detto la metrica WNOC da sola non sufciente a identicare le classi inuenti, perci si proceduto analizzando in dettaglio queste e altre classi con WNOC minore. Cos facendo si scoperto che la pi inuente, e quindi quella che con pi urgenza va sottoposta a refactoring, sicuramente JRCommonElement, perch oltre ad avere WNOC pari a 111 ha ben 302 sottoclassi e 70 invocazioni uscenti. A seguire, come mostra limmagine 11 nella pagina successiva, ci sono: JRElement con WNOC 66, 132 sottoclassi (le quali ereditano 26 metodi ciascuna, il ch comporta unaltissima inuenza di JRElement su una vasta gerarchia 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

1.1 analisi progettuale e programmativa

12

Figura 11: Analisi WNOC e NOM: classi inuenti

Premesso che per approfondire ulteriormente questanalisi servirebbe che CodeCity fornisca la DIT12 (cosa che purtroppo non fa) per valutare la profondit delle gerarchie di classi, bisogna dire che classi come JRCommonElement, JRElement etc. etc. con un numero di classi glie troppo elevate e un pi o meno elevato numero di metodi vanno sottoposte a refactoring in quanto al crescere del WNOC cresce il livello di riuso ma tende purtroppo ad evaporare lastrazione che esse dovrebbero operare. Inoltre in queste condizioni aumenta considerevolmente la possibilit che una classe glia non sia membro appropriato della madre. Sarebbe perci preferibile diminuire i gli di queste classi, mantenendo soltanto quelli considerati legittimi, dato che al crescere del WNOC, cresce ance la quantit di test case necessari a testare ogni classe glia. 1.1.5 Anti-Pattern

Al ne 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 codice svolgiamo una analisi basata su metrica nalizzata allidenticazione del pi comune tra i design issues: Spaghetti Code. La metrica utilizzata a tale scopo la NOAM13 in congiunzione alla NLOC. La NOAM quantica il numero di metodi daccesso get e set utilizzati per usare e manipolare le variabili distanza delle classi. Utilizzando la congurazione di base di tipo ne-grained per il package net.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)

1.1 analisi progettuale e programmativa

13

tuali, abbiamo individuato in esso principalmente 3 classi che potenzialmente contengono Spaghetti Code, come mostra limmagine 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 mancanza di metodi daccesso get e set. Le classi individuate sono addirittura sprovviste completamente o quasi di tali metodi: emerge un coding style poco attento a mantenere il usso di controllo il pi semplice possibile; si noti infatti tutte le classi hanno un valore di NOAM uguale a 0 o in un suo intorno destro molto piccolo. Oltre al mancato utilizzo dei metodi daccesso citati lo Spaghetti Code ha altre caratteristiche: classi contenenti pochi metodi con vaste implementazioni e un singolo usso di processo, metodi orientati ai processi spesso senza parametri, vasto utilizzo di variabili globali, scarso utilizzo dellereditariet e del polimorsmo.

1.1 analisi progettuale e programmativa

14

Esso causato da un lavoro isolato, frettoloso e spesso senza unaccurata fase di progettazione e revisione. Tutto ci si traduce in un codice con un usso di controllo molto complesso che crea 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 daccesso (get e set) per le variabili distanza, rimozione codice inaccessibile e, pi generalmente, prevenzione. Per quanto riguarda le classi individuate, comunque, la mancanza dei metodi daccesso un buon indizio riguardo la presenza di Spaghetti Code ma non sufciente per poterlo asserire con certezza. Purtroppo, mancando la possibilit di vericare la maggior parte delle ulteriori cause in CodeCity siamo costretti a concludere qui questanalisi e dedicarci alla fase successiva anticipata allinizio della sezione. Ora ci dedichiamo, come anticipato, allanalisi 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 ltrare) quali anti-pattern rilevare e con quale colore segnalarli.

Figura 13: Men Disharmony Map in CodeCity

Una volta selezionato lanti-pattern da rilevare CodeCity lo identica e notica il numero di design issues trovati.

1.1 analisi progettuale e programmativa

15

Nel caso in analisi esso rileva 38 God Class (si veda la gura 13 nella pagina precedente), la maggior parte delle quali risiede nel package net.sf.jasperreports.engine (ma non solo) come mostrato dalla gura 14.

Figura 14: God Class in CodeCity

Riportiamo qui sotto i i package maggiormente le relative God Class (di maggiori dimensioni): net.sf.jasperreports.engine: JRAbstractExplorer, JasperPrint; net.sf.jasperreports.engine.ll: JRBaseFiller, JRTemplatePrintText, JRTemplatePrintImage, JRFillElement, JRFillFrame; net.sf.jasperreports.engine.design: JasperDesign, JRDesignDataset; net.sf.jasperreports.crosstabs.design: JRDesignCrosstab; net.sf.jasperreports.components.table.ll: TableReport. Come facile intuire anche dai nomi delle classi, molte di esse sono nate con lintento (probabilmente non sviluppato in fase di progettazione) di implementare il pattern Mediator che poi stato applicato male. Questa situazione molto comune infatti nei software sviluppati con un processo iterativo con scarsa progettazione architetturale; famosa infatti la frase con cui si identica il (puntuale) vericarsi di anti-pattern di questo tipo: Una classe per domarli tutti, e nel buio incatenarli [Cunningham]. La soluzione principale da adottare in merito a queste disarmonie consiste nellidenticare e raggruppare (in una nuova classe o nella loro casa naturale, se gi esistente) le operazioni con coesione alta e ridurre laccoppiamento.

1.1 analisi progettuale e programmativa

16

Per quanto riguarda invece le Brain Class, che ricordiamo essere delle classi che incorporano e accorpano moltissime funzionalit risultando avere una quantit eccessiva intelligenza (che risiede nei cosiddetti Brain Methods), la quale si traduce inne in una complessit molto elevata (caratteristica che auspicabile evitare se possibile); CodeCity ne identica solo 2: JRXMLExporter, del package net.sf.jasperreports.engine.export, che vedremo essere molto coinvolto negli antipattern rilevati, e net.sf.jasperreports.swing.JRViewerPanel, evidenziate in giallo nellimmagine 15.

Figura 15: Brain Class in CodeCity

Una caratteristica molto utile (chiamata Both God & Brain Class) di CodeCity quella di identicare le classi catalogabili sia come God Class sia come Brain Class. Delle 38 God Class rilevate in JasperReports, 23 di esse risultano classicabili anche come Brain Class (si vedano edici arancioni presenti in gura 16 nella pagina seguente).

1.1 analisi progettuale e programmativa

17

Figura 16: Both God & Brain Class in CodeCity

Per alcune di queste classi si scelto di approfondire lanalisi utilizzando una ulteriore vista di CodeCity, la Complexity View: essa, sempre seguendo la metafora alla base di CodeCity, mostra gli edici correlando la loro intensit di colore alla 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 anche una standalone class da CodeCity (tramite lo strumento di selezione: select standalone classes); evidenziata in gura 17 nella pagina successiva;

1.1 analisi progettuale e programmativa

18

Figura 17: Complessit della Both God & Brain Class JRApiWriter, considerata anche una standalone class da CodeCity

net.sf.jasperreports.engine.design.JRVerier, mostrata nella gura 18 nella pagina seguente, che possiede un NOM (numero di metodi) pari a 93 ma soprattutto un WMC14 pari a 635. Poich WMC una media, questo valore indica che, non potendo essere tutti (o comunque la maggior parte) dei metodi mediamente cos complessi, essa possiede uno (o pochi) metodi con complessit spropositata (che causano linnalzarsi a tale livello della WMC). Pare palese che questa classe vada immediatamente riprogettata dividendo e proceduralizzando i metodi complessi o adoperando soluzioni alternative che ne diminuiscano la complessit totale risultante.

14 Metrica: Weighted methods per class (WMC)

1.1 analisi progettuale e programmativa

19

Figura 18: Complessit della Both God & Brain Class JRVerier

il package net.sf.jasperreports.engine.util.ll, come a questo punto era immaginabile, contiene molte classi catalogate come Both & God Classes da CodeCity; limmagine 19 nella pagina successiva conferma quanto appena asserito;

1.1 analisi progettuale e programmativa

20

Figura 19: Complessit delle Both God & Brain Classes del package engine.ll

il package net.sf.jasperreports.engine.util.export, come il precedente, risulta essere critico dal punto di vista della complessit; esso contiene infatti molte classi con elevata complessit (JRHtmlExporter, JRXHtmlExporter, JRDocExporter, JRPptxExporter, JRExecApiExporter, JRPdfExporter) come mostra limmagine 20 nella pagina seguente che, inoltre, hanno tutte un basso livello di coesione;

1.1 analisi progettuale e programmativa

21

Figura 20: Complessit delle Both God & Brain classes del package engine.ll

anche il package net.sf.jasperreports.engine.base inne, come mostrato dalla gura 21 nella pagina successiva, presenta Both God & Brain Class che chiaramente hanno complessit elevatissima.

1.1 analisi progettuale e programmativa

22

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 questanomalia (limmagine 22 nella pagina seguente presenta una panoramica sulle Data Class rilevate da CodeCity evidenziandole in rosso).

1.1 analisi progettuale e programmativa

23

Figura 22: Data Class rilevate da CodeCity

Esse sono classi composte principalmente da attributi, metodi get e set ad essi relativi e nulla o poco altro; tali classi sono dei contenitori stupidi di dati che nella maggior 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 altre classi che dipendono cos da essa. Tale situazione presenta una similitudine con quella causata dallanti-pattern Buttery: 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 uninterfaccia (e non questo il caso). Relativamente a questo argomento bisogna notare inne che la classe ChartThemesConstants, di cui abbiamo gi parlato in precedenza a pagina 8, non viene rilevata come una Data Class da CodeCity poich essa uninterfaccia. In realt, essa possiede molte delle caratteristiche utili ad essere denita una Data Class. Limmagine nella pagina seguente presenta inne una visione completa di JasperReports e di tutti le God, Brain, God & Brain e Data Class rilevate. Ad onor del vero va notato inne, che il progetto in analisi contiene piccole percentuali (inferiori allo 0,5%) di classi affette da questi anti-pattern e, per quanto alcune di esse possano essere considerate meritevoli di un refactoring urgente, la situazione complessivamente non affatto grave.

1.1 analisi progettuale e programmativa

24

Figura 23: God (in fucsia), Brain (in giallo), Both God & Brain (in arancione) e Data Class (in viola) rilevate da CodeCity

1.1.6

Code Smell

CodeCity fornisce inoltre la possibilit di rilevare varie disarmonie presenti a livello dei metodi delle classi focalizzando la vista Disarmonies Map sui metodi. Utilizzando questa feature abbiamo potuto effettuare unanalisi nalizzata alla rilevazione di vari code smell: Brain Methods, Feature Envy, Shotgun Surgery, Intensive e Dispersed Coupling. Si proceduto, per dare continuit allanalisi, focalizzando lattenzione sui Brain Methods, 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. Lanalisi in questione ha confermato quanto osservato nora, 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 molti Brain Methods rispetto agli altri package come mostra limmagine 24 nella pagina seguente.

1.1 analisi progettuale e programmativa

25

Figura 24: Brain Methods del package engine

In ottica globale bisogna comunque osservare, come gi sottolineato, che, data la dimensione di JasperReports essi non sono in quantit troppo elevata. Stesso discorso possibile fare sia per i 70 metodi etichettati come Intensive Coupling, cio i metodi legati a molte altre operazioni localizzate tuttavia in poche 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 nellimmagine 32). CodeCity rileva, invece, ben 458 metodi catalogabili come Shotgun Surgery, cio metodi che, se modicati, comportano un propagarsi vasto delle modiche che porta a dover modicare molte altre porzioni di codice disperse nel progetto: essi risiedono principalmente nel package net.sf.jasperreports.engine.ll, e particolarmente nella classe JRLineBox come mostra limmagine 25 nella pagina successiva evidenziandoli in marrone.

1.1 analisi progettuale e programmativa

26

Questa appena descritta chiaramente una situazione che andrebbe evitata per questioni di manutenibilit del sistema (ne consegue che il suddetto package poco manutenibile) e perci andrebbe operato un refactoring spostando i metodi in questione e gli attributi ad essi relativi. Si ricorda inoltre che la presenza di questo code smell spesso correlata alla presenza anche al cosiddetto Parallel Inheritance Hierarchies, un code smell che descrive la spiacevole situazione in cui, ogni volta che si specializza una classe, si costretti, parallelamente, a specializzarne unaltra.

Figura 25: Shotgun Surgery e Feature Envy rilevati da CodeCity

Per quanto riguarda le Feature Envy, cio metodi che effettuano troppe chiamate verso altre classi al ne di ottenere dati o funzionalit, CodeCity rileva 1191 metodi che presentano tale code smell; essi risiedono principalmente nel package net.sf.jasperreports.engine.ll e secondariamente in net.sf.jasperreports.engine.export, come immaginabile. Limmagine 25 evidenzia in viola i metodi affetti da Feature Envy. Essendo essi in quantit elevata andrebbe adoperato un refactoring principalmente estraendo i metodi (e i relativi attributi) che chiamano, spostandoli nella classe del metodo affetto da Feature Envy. Inne, si utilizzata una metrica, WNOCmts15 , per valutare la presenza o lassenza di code smell quali Too Need Comments tramite una vista delle metriche a livello di package. Utilizzando tale metrica (si veda gura 26) in congiunzio-

15 Metrica: Numero pesato di commenti (WNOCmts)

1.1 analisi progettuale e programmativa

27

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 package net.sf.jasperreports.engine e JRAbstractExporter.ParameterOverrideResolver e JRAbstractExporter.ParameterOverriddenResolver entrambi con WNOCmts uguale a 0 e WLOC rispettivamente 136 e 164. Bisogna notare che queste 2 classi sono inner class e quindi il code smell meno signicativo in quanto si suppone che i commenti siano 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 dellingegneria del software 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 difcili da modularizzare. Solo per completezza si fa presente che la ricerca in questo campo ha dato luogo, come soluzione, allutilizzo di paradigmi di programmazione aspect-oriented in cui le tecniche di generazione del codice sono utilizzate per affrontare questioni che interessano trasversalmente il codice. Relativamente a tale ambito, una congurazione poco esplorata (ma molto utile) di CodeCity la vista chiamata fanInOut. Questa vista prende il nome dalle 2 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)

1.1 analisi progettuale e programmativa

28

Lanalisi FANIN appunto nalizzata a individuare i crosscutting concerns, la cui implementazione, che consiste in (molte) chiamate di metodi si sparge su un gran numero di elementi. I crosscutting concerns si vericano spesso in moduli di tracing e/o logging, cos come in moduli che usano e abusano della notica di eventi, della gestione degli errori e di wrapping. In tutti questi casi (e altri non citati) la funzionalit trasversale tipicamente implementata da un metodo che viene poi invocato da un gran numero di classi esterne (si congura quindi la presenza di un anti-pattern). La metrica FANIN per un metodo (o una classe, aggregando i vari FANIN dei singoli 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 da molte classi, spesso sparse, alle quali in letteratura ci si riferisce anche con il termine candidate-seeds. Lanalisi, brevemente, consiste nellindagare i candidati-seeds usando come linea guida le relazioni fra le classi e accettarle o meno come tali. La situazione desiderabile, in generale, che una classe che possieda un alto FANIN possieda necessariamente, allo stesso tempo, un basso FANOUT cosicch non presenti un anti-pattern di tipo Hub (situazione che si verica se il FANOUT, in questo contesto, ha un valore medio) [vedi Caserta and Zendra, 2010]. Si noti comunque che le classi con un alto FANIN sono candidate a presentare un anti-pattern di tipo Buttery, mentre quelle con alto FANOUT sono candidate a presentare un anti-pattern di tipo Breakable. Riguardo questa analisi, la suddetta vista di CodeCity daiuto grazie allintuitivit con la quale riesce a rendere e far percepire i concetti appena esposti e le conseguenti situazioni che presentano design issues: i parallelepipedi molto stretti che si sviluppano in verticale (e hanno un colore rosso) identicano la presenza di un FANOUT elevato mentre quelli pi sviluppati in larghezza (che hanno colore blu) identicano la presenza di un FANIN elevato. Combinando le due informazioni ne deriva che i parallelepipedi (con colore pi o meno tendente al viola) che tendono ad una forma cubitale segnalano la presenza di un anti-pattern di tipo Hub.

1.1 analisi progettuale e programmativa

29

Figura 27: Analisi FANIN per i crosscutting concerns e rilevazione dell anti-pattern Hub

Per quanto riguarda lanti-pattern Breakable, limmagine 27 evidenzia come tali le seguenti classi (in verde): JRApiWriter, JRXmlWriter (del package net.sf.jasperreports.engine.ll) avendo esse rispettivamente FANOUT pari a 129 e 111 con FANIN pari rispettivamente a 2 e 13; net.sf.jasperreports.view.JRViewer (di cui abbiamo parlato a pagina 4) con FANOUT pari a 84 e FANIN pari a 5; net.sf.jasperreports.chatthemes.spring.GenericChartTheme (di cui abbiamo parlato a pagina 17) con FANOUT pari a 192 e FANIN pari a 2.

1.1 analisi progettuale e programmativa

30

Figura 28: Analisi FANIN per i crosscutting concerns e rilevazione dell anti-pattern Hub

Per quanto riguarda invece lanti-pattern Hub, limmagine 28 evidenzia come tali le seguenti classi (in verde): net.sf.jasperreports.engine.design.JRVerier (di cui abbiamo gi parlato a pagina 18) con FANIN = 32 e FANOUT = 84; net.sf.jasperreports.engine.JRExpressionCollector (della quale abbiamo gi discusso in merito allanti-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 come God Class a pagina 15) con FANIN = 94 e FANOUT = 45. I valori delle metriche analizzate ci dicono che gli Hub JRVerier e JRExpressionCollector esigono un refactoring chiaramente pi urgente rispetto a JRBaseObjectFactory e JRAbstractExplorer (che hanno un FANIN minore ma un altissimo FANOUT, indice della loro tendenza a essere Breakable). Va notato inne che, complessivamente, ad esclusione di una classe (si noti il parallelepipedo blu che si estende in larghezza, pi o meno al centro delle immagini), JasperReports non presenta classi con elevatissimi valori di FANIN: questo, come facilmente intuibile, un buon segnale riguardo la presenza di pochi anti-pattern di tipo Buttery.

1.2 analisi evolutiva

31

1.2

analisi evolutiva

CodeCity permette la visualizzazione incrementale dellevoluzione del software nelle 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 come il software stato progettato e sviluppato iterativamente, e a quali operazioni di refactoring stato sottoposto. La tabella 1 mostra innanzitutto levoluzione dal punto di vista quantitativo del numero di linee di codice, di classi, di package e di elementi parallelamente al rilascio delle versioni 0.x.x, 1.0.0, 2.0.0, 3.0.0 e 4.0.2 di JasperReports. Da essa si nota come la maggior evoluzione del software target avvenuta al rilascio della release 1.0.0 dove le dimensioni LOC, NOC e NOP di JasperReports, precedentemente molto modeste, si sono quasi settuplicate; con la successiva release invece lincremento consistito approssimativamente in un raddoppiamento delle linee di codice, del numero di elementi e del numero di classi e un incremento sostanziale del numero di packages; tra la release 2.0.0 e la 3.0.0 non si segnalano incrementi di tali entit, contrariamente invece a quanto si pu riscontrare con la release 4.0.2 dove le dimensioni sono nuovamente raddoppiate. release 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 loc 7.659 48.556 94.875 107.795 168.840 noc 235 1.163 1.962 2.161 3.185 nop 37 146 203 226 325 numero elementi 6.929 44.290 98.535 113.409 187.793

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

1.2 analisi evolutiva

32

Si procede ora allanalisi dellevoluzione del software fra la versione 0.x.x e la 1.0.0. Limmagine 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

Limmagine relativa alla versione 0.x.x mostra la presenza di una classe, JasperReport, del package net.sf.jasperreports.engine molto pi consistente rispetto alle altre presenti. Si suppone da ci che essa presenti qualche anomalia. Infatti tale supposizione viene confermata dalla successiva analisi sugli antipattern la quale (come possibile notare nellimmagine 30 nella pagina seguente) la identica come una God Class, insieme a altre 3 God Class (parallelepipedi arancioni) che sono tuttavia di dimensioni (LOC) modestissime. Inoltre tale analisi notica la mancanza di Brain Class (informazione prevedibile viste le dimensioni di JasperReports nella versione 0.x.x) ma, al tempo stesso, la presenza, precisamente nel package net.sf.jasperreports.engine, di ben 10 Data Class (parallelepipedi viola).

1.2 analisi evolutiva

33

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

Ci signica che in generale, almeno in questa fase, il software in analisi ha tendenzialmente un altissimo accoppiamento poich molte classi (ad esclusione chiaramente delle God Class suddette) sono classi che non forniscono alcuna funzionalit concreta ma fungono esclusivamente da contenitori di dati che vengono utilizzati da poche altre classi (presumibilmente le God Class). Nella release successiva, la 1.0.0, JasperReports oltre a subire un incremento

1.2 analisi evolutiva

34

notevolissimo delle dimensioni stato sicuramente sottoposto ad un primo refactoring mirato esclusivamente alla classe JasperReport. Essa infatti risulta non essere pi identicata come una God Class e risulta possedere un valore di LOC minore nonch una maggiore coesione. Complessivamente, JasperReports 1.0.0, dal punto di vista delle anomalie progettuali sembra essere rimasto quantitativamente costante, ad esclusione delle Data Class.

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

Quanto appena affermato supportato dai seguenti dati (nonch dallimmagine nella pagina successiva); CodeCity rileva: 14 God Class (1,20% sul totale delle classi) rispetto alle 4 rilevate alla release precedente (corrispondenti al 1,73% sul totale delle classi), tra le quali JRBaseFont del package net.sf.jasperreports.engine.base, JRFillChart e JRFillText del package net.sf.jasperreports.engine.ll; 1 Brain Class rispetto alle 0 rilevate precedentemente;

1.2 analisi evolutiva

35

3 Both God & Brain Class rispetto alle 0 rilevate precedentemente: JRPdfExporter, del package net.sf.jasperreports.engine.export, JasperDesign, JRViewer e JRDesignViewer del package net.sf.jasperreports.view; ben 64 Data Class (corrispondenti al 5,50% delle classi) rispetto alle 10 (il 4,25% delle classi) rilevate nella versione precedente, come mostra limmagine 32.

Figura 32: Data Class in JasperReports, release 1.0.0

Il lieve peggioramento relativo esclusivamente al leggero incremento del numero di Data Class fa intuire che, tendenzialmente, il team di sviluppo, oltre a svolgere una fase di progettazione probabilmente frettolosa, ha un coding style che abitualmente fa un utilizzo marcato di classi stupide che fungano da semplici contenitori di dati non tenendo in considerazione i risvolti negativi che ci comporta (ad esempio: il forte accoppiamento). Un esempio palese di quanto appena detto la Data Class JRXmlWriter (di dimensioni notevoli, LOC = 2230). Essa presenta un gran numero (che non stato possibile identicare poich non fornito da CodeCity) di invocazioni sia entranti che uscenti da e verso praticamente tutto il progetto attuale ad esclusione del package net.sf.jasperreports.view come attesta limmagine 33 nella pagina seguente.

1.2 analisi evolutiva

36

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

Procedendo come fatto per levoluzione di JasperReports dalla release 0.x.x alla release 1.0.0 si affronta ora lanalisi dellevoluzione del software in questione relativamente alle successive release. La tabella 2 riporta tutti i dati relativi agli anti-pattern rilevati da CodeCity nelle release analizzate sintetizzando quanto mostreremo di seguito.

1.2 analisi evolutiva

37

release 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2

god class 4 (1.73%) 14 (1.20%) 34 (2.92%) 22 (1.01%) 38 (1.19%)

brain class 0 1 (0.09%) 0 0 2 (0.06%)

both god & brain class 0 3 (0.26%) 14 (0.71%) 16 (0.74%) 23 (0.72%)

data class 10 (4.25%) 64 (5.50%) 98 (4.99%) 80 (3.70%) 83 (2.61%)

Tabella 2: Variazioni quantitative degli anti-pattern durante levoluzione di JasperReports

La release 2.0.0 del software in analisi, che si riporta gracamente in gura 34, presenta un aumento consistente rispetto alla release precedente sia del numero di God Class sia del numero Both God & Brain Class, per quanto esse siano complessivamente poche (si vedano percentuali in tabella 2); al tempo stesso questa release presenta una leggera diminuzione, in percentuale, del numero di Data Class.

Figura 34: Rilevazione degli anti-pattern in JasperReports, release 2.0.0

1.2 analisi evolutiva

38

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

Con il rilascio di questa versione di JasperReports vediamo quindi comparire nuove classi affette da anti-pattern, quali, ad esempio: JRDesignCrosstab del package net.sf.jasperreports.crosstabs.design, classicata come una nuova God Class; JRVerier del package net.sf.jasperreports.engine.design, classicata come Both God & Brain Class; JRXmlWriter del package net.sf.jasperreports.engine.xml, che da essere catalogata come Data Class nella release precedente viene ora catalogata come Both God & Brain Class; CrossTabFiller e JRFillChart (NOM = 150, NOA = 17, LOC = 1919) del package net.sf.jasperreports.engine.ll, nel quale si registra, in generale una proliferazione di God Class, come mostrato in gura 35; JRRtfExporter, JExcelApiExporter e JRHtmlExporter del nuovo package net.sf.jasperreports.engine.export relativamente al quale si registra una proliferazione di Both God & Brain Class, come mostrato in gura 36 nella pagina seguente. Si noti comunque che questo package appena nato e diventer ben presto, come abbiamo visto per lultima release, la 4.0.2, quello, insieme al suddetto, maggiormente affetto da design issues.

1.2 analisi evolutiva

39

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

Si noti inne 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 diminuzione consistente sia nel numero di God Class, sia nel numero di Data Class (si veda la tabella 2 a pagina 37). Presumibilmente, a partire da questa versione del software, il team di sviluppo ha operato importanti operazioni di refactoring contemporaneamente ad una migliore progettazione e implementazione delle nuove feature. Limmagine 37 nella pagina seguente mostra la panoramica che CodeCity offre relativamente agli anti-pattern presenti in questa release di JasperReports. Comunque, anche nella versione 3.0.0 continuano a persistere alcune anomalie progettative, in particolare God Class, presenti nei soliti package: il caso della classi JRFillChart, JRViewer, JRDesignCrosstab, JasperDesign, JRXmlWriter, JRVerier che rimangono praticamente invariate anche se necessiterebbero di un refactoring. Al contempo, in un quadro generale abbastanza buono, come gi detto, emergono tuttavia nuove classi che presentano design issues: il caso di JRAbstractExporter e di 2 nuovi package, net.sf.jasperreports.charts.ll e net.sf.jasperreports.charts.base, composti pressappoco solo da classi catalogabili come Data Class, come mostrato in gura 38 nella pagina successiva.

1.2 analisi evolutiva

40

Figura 37: Rilevazione degli anti-pattern in JasperReports, release 3.0.0

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

Con lavvento dellultima relase di JasperReports, che gi stata oggetto di unanalisi progettuale e programmativa pi approfondita, notiamo in generale una diminuzione consistente delle classi catalogate come Data Class (si veda la

1.3 suggerimenti per migliorare codecity

41

tabella 2 a pagina 37) anche se queste rimangono di gran lunga gli anti-pattern pi comuni in JasperReports. 1.3 suggerimenti per migliorare codecity

CodeCity un tool di software analysis molto intuitivo (soprattutto per le funzionalit di base) e utile. La metafora che porta a rappresentare gli elementi software come distretti ed edici la chiave di CodeCity e si rilevata essere una visualizzazione vincente del software, almeno dal punto di vista della comprensione iniziale e superciale del software e della scalabilit dei dati rappresentati. La capacit inoltre di CodeCity di rilevare ed evidenziare automaticamente gli anti-pattern e i code smell che individua lo rende un tool di ottimo livello. Tuttavia, scendendo pi in dettaglio e volendolo utilizzare per unanalisi del software pi approfondita, si incontrano alcune difcolt, dovute principalmente alla mancanza di reale documentazione, e la facilit di comprensione e accesso alle 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 seguendo i seguenti passi: creare una cartella src allinterno della folder da cui si esegue CodeCity; copiare dentro la cartella appena creata quella sottomessa a inFusion per creare il le .mse; assicurarsi che il nome della cartella appena copiata corrisponda al nome del modello importato in CodeCity questa carenza dovuta a come il processo di import di un progetto in CodeCity stato concepito, cio basato sul modello FAMIX 2.1: questo uno degli aspetti pi fastidiosi e carenti di CodeCity, anche perch il software che va utilizzato per generare il le .mse, cio inFusion, non stabile quanto lo CodeCity. Per proporre una soluzione andrebbe ripensato lintera fase di import del software poich al momento risulta difcile identicare una soluzione alternativa e pi comoda a quella attuale 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 di un anti-pattern. difcile accedere a viste pi rafnate e al pannello per lesplorazione dei valori delle metriche relativamente alle classi di un package

1.4 suggerimenti per migliorare jasperreports

42

questa carenza sarebbe limata se CodeCity fosse meglio documentato e ancor di pi, se il pannello per la congurazione di nuove viste e la scelta delle viste predenite fosse pi accessibile e intuitivo. gli edici vengono disegnati solo in base alle correlazioni con gli elementi del loro stesso package: ci signica che lintensit (ma stesso discorso vale anche per le altre viste e metriche utilizzabili) di ogni edicio, cio il valore di LOC, relativo esclusivamente al package cui appartiene; questo comporta che non si possa avere una vista complessiva del sistema qualora venisse implementata la rappresentazione degli edici correlata allintero progetto e non al singolo package sarebbe ideale rendere commutabili le due rappresentazioni. CodeCity pecca nella rilevazione delle Brain Class poich basa tale decisione esclusivamente sulla complessit: sarebbe utile basare la rilevazione di questo anti-pattern su ulteriori parametri (ad esempio, il numero di global e local dependencies). 1.4 suggerimenti per migliorare jasperreports

Come gi anticipato pi volte durante la trattazione n qui effettuata, JasperReports un software di medie dimensioni (3185 classi e 325 package) nel complesso ben progettato e sviluppato. La versione 4.0.2, in particolare, come specicato durante lanalisi evolutiva (si veda pagina 31), mostra un netto miglioramento del software in termini di quantit di design issues; daltronde tale tendenza si era percepita gi analizzando la versione 3.0.0 noticando una drastica diminuzione delle classi catalogabili come Data Class. Ci nonostante, come normale che sia, in particolare i gi citati package net.sf.jasperreports.engine.ll e net.sf.jasperreports.engine.export e altri elementi ad essi 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 non superano, tranne che per quanto riguarda le Data Class, la soglia del 3%. Perci, al ne di migliorare ulteriormente JasperReports, la priorit procedere evitando di utilizzare le classi come contenitori e fornitori di metodi daccesso ai dati, afnch diminuiscano le classi affette da anti-pattern Data Class e, possibilmente, migliorando lattuale coding style che fa spesso un uso improprio delle interfacce (le quali vengono spesso utilizzate come contenitori di costanti, come gi 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 dereditariet troppo profondi,

1.5 considerazioni finali su jasperreports

43

soprattutto quando nei nodi pi in alto dellalbero, come capita in un caso in JasperReports, una superclasse astratta (e/o un interfaccia) ha un numero elevatissimo di metodi: questo chiaramente un aspetto invalidante per il livello di manutenibilit e estendibilit del software. In ultima fase bisognerebbe agire sui package sopracitati adoperando un refactoring 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 dal compromesso tra alta coesione e basso accoppiamento, cercando anche, possibilmente, di mantenere la complessit ciclomatica a livelli pi bassi laddove si sono segnalati metodi affetti da code smell Brain Method. Per quanto riguarda invece le classi che si sono rivelate essere affette da anti-pattern Spaghetti Code si consiglia una loro re-ingegnerizzazione (con maggior modularizzazione basata su consistenza e sulle funzionalit) e ladozione di un coding style pi attento che prevenga il vericarsi di tali situazioni. Inne, soprattutto in ottica evolutiva, vanno tenuti docchio i crosscutting concerns: si riscontrato (si veda la relativa sezione a pagina 27 per maggiori dettagli) da questo punto di vista lemergere di alcuni anti-pattern di tipo Hub o Breakable su classi rilevanti soprattutto nellultima versione di JasperReports; bene perci che si adottino contromisure nalizzate alla riduzione (o meglio alla decentralizzazione) delle dipendenze entranti e uscenti. 1.5 considerazioni finali su jasperreports

Analizzando JasperReports con CodeCity abbiamo potuto notare come con il passare del tempo esso sia passato da essere un progetto amatoriale, sia in termini di dimensioni sia in termini di qualit del software, ad essere un progetto di medie dimensioni complessivamente ben strutturato. Questa inversione di tendenza (o, se vogliamo, semplice cambio di rotta) la si riscontra con il rilascio della versione 2.0.0 e 3.0.0. Precedentemente a queste versioni invece si constatato come mancasse una fase di progettazione ben fatta e le nuove feature venissero implementate in poche classi che divenivano quindi sempre pi affette da (vari) anti-pattern. Come detto, per, successivamente, parallelamente allintroduzione di nuove feature stata adoperata una riorganizzazione concettuale e logica del progetto e contemporaneamente stato adoperato un refactoring (per quanto esso non sia stato ancora completato): le classi che nelle prime release erano il fulcro del software divengono man mano delle entit minori, seppur presenti; i package iniziali con il passare del tempo vengono riposizionati e poi ampliati. Gli anti-pattern e i code smell presenti costituiscono solo una piccola percentuale dellintero progetto (circa 1% ad esclusione delle Data Class che costituiscono il 3% di tutte le classi) e perci non intaccano signicativamente la qualit della progettazione e implementazione sottostanti JasperReports. Alcune tendenze riscontrate nel software, dovute al coding style degli sviluppatori, quali ad esempio

1.6 considerazioni finali su codecity

44

lutilizzo delle interfacce come contenitori di costanti e la scarsa abitudine alla documentazione, soprattutto in ottica evolutiva, cio allulteriore crescita delle dimensioni del progetto, costituiscono dei potenziali problemi per i quali vanno adottate contromisure di tipo manageriale (ad esempio listituzione di linee guida aziendali da seguire durante limplementazione). In denitiva, comunque, come ampiamente ribadito, JasperReports pu considerarsi un software solido e ben strutturato. 1.6 considerazioni finali su codecity

Dopo aver utilizzato CodeCity possiamo affermare che limpressione iniziale, cio quella che sia un buon tool per lanalisi preliminare di un sistema confermata. Esso permette, come detto, di individuare anti-pattern e design issues in generale per mezzo della vista coarseGrainedDisharmonies tramite una visualizzazione intuitiva della struttura del sistema. Risulta inoltre molto utile anche grazie alle altre viste di default denite (ad esempio la vista magnitude, complexity etc. etc.) che tuttavia, come detto, non sono facilmente accessibili. Unottima feature che si segnala quella della possibilit di generare delle viste customizzate, anchessa purtroppo una feature che CodeCity offre ma non facilmente accessibile e individuabile. Si potuto inoltre constatare che CodeCity svolge un buon lavoro anche dal punto di vista dellanalisi evolutiva del software. Dal punto di vista della scalabilit, CodeCity funziona egregiamente sia che lo si utilizzi con sistemi di grandi dimensioni, sia che si voglia analizzare un sistema pi 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 dellimport e del codice sorgente, pu essere utilizzato anche per analisi pi approfondite. Si consiglia comunque, in generale, di utilizzare CodeCity insieme ad altri tool, ad esempio Bauhaus per svolgere analisi pi dettagliate. 1.7 1.7.1 dettagli tecnici Congurazioni macchine utilizzate

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

1.7 dettagli tecnici

45

c-1 Windows Vista Home Premium SP1 (32 bit) Intel Core 2 Duo T7300 2.00 GHz 2.00 GB

c-2 Windows XP Professional SP3 (32 bit) Intel Core 2 Duo T2300 1.66 GHz 1.00 GB

Tabella 3: Congurazioni 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 con inFusione e successivamente importarlo in CodeCity con la congurazione C-1. versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo creazione modello 2.4 sec 11.6 sec 19.9 sec 22.1 sec 27.4 sec tempo import 10.1 sec 45.5 sec 87.2 sec 293.4 sec 426.3 sec

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

Come fatto per la congurazione C-1, si riportano i tempi relativi alla congurazione C-2 nella tabella 5. versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo creazione modello 3.8 sec 13.7 sec 21.1 sec 23.8 sec 31.2 sec tempo import 11.8 sec 53.3 sec 102.1 sec 391.5 sec 523.1 sec

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

1.7 dettagli tecnici

46

1.7.3

Installazione

Lutilizzo di CodeCity non comporta un vero e proprio processo di installazione. Infatti, non appena decompresso il le .zip scaricato dal sito web ad esso dedicato (pagina di download: http://www.inf.usi.ch/phd/wettel/codecitydownload.html) possibile avviare CodeCity da questa stessa cartella. Inoltre non 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 del modello .mse. In tale circostanza, infatti, nonostante si fosse generato il modello FAMIX 2.1 di JasperReports, CodeCity andato in crash interrompendo la propria esecuzione. Ulteriori problemi di tipo operativo e defcienza si presentano quando si intende navigare, a partire da una vista coarse-grained, un elemento di grosse dimensioni con viste ne-grained e quando si intendono investigare le relazioni entranti e uscenti (ad esempio, incoming e outgoing invocations) di una classe di grandi dimensioni. Si notica inoltre, anche se questo un bug gi documentato ufcialmente (a dire il vero lunico), il crash di CodeCity quando il sistema con cui si genera il le .mse diverso da quello con cui lo si vuole utilizzare per effettuare la software analysis con CodeCity. Inne, limplementazione di CodeCity andrebbe migliorata gestendo le eccezioni poich al momento, ogni qual volta se ne verica una, non essendo questa gestita, 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 principalmente da: 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 sufciente per un tool come CodeCity: questa convinzione supportata dallesperienza affrontata nella quale

1.7 dettagli tecnici

47

si dovuto impiegare molto tempo ad esplorare le molte funzionalit offerte del software, alcune delle quali non sono cos intuitive come la sua caratteristica principale.

M A N H AT TA N

Manhattan un semplice plug-in di Eclipse, il quale permette di visualizzare tridimensionalmente i progetti precaricati nel workspace. La visualizzazione ha due obiettivi fondamentali: rappresentare i progetti in maniera tale da facilitare la comprensione della loro architettura; aumentare la consapevolezza individuale degli sviluppatori che svolgono attivit in team. Il primo obiettivo stato raggiunto con il porting base per Eclipse del tool CodeCity, lo strumento di visualizzazione creato da Richard Wettel [Wettel, c]. Team Activity Awareness invece la funzionalit che permette di evidenziare in real-time linsieme di modiche introdotte nel codice sviluppato da ogni componente del team. Conoscere ci che gli altri sviluppatori del team stanno implementando in un preciso istante, riduce drasticamente le possibilit di avere dei conitti su modiche introdotte e consente inoltre una migliore comprensione dellevoluzione del progetto. Tramite lutilizzo di Syde1 , allutente vengono noticate, tramite viste dinamiche SWT, le modiche 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 allutente. 2.1 analisi

In questa sezione lanalisi verr effettuata soltanto sullultima versione del software target, per riuscire a trarre delle conclusioni sullo stato corrente del progetto. Invece nella sezione analisi evolutiva verranno analizzate tutte le versioni con ogni 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 lanalisi progettuale e dunque la ricerca di anti-pattern, Manhattan non fornisce funzionalit che avvertono lutente riguardo la presenza di questo tipo di disarmonie. Per mette a disposizione dellutente una vista
1 Tool per lo sviluppo collaborativo del software

48

2.1 analisi

49

che permette di individuare facilmente anti-pattern comunemente presenti nel codice. Infatti basta utilizzare la vista First Person e passeggiare per qualche secondo tra gli elementi della vista, per accorgerci di disarmonie del codice. Come possiamo vedere in gura 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 uninterfaccia ha un aspetto differente rispetto agli elementi del 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 e allungata. Queste informazioni denotano che linterfaccia in questione possiede molti metodi e poche variabili. Infatti possiamo leggere dalla info-box che linterfaccia possiede soltanto una variabile e ben 170 metodi. Capiamo subito di essere di fronte ad un anti-pattern chiamato Swiss Army Knife (coltellino svizzero) le cui principali conseguenze sono la difcolt di utilizzare e manutenere linterfaccia. Sarebbe preferibile risolvere o minimizzare questo problema dividendo linterfaccia in ulteriori interfacce pi semplici, ognuna con un compito specico. Oppure, se non fosse possibile dividerla, si potrebbe pensare di creare dei proli di utilizzo, cio dei sottoinsiemi di operazioni dellinterfaccia, limitati da convenzioni e condizioni da soddisfare. Se nemmeno i proli fossero applicabili, si potrebbe pensare di considerare politiche di utilizzo in ambito generic programming.

2.1 analisi

50

Figura 40: Package engine on Orbital View

Dalla gura 40 possiamo notare che la distribuzione delle classi abbastanza omogenea per ogni package e non ci sono forti disarmonie che balzano subito allocchio. Una caratteristica che ci pu insospettire il fatto che la gran parte dei packages fanno parte del package padre engine (evidenziato in verde). Questa una scelta progettuale che pu essere corretta o meno in base alle funzionalit delle classi e delle interfacce. Tramite questo tool non possiamo dire nulla di pi di quello appena citato. 2.1.2 Analisi programmativa - Code Smell

Per quanto riguarda lanalisi programmativa, Manhattan fornisce due funzionalit basilari che ci permettono di avere un quadro generale delle dimensioni del software target. Queste due funzionalit sono la First Person View e la Orbital View. Navigando con la vista First Person View, notiamo subito un edicio blu (in gura 41 evidenziato di verde per distinguerlo) molto esteso e basso. Questa vista ci fornisce due informazioni importanti: la prima si riferisce al fatto che la classe in questione possiede un grande numero di variabili, mentre la seconda si

2.2 analisi evolutiva

51

riferisce alla scarsit di metodi posseduti. Tramite l info-box appuriamo che la classe, 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 per modicarli (setter e getter). Queste classi 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 quella di ridistribuire meglio le variabili in diverse classi, in maniera tale da diminuire anche il numero di metodi presenti nella Data Class ed il numero di entit che hanno bisogno di accedervi. 2.2 analisi evolutiva

Manhattan risulta inoltre molto utile per lanalisi evolutiva del software, dato che fornisce una vista tridimensionale chiara che ci permette di avere una visione completa del progetto target. Infatti utilizzando la vista First Person possiamo notare come il progetto si popoli e si ridistribuisca col tempo.

2.2 analisi evolutiva

52

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

Inizialmente, nella versione 0.x.x, possiamo notare lesistenza di una classe visibilmente pi grande delle altre, che guardando poi nelle versioni successive sembra scomparire. Si tratta della classe JasperReport che, come possiamo notare nellimmagine 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 suddetta classe ha 65 metodi, che in confronto alle altre classi del progetto di quella versione sono senza dubbio eccessive.

Figura 43: JasperReports tramite Orbital View

Continuando a visionare la gura 45 notiamo inoltre una forte presenza di interfacce che nella prima versione non erano erano cos evidenti. Infatti indagando tramite la vista Orbital possiamo facilmente vedere che con il passare del tempo (e quindi delle versioni), le interfacce sono cresciute linearmente con la crescita del codice sorgente del progetto. Vediamo che ad ogni versione le interfacce vengono giustamente ridistribuite in maniera tale da non incorrere in anti-pattern tipo lo Swiss Army Knife.

2.2 analisi evolutiva

53

Figura 44: Confronto versioni tramiter Orbital View

Avendo una buona distribuzione di classi e interfacce per package ci riteniamo soddisfatti del software e ritorniamo ad analizzare il codice tramite la vista First Person. 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 classe vicina chiamata JRViewer. Notiamo che questo assorbimento continuer anche nelle versioni successive (dalla 2.0.0 alle 3.0.0) con altri classi simili, facendo divenire sempre pi imponente la suddetta classe (si pu notare la classe JRViewer dal riquadro giallo in gura 45). Pensiamo di essere difronte ad una God Class ma non ne siamo completamente certi data la mancanza di metriche. Si potrebbe comunque pensare di suddividere la classe anche se bisognerebbe investigare meglio sulle sue funzionalit. Non capiamo il perch tutte le sottoclassi della classe JRViewer siano state inglobate nella classe madre. Supponiamo che siano state funzionalit talmente secondarie da non necessitare ulteriore spazio nel

2.3 forward engineering

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

forward engineering

Questo tool possiede un elevato potenziale nel campo del forward engineering. Infatti utilizzando il tool per qualche minuto ci si accorge subito che modicando il codice del progetto, quindi creando packages, classi o soltanto modicando attributi 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 noticare allo sviluppatore eventuali disarmonie nel codice che sta scrivendo.

2.3 forward engineering

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 allintero di un team di sviluppo, quale programmatore sta lavornado su quale entit del progetto in realtime. Inoltre permette di differenziare il colore dellentit in base alle azioni che il programmatore sta svolgendo su di essa. Infatti lentit verr colorata di giallo se lazione introduttiva (ovvero inserimento di un nuova variabile, di un nuovo metodo, classe o package) altrimenti verr colorata di arancio se lazione compiut ritenuta essere una estromissione o eliminazione di un elemento.

2.4 suggerimenti per migliorare manhattan

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. Sarebbe limitativo giudicare un tool in questo momento dato che tuttora in fase di sviluppo. Ci limiteremo dunque a giudicare soltanto le funzionalit complete e a dare dei consigli per migliorare o introdurre funzionalit. Le carenze pi evideni che abbiamo riscontrato utilizzando il tool sono: carenza di funzionalit: mancanza di autoidenticazione di alcun genere di code smell o anti-pattern;

2.4 suggerimenti per migliorare manhattan

57

introdurre una checkbox per lauto identicazione di anti-pattern, come quella di CodeCity. carenza di chiarezza: le funzionalit di selezione e di navigazione della vista First Person e della vista Orbital sono inizialmente difcili da trovare dato che non esistono bottoni ma soltanto short-cut tramite tastiera. si potrebbe pensare di introdurre una semplice interfaccia graca per permettere i movimenti; si potrebbe pensare di implementare lo spostamento della visuale tramite il movimento del mouse. carenza di completezza: una possibile ulteriore feature potrebbe essere una semplice info-box che fornisca informazioni di carattere generale sul numero di packages, classi, metodi, linee di codice dellintero 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 metriche utilizzate per la rappresentazione degli elementi del progetto non chiara a priori senza una previa lettura della documentazione. si consiglia di inserire nella vista una piccola legenda che denisca i colori e le caratteristiche degli elementi rappresentati (altezza corrisponde al numero di metodi, larghezza corrisponde al numero di campi, etc.). carenza di fruibilit: dal punto di vista attuale viene visualizzato in una singola vista un unico layout di lavoro, quindi lutente pu cimentarsi in una sola vista per volta senza poter effettuare confronti tra viste; sarebbe utile avere nelle prossime versioni di Manhattan un layout che possa contenere pi viste, per offrire una completa rappresentazione del sistema. produzione di report e documentazione: questa funzionalit potrebbe divenire utile dato che Manhattan produce diverse informazioni di carattere tecnico che poi vengono rappresentate mediante una vista tridimensionale. si potrebbe pensare di far produrre a Manhattan dei report in formato pdf o xml contenente tutte le informazioni rappresentate nelle info-box delle viste Orbital e First Person. si potrebbe pensare di far produrre a Manhattan delle immagini contenenti le due viste polimetriche. carenza di visibilit delle dipendenze: Manhattan non permette in alcun modo di visualizzare le dipendenze tra gli elementi del progetto.

2.5 suggerimenti per migliorare jasperreports

58

sarebbe utile poter visualizzare le dipendenze tra classi e interfacce; sarebbe utile poter visualizzare le dipendenze tra packages; 2.5 suggerimenti per migliorare jasperreports

Essendo JasperReports un software ben strutturato, il compito di migliorarlo risulta complesso. Tramite questo tool possiamo di certo affermare che: La mancanza di commenti nel codice sorgente scritto nella versione 0.x.x, rende di difcile comprensione le classi fondamentali del progetto. I commenti presenti seguono formattazioni Doxygen ma non il buonsenso della limitazione ad 80 caratteri per linea. si pu pensare di introdurre almeno un commento nellintestazione di ogni classe, o ancor meglio nellintestazione 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 contenente soltanto parametri/variabili e metodi per modicarli (setter e getter). Queste classi 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 quella di ridistribuire meglio le variabili in diverse classi, in maniera tale da diminuire anche il numero di metodi presenti nella Data Class ed il numero di entit che hanno bisogno di accederci. Linterfaccia JRStyle un anti-patter chiamato Swiss Army Knife (coltellino svizzero). Le principali conseguenze di questo anti-pattern, sono la difcolt di utilizzare e manutenere linterfaccia. Sarebbe preferibile risolvere o minimizzare questo problema dividendo linterfaccia in ulteriori interfacce pi semplici, ognuna con un compito specico. Oppure, se non fosse possibile dividerla, si potrebbe pensare di creare dei proli di utilizzo, cio dei sottoinsiemi di operazioni dellinterfaccia, limitati da convenzioni e condizioni da soddisfare. Se nemmeno i proli fossero applicabili, si potrebbe pensare di considerare politiche di utilizzo in ambito generic programming. La classe JRViewer ha le carte in regola per essere una God Class ma non ne siamo completamente certi data la mancanza di metriche.

2.6 considerazioni finali su jasperreports

59

Si potrebbe comunque pensare di suddividere la classe in diverse sottoclassi o smistare i suoi metodi in classi differenti, anche se bisognerebbe investigare meglio sulle sue funzionalit. Non capiamo il perch tutte le sottoclassi della classe JRViewer siano state inglobate nella classe madre. Supponiamo che siano state funzionalit talmente secondarie da non necessitare ulteriore spazio nel progetto. 2.6 2.6.1 considerazioni finali su jasperreports Tramite Manhattan

Analizzando il progetto con Manhattan possiamo notare come, con il tempo (e con il passare delle versioni), sia stato profondamente modicato e notevolmente migliorato. La progettazione iniziale della versione 0.x.x sembra essere stata modicata pesantemente. Le classi che una volta erano il fulcro del software, ora sono 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 dellapplication logic sono ben strutturate. Durante lanalisi del software abbiamo incontrato un solo anti-pattern, lo Swiss Army Knife e alcuni code smell che anche se presenti non compromettono la solida progettazione ed implementazione alla base di JasperReports. Un difetto riscontrato anche con altri software di analisi la scarsit di commenti nel codice sorgente; infatti tutte le classi anziane, ovvero create nella prima versione del software, non presentano commenti nel codice. Per un software di queste dimensioni e di questa importanza risulta essere un forte fattore negativo che va ad intaccare la comprensione e la riusabilit del codice. Inoltre evitando di scrivere commenti si aumenta persino il tempo di debugging e di manutenzione del codice. In denitiva, utilizzando Manhattan possiamo affermare che JasperReports un software solido e ben strutturato. 2.7 considerazioni finali su manhattan

difcile giudicare un tool emergente, cercheremo per di evidenziare i punti a favore e a sfavore. Innanzi tutto va chiarito che il tool non possiede assolutamente abbastanza metriche 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 considerazioni finali su manhattan

60

la sua natura open-source che permette una sua maggiore diffusione (multipiattaforma) e possibilit di miglioramento; funzioni che permettono di avere unottima scalabilit; non richiede di meta-les per eseguire le analisi, ma soltanto del codice sorgente; non stand-alone ma si basa sul Framework di Eclipse; possibilit di modicare il codice sorgente mentre si utillizzano viste tridimensionali; le metriche disponibili seppur poche sono utili; presenza di un sistema di caching per mantenere in memoria le viste gi analizzate dei progetti non modicati. Mentre i suoi difetti sono: mancanza di metriche utili a riconoscere code smell e anti-pattern; fortemente legato ad altre librerie sia grache che di analisi; enormi difcolt nellinstallazione; 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 modicate dallutente; mancanza di esportazione dei graci 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.

2.8 dettagli tecnici

61

Il dettaglio che Manhattan non un software stand-alone stato inserito sia nei pregi che nei difetti, questo perch per alcuni sviluppatori che utilizzano gi Eclipse pu essere un vantaggio avere in un unico ambiente sia leditor che un software di analisi. anche per questo che Manhattan pu anche essere utilizzato per il forward engineering, dato che ci si accorge velocemente di alcune disarmonie nel codice, vedendo la costruzione del progetto in real-time. Questo dettaglio per pu anche essere considerato come un difetto nel momento in cui il programmatore non solito utilizzare Eclipse. In questo caso diventa fastidioso dover installare pi di un software. Come possiamo notare sono pi i difetti che i pregi; ma leggendo bene, la maggior parte dei difetti sono dovuti alla mancanza di una determinata funzione o di un determinato comportamento. Questo signica che possono essere viste pi come feature mancanti che come difetti, dato che Manhattan ancora in fase di sviluppo. 2.8 2.8.1 dettagli tecnici Congurazione macchina utilizzata

Date le forti difcolt riscontrate durante linstallazione del tool, si deciso di testarlo soltanto su una sola macchina. Qui di seguito abbiamo una tabella con la congurazione del computer utilizzato. 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: Congurazione macchina utilizzata

2.8.2

Tempistiche di analisi

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

2.8 dettagli tecnici

62

configurazione S-1 S-1 S-1 S-1 S-1

versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2

tempo 0.41 sec 13.06 sec 14.11 sec 18.12 sec 4.15 min

Tabella 7: Tempistiche di analisi con Manhattan su JasperReports

2.8.3

Installazione

Linstallazione di Manhattan [Rigotti] stata molto difcoltosa. In caso di mancata installazione o di mancato download vengono esposti errori poco comprensibili e non risolvibili in maniera intuitiva. stato rieseguito il processo di installazione per 4 volte su due sistemi operativi differenti 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 funzionamento del tool sono: sistema operativo a 32 bit; almeno 512 Mb di ram (1 Gb consigliato); Eclipse correttamente aggiornato allultima versione disponibile (Indigo 3.7 o superiori) [Coorporation]; SDK Java aggiornata allultima versione (versione 6 - u26 o superiori) [Oracle, a]; Appurato di avere i requisiti minimi possiamo procedere con linstallazione: 1. aprire Eclipse e selezionare il men Help; 2. selezionare il sottomen install new software; 3. installare la libreria graca 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/u

2.8 dettagli tecnici

63

Figura 49: Tutorial di installazione

2.8.4

Bug

Durante linstallazione del tool si sono vericati problemi che hanno comportato la reinstallazione del framework di Eclipse e la reinstallazione di Manhattan. Esistono due piccoli bug, se cos si possono denire: 1. il primo fa persistere la schermata di attesa di elaborazione, anche se in realt il tool ha gi nito di analizzare il progetto target; 2. il secondo (capitato una sola volta), fa si che quando noi andiamo a rianalizzare un progetto gi analizzato, compaia un errore che non permetta di completare loperazione richiesta.

Figura 50: Schermata di errore (n2)

Questi due malfunzionamenti possono essere attribuiti alle scarse performance del computer, dato che il tool stato testato su una macchina virtuale con soli 512 Mb. Sostanzialmente il software risulta privo di bug evidenti che compromettono il suo utilizzo.

2.8 dettagli tecnici

64

2.8.5

Documentazione

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 la metrica utilizzata.

Figura 51: Sito ufciale di Manhattan

BAUHAUS

Bauhaus nasce come progetto di ricerca della University of Stuttgart e la spin-off Axivion [Bauhaus]. Lo scopo del progetto si colloca nellambito del mantenimento software e del software reengineering e in particolare mira a rispondere al problema del decadimento software.1 Il decadimento software descrive il deterioramento del codice nel tempo che tende a rendere il programma instabile, inusabile o comunque bisognoso di manutenzione. Evidentemente non un fenomeno sico ma dovuto alla mancanza di aggiornamenti rispetto ai cambiamenti dellambiente in cui risiede. Bauhaus fornisce una vista complessiva del sistema da analizzare tramite metriche e permette di entrare in dettaglio per valutare gli interventi da effettuare per ristrutturare il codice. 3.1 analisi

In questa analisi effettuata tramite il software Bauhaus verr valutata solo lultima versione di JasperReports, la 4.0.2, per poi confrontare in modo evolutivo le principali release precedenti. 3.1.1 Analisi progettuale - Anti-Pattern

Bauhaus non stato espressamente creato con lintenzione di evidenziare le anomalie progettuali quanto piuttosto, come anticipato, per individuare i punti critici del software. Ad ogni modo gli strumenti forniti permettono di evidenziare alcuni punti di interesse. Come prima analisi signicativo evidenziare i cicli allinterno del sistema (si veda gura 52): in tutto sono presenti 67 nodi e 75 archi coinvolti. Come possiamo vedere in gura alcuni cicli sono piuttosto rilevanti arrivando a comprendere sette o otto nodi che si richiamano a vicenda, situazione tipica che identica lanti-pattern Tangle.

1 Il progetto Bauhaus fu iniziato da Erhard Ploedereder, Ph.D. e Rainer Koschke, Ph.D. alla University of Stuttgart[6] nel 1996. In origine era una collaborazione tra lInstitute for Computer Science (ICS) della University of Stuttgart e il Fraunhofer-Institut fr Experimentelles Software Engineering (IESE), che non pi coinvolto. La spin-off commerciale Axivion venne avviata nel 2005. Oggi, la ricerca portata avanti presso Axivion, lInstitute of Software Technology, il Department of Programming Languages alla University of Stuttgart cos come il Software Engineering Group della 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 piccola modica si ripercuote inevitabilmente su buona parte del sistema: questo rende il codice difcile da mantenere.

Figura 53: Complessit ciclomatica signicativa tipica di una Brain Class

Altro indice utile per individuare disarmonie dato dalla complessit ciclomatica. La McCabe Complexity, o complessit ciclomatica, il numero di decisioni nel corpo della funzione pi uno; una decisione un predicato in corrispondenza del quale il usso 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 poste sul cammino per raggiungere la locazione, pi necessario capire il contesto per arrivare a capire la locazione. Vediamo ad esempio che JRAbstractStyleFactory e JRStyledTextParser contengono metodi di complessit ciclomatica molto elevata rispetto alle linee di codice

3.1 analisi

67

eseguibili, portando a considerarle come Brain Class. Dal graco si notano in quanto 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 createHighLowDataset della classe ConvertChartContext. Queste classi sono delle Data Class come si pu notare analizzandone il codice.

Figura 55: JRApiWriter

Inne la classe JRApiWriter risulta essere una God Class a causa del numero di righe di codice ma soprattutto analizzando il suo neighborhood mostrato in gura 56 nella pagina successiva dove si evidenziano le relazioni con metodi e classi. Per quanto riguarda invece le interfacce possiamo vedere la presenza di una disarmonia nella classe JRStyle: osservando infatti nel graco il numero di linee di codice si nota come questo sia sproporzionato rispetto alle altre lasciando pensare a un sovraccarico di questa.

3.1 analisi

68

Figura 56: JRApiWriter Fish view

Figura 57: Disarmonia nella classe JRStyle

3.1.2

Analisi programmativa - Code Smell

Ponendosi da un punto di vista pi generale, e quindi pi ampio, possiamo avere unidea complessiva della struttura del progetto basandoci inizialmente su alcune metriche 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 del codice. Innanzi tutto possiamo misurare la lunghezza di classi e metodi in termini di numero di linee di codice, linee di codice eseguibili e rapportarle al numero di commenti. Possiamo vedere che il numero di linee di codice abbastanza omogeneo su tutti i nodi del progetto ma vi qualche eccezione che si discosta molto come riportato in gura 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 di dimensione 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 codice eseguibili. A prescindere dalla leggibilit del codice che sar sicuramente pi bassa a causa della lunghezza del metodo risulta essere forse troppo complesso e potrebbe essere diviso in pi metodi permettendo un maggiore riutilizzo del codice e una granularit pi ne, 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 particolare con la possibilit di vedere la correlazione tra metriche diverse, la distribuzione dei commenti rispetto al codice.

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

Come possiamo vedere dalla gura 61 i commenti sono distribuiti abbastanza uniformemente rispetto alle linee di codice e anche se bisognerebbe analizzare in dettaglio ogni classe per vericare che i commenti siano signicativi, 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 permette di raggruppare per ottenere una vista sintetica. possibile visualizzare le classi di un package alla volta ma sono generalmente in numero cos elevato da non permettere una visualizzazione signicativa. Una funzione interessante che mette a disposizione Bauhaus la ricerca automatica di codice duplicato. Abbiamo eseguito questo tool sul codice sorgente di JasperReports e abbiamo rilevato la presenza di moltissimo codice duplicato come si nota in gura 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 numero totale di cloni elevato come si pu notare dalla barra laterale

Andando nel dettaglio si vede come molti cloni siano in realt dati da metodi deprecati, probabilmente tenuti per retro compatibilit. Sono tuttavia presenti anche segmenti di codice con denizioni di costanti duplicate.

Figura 63: Esempio di codice contenente denizioni di costanti duplicate

3.2 analisi evolutiva

72

3.2

analisi evolutiva

Come gi illustrato, abbiamo analizzato in dettaglio soltanto lultima versione di JasperReports. Procederemo ora ad illustrare una analisi sullevoluzione del software in termini pi generali sfruttando le numerose metriche fornite da Bauhaus 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.2 gi affrontata nel capitolo precedente. Il primo strumento che abbiamo per valutare levoluzione del progetto dato dal conteggio degli elementi: in particolare possiamo notare una crescita del numero di package e classi pressoch costante anche se vi un notevole balzo dalla 3 alla 4 di pi del 50%.

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

Gi dalla prima versione comunque il progetto da considerarsi ampio anche se i numeri dellultima versione sono pi importanti. Dopo aver valutato lincremento di classi e package risulta naturale analizzare le eventuali variazioni nel numero di righe di codice per vericare se lincremento di dimensione del progetto corrisponda a un incremento di funzionalit o semplicemente a una riorganizzazione del codice gi esistente in una congurazione pi modulare. Questa volta invece non notiamo un sostanziale incremento o variazione: rimangono solo dei piccoli punti di differenza e in modo particolare sembrano apparire alcuni metodi lunghi e complessi, come se fosse stata aggiunta una funzionalit senza una vera integrazione nel sistema ma lasciata isolata e contenuta in un unico 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-

3.2 analisi evolutiva

73

Figura 65: Confronto del numero di linee di codice. Dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0. Non si nota una signicativa variazione tra le tre versioni.

getto abbassandone la qualit. Ma per essere sicuri di questo bisogna analizzare altri parametri come la complessit ciclomatica e la presenza di cicli. Anche per quanto riguarda la complessit ciclomatica possiamo notare un incremento per alcuni elementi isolati a conferma del fatto che laumentare di complessit del codice si ripercosso anche sulla sua mantenibilit, portando ad avere alcuni agglomerati di funzioni. Ultima considerazione sulla complessit del codice lanalisi sulla presenza di cicli. Valutando le versioni precedenti di JasperReports risultato che lultima quella che contiene meno cicli in assoluto mentre la peggiore la 2.0 che risulta pi intricata con cicli da decine di nodi. Osserviamo quindi che c stato un miglioramento anche da questo punto di vista nellultima versione in cui stato ottimizzato il codice riducendo la complessit ciclomatica, il numero di cicli e mantenendo stabili gli altri parametri a fronte di un signicativo aumento di dimensioni. Si nota anche un maggior riuso del software, sulla base dellaumento delle relazioni interne al programma. Ultimo parametro considerato per questa valutazione evolutiva il numero di linee di commento rispetto al numero di linee di codice come vediamo in gura 68 a pagina 76. Partendo dallultima versione, la 4.0.2, esaminata nel capitolo precedente, dove avevamo una distribuzione quasi lineare e quindi proporzionale, osserviamo che ancora una volta le versioni precedenti mostrano una qualit pi bassa: anche se

3.2 analisi evolutiva

74

Figura 66: Confronto della complessit ciclomatica assoluta e rispetto al numero di linee di codice eseguibili. Per ogni riga dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0.

sono abbastanza uniformi si nota dai graci la presenza di numerosi elementi con molte righe di codice e poche righe di commento. Per trarre delle conclusioni pi afdabili bisognerebbe analizzare direttamente il codice ma non offrendo Bauhaus strumenti sintetici per questa analisi non stato fatto, vista la mole di dati che si dovrebbe affrontare. Ultima singolarit il graco della prima versione dove si notano elementi con molte righe e nessun commento e vice versa elementi con nessuna riga di codice e soltanto commenti. Da questa informazione possiamo dedurre che la 1.0.0 stata una versione di passaggio dove limplementazione non era ancora terminata e molte classi e metodi erano soltanto commenti. Daltra parte non chiaro come mai una release sia stata pubblicata con questa strana congurazione, se non come versione provvisoria. Non avendo per analizzato le release successive alla 1.0.0 non sappiamo se le classi di soli commenti siano state implementate o se si sia aspettata la versione 2.0.0 dove queste disarmonie non si vericano.

3.3 suggerimenti per migliorare bauhaus

75

Figura 67: Confronto della presenza di cicli nelle varie versioni di JasperReports. Dallalto 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 aiutare gli utenti alle prime armi ad avvicinarsi a questo tool aggiungere una guida rapida che spieghi i concetti essenziali per analizzare subito un progetto. Sicuramente anche il fatto che lanalisi debba essere fatta da riga di comando non aiuta lapprendimento dello strumento e quindi aggiungere uninterfaccia gra-

3.3 suggerimenti per migliorare bauhaus

76

Figura 68: Vista comparativa della correlazione tra numero di linee di commento e numero di linee di codice di JasperReports. Dallalto JasperReports 1.0.0, JasperReports 2.0.0 e JasperReports 3.0.0

ca per la parte di estrazione delle informazioni da sorgenti e class le facilita lutente nellimparare a usare il tool senza dover leggere quattrocento pagine di documentazione. Le viste e i gra sono piuttosto chiari e ben fatti, anche gli strumenti di selezione sono funzionali e completi, ma anche in questo caso si pu migliorare qualche punto: per quanto riguarda linterfaccia graca necessario aggiungere delle informazioni al passaggio del mouse, o quando il puntatore si ferma in un punto, che spieghino i singoli componenti. Ad esempio il signicato dei sei campi che caratterizzano ogni vista, che corrispondo a numero di nodi e archi rispettivamente totali, selezionati e marcati, stato dedotto dopo qualche tentativo

3.4 suggerimenti per migliorare jasperreports

77

e confermato da una lettura della documentazione. Per quanto riguarda invece le voci dei men sarebbe utile ltrare a seconda del linguaggio del progetto che si sta analizzando: non tutte le opzioni infatti sono abilitate per ogni linguaggio ma sono tutte ugualmente presenti. Questo devia lutente che non capisce se sia il programma a non funzionare o sia una funzionalit non pertinente con lambiente di analisi. Automatizzare inoltre funzioni di ricerca, come anti-pattern e code smell semplicherebbe la vita a chi deve invece districarsi tra un numero elevato di classi e package, con la difcolt di scegliere le query giuste da eseguire per individuare i problemi del codice. In ultimo bisogna menzionare che risolvere i bug riportati nellapposita sezione renderebbe Bauhaus pi utilizzabile. 3.4 suggerimenti per migliorare jasperreports

Come abbiamo potuto notare tramite lanalisi evolutiva, JasperReports 4.0.2 gi stato migliorato rispetto alle versioni precedenti. Analizzando il codice non sono emerse delle disarmonie sorprendenti e se anche presente qualche punto che potrebbe essere ristrutturato nel complesso possiamo dire che ben progettato ma soprattutto che gi stato ristrutturato. 3.5 considerazioni finali bauhaus

Nonostante i problemi riscontrati, Bauhaus risultato un tool potente che lascia lutente libero di maneggiare il codice agilmente. Gli strumenti che mette a disposizione rispondono bene agli obiettivi posti dagli sviluppatori e mantiene effettivamente le promesse fatte. Non risulta comunque un tool completo ma ottimo se afancato da strumenti di individuazione automatica di anomalie perch, una volta focalizzato un punto dinteresse permette di entrare in dettaglio pi e meglio di altri tool. 3.6 considerazioni finali su jasperreports

A prescindere dalleffettivo funzionamento di JasperReports, che non stato considerato, lanalisi attraverso Bauhaus ha portato allidea che sia gi stato fatto un buon lavoro di refactoring. Il codice strutturato bene e le disarmonie presenti sono poche rispetto alla mole del progetto. Bisogna comunque analizzare altri aspetti con altri tool per confermare questa ipotesi.

3.7 dettagli tecnici

78

3.7 3.7.1

dettagli tecnici Congurazioni macchine utilizzate

Bauhaus stato utilizzato su due differenti calcolatori per generare i le .rfg, mentre la visualizzazione graca stata usata soltanto in uno dei due per alcune difcolt di supporto delle librerie gtk su piattaforma a 64 bit. Congurazione 1 (Old Iralab): Ubuntu 10.10 Maverick, 2GB RAM Linux 2.6.35-30-generic i686 GNU/Linux Intel(R) Pentium(R) 4 CPU 3.00GHz (1 core) Congurazione 2 (Personal Notebook): Ubuntu 11.04 Natty, 4GB RAM Linux 2.6.38-8-generic x86_64 GNU/Linux Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2 core) Congurazione 3 (New Iralab): Ubuntu 10.04 Lucid, 8GB RAM Linux 2.6.32-32-generic-pae i686 GNU/Linux Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz (8 core) Congurazione 4 (Essere): Gentoo Base System release 1.12.14, 4GB RAM Linux 2.6.36-gentoo-r8 x86_64 GNU/Linux Intel(R) Xeon(R) CPU E5320 @ 1.86GHz (8 core) 3.7.2 Tempistiche di analisi

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


jasperreports-1.0.0 real 0m0.007s user 0m0.004s sys 0m0.004s real 0m34.830s user 0m15.041s sys 0m11.713s jasperreports-2.0.0 real 0m0.019s user 0m0.008s sys 0m0.008s real 1m51.356s user 0m51.163s sys 0m47.935s jasperreports-3.0.0 real 0m0.023s user 0m0.012s sys 0m0.008s real 2m10.642s user 0m59.176s sys 0m58.152s

3.7 dettagli tecnici

79

jasperreports-4.0.2 real 0m0.092s user 0m0.008s sys 0m0.012s real 3m9.449s user 1m27.353s sys 1m25.917s

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


jasperreports-1.0.0 real 0m0.018s user 0m0.010s sys 0m0.000s real 0m16.718s user 0m8.940s sys 0m6.400s jasperreports-2.0.0 real 0m0.012s user 0m0.000s sys 0m0.010s real 0m56.148s user 0m28.640s sys 0m27.260s jasperreports-3.0.0 real 0m0.012s user 0m0.000s sys 0m0.010s real 1m1.632s user 0m31.270s sys 0m30.120s jasperreports-4.0.2 real 0m0.028s user 0m0.010s sys 0m0.010s real 1m33.007s user 0m46.420s sys 0m46.440s

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


jasperreports-1.0.0 real 0m0.003s user 0m0.000s sys 0m0.004s real 0m10.320s user 0m6.448s sys 0m3.856s jasperreports-2.0.0 real 0m0.017s user 0m0.008s sys 0m0.000s real 0m37.157s user 0m20.641s sys 0m16.429s jasperreports-3.0.0 real 0m0.007s user 0m0.008s sys 0m0.000s real 0m43.447s user 0m23.681s sys 0m19.705s jasperreports-4.0.2 real 0m0.009s user 0m0.012s sys 0m0.000s real 1m3.514s user 0m34.702s sys 0m28.722s

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


jasperreports-1.0.0 real 0m0.067s user 0m0.004s sys 0m0.000s real 0m19.820s user 0m10.181s sys 0m9.201s jasperreports-2.0.0 real 0m0.011s user 0m0.004s sys 0m0.004s real 1m11.070s user 0m32.662s sys 0m38.414s jasperreports-3.0.0

3.7 dettagli tecnici

80

real 0m0.012s user 0m0.000s sys 0m0.008s real 1m25.367s user 0m38.350s sys 0m47.015s jasperreports-4.0.2 real 0m0.017s user 0m0.012s sys 0m0.004s real 2m4.175s user 0m56.400s sys 1m7.776s

3.7.3

Installazione

Nellambito dellanalisi del software non stato possibile testare e sperimentare linstallazione di Bauhaus poich richiede una chiave di licenza apposita. Abbiamo invece utilizzato una versione precedentemente installata su server remoto. La versione utilizzata Axivion Bauhaus Suite Version 5.6.6 Built on 2009-03-23 by Axivion GmbH con licenza di tipo Academic. Bisogna notare che sufciente copiare la cartella contenente Bauhaus per poterlo utilizzare su altre macchine: con questo sistema stato possibile valutare le 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 la documentazione adeguata circa linstallazione. Riportiamo per completezza i passaggi 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 sso 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, specicando quando richiesto la cartella di destinazione. Licenza Il le di licenza acquisito insieme a Bauhaus deve essere posto nella cartella $HOME/.bauhaus/ per singolo utente o BAUHAUS/cong/ per licenze multi utente.

3.7 dettagli tecnici

81

Personalizzazione setup Tramite lo script setup.sh il software personalizza i link simbolici alle librerie necessarie al programma e congura i compilatori da utilizzare. Avviare Bauhaus Per prima cosa necessario importare il contenuto del le bauhaus-kshrc in modo da aggiungere le variabili dambiente necessarie. Inne sufciente invocare gravis da terminale per avviare il visualizzatore graco. 3.7.4 Analisi software java

Per analizzare i software java Bauhaus mette a disposizione un tool da riga di comando che a partire dal bytecode crea un le .rfg, ovvero il formato che descrive in termini di grafo tutto il progetto, memorizzando per ogni elemento alcune informazioni caratteristiche. La creazione di questo le facilitata se il progetto sotto forma di archivio JAR, in quanto il comando da eseguire accetta un unico le come elemento da analizzare. Se non si in presenza di un unico le JAR ma si hanno tutti i le class vi sono due alternative: Creare un le JAR Creare un le project La soluzione adottata stata quella meno comune di creare un le project, per sperimentare il funzionamento di Bauhaus anche in questa condizione. Un le project, come illustrato dalla main page di java2rfg, un le dove per ogni riga specicato il path di un diverso le class. Per generare questo le sufciente utilizzare il comando unix nd. Un altro parametro interessante da impostare il path del codice sorgente. Questo permette a Bauhaus di collegare il codice ai singoli elementi del graco in modo da permettere una navigazione del codice a partire dagli elemtenti del grafo. Dovendo analizzare pi versioni del progetto, strutturate con la stessa architettura di cartelle stato preparato uno script che genera automaticamente i le .rfg, vedi Algoritmo 3.1, per tutti i progetti calcolando il tempo di esecuzione della computazione. Gli output dello script sono stati riportati per mostrare i tempi di esecuzione su diverse macchine. Lanalisi per la ricerca di cloni piuttosto semplice anche se fornisce unalta personalizzabilit. Lesecuzione rapida come si evince dai risultati sperimentali dove i tempi di calcolo sono stati di soli cinque secondi sulla congurazione meno performante.

3.7 dettagli tecnici

82

Algorithm 3.1 Script per estrarre un le 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 specicare il linguaggio dei sorgenti, un pattern per i le da includere, il formato di output e la cartella in cui cercare ricorsivamente i sorgenti. Un esempio di comando il seguente: clones -lang java -le_patterns *.java -outformat cpf src >> clones.cpf. 3.7.5 Bug

In questa sezione riportiamo alcuni problemi riscontrati nellutilizzo di Bauhaus. Il primo dato dallimpossibilit di avviare e utilizzare linterfaccia graca su sistema a 64 bit. Non stato possibile vericare se con una versione adeguata allarchitettura si risolvano questi problemi ma si suppone di si: stata infatti usata lunica versione a noi disponibile che supportava architetture a 32 bit. Nellutilizzo del programma invece si sono vericate delle schermate di errore nellutilizzo di alcune funzioni. Questo in genere non un problema ma lo abbiamo riportato per due motivi: in alcuni casi lerrore portava alla chiusura del programma spesso lerrore dipendeva dal fatto che la funzionalit richiesta non era disponibile per il linguaggio supportato Per queste ragioni riteniamo che sarebbe meglio evitare questi errori in modo da rendere il lavoro dellutente pi uido. Questi sono alcuni degli errori riscontrati durante lutilizzo del programma. Non sono errori gravi in quanto non compromettono il corretto funzionamento del programma ma riducono lusabilit per lutente.

3.7 dettagli tecnici

83

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

Figura 70: Quando si cerca di aprire un package con doppio click viene mostrato questo errore perch non c, evidentemente, un le di codice di denizione del package

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 uscenti e molte altre varianti. Si verica per questo errore quando si sceglie lopzione Deselect nodes; bisogna invece scegliere Deselect all

Figura 72: Nei plot per la rappresentazione di informazioni metriche, impostando come assi alcuni criteri si ottiene un graco vuoto con gli elementi tutti spostati nella parte superiore della nestra. In gura il riquadro rosso segna dove dovrebbe essere il plot, notiamo che manca anche il riquadro, mentre tutti gli elementi si condensano in quella riga grigia nella parte superiore della schermata.

3.7 dettagli tecnici

84

3.7.6

Documentazione

La documentazione disponibile online scarsa o pressoch inesistente ma questa carenza compensata da una guida completa fornita assieme alla suite. Per gli utenti registrati, ovvero quelli in possesso di una licenza, disponibile accedere a un servizio di supporto [Axivion]. Nella guida sono spiegati in dettaglio tutti i passaggi relativi allinstallazione, un tour dellapplicazione che introduce alle tecniche e alle funzionalit, una guida ai comandi utilizzabili da linea di comando, una guida allanalisi dei linguaggi supportati, una parte sul visualizzatore graco, una guida allo scripting e inne una appendice su alcuni argomenti minori. La densit e il livello di dettaglio forniti sono tali da coprire abbondantemente le necessit dellutente che utilizza per la prima volta Bauhaus. Si rimanda pertanto a questultima per qualsiasi dubbio e approfondimento necessario.

L AT T I X

Lattix LDM (Lattix Dependency Models) un software parte di una pi ampia suite, cui scopo la generazione di DSM, dependency/design structure matrix, struttura molto usata in ambito gestionale-organizzativo, e la denizione di DR, design rules, a partire da tali matrici, da usare come strumento di guida alla stesura dellarchitettura software [Sangal, 2007]. Il programma pu analizzare progetti software in vari linguaggi, ed il supporto a Java nativo e non richiede tool esterni. I progetti Java sono preferibilmente forniti al programma come le .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 dellapproccio danalisi proposto dai creatori del software ovviamente la generazione della matrice per lintero progetto; il passo successivo lindividuazione di gerarchie tra i moduli software: per esempio, un modulo che non ha alcuna dipendenza uscente, ma molte entranti, probabilmente vicino la radice della gerarchia. Il workow di analisi prevede poi lordinamento ed il raggruppamento di moduli secondo le gerarchie individuate: ci permette di individuare anomalie in modo diretto, ed il punto di partenza, se desiderato, per lindividuazione di anti-pattern. Una funzionalit molto interessante del software la gestione delle design rules, che assieme al modello DSM costituisce il modello di dipendenza nella sua interezza. Una DR un vincolo di dipendenza impostato dallarchitetto che guida il processo di sviluppo, ed di supporto nella prevenzione di anti-pattern. Inne, come molti tool di analisi software, anche Lattix LDM in grado di mostrare allutente varie metriche tipicamente OO. Completa il quadro delle funzionalit principali una funzionalit di reporting, con vari possibili formati di output (.xls, .csv, .xml...). Il software multipiattaforma e di facile installazione, il sistema di DSM permette lindividuazione di anti-pattern comuni a colpo docchio e lapproccio DR un valido sistema di paletti per ripararsi da uno sviluppo controproducente. Daltro canto, il software assume che la divisione in moduli del progetto da analizzare sia stata fatta con perizia, e la visione dazione s glocale ma rilevante solo quando 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 dispersiva ed inefcace (la matrice diviene sparsa). Ci si dovrebbe attenuare adoperando Lattix LDM come plugin di Eclipse, avendo in tal modo una corrispondenza immedita con il codice. Notiamo anche che la versione standalone comunque necessaria a tal proposito, per la creazione dei progetti di lavoro. 4.1 analisi

Nota: con il termine classe intenderemo da qui in avanti un qualsiasi tipo di struttura 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 le: in Java quindi questo il numero massimo di le caricabili di tipo classe (atomi). Vista tale limitazione, non stato possibile valutare lorizzonte evolutivo del progetto su tutte e cinque le release principali nella loro interezza, e si stati costretti a selezionare un sottosistema, individuato come cuore dellapplicativo, e quindi presente in tutte le release, ma allo stesso tempo di dimensione inferiore al limite. In particolare sono stati individuati i package: engine view xml Il codice non ben commentato, ma da quanto si pu intuire: lengine come previsto fornisce funzionalit di supporto base, dalle classi per denire la struttura di un report no a quelle necessarie a riempirlo con dati anche per il package view non ci sono sorprese diciamo, troviamo le classi per la GUI; nota: sono state generate automaticamente con un tool graco, JForge, certicato da Novell, la cui ultima release data 1999 quasi scontato che unapplicazione moderna di reporting si basi su questo linguaggio, nel package xml troviamo classi di servizio per la scrittura di xml e limport di questi le, ogni elemento del documento testuale mappato in 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 sul numero di classi nel tempo e mettendo in evidenza il loro peso rispetto al numero totale di classi nelle release: release 0 1 2 3 4 classi 76 300 509 579 805 altre 1 59 104 131 195 totale 77 359 613 710 1000 totale progetto 77 566 925 1039 1526 peso 100% 63.4% 66.3% 68.3% 65.5%

Tabella 8: Panoramica quantitativa

Lultima versione stata rilasciata lo scorso aprile, mentre la prima datata 2001, e questi numeri sono testimoni di quel che la storia di questo progetto: nato come progetto individuale, cui nome originale era gi JasperReports, stato poi acquisito da una societ, la Jaspersoft, nel 2004, ed tuttoggi uno dei prodotti di punta di tipo free di questa: i package application core sono rimasti e larchitettura progettuale si arricchita attorno ad essi. 4.1.3 Il DSM del progetto JasperReports

In questa sezione vogliamo investigare i pesi dei vari package componenti ed isolare casi di dipendenze tra essi. Come possiamo vedere, il package dedicato alla gestione dellinterfaccia graca poca cosa rispetto al motore applicativo, la componente di modello. Addentrandoci quindi nel package engine, si hanno una serie di classi e vari altri package; tra di essi anche il package xml, originariamente indipendente, che non per il pi rilevante, giacch maggiori sono i package ll ed export: parte importante del codice allora concentrata nelle classi delegate alla creazione di report da fonti di dati lette ed al loro export in formati standard. La scacchiera delle dipendenze non segna eccessivi picchi, ma si nota lalto numero di dipendenze che lega le classi dei sottopackage ll, export, type ed engine a quelle presenti in engine: non necessariamente una situazione grave, o meglio una valutazione pi chiara richiederebbe ulteriori approfondimenti; tutto quel che si pu dire che laccoppiamento ha anche difetti, come per esempio la necessit di cambiamenti a cascata in caso di modiche a classi molto puntate.

4.1 analisi

88

4.1.4

Analisi progettuale - Anti-Pattern

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 denita; in realt essa chiara gi n dalla release 0, nella corrente pi composita per la maggior maturit del progetto non solo in termini di funzionalit: non siamo quindi in presenza di un big ball of mud project, anche se era quasi certo non sarebbe stato questo il caso. Il sistema appare fondato su di un paradigma MV, Model-View, infatti le logiche di controllo non paiono esplicitamente isolate, almeno ad una prima analisi. Il codice necessario alla gestione della GUI, il package view separato, seppure formi solo il 2% del sottosistema preso: non allora nemmeno il caso di Magic pushbotton pare. Lanalisi con X-Ray ad esempio suggerisce la classe JRBaseFactory avere un numero NOC (Number of children) troppo alto. Concentrandoci su questa classe in Lattix salta subito allocchio il numero di dipendenze singole che essa ha nei confronti di altre classi nello stesso package: 70; ci pu o meno essere un effettivo problema da risolvere, e nel caso lo sia, possibile aiutarsi impostando una regola. 4.1.5 Analisi programmativa - Code Smell

Nellinvestigare la presenza di eventuali code smell, facciamo afdamento esplicito alle metriche fornite oltre che alla struttura DSM. Lautore ha, per propria curiosit, aperto delle classi del progetto, a campione, una ventina. Il numero assai esiguo viste le dimensioni del progetto, ma circa la met sono risultate classi esclusivamente di comodo, che fanno poco, rivelando il code smell denominato Freeloader, che vuole intendere quegli elementi che sono s caricati in uso al programma, ma che hanno compito marginale e potenzialmente assimilabile altrove. Daltro canto, ben pi noto il problema duale, quello dei cosiddetti God objects, elementi contraddistinti sostanzialmente dallessere troppo estesi e troppo ricchi di funzionalit. Volendo sfruttare appieno le funzionalit offerte dal programma una procedura euristica manuale per lindividuazione 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 signicativo, esaminarla in quanto potenziale God class

4.2 analisi evolutiva

89

Figura 73: Focus sulla classe JRBaseFactory

4. se pi alto (basso) il LOC del package 5. ripetere dal punto 1 Lindividuazione di questi due particolari code smell non comunque troppo agevole in Lattix LDM: non obiettivo del software. 4.2 analisi evolutiva

Forniamo unanalisi dellevoluzione del progetto integrando alle matrici DSM lapplicazione delle metriche a disposizione su ognuna delle cinque versioni sotto esame. Come visto in tabella 8 il sottosistema preso in esame, composto dai due package view ed engine, infatti xml al momento sottopackage di engine, costituisce gran parte dellapplicativo. Volendo, si potrebbe assimilare al solo package engine il progetto: questo ha senso anche perch, in prima istanza, JasperReports si presenta 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 rilevanti nellultima release; essi sono presenti dalla release 1.0.0 in poi.

4.2 analisi evolutiva

90

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

release 1 2 3 4

xml 13% 12% 11% 10%

fill 25% 25% 22% 18%

export 4% 10% 12% 18%

totale 42% 47% 45% 47%

Tabella 9: Peso sotto-package

Da questa tabella vediamo che le cose non sono cambiate poi tanto durante gli anni e che il gruppo applicativo formato da questi package ammonta sempre al 45% circa dellapplicazione. Controlliamo ora quanto queste componenti siano sfruttate dallapplicazione: se vogliamo contare le dipendenze nella vista corrente, basta semplicemente sommare i valori della riga dinteresse; le dipendenze che contiamo saranno quelle entranti al package e provenienti dalle altre classi nel package engine e dagli 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 Peeger, 1998], sempre offerte da Lattix LDM e riferite allarchitettura nel suo complesso; per ognuna ricordiamo brevemente qual il

release 1 2 3 4

xml 34 43 10 9

fill 9 24 28 33

export 106 26 31 39

totale 149 93 79 81

Tabella 10: Panoramica dipendenze

4.2 analisi evolutiva

91

suo signicato.

Figura 75: Metriche assortite. Si pu chiedere al sistema di generare tre distinti tipi di metriche, di sistema, darchitettura 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 toccata da una modica del sistema 2. Impatto medio: limpatto per il cambiamento di una classe il numero di altre classi che potenzialmente andrebbero modicate, questo il valore di media su ogni classe 3. Numero dipendenze: la somma di tutte le dipendenze interne 4. Complessit: una delle possibili metriche per denire quanto sia intricato un sistema 5. Connettivit: la percentuale di elementi che direttamente od indirettamente sono in dipendenza da altri, quindi quelle classi per le quali, nel grafo delle dipendenze, esiste un cammino che parte da esse e termina in unaltra classe 6. Accoppiamento: percentuale delle componenti fortemente connesse nel grafo delle dipendenze; una componente fortemente connessa nel grafo rappresenta una cricca interdipendente Il calcolo di tutte le metriche supportate illustrato con chiarezza nella KB. Abbiamo quindi i seguenti valori: Analisi dei risultati.

4.2 analisi evolutiva

92

metrica 1 2 3 4 5 6

o.x.x 86% 11 221 0.002 14% 1%

1.0.0 76% 98 2191 0.089 24% 5%

2.0.0 77% 145 3393 0.208 23% 6&

3.0.0 78% 153 4260 0.302 22% 4%

4.0.2 65% 351 6576 0.658 35% 16%

Tabella 11: Metriche Architetturali

1. una successione della stabilit non crescente ci suggerisce che linterdipendenza 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 signicherebbe cambiare, al peggio, il 14%, nellultima il 35%; riteniamo ancora una volta accettabile questa situazione, glia di una maggiore ricchezza di funzionalit, anche ancillari 3. il numero di dipendenze va contestualizzato rispetto alle altre metriche, per esempio il numero totale di classi o limpatto; la statistica cresciuta enormemente nel tempo: maturit del programma od organizzazione povera? 4. la complessit del sistema rimane bassa, ed essendo calcolata come prodotto tra atomi ed archi normalizzato, i valori sono ragionevoli: un programma con numero di dipendenze non esorbitante, tipico di una libreria sostanzialmente automatica 5. la connettivit, come tutti gli altri valori, trova il suo picco nellultima release; essa il duale della stabilit, e quindi le considerazioni da farsi sono da ricondurre alla stabilit 6. il valore di coupling ha un vero e proprio balzo nellultima release; questa indicazione da non sottovalutare, anche nellottica di uneventuale refactoring del progetto: vengono ad individuarsi cluster di componenti interdipendenti, ed una volta individuati, se gi non lo sono, si potrebbe riunirle in un medesimo package

4.2 analisi evolutiva

93

metrica 1 2 3

o.x.x 0.067 0.791 0.175

1.0.0 0.273 0.803 0.203

2.0.0 0.255 0.739 0.156

3.0.0 0.292 0.781 0.172

4.0.2 0.316 0.930 0.200

Tabella 12: Metriche OO su JasperReports

4.2.2

Metriche OO

Un altro gruppo di metriche molto interessanti fornite da Lattix quello delle metriche object-oriented, dalle quali possiamo trarre grande vantaggio dato che stiamo lavorando in Java. Di quelle fornite, scegliamo le tre principali: 1. Astrattezza: appunto la misura di quanto sia astratta unarchitettura, ossia il numero di classi dichiarate abstract; si calcola come semplice rapporto 2. Instabilit: questa metrica OO di semantica abbastanza differente dalla Stabilit di sopra; valuta quanto un sistema sia da ritenersi stabile, prescindendo da eventuali modiche a classi ma concentrandosi sul tessuto di interdipendenze tra classi 3. Distanza: la metrica funzione diretta delle precedenti, la distanza dalla retta di sequenza principale nel piano Astrattezza X Instabilit; basta posizionarsi in un punto (astrattezza, instabilit), argomento, e calcolare la distanza tra esso e la retta passante per (1,0) e (0,1) Queste metriche devono essere valutate a livello di package, non di singola release nella sua totalit; unidea allora valutarle sul package principe, engine, confrontando attraverso il cammino evolutivo. Per la 0, dovremo considerare di sommare 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 luso dellastrazione molto basso, per crescere poi, anche se non monotni, no allultima release dove circa il 30% delle classi astratto. Intendiamo ci come una maturazione del gruppo di sviluppo, che peraltro sappiamo anche essere cambiato, nel tempo: maggiore padronanza dei concetti OO 2. linstabilit si mantiene sostanzialmente costante no allultima release, dove cresce e non di poco. Lo spirito di questa metrica accostare un assetto non troppo afdabile ad unimplementazione ricca di dipendenze, specie

4.3 miglioramenti possibili

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 adoperare ancora lastrazione 3. possiamo sostenere che la distanza ragionevolmente costante durante tutto larco di vita del progetto. Questo sicuramente assai positivo perch denota uno sviluppo lineare nel tempo, grazie al quale la qualit del progetto in termini di afdabilit rimane la stessa, ed un dato importante considerando i cambiamenti vissuti dal progetto 4.3 4.3.1 miglioramenti possibili Suggerimenti per migliorare il tool

Lattix LDM sicuramente un buon tool nellunire una struttura formale ma visivamente interessante come la matrice DSM e le pi importanti metriche danalisi, ad un sistema di gestione delle regole per uno sviluppo guidato e controllato. Analizzando un progetto gi esistente il nostro sforzo in questa sezione evidenziare in modo oggettivo i punti di debolezza di questo tool soprattutto nellambito della prima componente, quella di analisi quantitativa. Scalabilit: la struttura DSM di per se orientata a fornire una valutazione chiara del sistema in una prospettiva globale, anche se come detto si pu passare arbitrariamente dalla visione dinsieme 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 signicativit date proprio le sue dimensioni. Unidea potrebbe essere trovare una rappresentazione pi conveniente della matrice una volta raggiunta una certa dimensione con le espansioni Acquisizione: Lattix LDM per Java pu leggere progetti da le .zip, .jar ed alberi cartelle. Lavora con le .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 partendo direttamente dal codice non compilato Anti-pattern triggering: una funzionalit che si potrebbe pensare come estensione al programma il suggerire alcuni possibili anti-pattern a partire da funzioni sulle metriche calcolate; come abbiamo osservato nella relazione alcuni anti-pattern sono rintracciabili da unanalisi quasi esclusivamente quantitativa del codice, non semantica, e quindi questo il caso Interfaccia: la quantit dinformazione fornita dal programma davvero alta, bisognerebbe forse lavorare sullinterazione utente, per evitargli ogni volta di andare a fare mining per trovare quel che gli serve

4.4 dettagli tecnici

95

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, il software 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 classi potrebbero suggerire sia stato adottato il DP Abstract factory. Considerando il dominio e lo scopo dellapplicazione, una soluzione potrebbe essere integrare con il 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 inferiore al 55-60%. 4.4 4.4.1 dettagli tecnici Tempistiche danalisi

La release pi estesa la 4.1.2, e per essa, che rappresenta il caso peggiore, la performance media stata pi che sufciente: creazione progetto: 11s popolazione DSM: istantanea calcolo metriche: 9s Una metrica calcolata o meno dal tool in base alla grandezza del parametro ad essa in input, per evitare di affaticare il processo: infatti qualche metrica cubica nel numero di classi, ed un progetto medio-grande pu arrivare a contarne anche un paio di migliaia. Questa impostazione pu essere cambiata modicando il le delle preferenze del programma. 4.4.2 Installazione

Linstallazione non standard, poich leseguibile si pu scaricare liberamente, ma la chiave di licenza per poterlo utilizzare in modalit trial inviata manualmente dal team Lattix LDM previa lettura di una richiesta mail dellutente; salvo questo dettaglio, la modalit dinstallazione non presenta altre particolarit. Il programma distribuito sia per Windows sia per Linux, sia standalone sia come plugin Eclipse.

4.4 dettagli tecnici

96

4.4.3

Bug

Non sono stati scoperti bachi durante lutilizzo del sistema. 4.4.4 Documentazione

A ricercare sul web, Lattix LDM non sembra un software estremamente famoso, ma abbastanza usato come tool di analisi quantitativa statica. La documentazione non-ufciale scarsa, ma in compenso, anche con la versione 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 si dilunga eccessivamente su ogni aspetto ma scritta per essere chiara e di rapida consultazione. Da notare il manuale utente, aggiornato allultima branch, ed uno studio di caso sul noto software di build Ant.

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

SA4J

Structural Analysis for Java (SA4J) un tool che analizza le dipendenze strutturali delle applicazioni Java, per misurare la loro stabilit. Rileva anti-pattern strutturali e fornisce strumenti per effettuare la navigazione delle dipendenze per lesplorazione dettagliata di anti-pattern. SA4J permette anche lanalisi "what if" per valutare limpatto del cambiamento sulle funzionalit oltre ad offrire linee guida per il re-factoring dei packages. 5.1 analisi

Lanalisi dettagliata verr applicata soltanto allultima versione del software target per riuscire a trarre delle conclusioni sul progetto. Nella sezione analisi evolutiva verranno analizzate tutte le versioni con ogni metrica disponibile. 5.1.1 Analisi progettuale - Anti-Pattern

SA4J mette a disposizione dellutente una buona quantit di anti-pattern strutturali riconoscibili automaticamente. Gli anti-pattern riconoscibili tramite SA4J sono: Local buttery: oggetti con molti dipendenti diretti; possono essere interfacce di base, classi di base astratte e utilities; Global buttery: 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 buttery; sono spesso interessati quando qualcosa nel sistema viene modicato; interessano una percentuale signicativa del sistema;

97

5.1 analisi

98

indicano che il sistema non ben concettualizzato ed ha unalta instabilit; Tangle: dipendenze circolari interfacciate; se un oggetto in un tangle viene modicato, tutti gli oggetti nel tangle sono interessati. Notiamo nella gura 77 come il software target sia in possesso di alcuni antipattern.

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 causa della numerosit delle classi appartenenti al tangle. La stessa vista per ci fornisce pi informazioni quando andiamo ad investigare su 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 possibile rimedio potrebbe essere quello di diminuire le dipendenze verso questi due

5.1 analisi

100

package suddividendoli ulteriormente per limitare le loro interazioni con altri packages. Gli altri tangle presenti nel codice non risultano abbastanza signicativi da essere riportati. Passiamo ora a visionare i Global Hub presenti nel codice. La vista Summary denisce che nel codice sono presenti 423 Global Hub, ovvero il 13% degli oggetti in totale. Vediamo come la vista Explorer, anche in questo caso, non ci aiuti abbastanza a causa delle dimensioni del software target. Inoltre non permette di visionare i Global Hub pi signicativi in base al numero di entit coinvolte. Analizzando dunque tutti i 423 Global Hub, notiamo quello che a vista pare il pi signicativo (vedi gura 80).

Figura 80: Global Hub

JasperDesign sembra essere la classe che con pi probabilit necessit di refactoring per diminuire le dipendenze con tutte le altre entit.

5.1 analisi

101

Figura 81: JasperDesign

Da questa info-box notiamo come la classe JasperDesign sia affetta da qualsiasi tipo di anti-pattern riconoscibile dal software. Questo ci fa pensare ad una scorreta progettazione di questo modulo. Sarebbe stato interessante vedere che tipi di metodi fossero presenti nella classe per capire se fosse stato legittimo questo alto livello di dipendenza con altre classi e interfacce ma purtroppo il tool non ci permette di visionare il codice mentre si utilizzano le viste. Passiamo poi ad un vista caratteristica di SA4J chiamata Skeleton. Questa vista ci permette di vedere in maniera concisa la mappa delle dipendenze del sistema, oltre agli anti-pattern riconosciuti (Butteries, Breakables, Hubs and Tangles) e allimpatto ai cambiamenti di codice.

Figura 82: Skeleton view

La guida presente nel software ci informa che un buon skeleton di un progetto dovrebbe assomigliare il pi possibile ad un triangolo rettangolo. In realt questo skeleton ne ha solo una leggera parvenza, infatti lultima riga di oggetti continua per circa 8 lunghezze della riga superiore.

5.1 analisi

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 di classi e di ulteriori Tangle che gli dipendono. Gli oggetti colorati di giallo sono quelli che verrebbero modicati se il Tangle cerchiato di rosso venisse alterato. Continuando lanalisi progettuale passiamo alla vista What if che rappresenta tutti i packages in una sola vista, permettendo di visualizzare le dipendendze delle classi. Questa funzionalit risulta utile per vedere la distribuzione delle classi nei vari packages, ma sostanzialmente poco daiuto per visualizzare le dipendenze dato che la vista diventa molto confusionaria in un progetto di grandi dimensioni.

Figura 83: What if view

Notiamo che alcuni packages hanno soltanto una classe al loro interno, mentre altri 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 download aggiornamenti, stampa, etc..). Quando invece i packages diventano di dimensioni troppo elevate, pi probabile che sia una scorretta progettazione architetturale. Infatti notiamo che il package ll quello con pi classi/interfacce (176). Notiamo come la gran parte degli anti-pattern siano compresi proprio in questo package e nel package engine, anchesso di elevate dimensioni (133 entit). Dunque possiamo trovare una relazione tra il numero di classi nello stesso package e il numero di anti-pattern rilevabili.

5.1 analisi

103

per questo che sarebbe preferibile ridurre le dimensioni dei packages in maniera sensata, lasciando soltanto le classi con funzionalit puramente intrinseche al package padre. La funzionalit della vista What if per visualizzare le dipendenze risulta invece abbastanza incomprensibile, come si puo notare nella gura 84.

Figura 84: What if view- Dependency

Ulteriore vista che ci permette di trarre informazioni utili riguardo lanalisi progettuale la Inheritance view, che a differenza di altre viste, molto user friendly, infatti mette a disposizione un pratico men a scorrimento che permette di notare in maniera veloce possibili disarmonie nel codice. In questo caso si trattano di disarmonie relative ad ereditariet troppo elevate. Infatti, spesso utile avere classi con alta ereditarit dato che aumenta il livello di riuso del codice, per a volte si perde il senso e si cade in errore. Spesso si cerca di inserire nelle classi glie 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 glie, ma in realt ci siamo accorti che attraverso la lettura dei nomi delle classi, queste risultavano pi che legittime.

5.1 analisi

104

Figura 85: JRBaseFactory

5.1.2

Analisi programmativa - Code Smell

Partiamo subito con lidenticazione delle dimensioni del progetto in questione. Tramite la vista Summary possiamo accorgerci che JasperReports pu essere denito come un software di grandi dimensioni dato che possiede 69 packages. Purtroppo SA4J non offre una funzionalit che conti il numero di classi, di metodi o di linee di codice. Offre soltanto il conteggio degli oggetti, che per non signicativo dato che il tool non specica cosa si intende per oggetti.

Figura 86: Statistics

Per quanto riguarda lidenticazione di code smell possiamo basarci sulla presenza di funzionalit che ci permettono di avere una buona quantit di metriche da poter consultare. Partiamo con la vista Local Dependencies che ci permette di visualizzare le dipendenze entranti e uscenti, oltre a informazioni di carattere pi specico.

5.2 analisi evolutiva

105

Notiamo n da subito, che la classe con pi dipendenze la JRApiWriter con 285 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. 5.2 analisi evolutiva

Lanalisi evolutiva di JasperReports, tramite SA4J, stata abbastanza difcoltosa a causa della lentezza del software nel caricare i progetti, e della sua scarsa gestione della memoria. Inizialmente avevamo pensato di confrontare i vari risultati delle viste per ogni versione del software, memorizzandole tramite la funzionalit apposita. Ci siamo accorti pero che il risultato, in particolar modo quello delle immagini, non era allaltezza, ed per questo che abbiamo deciso di effettuare degli Snapshot delle viste per confrontarle. Come possiamo notare, inizialmente il progetto era composto da 3 packages soltanto. Notiamo subito un errore prodotto da SA4J che riporta nel summary 5 packages, anche se poi nella vista What if ne vediamo soltanto 3 (come giusto che sia). Continuando vediamo che il valore degli anti-pattern Global Breakable e Global Buttery abbastanza elevato. Notiamo inoltre come la distribuzione delle classi nei packages rispecchi anche la presenza di anti-pattern. Infatti notiamo che il package engine quello pi popolato sia di classi che di anti-pattern. Inoltre possiamo 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 SA4J 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 signicativa. Presumiamo che sia avvenuto un refactoring dalla prima versione. Infatti gli anti-pattern che prima erano presenti persino al 33% (Global Buttery) ora sono quasi 1/3 (12%).nte aumentato. Questo parametro solitamente comporta un aumento degli anti-pattern, ma in questo caso tutto cio non avviene grazie allottima progettazione. Anche la stabilit del software aumentata di molto portandosi al 93% (valore sopra la soglia).

5.2 analisi evolutiva

106

Figura 89: JasperReports 0.x.x

Figura 90: JasperReports 1.0.0

5.2 analisi evolutiva

107

Passiamo ora a visionare le versioni 2.0.0 e 3.0.0 del software, le quali si assomigliano 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 il numero di anti-pattern raggiunga soglie bassissime. Infatti ci accorgiamo come nella versione 2.0.0 molti siano addirittura non presenti. Quelli presenti non raggiungono percentuali che possano farci pensare a disarmonie gravi. Vediamo inoltre come nelle versioni 2.0.0 e 3.0.0 si raggiunga il valore record di stabilit del software (98%).

5.3 suggerimenti per migliorare sa4j

108

Passiamo ora alla versione nale 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 di anti-pattern nel codice. Anche la stabilit del codice diminuita, ma non scesa a livelli che possono impensierire. Lunico fattore, che stato anche evidenziato nellanalisi precedente, il numero di Tangle che sempre aumentato dalla prima versione no allultima. Possiamo dire che in generale JasperReports si evoluto in maniera sensata e costante, cercando di rimediare a problemi e disarmonie presenti nelle versioni precedenti. Notiamo un leggero calo nellultima versione, anche se le disarmonie presenti non risultano critiche. 5.3 suggerimenti per migliorare sa4j

SA4J 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 Analyst4J. Le mancanze che possiamo sottolineare sono: carenza di ordine nelle viste polimetriche: mancanza di viste che permettano di visualizzare in maniera semplice e comprensibile la struttura del progetto analizzato. mancanza di poter spostare le entit dei diagrammi; mancanza di autoordinamento delle entit;

5.4 suggerimenti per migliorare jasperreports

109

mancanza di visibilit dei diagrammi; mancanza di scalabilit: SA4J manca di scalabilit praticamente in ogni vista, fornendo una quantit di informazioni cos elevata e cos poco strutturata che confondono lutilizzatore. 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 packeges che mostrino in maniera intuitiva le dimensioni di ogni entit. debole interfaccia graca: carenza di chiarezza e di usabilit. spesso non permette allutente di visualizzare in maniera corretta le informazioni; impossibilit di vedere il codice sorgente. spesso risulta utile poter vedere il codice per accorgerci dellimportanza e della struttura delle entit software; mancanza di metriche per contare le classi i metodi e le linee di codice. risulta difcile farsi unidea delle dimensioni del progetto senza avere questi parametri; permettere di visionare i Global Hub pi signicativi in base al numero di entit coinvolte. basterebbe un algoritmo di riordinamento basato sul numero di dipendenze; migliorare la qualit dei report prodotti. aumentare la risoluzione delle immagini; produrre report in formato pdf; 5.4 suggerimenti per migliorare jasperreports

In denitiva JasperReports pare un software ben progettato ed implementato. Non sono emerse particolari disarmonie nel codice durante lanalisi tramite il tool SA4J. Gli unici suggerimenti che ci sentiamo di esprimere sono: di diminuire il numero di entit contenute nel package ll; creare ulteriori packages contenenti le classi non propriamente intrinseche del package ll.

5.5 considerazioni finali su jasperreports

110

di diminuire il numero di entit contenute nel package engine; creare ulteriori packages contenenti le classi non propriamente intrinseche 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 altre classi,meglio ancora in altri packages in maniera tale da poter eliminare questa forte dipendenza. tentare di eliminare i piccoli bug presenti nel codice. Seguendo queste semplici indicazioni si potrebbe diminuire in maniera signicativa la quantit di anti-pattern presenti nel codice, rendendo cos ancor pi stabile il software. 5.5 5.5.1 considerazioni finali su jasperreports Tramite SA4J

Lanalisi con il tool SA4J ha dato un risultato leggermente differente degli altri tool precedentemente analizzati. Possiamo notare come SA4J indichi che il software analizzato presenta diverse disarmonie pi o meno gravi. Una nota positiva dallutilizzo del tool la stabilit del software target che del 95%. Dunque tramite lutilizzo del tool SA4J possiamo vedere come in JasperReports ci siano anti-pattern di tipo: Global e Local Breakable e Global e Local Buttery. 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 considerazioni finali su sa4j

Possiamo denire SA4J un buon tool dato che presenta una lunga serie di metriche e funzionalit automatiche per il riconoscimento di anti-pattern, anche se, secondo il nostro parere, tutte le funzionalit presenti, a meno del Summury, sono quasi inutilizzabili su progetti di grandi dimensioni. Ci siamo trovati difronte a gravissime difcolt nel tentare di ridurre le viste o di capire la quantit enorme di informazioni forniteci. Crediamo fermamente che lutilizzo di questo tool su progetti di grandi dimensioni sia quasi controproducente. Infatti a differenza di

5.6 considerazioni finali su sa4j

111

altri tool, SA4J riconosce una disarmonia praticamente in ogni classe del progetto. La maggior parte delle viste tabellari sono pressoch insigicanti data la disposizione dei dati in maniera poco comprensibile. Persino la visualizzazione delle dipendenze stata resa indecifrabile. Comunque sia non esistono soltanto note negative, infatti come abbiamo detto prima, la vista summary tenta di placare la disorganizzazione del resto del tool e di raccogliere tutte le informazioni utili delle altre viste, esponendole in maniera comprensibile. I pregi sostanziali sono: facilit di installazione; non richiede di meta-les per eseguire le analisi, ma soltanto del codice sorgente; 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 spiegazione della metrica utilizzata. Mentre i suoi difetti sono: impossibilit di visualizzare e modicare il codice sorgente mentre si utillizzano le viste; impossibilit di creare metriche; impossibilit di modicare schemi o diagrammi; impossibilit di poter confrontare metriche differenti; viste poco comprensibile e spesso di dimensioni troppo elevate da essere rappresentate su una schermata sola; poca usabilit; non possiede funzionalit utili per il reverse engineering; utilizzabile soltanto su progetti Java; qualit report scadente;

5.7 dettagli tecnici

112

interfaccia graca scadente e poco stabile; conteggio dei package poco chiaro; utilizzabile soltanto su progetti open-source o di cui si possiede il sorgente. 5.7 5.7.1 dettagli tecnici Congurazione macchina utilizzata

Qui di seguito abbiamo una tabella contenente la congurazione della macchina utilizzata per testare SA4J. s-1 MS Windows 7 x64 bit Intel Core Duo 2.40 GHz 4.00 GB
Tabella 13: Congurazione macchina utilizzata

5.7.2

Tempistiche di analisi

Segue una tabella con il valore tempistico dellanalisi su tutte le versioni di JasperReports. configurazione S-1 S-1 S-1 S-1 S-1 versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo 2 sec 14.70 sec 54.30 sec 55.40 sec 1.23 min

Tabella 14: Tempistiche di analisi con SA4J su JasperReports

5.7.3

Installazione

Requisiti minimi I requisiti minimi richiesti non sono assolutamente limitativi.

5.7 dettagli tecnici

113

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 o superiori, raccomandati; RAM: 256 MB minimo - 512 MB raccomandati; DISK SPACE: Minimo: 100 MB per linstallazione. 200 MB raccomandati per il workspace; Versione standalone Linstallazione non ha richiesto particolare attenzione. Basta infatti scaricare linstaller dal sito [IBM, b] e seguire la seguente procedura: 1. download della versione opportuna del sistema operativo utilizzato; on 2. lanciare linstaller StructuralAnalysisForJava_WindowsSetup.exe. 5.7.4 Bug

Durante linstallazione del tool non stato riscontrato alcun bug. Unici eventi anomali, ma che non si possono considerare bug, sono stati i cambiamenti di visualizzazione graca del sistema operativo durante lutilizzo del tool e la lentezza nellaprire 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 non descresce mai, anzi continua a crescere nch il programma si semiparalizza. Ulteriori eventi anomali sono stati riscontrati nel conteggio dei packages nel primo progetto, dove il tool in una vista contava pi package che in unaltra.

5.7 dettagli tecnici

114

5.7.5

Documentazione

SA4J offre una documentazione leggermente carente, a differena di altri tool. LIBM, lazienda produttrice di SA4J mette a disposizione [IBM, a]: un breve tutorial on-line per effettuare linstallazione di SA4J Standalone Version; una breve spiegazione sugli anti-pattern riconosciuti dal tool; unutile funzionalit di help che spiega in breve le metriche e gli anti-pattern riconosciuti; un forum (poco frequentato) e delle FAQ; In denitiva la documentazione scadente. Questo causa unaumento della curva di apprendimento del software.

Figura 93: Sito ufciale di SA4J

X - R AY

X-Ray un plug-in open-source per il framework Eclipse. Fornisce viste per determinare la complessit di un intero sistema, dei suoi metodi, delle sue classi e dei suoi package, oltre ad offrirci viste per comprendere le loro dipendenze. 6.1 analisi

Lanalisi verr applicata soltanto allultima versione del software target, per riuscire a trarre delle conclusioni sullo stato corrente del progetto, mentre nella sezione analisi evolutiva verranno analizzate tutte le versioni con ogni metrica disponibile. 6.1.1 Analisi progettuale - Anti-Pattern

Per quanto riguarda lanalisi progettuale e dunque la ricerca di anti-pattern, X-Ray non fornisce funzionalit che avvertano lutente riguardo la presenza di questo tipo di disarmonie. Per mette a disposizione dellutente una serie di metriche che, se usate in maniera intelligente, possono fornire una serie di indizi e a volte di certezze che ci permettono di constatare la presenza di alcuni anti-pattern. Infatti questo proprio il caso della classe JRBaseFactory del package engine. Come possiamo notare dalla gura 94, la classe possiede 162 classi glie, che con i suoi due metodi e le sue 33 righe di codice, paiono eccessive: la classe ha un valore di NOC (Number Of Children) troppo elevato. Al crescere del NOC, cresce il livello di riuso ma tende ad evaporare lastrazione della classe madre, per non parlare della possibilit che una classe glia non sia membro appropriato della madre. Sarebbe preferibile diminuire i gli della classe JRBaseFactory, mantenendo soltanto i gli legittimi anche perch al crescere del NOC, cresce la quantit di test case necessari a testare ogni glia.

Figura 94: JRBaseFactory on System Complexity view

115

6.1 analisi

116

Ulteriori classi presentano la disarmonia che possiede JRBaseFactory anche se in maniera meno eclatante e meno evidente. Tramite la System Complexity, mediante la funzionalit info-box, possiamo facilmente notare uninterfaccia eccessivamente complessa, con dimensioni maggiori rispetto alle altre interfacce presenti nel software. Linterfaccia in questione ha il nome JRStyle e fa parte del package engine (gura 95). Essa possiede un numero di operazioni eccessivo e molto eterogeneo. Possiamo dunque riconoscere lanti-pattern dello Swiss Army knife (coltellino svizzero chiamato anche Kitchen Sink ovvero lavandino). Le principali conseguenze di questo anti-pattern, sono la difcolt di utilizzo, manutenzione e documentazione. Sarebbe preferibile risolvere o minimizzare questo problema dividendo linterfaccia in ulteriori interfacce pi semplici, ognuna con un compito specico. Oppure, se non fosse possibile dividerla, si potrebbe pensare di creare dei proli di utilizzo, cio dei sottoinsiemi di operazioni dellinterfaccia, limitati da convenzioni e condizioni da soddisfare. Se nemmeno i proli fossero applicabili, si potrebbe pensare di considerare politiche di utilizzo in ambito generic programming.

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

6.1.2

Analisi programmativa - Code Smell

Per quanto riguarda lanalisi programmativa, X-Ray fornisce una funzionalit basilare che ci permette di avere un quadro generale delle dimensioni del software target. Come possiamo vedere dalla gura 96, la info-box ci avverte delle dimensioni del software. JasperReports con i suoi 62 package, le sue 1733 classi, i suoi 16745 metodi e le

6.1 analisi

117

Figura 96: Dimensioni del software target

sue 272184 linee di codice pu essere denito come un software di medie-grandi dimensioni. Continuando con lutilizzo di diverse metriche, in particolare della System Complexity, scopriamo che la classe JApiWriter ha le carte in regola per essere una Brain Class con le sue grandi dimensioni e la sua elevata complessit; anche se non possiamo esserne certi. Questa incertezza dovuta alla scarsit di metriche disponibili 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 unulteriore disarmonia, questa volta legata alla classe JRVerier. Come possiamo notare in gura 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 di dipendenze con altre classi, soprattutto uscenti, che ci fanno pensare ad una God Class.

118 Figura 97: Classe JRVerier

6.1 analisi

119

Un ulteriore code smell spesso visibile tramite la funzione Show Classes l Empty Catch Clause (gura 98), ovvero la presenza nel codice di clausole di catch o nal senza nessun corpo. Questa pratica molto utilizzata per far compilare il codice in maniera veloce senza preoccuparsi delle exception che potrebbero sorgere. Purtroppo mettendo un blocco di catch vuoto si permette si di compilare ma cos facendo non si gestisce lexception che potrebbe scaturire e quindi perde completamente di signicato lutilizzo di un blocco try-catch.

Figura 98: Empty Catch Clause on JRClassGenerator

Ulteriore code smell percepibile tramite la funzione Show Class quello riferito alla mancanza di commenti nel codice sorgente appartenente al package engine e a tutte le interfacce presenti nel software target. In un progetto di dimensioni mediograndi pressoch inaccettabile avere il package pi importante del software privo di commenti (vedi gura 95 a pagina 116). Spesso i commenti presenti seguono la formattazione Doxygen ma non il buonsenso della limitazione ad 80 caratteri. Purtroppo ulteriori code smell, tramite lutilizzo di X-Ray, non possono essere facilmente rilevati. La gran parte di quelli appena citati sono stati trovati per caso utilizzando il tool, dato che X-Ray non fornisce funzionalit per lautoricerca di code smell (come del resto di anti-pattern).

6.2 analisi evolutiva

120

6.2

analisi evolutiva

Diversamente dalle sezioni precedenti, X-Ray risulta molto utile per lanalisi evolutiva del Software, dato che fornisce diverse viste polimetriche che ci permettono di avere una chiara visione dellintero progetto. Ogni metrica stata applicata sulle diverse versioni di JasperReports per analizzare al meglio levoluzione del software. Procedendo utilizzando tutte le viste che ci fornisce X-Ray possiamo indagare sullevoluzione del progetto. Notiamo che tramite la vista Package Dependency, il package con pi dipendenze 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 inizialmente queste informazioni come un indizio per analizzare meglio i due package, per capire se questa forte dipendenza lecita o una disarmonia che andrebbe corretta.

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

Ora che abbiamo una traccia possiamo indagare sul package engine mediante la vista Class Dependency. Notiamo subito (gura 102 a pagina 123) che una classe appartenente al package engine fortemente interdipendente con altre. Le dipendenze sono sia di tipo entrante che di tipo uscente, anche se quelle uscenti sono pi signicative. Queste informazioni sono molto signicative perch ci portano a pensare che la classe JasperReport del package engine abbia tutte le carte in regola per essere una God Class dato che subisce un accesso intensivo ai suoi parametri da parte

6.2 analisi evolutiva

121

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

di altre classi pi leggere, e possiede molti metodi non comunicativi. Inoltre caratterizzata da unalta complessit ed effettua un elevato numero di operazioni autonome senza disturbare altre classi. Investigando tramite la funzionalit Show Class scopriamo il codice sorgente, ma purtroppo non essendoci commenti signicativi non capiamo ancora di preciso le sue funzionalit principali. Sospettiamo una scarsit di commenti nel codice ma purtroppo non abbiamo modo di vericarlo tramite X-Ray dato che non presenta funzionalit per contare le linee di commento e rapportarle con quelle di codice effettivo. Leggendo il nome dei metodi della classe in questione possiamo comunque presuppore che questa sia parte integrante del motore di reporting. Questa affermazione viene inoltre supportata anche dallapplicazione della terza vista polimetrica disponibile: la System Complexity. Uningente quantit di informazioni pu essere estrapolata tramite la System Complexity view, dato che mette a disposizione dellutente uno strumento per constatare lintera 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 metodi e le sue 932 righe di codice (come possiamo notare in gura 101 nella pagina successiva). Notiamo inoltre che le dimensioni di questa classe possono far pensare ad una

6.2 analisi evolutiva

122

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 classe con pi metodi e con pi linee di codice. Notiamo anche che in collegamento con uningente quantit di classi in maniera pi o meno forte (notiamo tutto ci grazie alla saturazione delle dipendenze). Pensiamo sia utile per migliorare lintero software riformulare questa classe, magari suddividendola in maniera tale da rendere il software pi riutilizzabile per progetti futuri. Allaumentare del numero di metodi in una classe, diminuisce la possibilit di intuire e predire il comportamento della classe in questione. Inoltre, allaumentare del numero di metodi di una classe aumenta anche la complessit della classe stessa e quindi anche il suo valore di WMC1 . Infatti andando ad analizzare la stessa classe nella seconda versione stabile di JasperReports (1.0.0) notiamo che stato attuato un refactoring incentrato soprattutto 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

6.2 analisi evolutiva

123

1.0.0 i metodi divengono soltanto 3 con 55 linee di codice in totale. palese lapplicazione 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, come possiamo vedere in gura 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 ha portato ad avere una diminuzione delle dipendenze tra classi. Ovviamente le differenze dalla prima versione alla seconda non sono soltanto incentrate sulla ridistribuzione dei metodi nelle diverse classi, ma bens dallintroduzione 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, come possiamo notare in gura 103. Dalla gura 98 a pagina 119 notiamo anche che le dipendenze tra i package sono scomparse. Questo un segno di ottima progettazione ed implementazione. La modularizzazione di un software permette di facilitare la riusabilit del codice ed inoltre riduce le tempistiche collegate al debugging ed al testing. In questo modo nessun mattoncino risulter indispensabile per lintero progetto. Inoltre non avendo evidenti dipendenze tra package diversi, si evince che ogni parte possiede il suo compito ben preciso che pu eseguire in maniera indipendente senza dover render conto a nessuno. Questo tipo di programmazione, associato ad una corretta documentazione, pu facilitare molto il compito di reverse engineering. Vediamo ora in maniera pi generale come si evolve il sistema, senza cercare di scendere nello specico in ogni singola classe. Possiamo notare dalla gura 104 come le dimensioni del progetto siano passate da irrisorie a imponenti nel giro di 3 anni.

6.3 suggerimenti per migliorare il tool

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 di linee di codice. Invece, nellultima versione possiamo contare invece 64 package con oltre 272k linee di codice. Questa vista ci permette inoltre di notare che le dipendenze tra le classi nelle versioni successive alla prima e precedenti allultima erano evidentemente intrapackage, mentre nelle restanti versioni le dipendenze sono aumentate esponenzialmente divenendo interpackage. Questa supposizione confermata dalla Package Dependency view, come notiamo in gura 105. 6.3 suggerimenti per migliorare il tool

Secondo il nostro parere, il X-Ray una ottima base su cui lavorare. Le carenze pi evidenti sono dovute alle tempistiche di sviluppo (soltanto 3 mesi): carenza di funzionalit: mancanza di autoidenticazione di alcun genere di code smell o anti-pattern; carenza di chiarezza: una funzionalit utile ma leggermente nascosta o comunque poco evidenziata quella che ci permette di visualizzare le dipendenze in base al loro peso; questa funzionalit andrebbe modicata permettendo allutente di poter selezionare il numero di dipendenze limite, in maniera tale da poter evidenziare soltanto le classi o i package che risultano fortemente dipendenti;

6.3 suggerimenti per migliorare il tool

125

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 una semplice vista tridimensionale per dare lidea delle reali dimensioni dei package, dato che con le viste correnti, non risultano sempre molto chiare; a questo proposito giusto ricordare un ulteriore tool basato su X-Ray chiamato Citylyzer che appunto ha la funzione principale di generare una visione 3D dei package e delle classi [Malnati]; carenza di visibilit: nella vista Class Dependency si ha che i nomi delle classi sono ambigui visto che non mostrato il nome esteso ma soltanto una sua contrazione che spesso si ferma al nome del package (per vederlo bisogna fermarsi sulla classe dinteresse);

6.3 suggerimenti per migliorare il tool

126

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

una semplice modica graca renderebbe il tutto molto pi fruibile; carenza di viste polimetriche: come lavoro futuro si potrebbe pensare di progettare e realizzare almeno una vista in pi, tipo la System Hotspot [Lanza et al., 2006]. In questa vista i nodi rappresentano le classi, mentre le loro dimensioni rappresentano il numero di metodi che deniscono. Il colore di ogni classe andrebbe a rappresentare la loro tipologia. Questa semplice vista consentirebbe di visualizzare sia classi di grandi che di piccole dimensioni, permettendo inoltre di scalare sistemi di dimensioni non indifferenti. I nodi potrebbero essere ordinati in base al numero di metodi posseduti, in questo modo si renderebbe facile e veloce lidenticazione di valori anomali; carenza di fruibilit: dal punto di vista attuale viene visualizzato in una singola vista un unico layout di lavoro, quindi lutente pu cimentarsi in una sola vista per volta senza poter effettuare confronti tra viste; sarebbe utile avere nelle prossime versioni di X-Ray un layout che possa contenere pi viste polimetriche, per offrire una completa rappresentazione del sistema senza costringere lutente a cliccare manualmente e cambiare la visualizzazione; scalabilit: X-Ray soffre di scalabilit soprattutto nelle viste di dipendenza sulle classi e sui package; per risolvere questo problema bisognerebbe far si che lutente sia in grado di visualizzare lintero sistema o solo una sottoinsieme, oltre a permettere di ingrandire e rimpicciolire la vista corrente, mostrando o nascondendo i dettagli. Anche dei ltri e degli zoom semantici potrebbero risultare utili;

6.4 suggerimenti per migliorare jasperreports

127

opzioni: sarebbe utile che lutente avesse la possibilit di modicare e impostare il colore e le metriche da utilizzare su ogni entit, oltre che la loro dimensione. Inoltre sarebbe utile regolare dinamicamente parametri mentre si 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 indicata dallutente. Inoltre questo cambiamento sarebbe utile poterlo memorizzare allinterno di una struttura dati richiamabile dallutente. si potrebbe pensare di poter applicare delle viste di ordinamento preimpostate, in maniera tale da poter velocizzare loperazione di analisi del software; raccolta dati incrementali: questa funzione andrebbe introdotta in maniera tale da permettere allutente di poter rianalizzare soltanto una parte modicata del progetto. Ora come ora X-Ray effettua lanalisi intera del progetto senza tener traccia di elementi che sono stati analizzati precedentemente e che non sono stati modicati; si potrebbe introdurre una analisi parziale incentrata soltanto sulle entit modicate dallultima analisi complessiva. produzione di report e documentazione: questa funzionalit potrebbe divenire utile dato che X-Ray calcola una quantit di informazioni che devono essere visualizzate soltanto tramite la info-box. Queste informazioni sono numero di package, classi, linee di codice, metodi, dipendenze entranti e uscenti, interfacce e molte altre ancora. si potrebbe pensare di far produrre a X-Ray dei report pdf o xml contenente tutte le informazioni rappresentate nelle info-box delle viste polimetriche. 6.4 suggerimenti per migliorare jasperreports

Essendo JasperReports un software ben strutturato, il compito di migliorarlo risulta complesso. Tramite questo tool possiamo di certo affermare che: Le relazioni tra i package nellultima versione sono eccessive. si pu pensare di creare alcuni package ex-novo per diminuire le forti dipendenze che nellultima versione si accentuano e compromettono lottima progettazione alla base.

6.4 suggerimenti per migliorare jasperreports

128

La mancanza di commenti nel codice sorgente scritto nelle prime versioni, in un progetto di dimensioni medio-grandi pressoch inaccettabile. I commenti presenti seguono formattazioni Doxygen ma non il buonsenso della limitazione ad 80 caratteri. si pu pensare di introdurre almeno un commento nellintestazione di ogni classe, o ancor meglio nellintestazione 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 JApiWriter potrebbe sembrare una una Brain Class con le sue grandi dimensioni e la sua alta complessit anche se non siamo certi data la scarsit 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 pesante utilizzo della classe JApiWriter verso altre classi di servizio. La classe JasperReport del package engine ha tutte le carte in regola per essere una God Class. si pu pensare di smistare le funzionalit secondarie di questa classe altrove e mantenere solo i metodi intrinseci. La classe JRBaseFactory del package engine ha un valore di NOC troppo elevato. Al crescere del NOC, cresce il livello di riuso ma tende ad evaporare lastrazione della classe madre, per non parlare della possibilit che una classe glia non sia membro appropriato della madre. sarebbe preferibile diminuire i gli della classe JRBaseFactor, mantenendo soltanto i gli legittimi dato che al crescere del NOC, cresce la quantit di test case necessari a testare ogni glia. Linterfaccia JRStyle del package engine ha un numero di operazioni eccessivo e molto eterogeneo. Le principali conseguenze di questo anti-pattern (Swiss Army Knife) sono la difcolt di utilizzo, la manutenzione e la creazione di documentazione comprensibile. Esempi di interfacce eccessivamente complesse sono comuni soprattutto tra i programmi commerciali. sarebbe preferibile risolvere o minimizzare questo problema nei seguenti modi: * dividendo linterfaccia in altre interfacce pi semplici, ognuna con un compito specico; * se non si pu dividerla, creando dei proli di utilizzo, cio dei sottoinsiemi di operazioni dellinterfaccia, limitati da convenzioni e condizioni da soddisfare;

6.5 considerazioni finali su jasperreports

129

* se nemmeno i proli sono applicabili, usando politiche di utilizzo in ambito generic programming. La presenza del code smell Empty Catch Clause, ovvero la presenza nel codice di clausole di catch o nal senza nessun corpo non permette di gestire lexception che potrebbe scaturire e quindi perde completamente di signicato lutilizzo di un blocco try-catch. sarebbe preferibile introdurre il corpo di ogni blocco try-catch, in maniera tale da poter gestire leventuale exception nel migliore dei modi. 6.5 6.5.1 considerazioni finali su jasperreports Tramite X-Ray

Tramite lanalisi di X-Ray si evince che JasperReports un software che stato inizialmente progettato con poca cura, sfruttando fortemente la classe madre (che come spesso capita ha il nome del software), incapsulando il lei la gran parte delle funzionalit. Dalla seconda versione (1.0.0) notiamo che stata attuata una riprogettazione dellintero sistema. La classe madre stata smembrata e le funzionalit sono aumentate. 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 accorgiamo che JasperReports cambia persino proprietario; infatti inizialmente il software era sviluppato da ununica persona. Questo puo essere uno dei motivi per cui si deciso di riprogettare lintero software. Continuando con levoluzione del software ci accorgiamo che la linea progettuale introdotta nella seconda versione (1.0.0), viene mantenuta perch ben pensata. Ad ogni versione si introducono nuovi package che per non condizionano il normale funzionamento del software ma sono dei moduli quasi completamente slegati al resto del progetto (possiamo vederle come funzionalit aggiuntive). Purtroppo nellultima versione disponibile le funzionalit introdotte compromettono la stabilit di JasperReports a causa di unalta dipendenza tra i package che prima non esisteva. Anche la modularit viene intaccata e cos di seguito anche la riusabilit del codice ne risente per non parlare della stabilit. Possiamo anche pensare ad unaumento non irrisorio dei tempi di testing e debugging. In denitiva il codice sembra ben strutturato, esistono poche God Classes ma che non impensieriscono molto data la loro forte necessit. Alcune classi hanno un valore di NOC (Number Of Children) troppo elevato. Questo tende a dissolvere

6.6 considerazioni finali su x-ray

130

lastrazione della classe madre, per non parlare della possibilit che una classe glia non sia membro appropriato della madre. La progettazione dopo la prima versione sembra essere quella denitiva. Forse si pu pensare di creare alcuni package ex-novo per diminuire le forti dipendenze che nellultima versione si accentuano e compromettono lottima progettazione alla base. da notare inoltre che vari gruppi di classi sono accomunate da dimensioni rilevanti; questo per non costituisce un problema perch le classi dellapplication logic sono ben strutturate. Durante lanalisi del software abbiamo incontrato alcuni anti-pattern, tipo lo Swiss Army Knife e alcuni code smell tipo lEmpty Catch Clause. Anche se 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 inaccettabile non avere nemmeno un commento che spieghi almeno il contesto e la funzione di ogni classe. 6.6 considerazioni finali su x-ray

Non si pu giudicare male un tool di questo calibro dato che stato sviluppato da 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 denire X-Ray come una sorta di tool per unanalisi breve e architetturale. Infatti con i suoi brevi tempi di analisi e le sue informazioni generali, fornisce subito lidea o almeno un indizio riguardo possibili disarmonie nel progetto target. un utile tool per analizzare in maniera superciale un progetto sia di grandi che di piccole dimensioni, dato che le sue viste sono perlopi generali, incentrate su package, classi e sullintero sistema. Inoltre possiamo citare i suoi pregi, che potrebbero sembrare irrisori ma in denitiva non lo sono per niente considerando le difcolt riscontrate con altri tool di analisi per il reverse engineering. I pregi sostanziali sono: facilit di installazione dovuta prevalentemente allambiente su cui viene eseguito; la sua natura open-source che permette una sua maggiore diffusione (multipiattaforma) e possibilit di miglioramento; icone molto intuitive e facilmente ricollegabili allazione a loro attribuita; non richiede di meta-le per eseguire le analisi, ma soltanto del codice sorgente;

6.7 dettagli tecnici

131

non stand-alone ma si basa sul Framework di Eclipse; possibilit di modicare il codice sorgente mentre si utilizzano viste polimetriche; utile anche per il forward engineering oltre che per il reverse engineering; ottima documentazione disponibile in rete ricca di esempi e spiegazioni utili sulle metriche implementate; le metriche disponibile seppur poche sono pratiche e utili. Mentre i suoi difetti sono: difcolt nella scalabilit; mancanza di metriche; presenza di bug in funzionalit secondarie; utilizzabile soltanto su progetti Java; 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 pregi che nei difetti, questo perch per alcuni sviluppatori che utilizzano gi Eclipse pu essere un vantaggio avere in un unico ambiente sia leditor che un software di analisi. proprio per questo che X-Ray pu anche essere utilizzato per il forward engineering, 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 momento in cui il programmatore non solito utilizzare Eclipse. In questo caso diventa fastidioso dover installare pi di un software. 6.7 6.7.1 dettagli tecnici Congurazioni macchine utilizzate

Anche X-Ray, come del resto gli altri tool, sono stati testati su pi macchine con congurazioni differenti. Qui di seguito abbiamo una tabella con le congurazioni dei computer utilizzati.

6.7 dettagli tecnici

132

s-1 MS Windows 7 x64 bit Intel Core Duo 2.40 GHz 4.00 GB Eclipse helios Versione 3.5.0 s-3 MS Windows XP x32 bit Dual Core 1.66 Ghz 2.00 GB Eclipse helios Versione 3.5.0

s-2 MS Windows XP x32 bit Dual Core 1.66 Ghz 1.00 GB Eclipse helios Versione 3.5.0 s-4 Ubuntu Natty 11.04 x64 bit Intel Core Duo 2.40 Ghz 4.00 GB Eclipse helios Versione 3.5.0

Tabella 15: Congurazioni macchine utilizzate

6.7.2

Tempistiche di analisi

Segue una tabella con i valori tempistici delle analisi sulle diverse versioni di JasperReports. Tempistiche di analisi con X-Ray su JasperReports con la congurazione S-1: versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo 1.49 sec 5.31 sec 13.54 sec 17.12 sec 57.40 sec

Tabella 16: Tabella delle tempistiche di analisi con X-Ray su JasperReports con la congurazione S-1

6.7 dettagli tecnici

133

Tempistiche di analisi con X-Ray su JasperReports con la congurazione S-2: versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo 3.45 sec 9.41 sec 20.37 sec 27.58 sec 1.34 min

Tabella 17: Tabella con le tempistiche di analisi con X-Ray su JasperReports con la congurazione S-2

Tempistiche di analisi con X-Ray su JasperReports con la congurazione S-3: versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo 2.34 sec 7.10 sec 18.58 sec 24.31 sec 1.18 min

Tabella 18: Tabella con le tempistiche di analisi con X-Ray su JasperReports con la congurazione S-3

Tempistiche di analisi con X-Ray su JasperReports con la congurazione S-4: versione di jasperreports 0.x.x 1.0.0 2.0.0 3.0.0 4.0.2 tempo 1.43 sec 5.34 sec 12.20 sec 15.27 sec 57.12 sec

Tabella 19: Tabella con le tempistiche di analisi con X-Ray su JasperReports con la congurazione S-4

6.7 dettagli tecnici

134

6.7.3

Installazione

Linstallazione di X-Ray molto semplice, grazie al fatto che un plug-in di Eclipse [Coorporation]. Infatti seguendo la guida [Malnati] possiamo notare che baster: installare il GEF framework, utilizzato da X-Ray per alcune rappresentazioni grache; inserire nella cartella plugin di Eclipse il Jar di X-Ray. In nessuna congurazione stato riscontrato un malfunzionamento o una mancata installazione. 6.7.4 Bug

Durante lutilizzo del tool sono stati riscontrati alcuni bug che afiggevano funzionalit secondarie e quindi possiamo affermare che il tool ben implementato. I bug riscontrati sono: un malfunzionamento dellesposizione della vista ClassDependency che non permette di visualizzare la dipendenza delle classi ad alcune distanze in certe situazioni. (bug noto allo sviluppatore ma non ancora risolto); la funzionalit SnapshotAction che spesso scaturisce una MemoryHeapException, compromettendo il funzionamento di Eclipse. Inoltre il path di salvataggio dichiarato nella documentazione non lo stesso dove vengono realmente salvate le immagini. 6.7.5 Documentazione

Considerando le dimensioni di X-Ray, possiamo ritenerci soddisfatti della quantit di informazioni trovate nel sito ufciale [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 spiegazione dettagliata di ogni singola metrica.

Figura 106: Sito ufciale di X-Ray

135

DUDE

Dude (Duplication Detector) uno strumento indipendente dal linguaggio per la rilevazione di codice duplicato (code clones) creato dallo sviluppatore di CodeCity[Wettel, c]. Oltre al suo impiego in sistemi per il reverse engineering, Dude stato con successo utilizzato per rilevare plagio nel codice in progetti e incarichi 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 vicini gli uni agli altri. Tuttavia, spesso un blocco di codice sorgente non solo copiato in un altro le, ma anche leggermente modicato. Tale duplicazione sar normalmente rilevata come una serie di piccoli cloni apparentemente insignicanti, che per invece di essere resi noti allutente come lievi modiche, verranno uniti in maniera tale da poter essere identicati come operazioni di copia e incolla seguiti da modiche (inserimento, cancellazione, modica di codice). 7.1 analisi

Lanalisi verr applicata soltanto allultima versione del software target date le ristrette 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 somiglianti sulla base della distanza Levenshtein (distanza di edit) superiore a una determinata soglia. Questo processo richiede diverso tempo ed utile nel rilevare lievi modiche del testo (come ridenominazioni di singoli nomi); Tokenized Distance: ovvero si tratta di un approccio pi rafnato del Exact Matching che opera a livello sintattico, che in grado di rilevare i cambiamenti complessi come ridenominazioni di variabili. Partiamo dunque con la funzionalit Exact Matching sulla versione 4.0.2 di JasperReports. Notiamo n da subito che il numero di cloni intaccano il 34% dei le appartenenti dellintero progetto. Un numero considerevole, anche se dobbiamo tenere

136

7.1 analisi

137

Figura 107: Statistics in Dude

anche conto che JasperReports possiede classi che contengono pi di duemila righe di codice, e non detto che tutte e duemila siano cloni di unaltra. Infatti notiamo che il numero di righe di codice duplicate (39837) rispetto a quelle analizzate (330313) sono circa il 12%. Inoltre in questo conteggio appartengono anche quelle righe di codice di tipo clone modied, clone deleted e clone composed. Ovvero non tutte possono essere associate allanti-pattern cut and paste programming, dato che spesso la semantica di un programma si ripete in maniera consistente. Ad ogni modo questo anti-pattern, prodotto della convinzione che modicare un programma sia meglio che scriverlo da zero, e che ha come conseguenze il rischio di alti costi di manutenzione e documentazione, pu essere agilmente individuato: possiamo infatti vedere una anco allaltra le classi incriminate.

Figura 108: Dude view

Un fattore che ci pu far pensare la presenza di 956 righe di codice cloni in una classe di 1455. Possiamo dire che gran parte della classe clone di unaltra.

7.2 suggerimenti per migliorare il tool

138

Notiamo pero che anche il nome delle due classi simile. Questo ci fa pensare che possa essere lecito utilizzare una struttura che si ha appurato essere funzionante ed efciente. 7.2 suggerimenti per migliorare il tool

Una funzionalit che sarebbe interessante aggiungere a Dude lidenticazione della tipologia di codice clonato, per esempio dire se appartiene ad un metodo, ad istanziazioni di variabili, a commenti ecc, gestibile dallutente attraverso un ltro (es. si vuole cercare solo il codice clonato di metodi). Inoltre si potrebbe potenziare il reporting, e permettere lexport in formati tabellari o .pdf, non solo testo dettagliato in .xml 7.3 suggerimenti per migliorare jasperreports

Non ci sentiamo di poter dare delle indicazioni su quali metodi o classi attuare un refactoring, per ci sentiamo di affermare che sarebbe utile rivedere se le classi copiate e incollate non contengano metodi o attributi superui o non del tutto consoni al ruolo che occupano. 7.4 considerazioni finali su jasperreports

Riguardo allanalisi con Dude su JasperReports, il tasso di clonazione riportato alto: la maggior parte delle duplicazioni riscontrate appartengono alla tipologia modied, poich la gran parte delle linee di codice presentano una struttura semantica uguale ma differente nomenclatura delle variabili. 7.5 considerazioni finali su dude

Dude, come il nome stesso suggerisce, ha come funzionalit principale lindividuazione di codice replicato. E come funzionalit, ha solo questa, anche se in tre modi 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 vericare che i risultati degli altri tool fossero consistenti nella ricerca di cloni, ci riteniamo pi che soddisfatti del tool.

7.6 dettagli tecnici

139

7.6 7.6.1

dettagli tecnici Congurazione macchina utilizzata

s-1 MS Windows 7 x64 bit Intel Core Duo 2.40 GHz 4.00 GB
Tabella 20: Congurazione macchina utilizzata per lutilizzo di Dude

7.6.2

Tempistiche di analisi

Dude ha impiegato 1.58 m per analizzare lultima 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 o superiore[Oracle, a]. 7.6.5 Bug

Non sono stati riscontrati bug durante lutilizzo del tool. Unico difetto visibile il mancato funzionamento dei tasti di chiusura dei sotto-men.

7.6 dettagli tecnici

140

7.6.6

Documentazione

La documentazione presente nel software risulta esauriente[Wettel, b]. Descrive in 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 ufciale di Dude

Parte II ANALISI DI CRISP

A N A LY S T 4 J

Analyst4j offre un ambiente di analisi per vericare la qualit del codice con laiuto di metriche software automatizzate, graci e documenti. Le metriche a disposizione offrono diversi parametri di qualit del software target, che sono di grande utilit per valutare e capire la qualit del codice. Analyst4j garantisce un uso efcace delle metriche, fornendo uno strumento di ricerca automatica tramite metriche predenite. 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 alle metriche software. Valuta la manutenibilit corrente del progetto e trova aree dove poter applicare miglioramenti (refactoring) per garantire buona manutenzione futura. Aiuta a stimare lo sforzo della fase di testing sulla base di parametri quali la complessit ciclomatica e lo sforzo di Halstead. 8.1 analisi

Purtroppo i nostri sforzi profusi per richiedere una versione full (trial) del tool sono stati vani. Ed per questo che abbiamo deciso di utilizzare la versione free sul progetto Crisp, date le sue ridotte dimensioni. le analizzabili (soltanto 50 les). Analyst4j verr utilizzato inizialmente sulla versione di Crisp consegnataci allinizio del progetto di Progettazione e Sviluppo Software, in maniera tale da poter capire dove (se necessario) effettuare operazioni di refactoring, cos da iniziare il lavoro su una applicazione ben progettata e strutturata. Cos facendo infatti non impareremo soltanto ad utilizzare il tool, ma i risultati prodotti saranno realmente utili per un lavoro futuro di refactoring dellapplicazione la quale tuttora in fase di progettazione. 8.1.1 Analisi progettuale - Anti-Pattern

Analyst4j, a differenza di molti altri tool analizzati, offre unauto analisi degli anti-pattern precaricati. dal team di Code Swat, ma permette allutente di crearne dei propri. Gli anti-pattern riconosciuti in automatico sono quelli presenti nellimmagine seguente. Eseguendo lanalisi scopriamo che il codice del software Crisp possiede due anti-pattern.

142

8.1 analisi

143

Figura 110: Anti-pattern in Analyst4j

Il primo lo Zero Encapsulation Classes che afferma che esistono alcune classi 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 unaltra classe di essere modicata senza passare da metodi propri (come ad esempio setter). Il tool ci dice anche che sono presenti 9 occorenze di questo anti-pattern nel codice sorgente di Crisp.

Figura 111: Zero Encapsulation Classes

Se andiamo ad investigare nel codice per scopriamo che alcuni sono pi che legittimi dato che sono classi che vengono autogenerate dal compilatore per far si che parlino in maniera diretta. Ulteriore anti-pattern visibile il Procedure Oriented Design che a differenza dellObject Oriented Design (OOP), si focalizza principalmente sulle funzioni e sulle procedure che operano sui dati, oltre a seguire un approccio Top Down. Come possiamo vedere dalla gura seguente, le occorrenze di questo antipattern sono ridotte (soltanto 3). Date le ridotte dimensioni dellapplicazione target decidiamo di creare una nostra metrica. Tramite la funzione Analyst Search possiamo creare delle query basandoci persino su anti-pattern gi formulati allinterno 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 (se su un metodo, una classe, un package, etc. ) e persino modicare o introdurre

8.1 analisi

144

Figura 112: Procedure Oriented Design

qualsiasi metrica presente nella viste per rilevare i code smell (Metrics-Peer Comparison e Swat Index - Descendants Comparison ). Come possiamo notare in gura 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 gura sottostante.

Figura 113: Query - Analyst4j Searches

Vediamo ora i risultati della ricerca. Come possiamo notare dalla gura sottostante abbiamo tre classi candidate ad essere Data classes.

Figura 114: Candidate Data Classes

Notiamo subito che tutte e tre le classi appartengono allo stesso le. Questo fattore aumenta ancor di pi la possibilit che siano data classes. Inoltre dal path notiamo che il le in questione lR ovvero il le che viene automaticamente generato dal compilatore java-Andorid. Vediamo che la complessit ciclomatica

8.1 analisi

145

dei loro metodi 0 e il numero di parametri supera largamenta la nostra soglia prestabilita. Investigando, apriamo le singole classi e scopriamo di essere difronte a delle vere e proprie data classes, come si evince dalla gura sottostante.

Figura 115: Data Classes

8.1.2

Analisi programmativa - Code Smell

Analyst4j offre una quantit di informazioni straordinaria riguardo lanalisi programmativa di un software. La quantit di metriche cos elevata che la schermata iniziale 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 su quelle pi signicative. Innanzitutto bisogna sapere che tutte le metriche possono essere applicate allintero progetto o ai singoli package. Questo permette di velocizzare la ricerca di disarmonie. Se noi inizialmente analizziamo lintero progetto, possiamo facilmente notare la posizione delle disarmonie per poi andarle a visionare in dettaglio. Iniziando lanalisi con Analyst4j ci compare subito una info-box chiamata Analysis Report contenente informazioni utili sullanalisi appena effettuata e

8.1 analisi

146

sullarchitettura del progetto analizzato. Come possiamo notare in gura 116, abbiamo informazioni riguardanti la copertura dellanalisi. Nel nostro caso sono stati analizzati 12 le su 13. La classe ViewSetActivity inaspettatamente non stata analizzata. Abbiamo cercato di scoprire il motivo, ma anche andando a vedere il codice sorgente non si nota una sostanziale differenza dalle altre classi sia dello stesso package che dellintero progetto. Continuando con lanalisi passiamo a visualizzare il men Code Quality, che ci 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 piccola entit. Il resto delle metriche riportate verranno successivamente analizzate perch contenute in unaltra vista pi completa. Passiamo quindi al men Duration che permette di visualizzare il tempo utilizzato dal tool per effettuare lanalisi del software. Considerando le dimensioni del software non possiamo sbilanciarci sulle performance del tool dato che il numero di le analizzati soltanto 13, rispetto un software medio grande come JasperReports che conta migliaia di les. 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 base del progetto (suddivisione in base ai packages) e di selezionare lo scope su cui visualizzare le informazioni precedentemente prodotte. Notiamo subito una imprecisione, che inizialmente ci insospettisce sul corretto funzionamento del tool.

8.1 analisi

147

Figura 117: QA Scope View

Infatti come possiamo notare in gura117, il package reports viene riportato per ben due volte. Analizando pi in dettaglio pero possiamo vedere come il contenuto dei due package sia differente. Analyst4j in questo caso non ha assolutamente commesso un errore. Questo perch il software che si sta analizzando possiede un package che viene automaticamente creato dal compilatore Android, e che viene il pi possibile nascosto allo sviluppatore. Continuando con lanalisi passiamo a visualizzare la vista Metrics-Peer Comparison la quale assomiglia molto allAnalysis Reports visto in precedenza.

Figura 118: Metrics - Peer Comparison

Queste metriche forniscono moltissime informazioni molto speciche, le quali possono essere utili a programmatori esperti che le utilizzano tutti i giorni. Secondo noi questa vista possiede delle forti potenzialit poco sfruttate, dato che diviene difcoltoso accorgersi di una disarmonia a colpo docchio. Sarebbe preferibile che il software colorasse gli indici in maniera tale da capire indicativamente se il valore nella norma o potenzialmente pericoloso. Scandendo uno ad uno i vari valori ci accorgiamo che la maggior parte sono perlopi positivi, infatti notiamo che ad esempio la media della complessit ciclomaticadi ogni metodo del progetto 1.61.

8.1 analisi

148

Questo valore altamente al disotto del limite ideale proposto da McCabe, il quale raccomandava che i programmatori contassero la complessit dei moduli in sviluppo, e li dividessero in moduli pi piccoli, qualora tale complessita superava 10, anche se in certe circostanze pu essere appropriato rilassare tale restrizione e permettere moduli con una complessit anche di 15. Essendo per una media sarebbe utile scoprire il valore massimo per essere certi di non avere metodi nel progetto con una complessit cicolmatica eccessiva. Con grande stupore ci accorgiamo tramite la vista Swat Index - Descendants Comparison che un metodo contenuto nel package Reports ha complessit 11, come possiamo notare in gura 122.

Figura 119: Swat Index - Descendants Comparison

Questa metodo si chiama parseXml e fa parte della classe Parser. Notiamo che lidenticativo del metodo viene colorato di rosso da Analyst4j per aiutarci nella ricerca del metodo con complessit massima. Con un doppio click sul metodo, appare il codice sorgente, il quale, come possiamo notare, contiene moltissimi code smell visti a lezione. Leggendo il codice ci accorgiamo subito della presenza di linee di codice commentate. Questa pratica un sottogruppo del code smell Too Much Documentation. Infatti in questa classe notiamo una formattazione dei commenti insolita ed inutile, per non parlare appunto delle righe di codice che non dovrebbero nemmeno essere presenti sotto forma di commento (gura 120).

Figura 120: Too Much Documentation

Notiamo inoltre nel metodo parseXml il code smell Empty catch clauses, che comporta la presenza nel codice di clausole di catch o nal senza nessun corpo. Questa pratica molto utilizzata per far compilare il codice in maniera veloce

8.1 analisi

149

senza preoccuparsi delle exception che potrebbero sorgere. Purtroppo mettendo un blocco di catch vuoto si permette certo di compilare ma cos facendo non si gestisce lexception che potrebbe scaturire e quindi perde completamente di signicato lutilizzo di un blocco try-catch (riquadro verde in gura 121).

Figura 121: Empty catch clauses

Vedendo la quantit di code smell pi o meno gravi posseduti da questo metodo ci sentiamo di dire che sarebbe consigliato eseguire un refactoring completo sul metodo parseXml soprattutto per la sua complessit ciclomatica. Fortunatamente questo metodo era gi previsto che venisse smantellato dato che nelle prossime versioni di Crisp non verranno pi analizzati le Xml. Gli ulteriori valori presenti nella vista Metrics - Peer Comparison sono del tutto positivi, infatti il codice non possiede classi con profondit preoccupante, e nemmeno variabili istanziate ma non utilizzate. Persino il livello di mantenibilit molto elevato. Lunica disarmonia che possiamo notare, oltre a quelle precedentemente citate, riguarda il rapporto tra le linee di codice e il numero di linee di commenti. Infatti possiamo vedere che quasi il 40% delle linee scritte nel progetto siano commenti. Questa cifra per leggermente falsata, dato che basta vedere le classi per accorgersi che i commenti non sono sempre stati scritti in formato standard e spesso occupano pi righe anche se il contenuto scarso ( riquadro rosso gura 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 si voglia condividere il loro utilizzo. In questo caso, andando ad indagare, la scelta di utilizzare public limitata ai metodi setter e getter e a costruttori. Dunque non possiamo riconoscere nessun code smell, dato che si operato in maniera non opinabile. Passiamo ora allutilizzo della vista Swat Index - Descendants Comparison. Anche questa vista possiede uningente quantit di informazioni che vanno elaborate per comprendere la loro utilit a riconoscre code smell. Possiamo subito notare che a differenza della precedente vista, questa fornisce per ogni voce, oltre al valore medio, anche quello massimo e quello minimo. Questa vista risulta dunque pi utile a riconoscere in maniera pi veloce i possibili

8.1 analisi

150

Figura 122: Swat Index - Descendants Comparison

code smell presenti. Questa vista risulta utile una volta consultata quella precedente. Infatti, dopo aver trovato una possibile disarmonia, possiamo restringere lo scope e approfondire la ricerca tramite la visualizzazione dei valori specici mediante la vista Swat Index - Descendants Comparison. Infatti se notiamo bene, il tool evidenzier sempre lentit con il valore pi alto della metrica selezionata. Se lo scope riferito allintero progetto, la vista ci permetter di vedere il package contenente lentit con il valore pi alto della metrica selezionata (come visto precedentemente per il metodo parseXml). Possiamo persino restringere il campo alla singola classe o al singolo metodo. Ovviamente in base allo scope che gli si attribuisce vengono modicate le metriche disponibili. Questa vista, come la precedente, possiede una funzionalit molto utile chiamata Comparison Report che permette di creare dei report in formato Microsoft Word, contenenti le informazioni mostrate nelle viste.

8.1 analisi

151

Figura 123: Comparison Report

Queste metriche inizialmente possono sembrare poco chiare, a causa dei loro nomi concisi e a volte troppo specici. per questo motivo che Analyst4j possiede una piccola guida che spiega le metriche presenti nelle diverse viste dellintero tool (vedi gura 124).

Figura 124: Notes view

Ulteriori metriche offerte dal tool per facilitare il lavoro di riconoscimento di

8.1 analisi

152

disarmonie sono contenute nel men Comparison Analysis. Difatti come possiamo notare dallimmagine sottostate, questo men permette di mettere a confronto le metriche precedentemente analizzate, in maniera tale da poter ricavare alcune informazioni 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 graco comparativo che pu essere visualizzato in due differenti modi, in base alle preferenze dellutente (Line Chart o Scatter Plot). Partendo dalla prima voce, notiamo che cliccando sulla metrica compare un graco 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 nei metodi, aumenta anche la complessit ciclomatica. Questa vista ci informa inoltre del massimo valore di complessit ciclomatica dei metodi del progetto.

Figura 126: NLOC vs CC

Dato che da questa vista non compaiono disarmonie evidenti, possiamo passare alla Unstructuredness vs Documentation. Questa vista ci mostra il numero di righe di commento rapportato alla complessit del metodo. Sarebbe buona norma avere pi righe di commento quando i metodi sono complessi, ma come possiamo notare, in Crisp avviene lesatto contrario. Infatti possiamo notare come i metodi con complessit 1 possiedono molte pi righe di codice di metodi con complessit anche 6 volte superiore (vedi gura sottostante).

8.1 analisi

153

Figura 127: Unstructuredness vs Documentation

Passiamo poi ad analizzare la metrica che indaga sul numero di linee di commento rapportato al numero di linee di codice. Qui possiamo notare come allaumentare del numero di linee di codice aumentano anche i commenti. Esistono per dei casi anomali come ad esempio il metodo refreshDir che possiede pi linee di commento che linee di codice (cerchio verde in gura 128).

Figura 128: NLOC vs NOCL

In questo caso scopriamo che infatti allinterno del metodo, i commenti sono perlopi 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 analisi

154

sono poco signicative a causa delle loro piccole dimensioni e del loro numero ridotto. Vediamo una metrica molto utile e poco presente negli altri tool di reverse engineering. Questa metrica mette a confronto la mantenibilit del codice con lo sforzo per crearlo. Utilizza la metrica di Maurice Halstead [Maurice] per determinare 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 maniera inaspettata, infatti pi c voluto sforzo per creare il le e meno mantenibile. In effetti, pensandoci bene, se un le ha richiesto pi tempo per essere sviluppato, pu essere comprensibile pensare che sia pi complesso di uno che ne ha richiesto di meno. Dunque non possiamo trarre molte considerazioni solo da questa metrica. Andrebbe analizzata anche la complessit ciclomatica del le per essere sicuri di questa supposizione. Passiamo ora ad analizzare le metriche del men Distribution Analysis. Come possiamo notare nella gura sottostante, Analyst4j, anche in questo caso, ci offre una quantit esorbitante di metriche, anchesse come le precedenti, esportabili in report esplicativi.

Figura 131: Distribution Analysis

8.1 analisi

155

Passeremo in rassegna soltanto alcune di queste metriche, quelle pi signicative, per rimanere il pi sintetici possibili. Analizzando il primo graco riguardante la complessit ciclomatica notiamo che le supposizioni su una elevata complessit ciclomatica in un metodo effettuate prima, vengono palesemente smentite dato che lautoriconoscimento di metodi complessi attribuisce alla maggior parte dei metodi del progetto un basso rischio. Sono solo 11 i metodi che hanno un rischio moderato, ma che non ci impensieriscono 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 modicare i bounds che determinano le classi di rischio (questa funzionalit presente in ogni chart di Analyst4j).

Figura 133: Essential Complexity

Cambiando scope passiamo ora ad analizzare alcune metriche relative alle classi, in particolare alla metrica Lack of cohesion of methods. Analizzando il graco 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 lessenza della stessa. Anche questa vista evidenzia che una buona parte delle classi possiedono unimpronta Procedure Oriented Design.

8.1 analisi

156

Figura 134: Lack of cohesion of methods

Vediamo anche come la gran parte delle classi presenti nel progetto non possiede Inner Class. Questa volta visualizzeremo il graco a forma di report per sottolineare la potenza di questo tool.

Figura 135: Inner Class

Inne notiamo che la stabilit di ogni package notevolmente positiva, come possiamo vedere nella gura sottostante.

8.2 suggerimenti per migliorare il tool

157

Figura 136: Packages Instability

8.2

suggerimenti per migliorare il tool

Analyst4j senzaltro 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 visualizzare semplicemente la struttura del progetto analizzato (con al massimo alcune 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 autoidenticazione delle metriche con valori fuori norma. appurato che non esistono dei valori precisi per constatare che il valore di una determinata metrica normale o anomalo. Per per alcune metriche esistono dei valori che possono portarci a delle conclusioni pi o meno certe sulla presenza di disarmonie nel codice sarebbe consigliabile far si che per quelle metriche, i valori fuori scala venissero evidenziati di rosso in maniera tale da facilitare la ricerca di disarmonie nel software. 8.3 suggerimenti per migliorare crisp

Essendo Crisp un software di piccole dimensioni, gli anti-pattern e i code smell rilevati sono molto pochi. Tramite lutilizzo di Analyst4j possiamo di certo affermare che: I commenti presenti non sempre seguono formattazioni standard (es. Doxygenlike). Esistono molti blocchi di codice sorgente commentati, alcuni sono palesemente sistemi rudimentali di testing dimenticati poi nella versione nale.

8.4 considerazioni finali su crisp

158

si pu pensare di introdurre almeno un commento nellintestazione di ogni classe, o ancor meglio nellintestazione 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; si pu pensare di eliminare le linee di codice commentate. La presenza del code smell Empty Catch Clause, ovvero la presenza nel codice di clausole di catch o nal senza nessun corpo non permette di gestire lexception che potrebbe scaturire e quindi perde completamente di signicato lutilizzo di un blocco try-catch. sarebbe preferibile introdurre il corpo di ogni blocco try-catch, in maniera tale da poter gestire leventuale exception nel migliore dei modi. La presenza di una complessit ciclomatica superiore a 10 potrebbe condizionare la manutenibilit del sistema. Inoltre esiste una relazione tra elevata complessit e bassi livelli di coesione la quale si basa sul fatto che un modulo con pi punti decisionali generalmente implementer pi di una singola funzione ben denita [Stein, 2005]. Alcuni studi hanno trovato una forte relazione tra la complessit ciclomatica e il numero di errori nel codice. Moduli che hanno elevata complessit tendono a contenere un numero elevato di errori. 8.4 8.4.1 considerazioni finali su crisp Tramite Analyst4j

In denitiva lanalisi attraverso Analyst4j ha dato buoni frutti evidenziando poche disarmonie nel codice che non condizionano in maniera evidente il funzionamento dellapplicazione. Possiamo dire che i maggiori difetti del software possono essere attribuibili ad una scarsa capacit da parte dello sviluppatore di commentare in maniera standard il codice e ad alcuni metodi programmativi poco consigliati ma che non limitano in maniera evidente lutilizzo e il corretto funzionamento del software. Un fattore abbastanza rilevante che pu preoccupare, la complessit ciclomatica della classe Parser, che al di sopra di una ipotetica soglia di accettabilit. 8.5 considerazioni finali su analyst4j

Possiamo denire Analyst4j come uno dei pochi tool completi e autosufcienti per analizzare in maniera efcace un progetto Java. Mette a disposizione dellutente uninnit di metriche, anti-pattern, ltri, diagrammi, report che permettono in

8.5 considerazioni finali su analyst4j

159

breve tempo di notare le disarmonie pi palesi, e di approfondire in maniera pi dettagliata quelle meno evidenti. Inoltre offre funzionalit avanzate per lanalisi della mantenibilit del codice e del version comparison. I pregi sostanziali sono: facilit di installazione; icone molto intuitive e facilmente ricollegabili allazione a loro attribuita; non richiede meta-le per eseguire le analisi, ma soltanto del codice sorgente; presente sia la versione stand-alone che quella basata sul Framework di Eclipse; possibilit di modicare 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 spiegazioni utili riguardanti metriche e funzionalit implementate; grande quantit di metriche disponibili; grande quantit di anti-pattern auto-riconoscibili; possibilit di memorizzare impostazioni preferenziali dellutente; possibilit di creare, per qualsiasi metrica o vista, report informativi, in diversi formati (pdf, doc, ...); possibilit di utilizzare pi ltri contemporaneamente; elevata facilit di utilizzo; possibilit di creare ltri 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 spiegazione della metrica utilizzata. Mentre i suoi difetti sono: non open-source, anche se il suo costo per licenza singola di soli 137 ;

8.6 dettagli tecnici

160

mancanza di viste polimetriche con riferimento a dipendenza intra-entit; utilizzabile soltanto su progetti Java; utilizzabile soltanto su progetti open-source o di cui si possiede il sorgente. 8.6 8.6.1 dettagli tecnici Congurazione macchina utilizzata

Qui di seguito abbiamo una tabella contenente la congurazione della macchina utilizzata per testare Analyst4j. s-1 Ms Windows 7 x64 bit Intel Core Duo 2.40 GHz 4.00 GB Eclipse Helios Versione 3.5.0
Tabella 21: Congurazione S-1 macchina utilizzata per Analyst4j

8.6.2

Tempistiche di analisi

Segue una tabella con il valore tempistico dellanalisi sullultima versione di Crisp. configurazione S-1 crisp 4 sec

Tabella 22: Tempistiche di analisi con Analyst4J 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;

8.6 dettagli tecnici

161

Eclipse 3.1 o superiore. Requisiti hardware: Intel Pentium III 1.0 Ghz; 256 MB ram; 150 MB hard disk. Lunica limitazione percepibile della versione standalone riguarda il sistema operativo che deve essere perforza Windows, ma ricordiamo esiste la versione plug-in per Eclipse. Versione standalone Non esiste installazione per la versione standalone dato che un eseguibile. 1. download; 2. decomprimere la cartella; 3. lanciare leseguibile analyst4j.exe. Versione Eclipse plug-in Linstallazione di Analyst4j molto semplice, grazie al fatto che un plug-in di Eclipse. 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/a4j/update/ . In nessuna congurazione stato riscontrato un malfunzionamento o una mancata installazione. 8.6.4 Bug

Durante lutilizzo del tool non stato riscontrato alcun bug. Unico evento anomalo riscontrato stato durante lanalisi, in cui un le stato escluso dal processo di elaborazione.

8.6 dettagli tecnici

162

Figura 137: Tutorial di installazione

8.6.5

Documentazione

Analyst4j offre una documentazione dettagliata, molto chiara ed approfondita con molti esempi. Code Swat, lazienda produttrice di Analyst4j mette a disposizione: un tutorial on-line per effettuare linstallazione di Analyst4j Standalone Version; un tutorial on-line per effettuare linstallazione di Analyst4j - Eclipse Plugin; unottima guida incentrata sullutilizzo di tutte le funzionalit e metriche incorporate nel tool; unottima spiegazione sugli anti-pattern riconosciuti dal tool; unottima 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 a disposizione; delle analisi complete gi svolte su un software demo; dei tutorial video;

8.6 dettagli tecnici

163

informazioni aggiuntive su ulteriori espansioni e feature; Tutta la documentazione disponibile sul sito ufciale Code Swat in forma gratuita [Swat, b].

Figura 138: Sito ufciale di Analyst4j

Parte III CONCLUSIONI FINALI

CONCLUSIONI

9.1

tool analizzati

I tool adoperati per questa relazione sono i seguenti: CodeCity Manhattan Bauhaus Lattix XRay SA4J Analyst4j Dude Oggetto principale dellanalisi 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 Analyst4j. Lo stile lavoro stato il seguente: per ogni tool, si esegue unanalisi approfondita della versione pi recente, ed unanalisi evolutiva portata su tutte le versioni sopracitate, in ottica comparativa. 9.2 considerazioni finali su jasperreports

Durante la relazione, abbiamo dato un giudizio danalisi sul software, rispetto ad ogni tool adoperato. Quel che emerge, un parere positivo. In particolare, di JasperReports si apprezza la struttura del diagramma package, specie dalla

165

9.2 considerazioni finali su jasperreports

166

release 1.0.0 alla 3.0.0, ed il fatto che il codice in generale non sia stato stravolto ad ogni release, ma si evoluto con il sorgere della necessit di nuove funzionalit. Da ciascuna singola analisi si evince che sono principalmente due le note negative: la mancanza di commenti nel codice e il panorama delle dipendenze nellultima release. La mancanza di commenti, non una vera e propria costante lungo larco 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 prima versione, anche se spostate in altri package, rimangono non commentate, mentre le nuove aggiunte presentano un commento minimo, nellintestazione 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 di mantenersi al minimo indispensabile. Analizzando la 4.0.2, da tre tool in particolare abbiamo campanelli dallarme: Lattix LDM ci fa notare un balzo in avanti del coefciente dinterdipendenza,il Coupling, SA4J indica un anti-pattern Tangle ed il Class Dependency Diagram fornito da X-Ray, se confrontato con i quattro precedenti, di per se eloquente. Pur avendo mantenuto unarchitettura package ordinata, con lultima versione sono aumentati esponenzialmente i collegamenti tra classi lontane nellalbero: il "gomitolo" che appare con X-Ray la struttura graca che testimonia lanti-pattern Tangle individuato da SA4J, e Tangle appunto signica groviglio in inglese. Lattix avvalla la tesi di questa situazione preoccupante sulle dipendenze fornendoci la metrica Coupling, e la semantica rimane la medesima: la percentuale delle coppie 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 linee di codice. Non possiamo conoscere quali siano le logiche progettuali che guideranno lo sviluppo nei prossimi anni di questo progetto, ne possiamo conoscerne il vero stato di salute: un progetto pu essere ben fatto ma non essere pi il prodotto di punta, o comunque quello su cui si vogliono concentrare gli sforzi del team. Pensiamo che dalla penultima allultima versione analizzata i cambiamenti siano stati grandi, ma sarebbe da chiedersi se la situazione corrente accettabile: potrebbe essere, nonostante un grafo delle dipendenze molto connesso, che il team sia soddisfatto della progettazione e voglia continuare su questa strada, per esempio essendo in grado di difendere la scelta giusticando con prestazioni elevate od una migliore navigabilit. Altres possibile che un refactoring sia pianicato, per raggiungere un compromesso tra buone indicazioni di 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 incanalato lo sviluppo da un piano artigianale-individuale verso la prospettiva teamwork. Ultimo consiglio quindi unanalisi anti-pattern approfondita, ad esempio con un

9.3 considerazioni finali su crisp

167

tool come Analist4j, al ne di mettersi nella condizione di proseguire lo sviluppo partendo da una base solida, per non rischiare di trascurare situazioni per ora non 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 lultima release, la 4.0.2, registra un peggioramento in termini di grafo delle dipendenze. Detto ci, importante capire che questo peggioramento, pur essendo lecito ritenerlo globale perch il grafo delle dipendenze interessa relazioni rispetto allintero albero, non implica necessariamente peggioramenti ad altre metriche, che invece anzi possono anche risultare migliorate. Questo il caso, volendo fare un paio di esempi, della ciclicit 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 precedentemente erano entit uniche sono state successivamente partizionate in moduli pi piccoli, e pi gestibili. Per quanto riguarda la ciclicit, abbiamo constatato con SA4J che lanti-pattern Tangle rimane una realt, anche nellultima release; ma esaminando il progetto con Bauhaus, siamo piacevolmente sorpresi dai graci dei cicli: la situazione appare molto migliorata in questo senso, e quindi cresce uidit di esecuzione nonch la comprensibilit della strutturazione. Da ci giungiamo, ancora una volta, alla conclusione che non corretto dare giudizi di massima o affrettati sui progetti che analizziamo, ma auspicabile contestualizzarli e renderci conto che, talvolta, la situazione pu peggiorare in un senso ma migliorare per altri. 9.3 considerazioni finali su crisp

Il progetto Crisp un progetto di mobile application di piccole dimensioni, sviluppato nellarco di un periodo di stage di tre mesi, presso il laboratorio DISCo SAL. Date le sue ridotte dimensioni il reverse engineering potrebbe essere operato esaminando direttamente il codice. Il parere positivo, a giudicare da quel che ci suggerisce lottimo Analist4j; preoccupa solamente la classe Parser, che ha una complessit ciclomatica alta ed caratterizzata da funzionalit eterogenea, non si occupa solo di parsing ma anche per esempio della persistenza dei report. 9.4 considerazioni finali sui tool

Premettiamo che non corretto individuare il tool migliore in assoluto, poich diversi sono gli ambiti in cui uno strumento pu aiutarci. Le due categorie base sono il forward ed il reverse engineering, e seppur il corso, e di conseguenza questa

9.4 considerazioni finali sui tool

168

relazione, sono stati orientati maggiormente alla seconda, tra i tool analizzati alcuni possono ben essere utilizzati durante il processo di sviluppo. importante, pensiamo, che uno sviluppatore abbia un parco di strumenti ben collaudato e con il quale ha condenza per affrontare diversi task, e con le seguenti considerazioni vogliamo presentare una possibile squadra di lavoro: Analist4j con X-Ray per il reverse engineering, Manhattan e possibilmente Lattix per aiutarsi con lo sviluppo-forward. 9.4.1 Reverse: Analist4j, X-Ray

Analist4j ha convinto pienamente il gruppo, che ha avuto modo di adoperarlo purtroppo solo su un progetto limitato come Crisp, per via delle restrizioni della licenza free, lunica che stato possibile ottenere. La ricetta vincente unalta usabilit per il ricco numero di funzionalit offerte, soprattutto in riferimento allanti-pattern Detection, funzionalit rara perch sostanzialmente un task complesso nella maggior parte dei casi. Completano la panoramica delle funzionalit che spiccano le metriche, anche personalizzabili con un articolato sistema di query, unaccurata gestione dei report, ed il version comparison. Inoltre, pregi del programma sono lelevata documentazione presente, la scalabilit, apprezzabile analizzando un progetto esteso come ad esempio JasperReports, ed il costo della licenza che, volendo comparare a quello di altri tool anche commerciali, non altissimo a fronte delle funzionalit offerte. disponibile sia standalone sia come plugin per Eclipse, cosa molto importante se pensiamo alla potenza di un ambiente di sviluppo unico, modulare e dove i tool sono a contatto col codice. X-Ray un tool che il gruppo ha gi avuto modo di analizzare prima dello svolgimento di questa relazione, per le slide da presentare in aula. Integrato in Eclipse, poche funzionalit ma intuitive nellinterpretazione, rilevanti per valutare la salute del progetto ed immediate da utilizzare: questi sono i motivi che ci hanno convinto a promuovere a pieni voti questo tool, sviluppato come progetto di laurea alluniversit di Lugano. Pensiamo che sia un utile completamento al lavoro di Analist4j, ed stato molto utile per esempio nel far saltare subito allocchio la discontinuit progettuale tra la versione 3.0.0 e 4.1.2, avallata poi anche dai dati quantitativi degli altri tool. 9.4.2 Forward: Manhattan, Lattix

Manhattan un progetto giovane, anchesso frutto di uno stage di laurea, e si ispira a CodeCity. Ha sorpreso chi ha potuto utilizzarlo a fondo, soprattutto in virt di alcune funzionalit tanto rilevanti durante lo sviluppo quanto rese in modo efcace e non ambiguo tramite linterfaccia graca del programma. Anchesso Eclipse-aware, punto sempre a favore, e tra le funzionalit interessanti accennate laggiornamento della cittadina delle classi in tempo reale, la notica graca nel caso di potenziali conitti di modica in un progetto condi-

9.4 considerazioni finali sui tool

169

viso, funzionalit che lo proiettano anche in unottica forward. Altre accortezze potenziano la user experience: non c necessit di adoperare metale o strumenti esterni, ed i graci costruiti rimangono memorizzati per evitare re-build alla riapertura di un progetto. Lattix un software da promuovere, se non altro per la potenza e loriginalit dellapproccio DSM allanalisi ed il grande numero di metriche calcolate per quanto riguarda il reverse, ma pu volendo anche essere adoperato per lottica forward. Il suo sistema di impostazione e verica di regole pu essere utilizzato per guidare lo sviluppo in modo semplice ma anche abbastanza rigido, per evitare che il team di programmatori non si attenga alla progettazione dellarchitetto. Abbiamo qualche problema con la scalabilit e lusabilit, ma con un p di pratica Lattix diventa un buon tool. 9.4.3 La coerenza dellanalisi: punti discordanti tra i risultati

Se consideriamo lintero numero di funzionalit (calcolo di metriche, graci 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 una primissima impressione del progetto in analisi, indipendentemente dallo scope principale del tool. E il caso di metriche architetturali come il numero di package, classi, linee di codice: riguardo a queste, la risposta dei tool stata omogenea, eccezion fatta per SA4J che, nel conteggio dei package, considera anche cartelle che non lo sono (es. di sistema, con documentazione ecc). Un altro esempio di metriche discordi la disparit tra la percentuale di commenti che CodeCity indica e quella fornita da Bauhaus: probabilmente il valore fornito dal primo non frutto di un semplice conteggio ma di una media pesata. Bisogna stare attenti anche ai termini: CodeCity identica con NOC "Number of classes", mentre X-Ray "Number of children": un valore diverso potrebbe allora essere letto come un errore di uno dei due, quando in realt entrambi sono potenzialmente corretti poich gli acronimi hanno signicato differente. Il suggerimento per ovviare a problemi del tipo il seguente: ssare allinizio dellanalisi un set di tool e ricordarsi che sono gli unici che devono fare fede durante tutto il processo: infatti non siamo sostanzialmente interessati ai valori ed ai graci come statistiche di per s, ma in quanto indicatori che guidino il processo. Se allinterno dei tool scelti una o pi metriche sono proposte con risultati diversi, bisognerebbe ssarsi sul tool che pare migliore a riguardo, o per il quale la denizione della metrica, se illustrata nella documentazione, pi conforme alle nostre esigenze o corretta rispetto alla letteratura. 9.4.4 Da rivedere: SA4J

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 riferimenti a tool non analizzati

170

una "prima scelta" quando si tratta di formare una squadra di tool. La principale pecca linterfaccia graca, come sono presentati i risultati: le viste non possono essere ridotte, e le tabelle forniscono molti dati ma dalla semantica poco chiara e difcile 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 lalbero del progetto aprendo le classi presenti, appaiono alcune classi di comodo dal signicato poco chiaro e lindividuazione degli anti-pattern insospettisce, le disarmonie difatti sono individuate ovunque nel progetto, con troppa frequenza. SA4J bisogna anche dire che un programma non recente ma, essendo sviluppato da IBM ed avendo una ampia user base ci si aspetta che stia al passo con altri progetti, commerciali e non, pi freschi ma anche meno rinomati. 9.5 riferimenti a tool non analizzati

Tra tutti i tool proposti per la scelta dal docente, alcuni hanno funzioni assimilabili, e qui vogliamo brevemente citare qualche strumento non considerato nella nostra relazione ma analogo a quelli da noi scelti, per evidenziare analogie. Uno dei tool che abbiamo maggiormente apprezzato X-Ray, specie per la sua class dependency view. Codecrawler [Lanza] il padre di X-Ray, che costituisce la corrispettiva versione per Eclipse, sviluppato dal Prof. M. Lanza, dellUniversit di Lugano. Non vediamo per motivi particolari per preferire questo tool ad X-Ray, se non altro perch Codecrawler un progetto vecchio, proseguimento di Moose [Unibe] infatti, e riteniamo molto importante lintegrazione con Eclipse: perch dovremmo scegliere un tool che fa le stesse cose ma ha lo svantaggio di non essere integrato? Un tool che ci parso interessante Understand, e lipotesi dutilizzo sarebbe afancarlo a Lattix LDM. Il motivo di questa scelta che troviamo afnit tra questi due software: entrambi prestano molta attenzione al concetto di dipendenza, Lattix tramite la matrice DSM, Understand attraverso il graco Depends on; sia Lattix sia Understand forniscono varie metriche di analisi, ma il secondo aggiunge anche graci associati ad esse; gestione di report: in Understand per i report sono compositi e di livello superiore. Siamo quindi in presenza di due tool concettualmente differenti ma progettati per soddisfare unesigenza comune: guidare lesame di un progetto accostando metriche numeriche a rappresentazioni grache, pi immediate. In questo senso, non dimentichiamoci di JDepend anche: integrato in Eclipse, fornisce metriche che anche Lattix vanta (es. distanza sequenza principale) ma con relativo graco annesso, ed orientato allisolare conitti rispetto al rischio di ciclicit, cosa che

9.6 la stesura di questo documento

171

in Lattix non si pu fare direttamente, poich bisogna integrare linformazione degli score cyclicality alla matrice DSM. Tutti i tool che abbiamo analizzato nella relazione e citato in questa sezione sono stati pensati espressamente per analizzare progetti software, principalmente Java, che si imposto come il linguaggio OO per eccellenza. Daltro canto per, un sistema software , pi genericamente, un sistema denito spazio dinformazione, assimilabile in questo, per esempio, ad unontologia. Lunico tool di valore che si trovato per lanalisi di questa gerarchia SHriMP, ed esso supera i tool precedenti non tanto nella funzionalit, ma dalla potenza che deriva dallastrazione: analizzare un software da una prospettiva pi alta d adito a servirsi di altri concetti e chiavi di lettura che normalmente non ci si aspetterebbe di applicare. 9.6 la stesura di questo documento

Scrivere una relazione lunga e complessa ad otto mani, presenta varie difcolt: concordare una formattazione comune; gestire gli aggiornamenti del documento. Grazie soprattutto alla stesura delle nostre tesi, abbiamo imparato a conoscere ed A apprezzare L TEX, cui pregi sono soprattutto la grande disponibilit di componenti aggiuntivi per curare ogni singolo aspetto del documento, lessere un linguaggio rigoroso che libera dal paradigma WYSWYG e, non ultimo, quello di avere una numerosa base utenti essendo oramai quasi uno standard universale per la stesura di documenti scientici. A Una critica che si potrebbe per fare alladottare uno strumento come L TEX la necessit di dover imparare un linguaggio e pi in generale un certo approccio alla scrittura, e ci, se si stretti coi tempi, costituisce sicuramente un problema. La scelta del gruppo stata quindi quella di una via media, rappresentata dalla A scelta di LYX [Lyx]: questo programma permette di scrivere un documento L TEX con una sintassi pi semplice ed aiuta fornendo un alto numero di macro da inserire automaticamente. Permette inoltre di importare le .tex cosicch integrare A codice L TEX scritto a mano non costituisce un problema. Quando si lavora alla stesura di documento scritto nei modi illustrati, quel che si gestisce un insieme di le di testo, e si esporta in formati binari solo una volta completato il lavoro, per la presentazione. A questo proposito, un sistema di controllo delle versioni la scelta ideale, ed stato adottato SVN. Un server SVN era gi disponibile e predisposto poich fornito per il modulo della Dott.ssa Micucci, ma non avremmo comunque optato, ad esempio, per CVS se avessimo potuto: questo sistema, che un p il concorrente di SVN, stato conosciuto dalla maggior parte di noi nellesame di Ingegneria del Software alla triennale, ma non ha convinto per vari motivi tra cui, ad esempio limpossibilit di cancellare cartelle.

Parte IV APPENDICE

APPENDICE

In questo capitolo riportiamo alcune tabelle comparative sui tool analizzati nella relazione. Queste tabelle sono state aggiunte per completezza ma, viste le dimensioni delle stesse stato difcile inserirle nelle singole pagine mantenendo una buona leggibilit. Si consiglia pertanto di utilizzare i fogli di calcolo allegati alla relazione per una migliore comprensione. Oltre alle tabelle prestrutturate fornite per riassumere la comparazione dei tool, stata aggiunta una nuova tabella per noi signicativa: il suo scopo valutare per ogni tool il campo di applicazione in cui fornisce i migliori risultati. Ci sembrato valore aggiunto inserire delle voci gi affrontate nelle altre tabelle per avere un quadro complessivo mirato. Il ne ultimo di questa tabella dare a uno sviluppatore uno strumento concreto per scegliere da quali tool farsi assistere nellanalisi e sviluppo partendo dalle proprie esigenze.

173

Figure 139: Feature tools comparison 1

174

Figure 140: Feature tools comparison 2

175

176 Figure 141: Output of the tools comparison

177 Figure 142: Application eld comparison 1

Figure 143: Application eld comparison 2

178

BIBLIOGRAPHY

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 pagina 84.) Project Bauhaus. Bauhaus,software architecture, software reengineering, and program 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 alla pagina 62 e 134.) Cunningham. Cunningham and cunningham incorporated. URL http://www.c2. com. (Citato alla pagina 15.) Norman E. Fenton and Shari Lawrence Peeger. 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 development. 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 A4J, a. URL http://www.alphaworks.ibm.com/tech/sa4j. (Citato alla pagina 114.) IBM. S A4JDownload, b. URL http://www.alphaworks.ibm.com/tech/sa4j/ download. (Citato alla pagina 113.)

179

bibliography

180

B. Kang and J.M. Biemann. Cohesion and reuse in an object-oriented system. Proceedings of the 1995 Symposium on Software, pages 259262, 1995. (Citato alla pagina 6.) Lanza. Code Crawler web-site. URL http://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 alla pagina 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 alla pagina 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 and complexity. Journal of Computer Science, 2(137-144), 2005. (Citato alla pagina 158.) Code Swat. Analyst4J guide, a. URL http://www.codeswat.com/cswat/ index.php?option=com_content&task=view&id=47&Itemid=67. (Citato alla

pagina 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.)

bibliography

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.)