Progetto Ingegneria del Software - Computer Science Divisioncomputerscience.unicam.it/culmone/?download=Progetto Ingegneria del... · Il! presente! documento,! redatto! come! lavoro!

C o r s o d i L a u r e a M a g i s t r a l e i n C o m p u t e r S c i e n c e

Matteo Rucco

Matr. 082218

Progetto Ingegneria del Software:

MWI – MySql Weka Interface

Sommario

1. Introduzione........................................................................................................................................3

2. Descrizione del problema e raccolta dei requisiti..................................................................4 2.1. Requisiti Funzionali.................................................................................................................................5 2.2. Requisiti Non Funzionali........................................................................................................................5

3. Analisi ....................................................................................................................................................6 3.1. Il dizionario dei termini: Gellish .........................................................................................................6 3.2. Alloy ..............................................................................................................................................................7 3.3. UML................................................................................................................................................................9 3.3.1. Use Case.....................................................................................................................................................................9 3.3.2. Activity-‐Diagram ................................................................................................................................................12

4. Progettazione................................................................................................................................... 13 4.1. Class Diagram.......................................................................................................................................... 13 4.1.1. Associazione.........................................................................................................................................................14 4.1.2. Aggregazione........................................................................................................................................................14 4.1.3. Composizione ......................................................................................................................................................14 4.1.4. Ereditarietà...........................................................................................................................................................14

4.2. Sequence Diagram................................................................................................................................. 15 4.3. OCL.............................................................................................................................................................. 16 4.4. Reti di Petri .............................................................................................................................................. 17

5. Implementazione............................................................................................................................ 20 5.1. Dalla progettazione a Java : JML ....................................................................................................... 20 5.2. Test ............................................................................................................................................................. 22 5.2.1. JUnit .........................................................................................................................................................................23

6. Conclusioni........................................................................................................................................ 26 6.1. Fonti ........................................................................................................................................................... 28 6.2. Software di terze parti ......................................................................................................................... 28

Progetto Ingegneria del Software: MWI – MySql Weka Interface 3

1. Introduzione La vita quotidiana di ciascuno di noi è ormai dipendente da complessi sistemi informatici,

comunemente ci troviamo a utilizzare sistemi che hanno come obiettivo quello di velocizzare

o migliorare lo stile di vita: gli elettrodomestici hanno al loro interno piccoli computer che ci

aiutano nella gestione domestica, la produzione industriale e la distribuzione sono

completamente computerizzate, il sistema finanziario è lapalissianamente sotto il controllo di

flussi resi automatici grazie all’introduzione dei computer che eseguono software ad -‐ hoc.

Affinché questi sistemi siano affidabili, è necessario progettarli con metodicità: l’ingegneria

del software rappresenta quindi la disciplina che ha come obiettivo quello di garantire

software di qualità. La difficoltà è aumentata dall’astrazione che ha il software per sua natura:

è intangibile, non è governato da leggi fisiche. Con la crescita della produzione del software, si

è reso necessario introdurre sistemi di formalizzazione del software, uno sviluppo non

organizzato rendeva lento il rilascio del programma e spesso senza essere verificato nella

totalità dei casi e il tutto comportava un incremento notevole di costi di produzione, gestione

e manutenzione. Dal 1968 a oggi molto si è fatto: sono stati introdotti nuovi standard

documentali, sono stati individuati e ormai rispettati all’unisono i passi principali che portano

allo sviluppo e rilascio di software affidabile, ecc…. Solo grazie a questi miglioramenti siamo in

grado di compiere scoperte uniche, mantenere attivi i contatti, ricevere informazioni

costantemente, scrivere documenti che sono automaticamente corretti e anche giocare.

Il presente documento, redatto come lavoro conclusivo del progetto MWI: MySql Weka

Interface intende illustrare l’applicazione degli strumenti discussi durante il corso di

Ingegneria del Software tenuto dal prof. Rosario Culmone e quindi non vuole essere una guida

sostitutiva delle diapositive o di altre pubblicazioni. Il canovaccio sarà abbastanza simile alla

programmazione del corso di IDS e potrà essere così riassunto:

1. Descrizione del problema e raccolta dei requisiti

2. Analisi

3. Progettazione

4. Implementazione

5. Test

2. Descrizione del problema e raccolta dei requisiti Nel contesto della ricerca sull’analisi dei dati avviata per conto del gruppo Loccioni, è stata

riscontrata la necessità di realizzare un software in grado di estrapolare dei dati presenti in

un database relazionale e riassumerli in un file dal formato ARFF Attribute-Relation File

Format da utilizzare con il software open source per il machine learning Weka prodotto dalla

Waikato University. Il formato ARFF è un file di testo ASCII che descrive un elenco d’istanze

che condividono un insieme di attributi. Oltre alla produzione del file, per aumentare

