MACXIM: uno strumento per la misurazione di applicazioni Java.
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
MACXIM: uno
strumento per la
misurazione di
applicazioni Java.
Tesi di laurea di: Relatore:
Vincenzo Prof. Vieri
Pandico Del Bianco
Correlatore:
Matricola: Prof. Sandro
612160 Morasca
Dott. Davide
Taibi
Anno Accademico 2007‐2008Università degli Studi dell’Insubria
FACOLTÀ DI SCIENZE MATEMATICHE
FISICHE E NATURALI
Corso di Laurea specialistica in Informatica
MACXIM: uno strumento per la
misurazione di applicazioni Java.
Tesi di laurea di: Relatore:
Vincenzo Prof. Vieri Del Bianco
Pandico
Correlatore:
Matricola: Prof. Sandro Morasca
612160 Dott. Davide Taibi
Anno Accademico 2007‐2008Executive summary Quando si parla di valutazione, si deve prendere in considerazione il fatto che l’analisi può risultare molto difficile, soprattutto quando ad essere presi in esame sono progetti di grandi dimensioni, complessi ed articolati. Si deve considerare il codice scritto, le librerie utilizzate, l’ambiente in cui il prodotto viene sviluppato. Effettuare valutazioni con una metodologia manuale può risultare molto problematico e portare ad errori di stima. Il risultato di questo lavoro di tesi è stato la realizzazione di uno strumento di misurazione che prende il nome di MACXIM (Model And Code XML‐ based Integrated Meter). Questa applicazione permette di effettuare misurazioni metriche su progetti Java in maniera automatizzata. Il lavoro è cominciato a partire dallo studio di cosa si intendesse per misurazioni metriche e come queste potessero essere effettuate sul codice di un progetto. Il codice Java è infatti fonte di metriche, che possono essere utilizzate per misurare la quantità e le qualità del codice prodotto e di conseguenza la produttività del team di sviluppo. L’utilizzo della tecnologia XML per rappresentare le entità da misurare e i risultati delle misurazioni dà a MACXIM la possibilità di integrarsi facilmente con altre applicazioni e di rendere i suoi risultati portabili.
Sommario
Capitolo 1............................................................................................................................ 8
Introduzione ....................................................................................................................... 8
1.1 Obiettivi .................................................................................................................... 9
1.2 Struttura dello sviluppo MACXIM e della tesi........................................................... 9
Capitolo 2.......................................................................................................................... 12
Analisi del codice .............................................................................................................. 12
2.1 Analisi automatizzata e valutazione .......................................................................13
2.2 Qualità .................................................................................................................... 14
2.3 La misurazione del codice ...................................................................................... 15
2.4 Analisi di tipo statico............................................................................................... 17
2.4.1 Revisione del codice ........................................................................................ 18
2.4.2 Dipendenze del codice..................................................................................... 18
2.4.3 Complessità del codice .................................................................................... 18
2.5 Benefici dovuti all’analisi di tipo statico .................................................................19
2.6 Tipologie di analisi ..................................................................................................19
2.6.1 Analisi sintattica............................................................................................... 22
2.6.2 Analisi del flusso .............................................................................................. 22
2.7 Tecniche di analisi del codice................................................................................. 24
2.7.1 Codice sorgente ............................................................................................... 24
2.7.2 Codice compilato ............................................................................................. 26
Capitolo 3.......................................................................................................................... 29
Tecnologie utilizzate .........................................................................................................29
3.1 Java ......................................................................................................................... 29
3.1.1 Caratteristiche e qualità.................................................................................. 29
3.1.2 Linguaggio .......................................................................................................32
3.1.3 Ambiente Java.................................................................................................32
3.2 Abstract Syntax Tree............................................................................................... 33
3.3 XML ........................................................................................................................ 353.4 XQuery e XQueryX .................................................................................................38
3.5 eXist ....................................................................................................................... 40
Capitolo 4.......................................................................................................................... 42
Architettura dell’applicazione .......................................................................................... 42
4.1 Architettura ............................................................................................................43
4.2 MACXIM: descrizione generale............................................................................... 45
4.2.1 Rappresentazione XML di sorgenti Java .......................................................... 46
4.2.2 Rappresentazione XML delle metriche e dei risultati ......................................47
4.3 Flusso delle informazioni: dall’estrazione ai risultati.............................................. 48
4.3.1 Estrazione delle informazioni .........................................................................51
4.3.2 Misurazione del software ............................................................................... 51
4.3.2 Visualizzazione dei risultati ............................................................................. 51
Capitolo 5.......................................................................................................................... 53
Modulo estrazione informazioni ...................................................................................... 53
5.1 Abstract Syntax Tree............................................................................................... 53
5.2 Abstract Syntax Tree: Parsing del codice ................................................................ 54
5.2 Abstract Syntax Tree: Node .................................................................................... 55
5.3 Ottenere informazioni da un nodo AST. .................................................................58
5.4 Pattern Visitor.........................................................................................................61
5.5 Rappresentazione XML di un sorgente Java. .......................................................... 64
5.6 Inserimento delle informazioni nel database XML ................................................ 68
5.6.1 Struttura del database XML ............................................................................69
Capitolo 6.......................................................................................................................... 71
Modulo misurazione e visualizzazione ............................................................................. 71
6.1 Esecuzione delle misurazioni .................................................................................. 71
6.1 Metriche in MACXIM .............................................................................................. 73
6.1.1 Metriche di codice ........................................................................................... 73
6.1.2 Complessità Ciclomatica .................................................................................. 76
6.1.3 Altre metriche..................................................................................................78
Capitolo 7.......................................................................................................................... 81
Conclusioni ....................................................................................................................... 81
Bibliografia........................................................................................................................ 83Capitolo 1
Introduzione
La misurazione del software consiste, per definizione, nella quantificazione
delle caratteristiche di un prodotto applicativo e nella possibilità di stimare
e pianificare lo sforzo produttivo necessario per la realizzazione di progetti.
Questa misurazione assume un ruolo di crescente importanza nel controllo
dei progetti di sviluppo con l’obiettivo di migliorare la qualità del prodotto
finale.
Tradizionalmente, i parametri con i quali si può misurare o definire la
qualità del software vengono classificati in due categorie:
• Qualità esterne: qualità del software così come è percepita dai suoi
utenti, e includono correttezza, affidabilità, robustezza, efficienza e
usabilità.
• Qualità esterne: qualità del software così come è percepita dagli
sviluppatori e includono verificabilità, manutenibilità, riparabilità,
evolvibilità, riusabilità, portabilità, leggibilità e modularità.
Esiste un legame che correla queste due categorie, si può infatti affermare
che un software mal scritto tende a funzionare male. In particolare in
questo studio vengono prese in considerazione solo le qualità interne
riguardanti la struttura del codice.Il software prodotto con modello di sviluppo Open Source possiede caratteristiche particolari ed interessanti che ne contraddistinguono il processo di sviluppo. Tra queste sicuramente la natura del codice di programmazione, disponibile e modulare, che permette di adattare il prodotto alle esigenze dell'utente. 1.1 Obiettivi L’obiettivo della tesi è strettamente legato alla caratteristica di visibilità del codice e consiste nella progettazione e sviluppo di uno strumento di misurazione: MACXIM (Model And Code XML‐based Integrated Meter), che permetta l'effettuazione di analisi quantitative di software open source java riguardanti il codice del prodotto analizzato. In questa ottica lo strumento realizzato consentirà la creazione di una base di dati di conoscenza, che permetterà di valutare correttamente alcune delle qualità del prodotto di interesse e ne consentirà il confronto con prodotti similari. 1.2 Struttura dello sviluppo MACXIM e della tesi Una volta individuati i requisiti, abbiamo implementato lo strumento di analisi MACXIM. IL processo per ottenere i risultati finali parte dalla preparazione dei dati da analizzare. Successivamente viene segue l'analisi vera e propria. Infine le informazioni ottenute vengono rielaborate e presentate. Entrando nello specifico si è suddivisa la realizzazione in moduli per permetterne la riusabilità.
Un primo modulo permette l'estrazione delle informazioni a partire dal codice sorgente fornito. Un secondo modulo, data una rappresentazione delle informazioni estratte ne permette l'analisi. La raccolta dei risultati derivanti da analisi di vari progetti potranno infine costituire materiale per indagini statistiche sulle qualità del software. Nel secondo capitolo vengono descritte alcune tecniche per l’analisi del codice, fondamentali per lo sviluppo di MACXIM. Nel terzo capitolo viene fatta una panoramica sulle tecnologie utilizzate e necessarie per spiegare lo sviluppo dello strumento. Nel capitolo seguente, il quarto, viene mostrata l’architettura del software, spiegando le scelte intraprese. Nel quinto e sesto capitolo verranno trattati rispettivamente il modulo preposto all’estrazione delle informazione a partire dalle classi Java e il modulo anteposto all’analisi delle informazioni estratte. Al termine di quest’analisi verranno fatte alcune considerazioni sullo strumento realizzato e sui suoi possibili sviluppi futuri.
Capitolo 2
Analisi del codice
Con "analisi del codice" si intende analizzare staticamente il codice per
controllare se soddisfa uniformemente le aspettative riguardanti la
sicurezza, l'affidabilità, le prestazioni e la manutenibilità. Eseguita correttamente questa
operazione fornisce le fondamenta per la produzione di codice di qualità evitando errori
strutturali.
Non importa quanto uno sviluppatore sia esperto ed organizzato perché,
nonostante tutte le sue buone intenzioni, continuerà a scrivere codice che
probabilmente avrà qualche bug. La maggior parte delle applicazioni
software sono diventate così complesse che è quasi impossibile scrivere
codice che soddisfi i requisiti senza creare comportamenti indesiderati nel
sistema. Applicazioni di tale livello di complessità sono spesso costituite da
un numero molto elevato di componenti e svariate migliaia di righe di
codice. Per facilitare la comprensione e l'implementazione di sistemi
complessi esistono processi di sviluppo agile. Ma anche con l'utilizzo di
queste tecniche continua a presentarsi un largo numero di bugs all'interno
dei software. Dove con il termine bug si identifica un errore nella scrittura
di un software in grado di causare un funzionamento errato o diverso da
quello atteso nell’esecuzione del programma. Anche se questo è un passo
nella giusta direzione, per arrivare a standard di qualità è necessario avere
strumenti di analisi automatizzata. Il momento migliore per scoprire
problemi è quando si effettua una revisione del codice appena scritto. Con
l'aiuto di strumenti di analisi di tipo statico la maggior parte della
rivisitazione del codice può essere effettuata automaticamente.Le Misurazioni di tipo statico forniscono un meccanismo per poter realizzare tool per la revisione di codice attraverso i quali è possibile trovare difetti nella fase di implementazione. Analisi di questo tipo permettono di scovare bug nel codice ancor prima dell’esecuzione del programma stesso. L’individuazione di bug permette di conseguenza di individuare le soluzioni per una corretta implementazione migliorando la qualità della fase produttiva e l’affidabilità del prodotto finale. Le analisi di tipo statico aiutano inoltre a far rispettare convenzioni di codifica, rendendo più facile la manutenibilità. Queste sono le motivazioni che hanno spinto a prendere in considerazione questo tipo di analisi come supporto alla produzione di applicazioni di qualità. 2.1 Analisi automatizzata e valutazione Quando si parla di valutazione, bisogna prendere in considerazione il fatto che l’analisi può risultare molto complessa, soprattutto quando ad essere presi in considerazione sono progetti di grandi dimensioni, complessi ed articolati. Si deve considerare il codice scritto, le librerie utilizzate, l’ambiente in cui il prodotto viene sviluppato. Effettuare valutazioni di questo tipo con una metodologia manuale può risultare molto difficile e portare ad errori di valutazione. La soluzione migliore consiste nel prendere in considerazione un tipo analisi che possa essere applicata in maniera automatizzata così da migliorare il processo complessivo che porta al perfezionamento del prodotto.
Per questo motivo l’approccio deve essere di tipo quantitativo, in modo da fornire misure paragonabili, deve poter essere ripetibile e, vista la complessità delle operazioni, automatizzato. Anche avendo dati quantificati, derivanti da analisi, rimane il problema della valutazione di questi. Valutare un’applicazione e paragonarla ad un’altra infatti non è assolutamente una procedura agevole, specialmente quando si paragonano prodotti di domini differenti. In questa situazione ci si può porre la questione di come interpretare una misurazione, potrebbe, ad esempio, essere valutata in base a dei valori medi oppure avere una scala graduata con cui avere un confronto. Si possono introdurre delle soglie, stabilire cioè dei valori minimi che devono essere rispettati. In questo modo per avere un prodotto di qualità devono essere soddisfatti dei requisiti minimi, ma in un confronto tra software rimarrebbe la questione di interpretare correttamente la distanza tra due o più misurazioni. Probabilmente una valutazione di tipo relativo è più interessante specialmente per comparazioni del tipo “il programma X è due volte un certo valore di qualità rispetto ad Y”. L'analisi automatica è un approccio interessante, tuttavia bisogna fare delle considerazioni di cui tenere conto per la realizzazione di un tale approccio. Dobbiamo avere delle metriche per progetto che siano il più possibile automatiche, che siano comparabili da progetto a progetto e che siano il più significative possibile. 2.2 Qualità
Le qualità che il software deve possedere sono molteplici in relazione all’ambito in cui verranno utilizzati. In applicazioni critiche come in medicina, aviazione, attività finanziarie, affidabilità, correttezza e sicurezza assumono un ruolo importante mentre per applicazioni destinate ad un utente, che non richiede come qualità fondamentale l’affidabilità solitamente vengono richieste altre qualità quali elevate prestazioni ed usabilità del prodotto. Il produttore invece desidera un software con elevata manutenibilità, verificabilità e riusabilità, in modo da aumentare il rendimento del prodotto, in quanto saranno necessarie minori risorse per individuarne e correggerne i difetti, ed esso potrà essere più facilmente fatto evolvere o riusato in nuovi progetti. Attraverso l'utilizzo di misurazioni è possibile quantificare le qualità e le caratteristiche del progetto in analisi e, a partire da queste misure, sarà poi possibile individuarne le inefficienze, punti di partenza per ogni futuro miglioramento del prodotto. Dunque la misurazione di varie metriche di un prodotto software rappresenta un'insieme di informazioni fondamentali per stimare la qualità del progetto e le misurazioni sul codice ne rappresentano una parte fondamentale. 2.3 La misurazione del codice I metodi quantitativi , che ottengono risultati misurabili e non descrittivi, si sono dimostrati strumenti potenti in altri campi della scienza, per questo motivo per la scienza dei computer pratici e teorici si è studiata una tecnica per mettere a punto un simile approccio nello sviluppo di software.
Tom DeMarco ha asserito che " You cannot control what you cannot
measure" [1].
Quantificare le qualità e le caratteristiche del progetto in analisi, a partire
da una serie di misurazioni, permette di individuarne le inefficienze le quali
sono i punti di partenza per ogni futuro miglioramento del prodotto. Avere
delle misurazioni è utile inoltre per controllare lo sviluppo del prodotto,
[Figura 1].
Figura 1 Uso delle metriche per controllare le fasi di sviluppo del software.
Rendere il processo di revisione del codice più gestibile e prevedibile
mediante un'analisi statica dello sviluppo del software migliora la
produttività e l'affidabilità del prodotto finale. Tuttavia il più grande
vantaggio è la capacità di individuare i difetti in fase di codifica, che
incidono direttamente sull'affidabilità del software.Per ottenere questi benefici è però indispensabile applicare l'analisi di tipo statico con gli strumenti giusti, con corrette regole di configurazione, di modo da poter essere un meccanismo molto potente per ottenere una misurazione quantitativa che aiuti a migliorare l'accuratezza globale del progetto. MACXIM è realizzato per effettuare delle misurazioni sul codice e quindi per misurare quello che abbiamo appena descritto. 2.4 Analisi di tipo statico Analisi statica significa lo studio di qualcosa che non cambia. In termini software può essere ridefinita come lo studio del codice sorgente non ancora in esecuzione. Sappiamo che i debugger ci permettono di analizzare il codice durante la sua esecuzione, ma possiamo conoscere molto dal codice senza dover eseguire l'applicazione. Ad esempio se si analizzano i file sorgenti di un’applicazione è possibile garantire che il codice sorgente aderisca ad uno standard di codifica predefinito. È anche possibile individuare problemi di prestazioni più comuni. Si possono anche esaminare le classi importate per capire le relazioni di dipendenza. Per fare tutto questo non vi è la necessità né di compilare il programma né di eseguirlo. Tuttavia ci sono molti tipi di analisi di tipo statico categorizzati a seconda dei valori che forniscono.
2.4.1 Revisione del codice Negli strumenti che effettuano l’analisi del codice in maniera automatizzata ogni file sorgente è caricato ed analizzato da un parser il quale scorre il codice alla ricerca di particolari patterns che violano delle regole prestabilite. In alcuni linguaggi, come C++, molte di queste regole sono insite nel compilatore o disponibili in programmi esterni. In altri linguaggi, come Java, il compilatore controlla poco sotto l'aspetto della revisione. La revisione del codice è un buon strumento per forzare alcuni standard del codice, scovare problemi di base relativi alle performance e trovare possibili abusi nell'utilizzo delle API (Application Programming Interface). La revisione del codice può inoltre includere forme di analisi più approfondite come il flusso di dati, controllo di flusso, e così via. 2.4.2 Dipendenze del codice Piuttosto che esaminare il formato di singoli file sorgente, gli strumenti che analizzano le dipendenze del codice esaminano le relazioni tra i file di origine (in genere le classi) per creare una mappa generale dell'architettura del programma. Strumenti di questo tipo sono comunemente utilizzati per scoprire design pattern funzionali oppure non funzionali a seconda delle esigenze. 2.4.3 Complessità del codice
Gli strumenti che analizzano la complessità del codice del programma effettuano delle metriche del software stabilite per determinare quando risulta inutilmente complesso. Quando un particolare blocco di codice supera una certa soglia di valutazione metrica, può essere marcato come candidato per una ristrutturazione in modo da migliorarne la manutenibilità. 2.5 Benefici dovuti all’analisi di tipo statico I benefici dovuti ad analisi di tipo statico non solo apportano miglioramenti qualitativi, ma anche, aspetto di almeno altrettanta importanza, portano a risparmiare tempo e denaro. Un aspetto inerente al risparmio di tempo dovuto a strumenti che permettono analisi di tipo statico è abbastanza ovvio: ci vuole meno tempo per ottenere codice di maggiore qualità. Il risparmio di denaro è strettamente legato alla qualità del codice, in quanto la scrittura di codice con pochi difetti porta al risparmio legato alla risoluzione dei problemi che si possono riscontrare. Scoprire difetti durante il processo di sviluppo costa meno e risolvere bug mentre in ogni fase successiva diventa sempre più costoso. 2.6 Tipologie di analisi In generale, molti progetti spendono più della metà del loro ciclo di vita nella revisione del codice e nella prevenzione di difetti [2]. Questo sforzo può essere significativamente ridotto automatizzando il processo di revisione del codice. L'automatizzazione inoltre aiuta nel
realizzare la consistenza in termini di norme di codifica e buone pratiche di
realizzazione. Qui ci focalizzeremo su Java esplorando le differenti tecniche
usate per ottenere una revisione automatica del codice.
Per prima cosa viene descritto il ruolo, come illustra la Figura 2, delle
analisi statiche nel ciclo di vita dello sviluppo del software e i partecipanti
coinvolti nel processo:
Figura 2 Processo di analisi statica.Gli sviluppatori sono responsabili della scrittura del codice e dell'effettuazione delle analisi statiche al fine di identificare e risolvere eventuali difetti e problemi. Gli "architetti" sono responsabili della selezione degli strumenti di analisi statiche e della configurazione delle regole. I consulenti della qualità del software sono responsabili dei difetti delle analisi e della prevenzione. Sempre dalla Figura 2 si può notare che l'analisi statica non compromette l'importanza dei programmatori e degli architetti del software, perché la selezione di tool affidabili e appropriati di analisi statiche è critica. L'automatizzazione di analisi statiche implica che gli sviluppatori debbano garantire l'individuazione di errori e la loro risoluzione. In breve, gli sviluppatori dovrebbero fornirsi di un processo di revisione affidabile e automatizzata che permetta al team di sviluppo di concentrarsi su altri importanti processi di sviluppo per soddisfare le richieste funzionali. Prima di entrare nei dettagli delle varie tecniche usate per automatizzare le misurazioni in MACXIM, è importante comprendere i parametri base richiesti per automatizzare strumenti di revisione dal punto di vista di Java e visionare quali tipologie di misurazioni è possibile effettuare avendo a disposizione un codice sorgente. Le tipologie di analisi possibili per effettuare misurazioni sono varie, di seguito ne vedremo alcune ma vediamone alcune.
2.6.1 Analisi sintattica
L'analisi sintattica è fatta determinando la struttura del codice java in input
e comparandola con modelli predefiniti. I difetti più comuni usando questa
metodologia vengono riscontrati utilizzando delle convenzioni, come l'uso
di una tipologia di nomi standard, oppure avere sempre la clausola di
default negli statement switch (costrutti di controllo utilizzati quando è
necessario eseguire una serie di controlli sulla stessa variabile).
Per esempio, vedi Figura 3, l'assenza della clausola di default potrebbe
nascondere potenziali bugs che potrebbero essere rilevati da questa
clausola.
Figura 3 Switch statement.
switch (expression) {
case c1:
statements // do these if expression== c1
break;
case c2:
statements // do these if expression == c2
break;
}
2.6.2 Analisi del flusso
L'analisi del flusso di dati tiene traccia degli oggetti (variabili) e del loro
stato (valore del dato) in un particolare momento di esecuzione di un
metodo del programma. Questa metodologia monitora la situazione delle
variabili in tutti i suoi possibili stati, predicendo così, ad esempio, dellepossibili eccezioni dovute a puntatori nulli oppure oggetti di un database
che non sono stati chiusi.
La figura 4 mostra l'oggetto connessione al database "con2" che non è
stato chiuso in tutti i possibili flussi. Questa situazione potrebbe portare ad
uno stato critico. Inoltre, se le connessioni a una base di dati sono una
risorsa limitata, tenerli in vita potrebbe creare altri problemi.
Figura 4
class TestResourceLeak{
public CoreResponse process(Entity entity) throws ResourceException {
CoreResponse coreresponse = new CoreResponse();
DatabaseConnection dbcon = new DatabaseConnection();
Connection con1 = null;
Connection con2 = null;
//getting the Data Base Connection
try{
con1 = dbcon.getConnection();
con2 = dbcon.getConnection();
...
}
catch(Exception e) {
con1.close();
throw new ResourceException(e.getMessage(),e) ;
}
con1.close();
return coreresponse;
}
}2.7 Tecniche di analisi del codice Fino ad ora abbiamo considerato alcuni possibili tipi di analisi che si possono effettuare sul software, ma adesso prendiamo in esame come effettivamente queste misurazioni possono essere fatte, tenendo presente che da qui in avanti le considerazioni riguarderanno il linguaggio Java. Le tecniche di ispezione possono essere categorizzate in due tipologie che possono essere applicate sul codice sorgente Java (.java File) oppure sul bytecode generato dal compilatore (.class File). 2.7.1 Codice sorgente L’ispezione del codice sorgente permette di prendere codice Java sorgente in input. Tecniche di questo tipo per prima cosa scansionano il file sorgente usando un parser, successivamente eseguono regole predefinite su questo codice sorgente. La comprensione profonda del linguaggio è imprescindibile per ogni tool che vuole avere la capacità di identificare bugs o problemi in un particolare linguaggio di programmazione. Ci sono numerosi parser del linguaggio Java che si attengono alle specifiche del linguaggio Java (JLS), come ad esempio JavaCC (https://javacc.dev.java.net/) e ANTLR (http://www.antlr.org/). L’aspetto importante è che strumenti di questo tipo abbiano la capacità di scansione del codice in modo strutturato e forniscano delle APIs che semplifichino le regole di implementazione. Il Java parser inoltre semplifica il sorgente Java convertendo il codice in una struttura ad albero conosciuta come "Abstract Syntax Tree". La Figura
5 mostra un abstract syntax tree (AST) generato per codice Java usando
JavaCC e JJTree parser (https://javacc.dev.java.net/) per costruire un
programma che riconosca l'abbinamento tra il codice e le specifiche della
grammatica. Infine genera un AST del file codice sorgente Java. L’utilizzo di
questa struttura verrà meglio spiegata nel capitolo 5, poiché rappresenta il
nodo centrale per l’estrazione delle informazioni necessarie a MACXIM per
eseguire le proprie metriche.
Figura 5 Abstarct Syntax Tree generato.
public class GenerateAST {
private String printFuncName() {
System.out.println(funcName + "Generate AST");
}
}
CompilationUnit
TypeDeclaration
ClassDeclaration:(public)
UnmodifiedClassDeclaration(GenerateAST)
ClassBody
ClassBodyDeclaration
MethodDeclaration:(private)
ResultType
Type
Name:String
MethodDeclarator(printFuncName)
FormalParameters
Block
BlockStatement
Statement
StatementExpression
PrimaryExpressionPrimaryPrefix
Name:System.out.println
PrimarySuffix
Arguments
ArgumentList
Expression
AdditiveExpression:+
PrimaryExpression
PrimaryPrefix
Name:funcName
PrimaryExpression
PrimaryPrefix
Literal:"Generate AST"
2.7.2 Codice compilato
La tecnica di scansione di bytecode Java analizza il codice compilato, cioè i
file con estensione .class creati dalla compilazione del codice sorgente.
Questo approccio, noto come “reflection”, utilizza delle librerie per
accedere al bytecode Java e implementa modelli e regole predefiniti
usando queste librerie.
Le librerie Java bytecode aiutano l'accesso al compilato fornendo
interfacce di astrazione del livello sorgente.
Possiamo così leggere una classe e le sue informazioni senza conoscere in
modo dettagliato il bytecode. L'API reflection è così un'infrastruttura che
permette di ispezionare un oggetto a runtime, al fine di scoprire la classe
di appartenenza, la sua composizione in termini di metodi, campi,
interfacce implementate, i modificatori utilizzati e persino di lavorare su
ciascuno di questi elementi in modo simile a quanto si può fare usando gliappositi operatori del linguaggio durante la stesura di un programma. La "Reflection" consente dunque a Java l'abilità di ispezionare dinamicamente all'interno del proprio codice delle classi caricate. Le API Java Reflection forniscono un meccanismo per prendere le informazioni di una classe (super classe, nomi di metodi...) che sono usati per implementare regole come gerarchie di ereditarietà o il numero massimo di metodi in una classe. La scelta effettuata per la realizzazione di MACXIM è quella di analizzare solo il codice sorgente. Questo perché il nostro strumento si vuole presentare e collocare in ambito open source, motivo per cui suppone che il codice sorgente sia disponibile ed aperto.
Capitolo 3
Tecnologie utilizzate
In questo capitolo saranno introdotte brevemente le tecnologie utilizzate
per realizzare MACXIM. Questa panoramica consente di poter meglio
comprendere le scelte per lo sviluppo dello strumento,
3.1 Java
Il linguaggio di programmazione Java è stato creato verso la metà degli
anni novanta, e per questo è ancora in fase evolutiva, tanto che ogni anno
circa ne viene rilasciata una nuova release. Da linguaggio nato solo per la
rete è divenuto un vero e proprio linguaggio di programmazione,
paragonabile, dal punto di vista delle funzionalità, al C++.
3.1.1 Caratteristiche e qualità
Java venne creato per soddisfare le seguenti caratteristiche [3]:
• Il tuo linguaggio di programmazione è orientato agli oggetti, ed è
semplice.• Il tuo ciclo di sviluppo è molto veloce perché Java è interpretato. Il
ciclo compile-link-load-test-debug è obsoleto, ora devi compilare ed
eseguire.
• Le tue applicazioni sono portabili attraverso più piattaforme. Scrivi
le applicazioni una sola volta, e non avrai mai bisogno di "portarle",
esse sono eseguibili senza modifiche su diverse piattaforme
hardware e su diversi sistemi operativi.
• Le tue applicazioni sono sicure perché il sistema run-time Java
gestisce la memoria per te.
• Le tue applicazioni grafiche interattive sono ad alte prestazioni
perché più thread simultanei possono essere attivi, e le tue
applicazioni supportano il multithreading incorporato nell’ambiente
Java.
• Le tue applicazioni sono adattabili ai cambiamenti di ambiente
perché puoi scaricare dinamicamente moduli di codice da
qualunque parte sulla rete.
• I tuoi utenti possono fidarsi delle tue applicazioni esse sono sicure,
anche se essi scaricano codice da Internet; il sistema run-time Java
ha incorporato protezioni contro virus e altre manipolazioni.
Java supporta applicazioni che saranno eseguite su architetture hardware
e sistemi operativi diversi. Per risolvere questa diversità di ambienti
operativi, il compilatore Java genera il bytecode, un formato di codice
intermedio tra il codice ad alto livello e quello macchina, progettato per
essere efficientemente trasportato su piattaforme hardware e software
diverse. Esso viene poi eseguito da una virtual machine, Java Virtual
Machine (JVM), cioè da un interprete. L’interprete Java può così eseguire
i bytecode Java su ogni macchina sulla quale l’interprete e il sistema run‐time è stato portato. JVM è la specifica di una macchina astratta per la quale il compilatore Java genera il codice. Una specifica implementazione della JVM per piattaforme hardware e software specifiche provvede alla realizzazione concreta di questa macchina virtuale. La compilazione dei sorgenti java avviene con controlli severi, ma il linguaggio è dinamico nella fase di link. Le classi infatti sono collegate solo quando occorre. In questo modo la fase di link di un programma è semplice e leggera e il ciclo di sviluppo del software diventa molto più rapido. Grazie a queste caratteristiche è così possibile eseguire su hardware e sistema operativo diverso programmi scritti in Java ed aspettarsi lo stesso comportamento durante la fase della sua esecuzione. Una Java Virtual Machine è implementata anche nei vari Browser per poter eseguire programmi Java remoti nella rete, i cosidetti Applet. Un Java applet è un particolare tipo di applicazione che può essere avviata all’interno del browser dell’utente, eseguendo codice scaricato da un server web remoto. Questo codice viene eseguito in un’area altamente ristretta, che protegge l’utente dalla possibilità che il codice sia malevolo o abbia un comportamento non desiderato. Chi pubblica il codice può applicare un certificato che usa per firmare digitalmente le applet dichiarandole “sicure”, dando loro il permesso di uscire dall’area ristretta e accedere al filesystem e al network, presumibilmente con l’approvazione e sotto il controllo dell’utente. Java ha introdotto la possibilità di creare applicazioni multi‐thread, ovvero applicazioni che svolgono in modo concorrente molteplici attività. In Java è anche stato introdotto, aspetto di nostro interesse ai fini dello studio e realizzazione di MACXIM, il supporto per la riflessione,
ovvero la capacità di un programma di agire sulla propria struttura e di utilizzare classi caricate dinamicamente dall’esterno. Aspetto questo, che permette di analizzare il codice Java dall’interno. Tra gli argomenti che depongono spesso a favore di Java nella scelta del linguaggio di implementazione di un progetto software moderno, inoltre, si deve certamente sottolineare la notevole quantità delle librerie standard di cui il linguaggio è dotato. Questo contribuisce a renderlo altamente integrabile con le altre tecnologie. 3.1.2 Linguaggio Progettato per creare software altamente affidabile, fornisce ampi controlli in fase di compilazione, seguito da ulteriori controlli in fase di esecuzione. La filosofia object‐oriented di Java ha come obiettivo la creazione di un linguaggio estremamente semplice, facile da apprendere e volto a produrre programmi affidabili. Affidabilità che si cerca di garantire anche attraverso la gestione automatica della memoria. Oltre a semplificare il lavoro del programmatore, tali scelte sono orientate ad aumentare la sicurezza, intesa sia come protezione da errori accidentali che come prevenzione nei confronti di operazioni illecite da parte di estranei. 3.1.3 Ambiente Java Esaminiamo adesso la struttura dell’ambiente Java. Semplificando possiamo dire che la compilazione di codice sorgente Java porta alla
creazione del Java Byte Code, che verrà eseguito da un interprete la cui
implementazione dipende dalla piattaforma di esecuzione. Da quanto
detto si evidenzia la portabilità del codice Java, una tra le più importanti
qualità di tale linguaggio. In figura 6 viene schematizzato l’ambiente
Java.
Figura 6 Ambiente Java
Caricatore di
Codice Java bytecode
Compilatore Network o file Verificatore
Java system di bytecode
Interprete Generatore di
Bytecode Java Java codice
Run Time
Hardware
3.2 Abstract Syntax TreeUn Abstract Sytanx Tree, o semplicemente Syntax Tree, è una rappresentazione ad albero della sintassi di un qualche codice sorgente( che è stato scritto tramite un linguaggio di programmazione). Ogni Nodo dell'albero denota un costrutto che occorre nel codice sorgente. L'albero è astratto nel senso che potrebbe non rappresentare qualche costrutto presente nel codice originale. Un classico esempio di omissione è il raggruppamento delle parentesi poiché in un AST il raggruppamento degli operandi e dei costrutti è implicito. Un AST è spesso costruito da un parser come parte del processo di compilazione del codice sorgente. Una volta costruito l'albero, le informazioni aggiuntive sono inserite nell'AST da un processo seguente, ad esempio l'analisi semantica. Questa tecnologia permette così di avere una rappresentazione del codice sorgente da cui si possono ricavare molte informazioni. Esistono vari strumenti di questo tipo, per l'implementazione di MACXIM si è deciso di utilizzare il framework Abstract Syntax Tree per Eclipse [4]. Questo tool permette di mappare codice sorgente Java in forma di albero. Il flusso delle informazioni per estrarre i dati di interesse da parte di MACXIM, per quanto riguarda l'utilizzo dell'AST, è il seguente, [Figura 7]:
Figura 7 1 Sorgente Java. Per cominciare è necessario fornire il codice da analizzare. 2 Parsing. Il codice sorgente fornito dal passaggio precedente viene analizzato. Tutto ciò di cui si ha bisogno per questo passo è fornito dalla classe org.eclipse.jdt.core.dom.ASTParser. 3 Rappresentazione. Dal passo precedente si ottiene un Abstract Syntax Tree (AST). Si tratta di un modello ad albero che rappresenta interamente la fonte fornita dal primo passo. Manipolare l'AST. A questo punto è possibile usufruire delle informazioni della rappresentazione ad albero del codice sorgente Java. Tutte le classi rilevanti per utilizzare la struttura AST sono localizzate nel package org.eclipse.jdt.core.dom del plug‐in org.eclipse.jdt.core. 3.3 XML XML (eXtensible Markup Language) [5], è nato come raccomandazione del W3C (World Wide Web Consortium) ed è stato pensato nell’ottica di una rivisitazione di SGML (Standard Generalized Markup Language). La
tecnologia XML permette di rappresentare informazioni di tipo testuale e strutturato. E’ un linguaggio di tipo descrittivo che permette all’utilizzatore di definire un proprio linguaggio di markup. Per questo motivo possiamo definire XML come un metalinguaggio, finalizzato alla rappresentazione di contenuti testuali organizzati in gerarchia. XML non possiede un insieme predefinito di marcatori, come invece è per l’HTML, chiamati TAG, ma permette di definirne di nuovi, e di stabilire come essi potranno essere organizzati in strutture gerarchiche. Questi TAG ci permettono di leggere le informazioni in essi contenuti, in base al loro nome e non necessariamente alla loro posizione. A ogni documento XML possiamo associare la definizione della struttura al suo interno utilizzata, al fine non solo di renderlo facilmente leggibile anche a chi non lo ha mai visto, ma anche di rendere rapido il processo di verifica per il controllo che tale struttura sia rispettata nel documento. Questa struttura, le regole che stabiliscono quali sono i TAG e come essi possono essere organizzati in uno specifico file XML, sono contenute in un file detto DTD (Document Type Definition). In tal senso si può dire che un documento XML è ben formato se rispetta tutte le regole sintattiche previste dal linguaggio, mentre è definito valido se, e solo se, esso è conforme alle regole presenti nella DTD ad esso associato. Infatti un documento leggibile non implica che abbia anche un senso dal punto di vista semantico. I DTD presentano alcune limitazioni. Ad esempio, secondo i DTD il contenuto dei TAG è sempre testo. Non è prevista la possibilità di definire tipi di dato e pertanto non è possibile ottenere un controllo accurato sul contenuto dei TAG e sul valore degli attributi. Non c’è possibilità di comporre documenti XML che facciano riferimento a DTD diversi. Occorre
inoltre precisare che la sintassi di un DTD è slegata dal mondo XML. A prima vista quest’ultimo aspetto può essere considerato di poco conto, ma ha invece ha la sua importanza se consideriamo che in linea di principio non possiamo riutilizzare gli stessi strumenti che usiamo per XML quando lavoriamo con un DTD. A questi problemi cercano di dare una soluzione gli XML Schema Definition (XSD). XML come abbiamo detto è un metalinguaggio, quindi può essere utilizzato per rappresentare altri linguaggi. XSD è un documento XML che utilizza un insieme di TAG speciali per definire la struttura di un documento XML. Il vincolo che dobbiamo rispettare nella creazione di uno schema è l’uso dei TAG definiti dall’XML Schema Language, definito dal W3C. Una delle principali novità introdotte dagli XML Schema rispetto ai DTD è la possibilità non solo di definire il tipo di dato di un elemento, ma anche di poter personalizzare un tipo di dato. Esistono tipologie di dato: semplici e complessi. I tipi di dato semplici sono relativi a quegli elementi che non possono contenere altri elementi e non prevedono attributi. Sono previsti numerosi tipi di dato predefiniti. È possibile definire tipi semplici personalizzati derivandoli da quelli predefiniti. Ad esempio, possiamo definire un tipo di dato come restrizione del tipo stringa, vincolando i valori ad uno specifico insieme di stringhe o ad un pattern individuato da un’espressione regolare. I tipi di dato complessi si riferiscono alla definizione degli elementi con attributi e che possono contenere altri elementi. La definizione del tipo complesso consiste generalmente nella definizione della struttura
prevista dall’elemento. Se l’elemento può contenere altri elementi possiamo definire l’insieme degli elementi che possono stare al suo interno come sequenza, come insieme di valori alternativi o come gruppo. Grazie a queste caratteristiche possiamo trasmettere contenuti XML tra diversi sistemi senza avere vincoli né in termini di piattaforma né di protocolli. Basta che sia supportato il testo. Queste qualità rendono XML una tecnologia decisamente molto interessante e finalizzata a essere utilizzata quando vogliamo gestire lo scambio di informazioni tra diverse realtà, così come ogni qual volta sia necessario mantenere i dati puri separati dal loro aspetto grafico. 3.4 XQuery e XQueryX XQuery [6] (XML Query Language) è un linguaggio di programmazione specificato dal W3C nato con l'obbiettivo di recuperare agevolmente informazioni da documenti e basi di dati XML. Può essere visto come una sorta di SQL per XML. Ma a differenza di SQL, che opera su tabelle relazionali, XQuery usa delle strutture dati organizzate nell'ordine in cui appaiono nel documento XML sorgente. Tutte le espressioni XQuery devono rispettare questo ordine tranne nel caso in cui sia diversamente specificato nell’ espressione stessa. XQuery non è un linguaggio basato su XML ed è costituito da una sintassi semplice basata sulle espressioni di XPath per la selezione di specifiche porzioni di documenti XML, con l'aggiunta delle cosiddette espressioni
FLWOR per la formulazione di query complesse. Dove FLOWR è un
acronimo che deriva dai seguenti costrutti:
• For che fornisce un meccanismo iterativo.
• Let che definisce un meccanismo per l'assegnamento.
• Where che consente di filtrare i risultati tramite condizioni
booleane.
• Order by che offre un meccanismo di ordinamento.
• Return che indica l'espressione da valutare e restituire.
Una query in XQuery è così composta da un’espressione che legge una
sequenza di nodi XML oppure un singolo valore e restituisce come
risultato una sequenza di nodi od un singolo valore.
XQueryX [7] (XML Syntax for XQuery) è un linguaggio basato su XML
per esprimere le interrogazioni XQuery e gli elementi che costituiscono
la sua sintassi consentono di riprodurre, mediante tag XML, le espressioni
XQuery.
Una versione XML delle espressioni XQuery è molto utile perché ci
permette di utilizzare tutti gli strumenti XML (parser XML, XSLT, ecc.) per
creare, analizzare e manipolare le query sui documenti XML.
L’interrogazione avrà però una sintassi più complicata e meno leggibile
rispetto alla versione XQuery poiché ciascuna espressione XQuery viene
mappata in un apposito tag XQueryX.
Questa maggiore complessità ha portato a non utilizzare XQueryX in
MACXIM. Si è così scelto di definire un formato XML per la
memorizzazione delle query. Formato che permette di definire nuovidocumenti meno strutturati di XQueryX ma con il vantaggio di essere più facilmente controllabili e modificabili. 3.5 eXist eXist [8] è un database che permette di memorizzare documenti in formato XML ed è un prodotto open‐source. Il supporto a XQuery offre la possibilità di costruire su eXist applicazioni web complete, con l’ausilio della sola tecnologia dei fogli di stile Xslt. Le XQuery interrogano il database in vari modi: attraverso una XQueryServlet, piuttosto che un XQueryGenerator o mediante l’uso di un Api. Per realizzare l’interfaccia utente per la misurazione è stato scelto il primo metodo: il servlet XQueryServlet processa i file XQuery dell’applicazione, per poi restituire l’output HTML al browser. Il database può funzionare in vari modi. Come processo server stand‐ alone, richiamato via rete con protocolli come Xml‐Rpc o Api Rest basate quindi su http. Come database embedded in un’applicazione ospite (di cui usa la Jvm). Oppure connesso a un servlet engine. In tutte queste modalità viene garantito l’accesso multiutente e si possono, se necessario, utilizzare i thread. Ci sono varie soluzioni libere che permettono di memorizzare documenti XML, ma eXist ha i suoi punti di forza nel supporto a XQuery e a XUpdate, nonché funzionalità di auto indicizzazione ed estensioni per ricerche full‐ text.
Capitolo 4
Architettura dell’applicazione
In questo capitolo viene analizzata l’architettura generale dell’applicazione
e spiegate le scelte di progettazione. Per la base di questo lavoro si è
partiti dall’idea che utilizzando una qualsiasi tecnologia da cui poi si
potessero ottenere dei risultati in formato XML sarebbe stato possibile
uno strumento con certe caratteristiche:
• Estendibile, per poter definire nuove metriche.
• Modificabile, per poter modificare le metriche già implementate.
• Trasparente, per avere a disposizione l’implementazione delle
metriche.
• Indipendente, per poter misurare codice indipendentemente dagli
strumenti di sviluppo utilizzati.
• Interoperabile, per permettere all’applicazione di poter interagire
con altre.
Esistono svariati strumenti per analizzare il codice sorgente o il codice
compilato ed alcuni effettuano anche misurazioni automatiche del codice.
Molti di questi strumenti forniscono un insieme completo di metriche
predefinite e producono misure affidabili.
Alcuni strumenti esistenti sono dotati di interfacce utente abbastanza
sofisticate in grado di visualizzare il risultato delle misurazioni anche
attraverso grafici di varie tipologie.
Per esempio PMD () and CheckStyle (http://checkstyle.sourceforge.net/)
sono buoni esempi di strumenti che analizzano il codice sorgente Java.FindBugs (http://findbugs.sourceforge.net/) e JLint (http://jlint.sour ceforge.net/) analizzano il bytecode per effettuare analisi di tipo statico. Tuttavia spesso non sono presenti alcune funzionalità che riteniamo importanti, come la possibilità di definire nuove metriche, modificare quelle predefinite, ottenere una rappresentazione XML dei risultati delle misurazioni, ricavare metriche complesse e misurare le variazioni tra due diverse versioni . 4.1 Architettura La realizzazione dell’applicazione è partita dalla progettazione della sua architettura che rappresenta una fase cruciale al fine di sviluppare un tool flessibile, modulare e semplice. L’architettura di MACXIM è suddivisa in due sottoparti fondamentali. Una adibita all’estrazione delle informazioni e l’altra con il compito di effettuare le misurazioni sul progetto preso in analisi. In mezzo a questi due moduli è presente il database eXist. In questo database viene salvata la rappresentazione XML del progetto che costituisce il risultato del primo modulo. Il secondo modulo invece ha il compito di analizzare questa rappresentazione e fornire i risultati delle analisi attraverso una interfaccia. Lo scopo primario della scomposizione del sistema in sottosistemi è la realizzazione di più componenti distinti che risultano meno complessi rispetto alla realizzazione di un sistema unitario. Ridurre la complessità di realizzazione non è però l’unico scopo della fase di realizzazione dell’architettura. Un altro fine è quello di migliorare le caratteristiche di qualità del sistema e nello specifico i seguenti aspetti:
Modificabilità. È possibile circoscrivere le modifiche da apportare al sistema alle sole componenti ove si desiderano apportare dei cambiamenti. Questa caratteristica permetterà di introdurre nuovi tipi di metriche o modificare quelle esistenti senza dover implementare la parte di estrazione dei dati sui quali queste vengono effettuate. Interoperabilità. Non solo si può migrare l’applicazione su una piattaforma distinta, ma le singole componenti dell’applicazione possono essere distribuite su varie piattaforme, in modo trasparente allo sviluppatore. Così facendo, ad esempio, si può applicare il sottosistema adibito al calcolo delle metriche a qualsiasi base di dati che contenga informazioni strutturate secondo le specifiche necessarie all’analisi. Favorire l’interoperabilità significa quindi fornire anche l’infrastruttura di comunicazione usata dalle varie componenti. Riuso di componenti già esistenti. L’idea che il software possa essere scomposto in componenti, e che per la sua realizzazione si possano usare componenti precostituiti è stata presentata da Douglas McIlroy’s [4]. La prima implementazione di questa idea fu l’uso di componenti prefabbricati nel sistema operativo Unix. Un altro esempio è .NET che include un insieme di componenti base riutilizzabili che forniscono varie funzionalità (gestione della rete, sicurezza, etc.). Riuso di componenti realizzati in precedenti progetti. Il riuso di componenti esistenti mira a sfruttare in un nuovo progetto, e quindi in un nuovo contesto, un componente già realizzato, senza modificarlo. Si può anche progettare un componente in previsione di un suo riuso futuro.
Puoi anche leggere