l’interazione con l’utente finale (esperto di dominio) si è avvertita la necessità di produrre a

monitor un plot (X-‐Y) e una tabella riepilogativa dei dati estratti dalla base di dati. Poiché il

software dovrà essere utilizzato in un contesto aziendale, quindi di produzione commerciale,

questo dovrà garantire affidabilità, portabilità e velocità d’utilizzo. Considerando che Weka è

stato interamente scritto in Java, è stato naturale codificare anche MWI con lo stesso

linguaggio.

La struttura del file ARFF è vincolata dalle specifiche imposte da Weka, mentre si è scelto di

produrre i due pannelli contenenti rispettivamente il ResultSet della query sql eseguita sul

database e il grafico in maniera indipendente l’uno dall’altro, questo per garantire all’utente di

scegliere quale informazione conservare a monitor (entrambe o una sola delle due). Il grafico

sarà comunque raggiungibile anche dopo la terminata esecuzione del programma, infatti, esso

al momento della sua generazione sarà anche salvato come file d’immagine. Questa

descrizione informale, può essere resa rigorosa adottando la notazione MoSCoW che consente

per discernere i requisiti funzionali e quelli non funzionali. I primi ci indicano la parte

funzionale, ossia a cosa serve e cosa deve fare il software mentre quelli non funzionali

possono essere adoperati per descrivere, puntualizzare, proprietà del software che non sono

indispensabili per il suo corretto funzionamento. Sintetizziamo quanto sopra utilizzando due

tabelle:


2.1. Requisiti Funzionali ID Descrizione MoSCoW

0 Il programma deve generare un file ARFF Must Have

1 Il programma deve salvare il grafico con formato

immagine.

Must Have

2 Il programma deve far vedere il grafico durante la

sua esecuzione.

Must Have

3 Il programma deve far vedere una tabella

riassuntiva della query durante la sua esecuzione.

Must Have

Tabella 1 requisiti funzionali

2.2. Requisiti Non Funzionali ID Descrizione MoSCoW

0 Il programma dovrebbe generare a monitor due

pannelli separati: uno per la tabella riassuntiva e

uno per il grafico.

Must Have

1 Il programma deve essere sviluppato in Java. Must Have

2 Il programma deve essere veloce Must Have

3 Ci dovrebbero essere due panel separati Should Have

4 Il programma dovrebbe essere personalizzabile con

file XML esterni per la definizione dei parametri di

connessione al database.

Should Have

Tabella 2: requisiti non funzionali

Ricordiamo il significato delle etichette caratterizzanti il sistema MoSCoW:

• Must Have: sono requisiti che devono essere analizzati obbligatoriamente affinché la

consegna del progetto risulti con successo. Se anche uno solo dei requisiti

appartenente a questa categoria dovesse essere ignorato, allora il progetto fallirebbe.

• Should Have: requisiti importanti ma non fondamentali. Questi spesso a differenza dei

“Must Have” sono requisiti che non sono ritenuti time-‐critical. Possono essere

riscontrati durante la seconda release del progetto.

• Could Have: sono requisiti solitamente necessari solo per aumentare la customer-‐

satisfaction.

• Won’t Have: requisiti che non devono essere implementati (negazione di una funzione)

particolarmente importanti ad esempio in software bancari (non si può accedere senza

password).

3. Analisi

3.1. Il dizionario dei termini: Gellish Per evitare ambiguità nella stesura del progetto e soprattutto per evitare incomprensioni fra

gli esperti di dominio (committente) e analisti, progettisti e programmatori è bene formulare

un dizionario dei termini. Si è deciso di adottare Gellish come dizionario, esso ha al suo

interno diversi termini che da un standard de-facto sono diventati standard ISO. Oltre ad

avere una struttura intellegibile un altro punto di forza di Gellish è rappresentato

dall’immediatezza con cui si possono definire nuovi termini per mezzo di relazioni con altri

già presenti. Per ogni termine e relazione è presente un codice univoco, questo consente

anche di eseguire più rapidamente ricerche.

Nell'esempio precedente, i concetti denominati 'torre' e 'città', così come i tipi (standard) di

relazione sono selezionati con i loro UID dal Gellish English Dictionary. Ciò permette di

formulare le domande utilizzando lo stesso linguaggio Gellish. Per consentire di esprimere le

query e il linguaggio Gellish comprende termini standardizzati, come what, which, where e

when. I progettisti, una volta individuati i termini principali potranno decidere se utilizzare

un dizionario già pronto (quindi ad esempio quello di Gellish) o realizzarne uno

personalizzato. Qualora si dovesse adottare la seconda soluzione, come nel presente

documento, si suggerisce come buona pratica di mantenere una struttura non troppo dissimile

dai dizionari noti, prevedendo così una possibile futura migrazione verso dizionari adottati da

altre realtà. Seguendo uno schema di dizionario presentato nel corso di IDS, si conviene nel

realizzare quanto segue:


Termine Relazione Termine

Algorithm Is used by Person

Machine Learning Is a set of Algorithm

Weka Is a set of Machine Learning

Interface Is used by Person

GUI Is a specialization of Interface

Jtable Is a component of GUI

ARFF Is a specialization of File

ARFF Is used by WEKA Tabella 3 Esempio di dizionario personalizzato

Nel compilare il dizionario si è scelto di non inserire le relazioni per i termini che si ha

certezza che non abbiano interpretazioni univoche (file, person, ecc…)1.

3.2. Alloy I sistemi complessi possono essere analizzati ricorrendo al concetto di modello: esso può

essere inteso come una rappresentazione astratta che si presta quindi ad essere più

agevolmente analizzata rispetto alla forma iniziale del problema. Design and coding

rappresentano due fasi distinte del processo di produzione del software e nella fase di

disegno la formulazione del modello è necessaria per spiegare e valutare l’intero sistema.

Alloy è un linguaggio, piuttosto semplice, basato sulla Logica del Primo Ordine FOL e creato

allo scopo di assistere la progettazione di una grande varietà di sistemi software. Utilizzando

Alloy si possono generare scenari con cui verificare i vincoli espressi dai requisiti. I domini di

elementi sono specificati attraverso la parola riservata sig – signature – che può essere

interpretata come l’analogo della classe nella programmazione ad oggetti. All’interno di ogni

signature possono essere specificate le relazioni con elementi di altre signature o con suoi

stessi elementi. Altra struttura essenziale è espressa dai fact – fatti – postulati che devono

essere rispettati durante il checking del modello. I vincoli nel sistema sono invece realizzati

1 Per informazioni su Gellish: http://sourceforge.net/apps/trac/gellish/wiki

attraverso i predicati pred. Alloy consente di utilizzare gli operatori matematici di confronto

(o più genericamente relazionali), definire il numero di elementi – cardinalità – degli insiemi2.

Figura 1 Esempio di modellazione con Alloy

Nell’esempio di Figura 1, è riportato un estratto della modellazione del problema in esame, in

dettaglio si possono riscontrare le definizioni delle signature principali, l’introduzione di

alcuni fatti (ad esempio negano che nome utente e password siano li stessi o che nome utente

e nome database siano uguali, ecc…) e di un predicato che agisce sulla cardinalità . Il risultato

dell’esecuzione con Alloy Analyzer può essere sia testuale sia visivo:

2 Per la semantica e la sintassi completa e aggiornata si invita il lettore a consultare il seguente:

http://alloy.mit.edu/alloy/documentation.html


Figura 2 Esempio di run su predicato con Alloy Analyzer

3.3. UML Dal punto di vista di ingegnerizzare il processo di produzione di software di qualità, ed in

particolare contemplando le peculiarità dei linguaggi orientati agli oggetti fu inventato il

linguaggio UML, la cui sigla sta per Unified Modeling Language. L'UML è un metodo per

descrivere l'architettura di un sistema in dettaglio. Adoperando una sorta di cianografia sarà

possibile costruire o manutenere un sistema e assicurarsi che il sistema stesso si presterà

senza troppe difficoltà a futuri cambiamenti dei requisiti. La forza dell'Unified Modeling

Language consiste nel fatto che il processo di disegno del sistema può essere compiuta in

modo tale che i clienti, gli analisti, i programmatori e chiunque altro sia coinvolto nel sistema

di sviluppo possa capire ed esaminare in modo efficiente il sistema e prendere parte alla sua

costruzione in modo attivo. L’UML si struttura di diversi tipi di diagrammi, qui saranno

applicati solo alcuni di questi3

3.3.1. Use Case

La modellazione dei casi d’uso è una forma più articolata di ingegneria dei requisiti. La

modellazione dei casi d’uso prevede tipicamente i seguenti passi:

• Individuare un potenziale confine del sistema

• Individuare gli attori

• Individuare i casi d’uso:

o Identificare il caso d’uso

o Identificare le principali sequenze degli eventi

3 Per dettagli maggiori si invita a consultare il seguente: http://www.uml.org/

In dettaglio:

• Attori: i ruoli assunti dalle persone e dalle cose che usano il sistema

• Casi d’uso: quello che gli attori possono fare con il sistema

• Relazioni: relazioni significative tra gli attori e i casi d’uso

• Confine del sistema: un rettangolo disegnato intorno ai casi d’uso per indicare il

confine del sistema oggetto del modello

Oltre alla rappresentazione grafica che segue:

Figura 3 Esempio di Use Case

Possiamo riassumere le attività adoperando delle tabelle, ad esempio:

Use Case : Database e Query

ID : 1

Descrizione Sommaria: Connessione al Database ed esecuzione query SQL. Il dataset

prodotto come output sarà utilizzato per realizzare il grafico, la produzione del file ARFF e la

generazione del report a video

Attore Unico (primario e secondario): Amministratore

Pre-‐Condizioni:

1. Il server per il database deve essere attivo

2. I driver per la connessione al database devono essere validi

3. Non ci devono essere altre query in esecuzione (accesso esclusivo)

Flusso:

1. Use Case avviato al momento dell’esecuzione del software


2. Si verifica la connessione al database

3. Si esegue la query di tipo Select

4. Si popola una struttura dati che verrà utilizzata per gli altri Use Case

Post-‐Condizioni:

1. La struttura dati deve essere disponibile per gli altri Use Case

Flusso Alternativo: generazione avvisi di errore

Use Case : ARFF

ID : 2

Descrizione Sommaria: Se la struttura dati prodotta dall’Use Case ID=0 non è vuota, allora si

procede alla generazione del file ASCII con formato ARFF che dovrà rispettare la struttura

decisa dai produttori di Weka


Pre-‐Condizioni:

1. La struttura dati deve essere disponibile e non deve essere vuota

Flusso:

1. Si individuano il nome delle colonne che saranno utilizzati come nome dei parametri

del file

2. Si individuano il numero di righe

3. Si esegue un loop sulle righe e sulle colonne per popolare una nuova struttura dati ad -‐

hoc per il file ARFF

4. Si scrive il contenuto della struttura dati creata al punto precedente in un file

Post-‐Condizioni:

1. Generazione del file con struttura ed estensione ARFF


Use Case : Grafico

ID : 3

Descrizione Sommaria: Il dataset prodotto in ID=0 è utilizzato per la generazione di un

grafico che sarà visualizzato a monitor e salvato su disco fisso


Pre-‐Condizioni:

1. Il dataset deve essere stato popolato dalla query SQL

Flusso:

1. Si estrapolano le colonne 1 e 4 dal dataset (relative a ID e valori di temperatura)

2. Si realizza e si salva il grafico

3. Il grafico è mostrato a schermo

Post-‐Condizioni:

• Generazione file di immagine contenente il grafico


3.3.2. Activity-Diagram

I diagrammi di attività possono essere interpretati come diagrammi di flusso che consentono

di modellare un processo come un’attività costituita da un insieme di nodi connessi da archi.

Questi diagrammi spesso sono chiamati, in letteratura, “diagrammi di flusso OO”. La loro

semantica è stata rivista con la pubblicazione delle ultime versioni di UML (versione 2 in

particolare) ed è fortemente basata sulle reti di Petri4.

Esistono tre categorie di nodi5:

1. Nodi azione: rappresentano unità discrete di lavoro atomiche all’interno dell’attività;

2. Nodi controllo: controllano il flusso attraverso l’attività;

3. Nodi oggetto: rappresentano oggetti usati nell’attività.

Gli archi rappresentano il flusso attraverso l’attività, possono essere suddivisi in due

categorie:

4 Utili indicazioni al seguente: http://www.agilemodeling.com/style/activityDiagram.htm 5 Si suggerisce il seguente strumento online per disegnare i diagrammi: https://creately.com/


1. Flussi di controllo: rappresentano il flusso di controllo attraverso l’attività;

2. Flussi di oggetti: rappresentano il flusso di oggetti attraverso l’attività.

Figura 4 Activity Diagram con costrutto condizionale e fork

4. Progettazione Terminate le fasi precedenti in cui sono stati raccolti ed analizzati i requisiti, si deve passare

dal “che cosa fare” alla fase di “come fare”. La fase di progettazione serve a stabile come la

realizzazione deve procedere. Sinteticamente possiamo affermare che l’input della

progettazione è il documento di specifica e l’output sarà il documento di progetto che diventerà

la guida per la codifica.

Esistono diversi strumenti a supporto della progettazione, alcuni sono dettagliati dall’UML

(per esempio: class diagram) altri invece sono strumenti autonomi quali OCL e Petri Net

(questi ultimi possono essere talune volte adoperati anche in fase di analisi)

4.1. Class Diagram Rappresentano la struttura di un sistema. Sono usati durante la fase di analisi dei requisiti e il

system design di un modello. È possibile definire diagrammi contenenti classi astratte e altri

in cui compaiono istanze delle stesse con i relativi attributi specificati. Ogni nodo del grafo

rappresenta una classe o un istanza con un nome (nel caso di un’istanza il nome è

sottolineato) e contiene i suoi attributi e il suoi comportamenti (le operazioni che essa

svolge). Ogni attributo ha un tipo e ogni operazione ha una firma. Le entità del grafo possono

essere interconnesse tramite archi con freccia, senza freccia o tratteggiati ed avere le seguenti

relazioni:

4.1.1. Associazione

L’arco semplice rappresenta una associazione che può essere specificata anche da un testo,

inoltre è possibile indicare le molteplicità: ad esempio un’entità X può essere associata ad una

o più entità Y in tal caso avremo il seguente diagramma:

Figura 5 Class Diagram: Associazione

4.1.2. Aggregazione

E’ possibile rappresentare chi contiene cosa sotto forma di grafo (o albero) utilizzando la linea

con il rombo terminatore come nella figura.

Figura 6 Class Diagram: Aggregazione

4.1.3. Composizione

Una particolare aggregazione che comporta l’esistenza di un’entità padre data un’entità figlio.

In particolare:

Figura 7 Class Diagram: Composizione

4.1.4. Ereditarietà

Indica l’ereditarietà tra entità: la classe figlio eredità attributi e operazioni del padre

semplificando il modello ed eliminando la ridondanza.

Figura 8 Class Diagram: Ereditarietà


Figura 9 Class Diagram per MWI

La classe MyTable2 utilizza oggetti di altre classi, ad esempio adoperando un oggetto della

classe XMLreader legge da un file XML i tre parametri necessari da passare ad un oggetto della

classe MySQLAccess che stabilisce la connessione al database ed esegue la query sql. Il

costruttore della classe MySQLAccess vuole tre parametri in input per stabilire la connessione

con MySQL. Lo stereotipo “usa” sulla linea tratteggiata può essere omesso, il suo significato è

univoco. L’elemento grafico sopra MySQLAccess è invece un commento.

4.2. Sequence Diagram I diagrammi di sequenza mostrano lo scambio di messaggi (cioè la chiamata ai metodi) tra

diversi oggetti in una situazione temporale precisa. Gli oggetti sono istanze di classi. I

diagrammi di sequenza mettono particolare enfasi sull'ordine temporale con cui i messaggi

sono inviati agli oggetti. Nei diagrammi di sequenza gli oggetti sono rappresentati con linee

verticali tratteggiate, con il nome dell'oggetto in cima. Anche l'asse temporale è verticale, e

aumenta andando in giù, in modo che i messaggi sono inviati da un oggetto all'altro nella

forma di frecce con l'operazione e il nome del parametro. Se il progetto è ben strutturato, ci

deve essere corrispondenza fra i blocchi dell’activity diagram e il sequence diagram. Il

diagramma permette di identificare puntualmente il ruolo di ciascun attore e di descrivere il

flusso prodotto dalle sue azioni. Ci sono differenze sostanziali fra il sequence diagram

introdotto con l’UML 2 con quello del precedente UML 1. La nuova versione consente di

rappresentare i costrutti decisionali, i cicli o esecuzione in parallelo: alt, loop e par

rispettivamente6.

Figura 10 Esempio di diagramma di sequenza (Sequence Diagram) – il diagramma è parziale

I rettangoli con sfondo verde indicano gli oggetti delle varie classi che sono utilizzati dal

metodo main della classe MyTable2. Lungo le frecce orizzontali tratteggiate possiamo

riscontrare l’istanza dei vari oggetti mentre sulle linee dense vi è la chiamata dei vari metodi.

4.3. OCL I linguaggi formali permettono di definire un’interpretazione univoca di una dichiarazione, a

differenza dei linguaggi naturali che spesso introducono ambiguità. OCL – Object Constraint

Language – è il linguaggio formale che affianca la modellazione di UML per risolvere le

ambiguità che i soli diagrammi potrebbero generare. I primi modelli formali quali Z e

Syntropy, prevedevano l’utilizzo della notazione matematica, questo sicuramente garantiva di

risolvere le ambiguità pur tuttavia rendeva il suo utilizzo confinato solo a una nicchia di

6 Per il disegno di sequence diagram: http://www.websequencediagrams.com/


utenti. Il linguaggio OCL è stato pensato proprio per estendere e superare questi limiti, la sua

sintassi è stata pensata per essere sia formale che semplice. Taluni autori, Warner ad esempio,

affermano che la sintassi di OCL si possa capire in pochi minuti di studio. Probabilmente tutto

ciò è vero se si pensa che le industrie ormai ne fanno un impiego diffuso. Le parole

maggiormente utilizzate sono context, pre, post e inv. Si può facilmente intuire che queste

servono a definire il contesto in esame, le pre-‐condizioni che devono essere verificate

(eventualmente facendo riferimento a frasi complesse, quindi condizioni che devono agire su

più attributi) e le post condizioni (ciò che si deve verificare dopo le pre-‐condizioni) e le

invarianti, ossia espressioni che devono essere sempre vere durante l’esecuzione

dell’applicazione.

Alcune espressioni OCL che potrebbero essere utilizzate per modellare MWI sono:

context MySQLAccess :: MySQLAccess( localhost : String, nomeDB: String, nomeUtente : String,

pwdUtente : String)

inv:

localhost != null

nomeDB != null

nomeUtente != null

pwdUtente != nulla

nomeUtente != pwdUtente Tabella 4 I esempio di OCL

In questo frammento di codice OCL, si specifica il “contesto” e si impone una invarianza, ossia

una condizione che deve essere sempre vera: i valori dei parametri non devono essere nulli e

il nome utente deve essere diverso dalla password.

context MySQLAccess :: connesso : Boolean

init: false Tabella 5 II esempio di OCL

Con questo tipo di istruzione OCL si può definire il valore iniziale che deve avere un attributo

particolare.

4.4. Reti di Petri Sono uno strumento per la modellizzazione di processi ed in particolare per la

modellizzazione delle comunicazioni e delle interazioni fra processi concorrenti. Quando si

avverte di descrivere un processo con sottoprocessi, si scopre di sovente che ci sono alcuni

sottoprocessi che devono essere eseguiti parallelamente e soprattutto in maniera

indipendente: potrebbe accadere che un determinato passaggio o una certa fase del processo

non possa verificarsi o non possa essere attivata fintanto che altre fasi o attività non sono

concluse o fino al verificarsi di determinate condizioni. Queste situazioni non possono essere

descritte attraverso un diagramma di flusso che per sua natura è pensato per descrivere

evoluzioni sequenziali. Infatti, in un diagramma di flusso le attività sono rigidamente

serializzate: due rami distinti di un diagramma di flusso non vengono mai “percorsi”

contemporaneamente, ma rappresentano due scelte decise secondo un criterio rigidamente

deterministico dipendente dall’esito della valutazione di una espressione booleana. Con le

Reti di Petri questo limite (la serializzazione degli step del procedimento) viene superato, ma

viene anche introdotto un formalismo grafico e semantico che permette di aggiungere una

“dimensione” ulteriore alle Reti di Petri rispetto ai diagrammi di flusso. Le RdP, infatti, non

solo permettono di rappresentare e di descrivere globalmente un processo, ma consentono

anche di seguirne l’evoluzione permettendo di visualizzare lo stato in cui si trova in un certo

istante la rete. Una Rete di Petri è un grafo che consiste di posti, transizioni ed archi che li

collegano; gli archi di input collegano i posti con le transizioni, mentre gli archi di output

collegano le transizioni con i posti. Possiamo dire che una Rete di Petri evolve passando

attraverso una serie di stati; si conferisce uno stato a una Rete di Petri mediante una

marcatura che consiste nell’assegnamento di un numero naturale a ogni posto. Graficamente,

questo si traduce nell’inserimento in ogni posto di un numero equivalente di token. I token

indicano lo stato di avanzamento delle operazioni descritte nei passi del processo.

Possiamo modellare con le RdP sia esperienze di vita quotidiana (esempio canonico:

preparazione di una ricetta) sia problemi più complessi e/o astratti quale quello in esame nel

presente documento7.

7 Oltre al materiale fornito nel corso, può tornare utile visionare il seguente: http://www.mat.uniroma3.it/users/liverani/doc/appunti_reti_di_petri.pdf


Figura 11 Esempio di marcatura della Petri Net per MWI

5. Implementazione

5.1. Dalla progettazione a Java : JML Java Modelling Language (JML) e' un linguaggio di specifica che permette di definire astrazioni

procedurali. Le specifiche vengono aggiunte all'interno del codice sorgente Java, tramite

commenti dotati di una speciale sintassi che precedono il metodo interessato. Questo significa

che il codice JML non viene letto dal compilatore Java, ma solo dagli strumenti di JML.

Adoperando JML i fatti introdotti con Alloy e tradotti in specifiche per OCL diventano dei

vincoli rigorosi direttamente all’interno del codice, ad esempio si può imporre che i metodi

accettino e ritornino un certo tipo ben specificato di parametro. Questo strumento che di fatto

è coercitivo, permette di appaltare lo sviluppo del codice anche a gruppi esterni, sarà JML a

verificare costantemente la corretta implementazione, quindi JML assume il duplice ruolo sia

di strumento documentale che di strumento di vincolo direttamente nel codice. Il codice

compilato non sarà sporcato da codice JML, questo perché esso apparirà come un commento

nella forma: /* @ statement JML @*/. Le principali direttive di JML sono:

• requires: definisce una pre-‐condizione sul metodo che segue

• ensures: definisce una post-‐condizione sul metodo che segue

• signals: definisce una condizione in base alla quale deve essere lanciata una eccezione

dal metodo che segue

• assignable: definisce di quali campi è consentito l'assegnamento dal metodo che segue

• pure: dichiara che il metodo che segue non ha effetti collaterali (è un'abbreviazione di

assignable \nothing)

• invariant: definisce una proprietà invariante della classe.

• also: dichiara che un metodo deve ereditare le condizioni dalla sua superclasse.

• assert: definisce una asserzione JML.

Nel seguito è illustrato un esempio di applicazione di JML al codice Java del progetto MWI8.

8 http://www.ibm.com/developerworks/java/library/j-jml/index.html


Figura 12 I Esempio di JML

Figura 13 II Esempio di JML con gestione del segnale d’errore

5.2. Test L’obiettivo di questa fase non deve essere quello di far vedere che il software non contiene

errori, bensì di trovarne il maggior numero possibile. Infatti per grandi programmi è

utopistico aspettarsi che il codice venga prodotto senza errori. Per raggiungere questo scopo

non è opportuno far testare il codice allo stesso team che lo ha prodotto: si assegna di solito

un team specifico per il test. La fase si esegue a vari livelli e consiste in operazioni distinte.

• Test di unità. Un’unità è il più piccolo blocco di software che ha senso collaudare, ad

esempio una singola funzione di basso livello viene verificata come un’entità a se

stante.

• Test di modulo. Un modulo è un insieme di unità interdipendenti.

• Test di sottosistema. Un sottosistema è un aggregato significativo di moduli spesso

progettati da team diversi, e quindi vi possono essere problemi di interfaccia.

• Test di sistema o integrazione. Si tratta del test del prodotto completo.

• α-‐test. Se il sistema è sviluppato per un unico cliente, viene portato nel suo ambiente

finale e collaudato con i dati sui quali dovrà normalmente operare.

• β-‐test. Se il sistema viene distribuito ad una comunità di utenti, viene dato in prova a

più utenti, che lo utilizzano e forniscono al produttore le loro osservazioni ed il

rilevamento degli errori riscontrati.

• Benchmark. Il sistema viene testato su dati standardizzati e di pubblico dominio per il

confronto con altri prodotti equivalenti già presenti sul mercato. Può venire richiesto

per contratto.

• Stress testing. Si verifica come si comporta il sistema quando è sovraccarico di lavoro,

portandolo al limite. Questo test sotto sforzo permette di causare un errore (da stress)

e verificare che il sistema fallisca in un modo accettabile (fail-‐soft).

Testing e debugging sono due concetti diversi. Il Testing serve a rilevare la presenza di un

errore. Il Debugging consiste nella localizzazione dell’errore, della sua analisi e della sua

correzione. Terminato il debugging si fa seguire il test di regressione: si verifica il

comportamento del modulo che è stato corretto nei confronti dei moduli con i quali coopera,

assicurandosi così che la correzione dell’errore non ne abbia introdotti di nuovi9.

9ftp://docenti.ing.units.it/arc_stud/Sbroiavacca/SistemiInformativi1_06/Ingegneria%20del%20Software%20%20Test%20e%20Collaudo.pdf


5.2.1. JUnit

JUnit è un framework open source per effettuare il testing in modo organizzato e semplice.

Come si può intuire dalla “J” è un framework scritto in Java e quindi gli esempi proposti

saranno tutti in Java. Comunque JUnit è una istanza della classe xUnit, cioè esistono

conversioni per un gran numero di linguaggi, fra i quali anche C#, C++ e Visual Basic. È stato

sviluppato da Erich Gamma e Kent Beck ed è scaricabile da http://www.junit.org. JUnit è nato

per la scrittura di test unitari. I test unitari sono dei test che vanno a verificare la correttezza

direttamente del codice, in ogni sua piccola parte. Questi test, che hanno avuto una grande

diffusione all’interno della extreme programming, vanno scritti ed eseguiti dal

programmatore stesso per ogni porzione di codice da lui sviluppata. I test funzionali, invece,

sono dei test che vanno a verificare che il software nella sua completezza funzioni

correttamente. Questi test trattano il sistema come se fosse una scatola nera alla quale danno

degli input e verificano la correttezza degli output. Devono essere ideati ed eseguiti da

personale che non ha partecipato alla costruzione del software. Un’alternativa all’uso dei test

unitari è sicuramente l’inserimento nel codice prodotto di comandi il cui unico scopo è di

effettuare debugging. La soluzione più semplice per questo scopo è sicuramente l’inserimento

di comandi tipo system.out.println atti a stampare variabili critiche per poterle analizzare.

Questa soluzione presenta però almeno due grossi inconvenienti: innanzitutto è necessario

andare a modificare il codice sorgente ogni qualvolta si voglia tracciare una nuova variabile,

in secondo luogo è necessario analizzare l’output alla ricerca di eventuali errori manualmente

e ad ogni esecuzione. Inoltre va sottolineato che per distribuire il progetto è necessario

eliminare tutti i comandi inseriti nel codice per il testing e, soprattutto, qualora si debba

apportare ulteriori modifiche ai sorgenti e si voglia testarli nuovamente è necessario

reinserire tutti i comandi precedentemente cancellati. Se per programmi brevi e semplici può

anche essere una soluzione valida, sicuramente per progetti di grosse dimensioni diviene

difficile e laboriosa tale gestione. JUnit, invece, permette una maggiore strutturazione dei test,

facilità nell’inclusione di nuovi test o nella eliminazione di altri e soprattutto un’immediata

lettura dei risultati. Infatti, come vedremo, la risposta dopo l’esecuzione di una batteria di test

in caso di successo è un semplicissimo OK. Questo velocizza non di poco l’esecuzione e la

verifica dei test. Inoltre, strutturando correttamente le classi adibite al testing, sarà possibile

distribuire il codice prodotto privato del codice di testing senza apportare alcuna modifica e,

se in un secondo momento si dovranno ripetere i test o aggiungerne di altri, non sarà

necessario riscriverli ma semplicemente rieseguirli. Pertanto, sebbene il lavoro richiesto per

la stesura dei test sfruttando JUnit possa sembrare eccessivo ad una prima analisi, è

assolutamente consigliato ricorrere a questa metodologia in quanto garantisce il corretto

funzionamento del codice prodotto. Forniamo un esempio di Junit su una classe con struttura

funzionale molto semplice:

Figura 14 Esempio di classe a cui sarà applicato JUnit

La classe MathOp oltre al costruttore, ha due metodi che accettano due interi e ritornano

rispettivamente la loro somma o sottrazione. Parallelamente a questa classe, ne scriviamo una

per i test case Per indicare a JUnit quali sono i metodi che effettuano i test è necessario

contraddistinguerli con l’annotazione @Test. In questo modo JUnit riconoscerà i metodi che

contengono le asserzioni e li tratterà di conseguenza:

Figura 15 Classe ombra per l'applicazione di JUnit

Con JUnit è possibile effettuare diversi tipo di test (con asserzioni diverse). Al momento

dell’esecuzione, un test si considera superato se tutte le condizioni specificate risultano

verificate.


• assertEquals(expected, actual), assertArrayEquals(expected, actual) : richiede

che il valore ‘expected’ sia uguale a ‘actual’

• assertTrue(cond): richiede che ‘cond’ abbia come valore: ‘true’

• assertFalse(cond): richiede che ‘cond’ abbia come valore ‘false’

• assertNull(obj): richiede che ‘obj’ sia un riferimento nullo

• assertNotNull(obj): richiede che ‘obj’ sia un riferimento non nullo

Nell’esempio precedente, in ognuno dei due test case è stato istanziato un oggetto MathOp.

JUnit mette a disposizione degli sviluppatori una funzionalità per eseguire delle istruzioni

prima che vengano eseguiti i test. Il metodo setUp() ha un’annotazione @Before che serve ad

indicare a JUnit che il metodo va eseguito prima dell’esecuzione dei test case. In questo modo,

il codice per inizializzare oggetti o risorse (ad esempio una connessione al DBMS) è

concentrato in un solo punto della classe di test. Analogamente a @Before, l’annotazione

@After indica a JUnit di eseguire il metodo dopo l’esecuzione dei test case.

Figura 16 Seconda versione della classe ombra

6. Conclusioni L’applicazione di tutti gli strumenti introdotti nel presente documento ha consentito sia di

risolvere l’obiettivo prefissato ma soprattutto di acquisire maggiore confidenza con la teoria e

con il ciclo di vita che ha portato al rilascio di un software di qualità. Alcune verifiche di

funzionamento, ci permettono di stabilire anche il tempo necessario per l’esecuzione del

software:

Configurazione utilizzata – MacBook Pro 2.4 GHz Intel Core 2 Duo – RAM 8 GB 1067 MHz

DDR3

Numeri di righe presenti nella tabella del database: 80

Tempo totale per connettersi al database MySQL, eseguire la Select, popolare la Jtable, salvare

il file ARFF, produrre il grafico e generare il file di immagine: 2.98s

Figura 17 Grafico della temperatura

Figura 18 JTable popolata da MySQL


Figura 19 Processing del file ARFF in WEKA

Figura 20 File ARFF

6.1. Fonti Oltre al materiale del corso e i siti inseriti nelle note a piè di pagina, sono stati consultati i

seguenti testi:

Sommerville I. Ingegneria del software. VIII edizione. Pearson Addison -‐ Wesley, 2007

Arlow J., Neustadt I. UML 2 e Unified Process: analisi e progettazione Object-‐Oriented. II

edizione. McGraw-‐Hill, Milano, 2006

6.2. Software di terze parti I seguenti software sono stati necessari per la progettazione e l’implementazione del

progetto:

• Alloy V4

• Pipe V4

• ArgoUML

• Eclipse con plugin per Junit

Documents

Progetto Ingegneria del Software - Computer Science Divisioncomputerscience.unicam.it/culmone/?download=Progetto Ingegneria del... · Il! presente! documento,! redatto! come! lavoro!