Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

tesi di laurea Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo

Anno Accademico 2009/2010

relatore Ch.mo prof. Marcello Cinque

correlatore ing. Catello Di Martino

candidato Luigi, Paolo Rossi matr. 534 000 308

A mio padre e mia madre

Non aetate verum ingenio apiscitur sapientia.

Indice

Introduzione 4

Capitolo 1. Wireless Sensor Network: Modellazione e Simulazione 7 1.1 Wireless Sensor Networks: Reti di Sensori senza filo 7 1.2 Progettare e Simulare una WSN 11 1.3 Il Tool Failure Model WSN Generator 19 1.3.1 Il simulatore Mobius 21 1.3.2 La topologia della rete 22 1.4 Motivazioni del remoting nella simulazione di WSN 24

Capitolo 2. Analisi dei Requisiti e Progettazione 27 2.1 Web Model WSN Generator: concetti chiave 27 2.2 Casi d’uso 31 2.3 Diminuire l’accoppiamento 33 2.3.1 La classe AmbientVar 35 2.3.2 Logging 36

Capitolo 3. Tecnologie e Strumenti per le Rich Internet Applications 38 3.1 Le RIA e metriche di valutazione 38 3.1.1 AJAX e JavaScript 40 3.1.2 Caratteristiche e metriche di valutazione dei framework 43 3.2 Java Server Pages e IceFaces 44 3.3 Openlaszlo 48 3.4 Adobe Flex 50 3.5 Echo 3 52 3.6 Google Web Toolkit 54 3.7 Apache Click 57

Capitolo 4. ZK Framework 59 4.1 Direct RIA: cos’è ZK Framework 59 4.2 Caratteristiche principali di ZK Framework 61 4.3 Integrazione con Java: il funzionamento di ZK Framework 62 4.3.1 Framework Server -Centrico e Client-Centrico 65 4.4 Estensibilità: MVC, Spring, Hibernate ed Integrazione 67 4.4.1 Il Pattern MVC con ZK 67 4.4.2 Spring con ZK 71 4.4.3 Hibernate con ZK 73

II 4.4.4 Integrare linguaggi in ZK 75 4.5 Qualità del supporto: ZK Forge e case studies 76 4.6 Curva di apprendimento: programming skills e linguaggio ZU ML 77 4.7 Strumenti di supporto: i tool di ZK 78 4.8 Costi di sviluppo: le versioni disponibili 81 Capitolo 5. Implementazione del tool 82 5.1 Pattern MVC e struttura della RIA 82 5.2 Le classi controller 84 5.3 Classi di utilità del tool web -based 85 5.4 La view ed i file ZUL 86 5.5 Il Disegno della Topologia: draw2d 88 5.6 Esempi di funzionamento 91

Conclusioni 95 Bibliografia 97 Sitografia 98

III Introduzione

I recenti sviluppi nel campo delle reti di sensori senza filo hanno ampliato lo spettro delle loro possibili applicazioni, l'efficienza di monitoraggio e i loro costi di sviluppo e di produzione. Se da una parte tale progresso ha portato a dei risultati sicuramente ottimali riguardo la loro applicazione concreta nel settore delle reti wireless, d'altro canto non può non essere osservato che tale procedimento innovativo ha condotto ad un diverso approccio nella progettazione, modellazione e simulazione delle Wireless Sensor Networks. Ciò in ragione della difficoltà di gestire un numero elevato di nodi sensore, ed inoltre, nei costi in termini economici e di tempo per testare in maniera pratica il funzionamento di questi microsistemi al fine di valutarne l'efficienza della trasmissione, l'affidabilità e la tolleranza ai guasti. In ragione di quanto appena affermato nella prassi applicativa delle Wireless Sensor

network (WSN), si è posta l'esigenza della modellazione del sistema da implementare e della simulazione dello stesso al fine di valutare i risultati ottenuti e correggere le scelte effettuate riguardo la loro progettazione nelle varie modalità di utilizzo. In tal senso è stata diretta l'attività del laboratorio Mobilab del Dipertimento di Informatica e Sistemistica, il quale ha apportato un notevole contributo sia nell'approccio della modellazione e simulazione dei sistemi WSN, sia nell'implementazione di framework e strumenti software. Nel procedere a tale attività il suddetto laboratorio ha adottato un metodo che si basa sulla

4 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool necessità di valutare a priori l’affidabilità dei sistemi, ricorrendo a modelli che possano rappresentare adeguatamente le caratteristiche rilevanti del sistema stesso e a metriche e tecniche di valutazione dell’affidabilità. In seguito tale attività si è concretizzata nell'implementazione di un tool per la generazione automatica di modelli di fallimento. Nell'ambito di tale lavoro sono emerse delle problematiche riguardo agli utilizzi di questo strumento software con i framework di sviluppo WSN che sono stati progettati e sviluppati dal Mobilab, poiché tali applicazioni richiedono notevoli risorse di calcolo nonché determinano difficoltà in ordine alla configurazione dei software e distribuzione degli stessi agli utenti finali.

E' nata, pertanto, l'esigenza di convogliare questi strumenti ed in particolare il tool di generazione automatica dei modelli di fallimento, in un ambiente operativo che abbia determinate caratteristiche: immediata disponibilità, estensibilità, facile manutenibilità, sicurezza dei dati, minore carico computazionale, riduzione costi di gestione e accessibilità. Si è resa, inoltre, l'esigenza di associare alle suddette caratteristiche una funzionalità che permetta allo sviluppatore WSN di riprodurre graficamente la topologia della rete da modellare e simulare senza l'utilizzo di ulteriori strumenti software. Le suddette caratteristiche hanno portato alla realizzazione di uno strumento web-based per la simulazione e modellazione remota di reti di sensori senza filo che è oggetto di trattazione del seguente lavoro di tesi.

Al fine di pervenire alla realizzazione di tale strumento sono state effettuate delle ricerche sulle tecnologie più diffuse per la realizzazione di applicazioni web che presentano più elementi di somiglianza in ordine al loro comportamento e alla visualizzazione degli applicativi desktop tradizionali, ovvero più simili non ad una web application tradizionale ma ad una RIA (Rich Internet Application) al fine di rendere più agevole l'utilizzo dello stesso nei confronti dell'utente finale. Al fine di addivenire a tale risultato si è reso necessario strutturare tale lavoro di tesi nel seguente modo: il Cap. 1 è dedicato ad una panoramica delle wireless sensor network, delle motivazioni che portano al remoting nella simulazione di WSN ed introduce il lettore

5 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool al dominio del problema. La progettazione e le scelte principali che sono state effettuate in ordine all'implementazione del suddetto strumento software sono poste ad oggetto del Cap. 2, nel quale contemporaneamente si procede alla analisi dei suoi requisiti. La progettazione della applicazione web procede nel Cap. 3, attraverso una panoramica delle tecnologie più diffuse per lo sviluppo delle RIA alla stregua delle seguenti metriche di valutazione: integrazione con Java, estensibilità, qualità del supporto, curva di apprendimento, strumenti di supporto e costi di sviluppo. Il Cap. 4 è dedicato al framework ZK procedendo allo studio delle sue caratteristiche, del suo funzionamento e delle sue potenzialità applicative sfruttate in combinazione con il tool web-based implementato. Tale iter progettuale si concretizza nel Cap. 5, il quale è completamente dedicato alla implementazione del tool, nonché all’esposizione della funzionalità disegno della topologia della WSN e su come si è utilizzato il framework per realizzarla.

6 Capitolo 1 Wireless Sensor Network: Modellazione e Simulazione

1.1 Wireless Sensor Networks: Reti di Sensori senza filo I recenti progressi tecnologici nei sistemi MEMS (Micro Electro Mechanical System), nelle comunicazioni wireless e nell'elettronica digitale hanno permesso lo sviluppo di piccoli apparecchi a bassa potenza dai costi contenuti, multifunzionali e capaci di

comunicare tra loro tramite tecnologia wireless a raggio limitato. Questi piccoli apparecchi, chiamati nodi sensori, sono formati da componenti in grado di rilevare grandezze fisiche (sensori di posizione, temperatura, umidità ecc.), di elaborare dati e di comunicare tra loro. Un sensore è comunemente definito come un particolare trasduttore che si trova in diretta interazione con il sistema misurato. Una rete di sensori (detta anche sensor network) è un insieme di sensori disposti in prossimità oppure all'interno del fenomeno da osservare. Questi piccoli dispositivi sono

prodotti e distribuiti in massa, hanno un costo di produzione trascurabile e sono caratterizzati da dimensioni e pesi molto ridotti. Ogni sensore ha una riserva d'energia limitata e non rinnovabile e, una volta messo in opera, deve lavorare autonomamente; per questo motivo tali dispositivi devono mantenere costantemente i consumi molto bassi, in modo da avere un maggior ciclo di vita. Per ottenere la maggior quantità possibile di dati occorre effettuare una massiccia distribuzione di sensori (nell'ordine delle migliaia o decine di migliaia) in modo da avere una alta densità (fino a 20 nodi/m3) e far sì che i nodi

siano tutti vicini tra loro, condizione necessaria affinché possano comunicare.

7 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

Fig. 1.1 – un esempio di Wireless Sensor Network – monitoraggio incendi

Una delle più comuni applicazioni in cui è possibile far uso di una rete di sensori consiste nel monitoraggio di ambienti fisici come il traffico in una grande città oppure dati rilevati da un'area disastrata da un terremoto. I nodi sensore all'interno di una rete hanno la possibilità di collaborare tra loro dal momento che sono provvisti di un processore on-board; grazie a quest'ultimo, ciascun nodo, invece di inviare dati grezzi ai nodi responsabili della raccolta dei dati, può effettuare delle semplici elaborazioni e trasmettere solo i dati richiesti e già elaborati. La comunicazione, realizzata tramite tecnologia wireless a corto raggio, è solitamente di tipo asimmetrico in quanto i nodi comuni inviano le informazioni raccolte ad uno o più nodi speciali della rete, detti nodi sink, i quali hanno lo scopo di raccogliere i dati e trasmetterli tipicamente ad un server o ad un calcolatore. Una comunicazione può avvenire autonomamente da parte del nodo quando si verifica un dato evento, o può venire indotta dal nodo sink tramite l'invio di una query verso i nodi interessati.

Le reti di sensori possono essere utilizzate in numerose applicazioni; tuttavia la

8 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione realizzazione di queste ultime richiede l'uso di tecniche utilizzate anche nelle reti wireless ad hoc. Sfortunatamente, molti degli algoritmi usati nelle reti ad hoc non sono compatibili con i requisiti di questo tipo di reti. I principali motivi derivano dal fatto che:  Il numero di nodi che compongono una rete di sensori può essere di alcuni ordini di grandezza maggiore rispetto al numero di nodi in una rete ad hoc  I nodi sono disposti con un’alta densità  I nodi sono soggetti a guasti

 La topologia di una rete di sensori può cambiare frequentemente a causa di guasti ai nodi o della loro mobilità  I nodi utilizzano un paradigma di comunicazione broadcast mentre la maggior parte delle reti ad hoc sono basate su una comunicazione di tipo punto-punto  I nodi sono limitati rispetto ad alimentazione, capacità di calcolo e memoria  I nodi solitamente non possiedono un identificatore globale (come l’indirizzo IP dei computer)

 I nodi necessitano di una stretta integrazione con le attività di rilevamento Per questo motivo, questa tipologia di rete necessita di algoritmi pensati e realizzati in maniera specifica per gestire la comunicazione e l’instradamento dei dati. Le reti di sensori possono migliorare in modo significativo la qualità delle informazioni: ad esempio possono garantire una elevata fedeltà, possono fornire informazioni in tempo reale anche da ambienti ostili e possono ridurre i costi di trasmissione delle stesse informazioni.

Lo scopo fondamentale di una rete di sensori è di produrre su un periodo esteso di tempo, una informazione globale significativa ottenuta da una serie di dati locali provenienti dai singoli sensori. È importante notare che la rete deve essere realizzata in modo da garantirne l'integrità per un periodo di tempo che sia il più lungo possibile, allo scopo di ottenere informazioni accurate anche in caso di attacco alla rete da parte di organi esterni o di cedimenti hardware. Il fatto che un singolo sensore sia dotato di una piccola quantità di energia non deve impedirgli di inviare le informazioni elaborate, che verranno raccolte e unite alle

9 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione informazioni provenienti dagli altri sensori. Un'importante via da seguire consiste nel rilevare il maggior quantitativo possibile di dati locali, evitando la trasmissione dei dati inefficienti attraverso la rete. Una rete di sensori quindi può essere vista come un insieme di sensori di diverso tipo capaci di rilevare grandezze come temperatura, umidità, pressione, luce, ma anche capaci di rilevare il movimento di veicoli, la composizione del terreno, livello di rumore, etc. Sono tantissime le applicazioni in cui possono essere impiegate WSN rispetto ad altre soluzioni, per migliorarne l’affidabilità e ridurne i costi. I principali impieghi, ad esempio, possiamo trovarli negli ambiti militari, ambientali, sanitari, casalinghi e commerciali. Nell’ambito militare le possibili applicazioni vanno dal monitoraggio di forze alleate, equipaggiamenti e munizioni alla sorveglianza del campo di battaglia. E’ possibile usare una rete di sensori per effettuare il riconoscimento di nemici, la stima dei danni di una battaglia oppure il riconoscimento del tipo di attacco (nucleare, biologico o chimico).

Questo col vantaggio che, essendo una rete di sensori basata su una disposizione densa di nodi monouso ed a basso costo, la distruzione di alcuni nodi da parte del nemico non danneggia le operazioni militari come potrebbe accadere con la distruzione di sensori tradizionali. Nell’ambito ambientale, le reti di sensori potrebbero essere utilizzate per effettuare il monitoraggio di una foresta e rilevare prontamente eventuali incendi, per la previsione e rilevazione di inondazioni, oppure per il monitoraggio del movimento di uccelli, piccoli animali, insetti con l’obiettivo di studiarne l’habitat e il loro comportamento. Più nello specifico, le reti di sensori possono essere utilizzate in ambito ambientale nell'agricoltura di precisione: monitorare il livello dei pesticidi nell'acqua, il livello di erosione del terreno e il grado di inquinamento dell'aria in tempo reale. Sempre nel settore ambientale, le reti di sensori possono essere di interesse per studiare gli spostamenti ed il dinamismo all'interno dei ghiacciai. A tal proposito i sensori vengono distribuiti all'interno del ghiaccio a profondità differenti. I sensori sono capaci di rilevare temperatura e pressione comunicando con una stazione base posizionata in cima al ghiacciaio che provvederà al

10 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

trasferimento di questi a chi di competenza. Nell’ambito sanitario gli utilizzi delle reti di sensori sono rivolte a fornire un'interfaccia per le persone affette da handicap, al monitoraggio di dati fisiologici, all'amministrazione ospedaliera sia essa relativa ai pazienti che ai medici (per una facile rintracciabilità). Inoltre è anche possibile usare i sensori per l'identificazione di allergie. L’utilizzo di una rete di sensori in ambito domestico è potrebbe focalizzarsi sull'automazione delle abitazioni: l’utilizzi di nodi, inseriti anche negli elettrodomestici,

possono interagire l'uno con l'altro e anche con reti esterne tramite l'utilizzo di internet o del satellite permettendo la gestione dell’habitat familiare anche da distanze remote. L'ambiente domestico viene ad assumere così le stesse caratteristiche di un piccolo centro fornito di una rete in grado di mettere in comunicazione tra loro tutti i vari strumenti di cui l'ambiente è composto. In ambito commerciale l’utilizzo di WSN abbraccia i campi più disparati: controllo ambientale di uffici, rilevamento furti d’auto, rilevamento della posizione e del movimento

dei veicoli (car tracking), monitoraggio del traffico, monitoraggio del consumo energetico di uffici e abitazioni, etc.

1.2 Progettare e Simulare una WSN La progettazione di una rete di sensori è influenzata da molti fattori che non solo sono necessari per la progettazione della rete, ma influenzano a loro volta la scelta degli algoritmi utilizzati nella rete stessa. Tra i più importanti citiamo:

 Tolleranza ai gusti: Nella rete di sensori c'è la possibilità che alcuni nodi della rete siano affetti da malfunzionamenti o guasti le cui cause possono essere danni fisici, interferenze o batterie scariche. La tolleranza ai guasti è la capacità di far funzionare una rete di sensori anche in caso di malfunzionamento da parte di alcuni nodi. I protocolli e gli algoritmi possono essere progettati in modo da garantire il livello di tolleranza ai guasti richiesto dalla rete. Il livello di tolleranza dipende fortemente dall'applicazione

in cui viene utilizzata la rete di sensori (uso militare, domestico, commerciale, etc...).

11 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

 Scalabilità Il sistema deve essere in grado di funzionare anche all'aumentare del numero di nodi (che possono andare da un basso numero di unità, fino ad arrivare a qualche milione di sensori). La scalabilità può essere ottenuta anche sfruttando la natura densa delle reti di sensori.  Costi di produzione Poiché una rete di sensori è formata da un grande numero di nodi, il costo di un

singolo nodo è molto importante. Se il costo della rete è maggiore rispetto all'utilizzo dei sensori tradizionali allora l'uso di una rete di sensori non è giustificabile. Il costo di un nodo sensore dovrebbe perciò essere abbastanza basso: un obbiettivo non molto facile da raggiungere in quanto un nodo ha spesso molte unità hardware: processore, campionatore, GPS, sistema radio e sensori di vario genere, e tutte queste cose portano ad un incremento del costo di un sensore.  Ambiente Operativo

I sensori sono disposti molto vicino o addirittura all'interno del fenomeno da osservare. Perciò, spesso, si trovano a lavorare in zone geografiche remote (es: all'interno di un macchinario, in fondo all'oceano, sulla superficie dell'oceano durante un tornado, in una zona biologicamente o chimicamente contaminata, in un campo di battaglia etc..) e senza la supervisione dell'uomo. Tutto ciò dà un'idea delle condizioni sotto le quali i sensori devono essere capaci di funzionare (devono sopportare alte pressioni se lavorano in fondo all'oceano, alte o basse temperature etc..).

 Topologia della rete Un gran numero di nodi sono disposti l'uno accanto all'altro a volte anche con un'alta densità. Questo richiede un'attenta attività per il mantenimento della topologia. Il mantenimento e il cambiamento della topologia può essere diviso in tre fasi: i) Pre-deployment e deployment phase: i sensori possono essere sia gettati sia disposti uno ad uno nell'ambiente; infatti possono essere gettati da un aereo, da una catapulta, collocati uno ad uno da un robot o da una persona umana.

ii) Post-deployment phase: i cambiamenti topologici della rete sono dovuti al

12 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

cambiamento della posizione dei nodi, oppure alla variazione della raggiungibilità di un nodo, dell'energia disponibile, alla presenza di malfunzionamenti etc... iii) Re-deployment of additional nodes phase: nodi sensore addizionali possono essere ridisposti in qualsiasi momento per rimpiazzare i nodi malfunzionanti o a causa della dinamica dei task. L'aggiunta di nuovi nodi comporta la necessità di riorganizzare la rete. L'alta frequenza di cambiamenti topologici e il vincolo stringente del risparmio energetico richiedono protocolli di routing molto particolari.

 Consumo energetico Un sensore è dotato di una limitata sorgente di energia. Il tempo di vita di un nodo sensore dipende molto dal tempo di vita della batteria. In una rete di sensori ogni nodo ha il ruolo sia di generare che di ricevere dati, perciò la scomparsa di alcuni nodi può portare a significativi cambiamenti topologici che possono richiedere una riorganizzazione della rete e del routing. È per queste ragioni che molte ricerche si stanno concentrando sulla creazione di protocolli e algoritmi power-aware, cioè

protocolli che ottimizzano il consumo energetico. Mentre nelle reti mobili e nelle reti ad hoc il consumo di energia è un importante fattore ma non è il principale (che risulta invece il soddisfacimento della QoS, cioè della qualità del servizio), nelle reti sensoriali il consumo di energia è la principale metrica per valutare le performance: questo perché nelle altre reti è possibile ricaricare o cambiare le batterie dei nodi mentre nelle reti sensoriali una volta che la batteria è scarica il nodo è da considerarsi morto. Il consumo di energia in un nodo sensore è essenzialmente dovuto alle tre

principali attività svolte dal nodo: i) Sensing: la potenza necessaria per effettuare il campionamento dipende dalla natura dell'applicazione; ii) Data processing: l'energia spesa nel processare i dati è molto piccola se comparata a quella spesa per la comunicazione; iii) Communication: dei tre fattori è quello che necessita della maggior quantità di energia. La comunicazione comprende sia la ricezione che la trasmissione di dati i cui

costi energetici possono essere ritenuti uguali.

13 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

Un ultimo fattore, importantissimo per la progettazione di una rete di sensori, è l’affidabilità (in inglese dependability). Esprimendo questo fattore nel senso più ampio di “sistema”, possiamo dire che un sistema è detto dependable se esibisce una probabilità alta di comportarsi così com'è definito nella sua specifica, ovvero l'abilità di un sistema di fornire un servizio che può essere considerato "fidato" in maniera giustificata. Il concetto di dependability viene solitamente utilizzato (insieme ad altri concetti che caratterizzano la cosiddetta “qualità del sistema”) come concetto base per definire sia la specifica che il rispetto della specifica da parte del sistema; nel fare ciò diviene fondamentale poter valutare la dependability attraverso opportune tecniche. La valutazione della dependability costituisce un’operazione utile e versatile in ogni fase del ciclo di vita di un sistema. Durante la fase di progettazione può conferire fiducia nelle scelte progettuali effettuate, validando e confrontando le diverse soluzioni individuate, durante la vita operativa del sistema permette di rilevare eventuali colli di bottiglia per l’affidabilità e suggerisce quali siano le soluzioni da adottare in future revisioni. Per poter effettuare una valutazione della dependability è necessario poter valutare caratteristiche sia qualitative che quantitative del sistema. Soffermandosi su quest’ultime, le tecniche di analisi quantitativa si possono classificare in tecniche basate su misure e tecniche modellistiche, a loro volta suddividibili in tecniche analitiche e simulative.  Tecniche basate su misure Le tecniche basate su misure si fondano sull’osservazione diretta del sistema sotto

analisi (o di un suo prototipo) utilizzando appositi moduli software e hardware chiamati monitor (per questo spesso queste tecniche sono chiamate tecniche di monitoraggio). Gli scopi di queste tecniche sono molteplici: permettono la caratterizzazione qualitativa e quantitativa del carico di lavoro, delle performance e dell'utilizzo delle risorse, informazioni utili ad esempio per creare un modello del sistema, caratterizzare l'ambiente in cui il sistema opera e validare un modello creato. Questo metodo è chiaramente costoso e complesso, e inoltre non sempre è attuabile

(si pensi al caso in cui il sistema non esista ancora e debba essere progettato), per di

14 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

più la dependability risulta spesso di difficile valutazione in quanto necessita di lunghi tempi di osservazione.  Tecniche basate su modelli Un modello è una rappresentazione fisica, matematica, logica o concettuale di un sistema di entità, fenomeni o processi. Lo scopo che si pone un modello è quello di ricapitolare la conoscenza di un fenomeno e del suo comportamento senza il bisogno di un testbed, o di una misura diretta sul sistema. I modelli sono tipicamente usati

quando è impossibile o poco pratico generare le condizioni sperimentali nelle quali gli scienziati possono direttamente misurare i risultati. Un modello è sempre frutto di assunzioni che si fanno sul sistema, ciò è inevitabile dal momento che la realtà è spesso troppo complessa per essere modellata senza l’uso di semplificazioni, più queste sono numerose più l’accuratezza e l’attinenza del modello diminuiscono e conseguentemente i risultati che si ottengono da esso si allontanano dal comportamento reale del sistema. L’uso di modelli richiede sempre di trovare un

punto di equilibrio tra la fedeltà del modello, ovvero l’accuratezza con cui questo rappresenta la realtà, e la trattabilità del modello, ovvero la possibilità di definire e risolvere il modello per ottenere le misure di interesse.  Tecniche analitiche La tecnica analitica (come anche quella simulativa) è basata sulla costruzione di un modello del sistema e delle sue componenti; un modello rappresenta le nostre assunzioni sul comportamento del sistema da analizzare. Nello specifico nei modelli

analitici le componenti del sistema sono rappresentate attraverso variabili di stato e parametri, e le loro interazioni sono rappresentate attraverso relazioni fra queste quantità. I limiti delle tecniche analitiche per la valutazione della dependability stanno nella maneggevolezza e utilizzabilità del modello nei casi di sistemi di reale interesse, in tali casi può spesso risultare difficile (anche se teoricamente possibile) riuscire a trovare una rappresentazione esplicita che possa essere usata in maniera semplice: la capacità di descrizione del modello e la sua aderenza al sistema reale stabilisce

l’eventuale necessità di passare ad un approccio simulativo.

15 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

 Tecniche simulative Le tecniche simulative sono uno strumento potente sia per predire il comportamento futuro di un sistema già esistente (forecasting), sia come supporto alla progettazione per valutare la dependability di un sistema prima che venga implementato e dando quindi i mezzi per la convalida del sistema o, in caso contrario, indicazioni utili al miglioramento del sistema stesso fornendo la possibilità di confrontare soluzioni progettuali differenti; inoltre permette una valutazione del sistema in condizioni rare o

pericolose, se studiate sul sistema reale, senza l’uso di tecniche invasive su quest’ultimo e con la possibilità di effettuare la simulazione con diverse configurazioni del sistema e con riferimento ad intervalli temporali di qualsiasi durata e con l’ulteriore vantaggio della riproducibilità della simulazione, cosa non sempre possibile nella realtà fisica; tutto ciò con costo, valutato in termini di tempo e complessità, generalmente minore se paragonato a tecniche basate su misure dirette del sistema. Le tecniche simulative consistono nella riproduzione del comportamento

dinamico del sistema nel tempo, viene generata così una storia artificiale del sistema che può essere usata per il suo studio; per fare ciò è necessaria la presenza di un modello simulativo che, con un determinato formalismo, descriva il comportamento del sistema e l'esecuzione di un software dedicato detto simulatore tale da permettere la rappresentazione dell'evoluzione temporale del sistema e da fornire una stima delle misure di interesse. Infatti la simulazione è una tecnica model based, e presuppone quindi l'esistenza di un modello che sia adeguatamente aderente al sistema reale

oggetto di studio, ossia fornisca con sufficiente accuratezza una descrizione del comportamento del sistema. Per valutare le caratteristiche che un tool web-based deve avere nella simulazione di reti wireless di sensori, analizziamo dapprima come l’utente interagisce con i modelli analitici e la simulazione. Infatti I modelli analitici sono usati per definire il fallimento e il funzionamento di riconfigurazione del sistema (ad esempio, per modelli WSN vengono presi in considerazione l’esaurimento della batteria, guasti hardware e ripristino guasti, fallimenti di comunicazione, ecc.) e per eseguire le misurazioni desiderate. D’altra parte, i

16 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione simulatori di funzionamento vengono usati per calcolare cifre utili per generare e configurare modelli analitici che hanno come parametri valori realistici (ad esempio, simulatori di funzionamento di WSN possono essere usati per mettere a punto numero e tipi di nodi e la topologia di connessione, per caratterizzare il carico di lavoro in esecuzione sui nodi, per valutare calcoli e cifre significative, come il consumo di energia, il profilo di propagazione wireless, ecc.). La simulazione di modelli analitici può essere suddivisa in due parti principali: i) generando il modello analitico attraverso i risultati delle simulazioni e preferenze dell’utente, e ii) gestendo i cambiamenti ottenuti durante l’evoluzione dei modelli analitici aggiornando il modello analitico con i nuovi valori ottenuti, cercando di evitare di eseguire nuove simulazioni ogni volta che avvengono cambiamenti.

Fig. 1.5 – Diagramma del procedimento adottato nella modellazione e nella simulazione di WSN.

Dal diagramma si può notare che nel passo 1 l’utente fornisce gli input necessari per specificare il sistema in oggetto e per configurare lo scenario da sperimentare. Per una

17 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

WSN, equivale a specificare: i) il numero ed il tipo di nodi, ii) la topologia della rete, iii) il carico di lavoro (ad esempio le applicazioni da eseguire) su ogni nodo, iv) il tipo di radio installata sui nodi, v) l’algoritmo di routing adottato, vi) il tipo di tecnologia di batterie per ogni nodo e vii) la tecnologia hardware di sensing adottata su ogni nodo. Questi input vengono usati per configurare i simulatori di funzionamento adottati (Tossim, Mobius, Avrora, etc.). In questa fase l’utente fornisce anche un set di metriche da valutare, come per esempio disponibilità, performance, etc.

E’ importante notare che quest’approccio consente all’utente di lavorare all’interno del suo dominio di conoscenza: ovvero, uno sviluppatore di WSN interagisce esclusivamente con l’ambiente relativo al suo dominio applicativo (numero, tipo e posizioni dei nodi, programmi e algoritmi da eseguire sui nodi, etc.) e alla fine del processo ottiene le misurazioni richieste senza sapere o preoccuparsi di come le misurazioni vengono calcolate e, cosa più importante, non ha bisogno di conoscere i dettagli sui modelli analitici utilizzati.

Il passo 2 riguarda la simulazione del comportamento del sistema in oggetto. L’obiettivo della simulazione è valutare i parametri necessari richiesti dall’external engine per generare e popolare il modello analitico, durante i passi 3 e 4. I parametri del modello possono essere sia statici che dinamici: i parametri statici sono relativi agli aspetti che non mutano durante la simulazione del modello analitico (ad esempio per una WSN sono la piattaforma hardware, la tecnologia della batteria, la tecnologia di comunicazione radio, etc.), i parametri dinamici dipendono invece dalla configurazione corrente del sistema, ad esempio il numero dei nodi WSN guasti, il numero di nodi isolati, il rate di trasmissione di ogni nodo, etc. e necessitano di essere ricalcolati ad ogni cambiamento durante simulazione del modello analitico. Nel caso di WSNs, esempi di parametri calcolati sono il profilo di consumo energetico per ogni nodo, la probabilità di perdita pacchetti di ogni link, e le caratteristiche dei workload, ovvero il duty-cycle (la media percentuale del lavoro utile eseguito da ogni nodo non in fase di stand-by) e la dimensione media dei pacchetti trasmessi/ricevuti.

La generazione automatica del modello analitico viene effettuata nel passo 3 dal Model

18 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

Generator. Il Model Generator produce modelli analitici partendo da una predefinita libreria di template modello, e il numero e il tipo di modelli da generare dipendono dagli input dell’utente. Per esempio, N modelli di nodo saranno generati per una WSN composta di N nodi. Ogni modello di nodo verrà poi specializzato a seconda della topologia (la quale specifica i vicini di ogni nodo), della piattaforma hardware (dalla quale dipenderà il modello di fallimento), etc. I valori iniziali dei parametri del modello vengono impostati partendo dai risultati delle simulazioni e da un set predefinito di parametri, come

ad esempio il failure rate dei componenti hardware. Il passo 4 riguarda la simulazione del modello analitico generato. Risulta chiaro come il funzionamento di un singolo nodo modifichi il comportamento dell’intera rete in modi inimmaginabili, e viceversa differenti scelte da parte dell’utente (come ad esempio l’algoritmo di routing) influenzino il comportamento di ogni singolo nodo. Per cercare di dominare questa complessità, utilizziamo modelli parametrici e riusabili, i quali sono autonomi e capaci di adattarsi ai cambiamenti indotti da altri modelli.

Infine, durante la simulazione, vengono valutate le metriche scelte e i risultati vengono proposti all’utente al passo 5. A questo punto, in dipendenza dai risultati ottenuti, l’utente può decidere se necessario di rivedere le proprie scelte e di riprogettare il sistema.

1.3 Il Tool Failure Model WSN Generator L’uso di strumenti quali la simulazione possono mostrare la necessità dell’apporto di modifiche alle specifiche iniziali, al progetto del sistema da implementare, o allo stesso

modello, ciò porterà ad una nuova simulazione in un processo iterativo di modifiche dove la flessibilità e la propensione al cambiamento è fondamentale, e ciò viene ben supportato da un tool di generazione automatica dei modelli di fallimento. Il supporto di un tool per la generazione automatica di modelli pone il modellista ad un livello di astrazione più alto rendendo la modellazione stessa più flessibile ed i modelli prodotti generali e facilmente particolarizzabili. L’idea si fonda sulla costruzione di un modello versatile e rappresentativo di un’ampia gamma di sistemi da un lato e sulla possibilità, offerta da un

generatore automatico, di specializzare tale modello ottenendo gli effettivi modelli

19 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione utilizzabili per la simulazione di un dato particolare sistema senza snaturare la generalità del modello iniziale e senza apportarne modifiche dirette; si è potuto così ottenere, per il particolare caso di studio, a partire da un modello che descrivesse in modo generale una famiglia di reti WSN, la specializzazione a una data rete con un proprio numero di nodi e una propria topologia tramite generazione automatica.

Fig. 1.2 – L’applicazione Failure model WSN Generator

Il Tool Failure Model WSN Generator, progettato e implementato nel lavoro di tesi [4], consiste in un applicazione desktop scritta in Java con gui Swing in cui l’utente: i) immette la path in cui si trovano i file della topologia da analizzare ii) seleziona la quantità di nodi presente nella topologia, il tempo di simulazione desiderato e la scelta di un’ottimizzazione del modello da generare iii) seleziona il percorso in cui verranno generati i file del modello da simulare. L’applicazione è formata da una serie di classi progettate partendo da un reverse- engineering del simulatore Mobius adottato, le quali dagli input dell’utente e dal click del tasto “Generate” si occupano di ricavare dalla topologia il modello corretto in forma di progetto Mobius da simulare, includendo sorgenti ed header in c++ necessari al progetto e librerie del modello di fallimento. La fase della generazione del modello viene descritta da

20 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

una serie di messaggi inviati ad una JtextArea della GUI e alla Console di Sistema: alla fine della generazione del modello di fallimento, l’applicazione lancia il simulatore Mobius per la compilazione dei file e per la simulazione.

Fig. 1.3 – Il nuovo approccio alla modellazione e simulazione utilizzato da Failure Model WSN Generator

1.3.1 Il simulatore Mobius Il tool Failure Model WSN Generator sfrutta il funzionamento del software Mobius[s1], uno strumento per la modellazione del comportamento di sistemi complessi. Benchè sia stato originariamente sviluppato per lo studio della reliability, availability, e le

performance di sistemi di elaborazione e sistemi di rete, l'uso di Mobius si è espanso rapidamente. Ora è usato per un’ampia gamma di sistemi a eventi discreti dalle reazioni biochimiche agli effetti di attacchi maliziosi sulla sicurezza di sistemi di elaborazione, in aggiunta alle applicazioni originarie. L’ampia gamma di usi è possibile per via della flessibilità e potenza riscontabili in Mobius, che provengono dal suo supporto alla modellazione multiformalismo e alla possibilità di ricorrere a diverse tecniche per la soluzione dei modelli. Questa flessibilità permette al modellista di rappresentare il sistema

oggetto di studio nel linguaggio di modellazione più appropriato al dominio del problema

21 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

in questione e poi risolvere il modello in maniera efficiente e accurata usando la tecnica di risoluzione più appropriata in relazione alla dimensione e complessità del sistema. Sono supportate dal tool la simulazione a eventi discreti distribuita e la risoluzione analitica e numerica.

Fig. 1.4 – L’architettura del tool Mobius

Per la costruzione di un modello Mobius mette a disposizione vari editor classificabili in base al tipo di modello da generare (atomico, composto etc.). Per ogni modello Mobius genera e compila del codice sorgente C++ ed i file oggetto prodotti vengono raccolti per formare un archivio di librerie. Queste librerie sono collegate insieme, attraverso l’uso di un linker, alle librerie base di Mobius per formare l’eseguibile per il solver [Fig. 1.4], che

viene poi lanciato per generare i risultati; l’uso di codice C++ conferisce efficienza nella risoluzione, e una grande flessibilità nella definizione del modello dal momento che è possibile arricchire il codice generato automaticamente da Mobius con proprie librerie.

1.3.2 La topologia della rete La topologia della rete data dal modellista in input al tool di generatore modelli di fallimento è composta dai seguenti file (di estensione .TXT):

 coordinate: racchiude le coordinate x e y esatte di ogni nodo. Esse sono espresse in

22 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

coppie di cifre in formato double separate da uno spazio e da un ritorno a capo per ogni nodo.  distances: è un file contenente una matrice quadrata in cui sono presenti le distanze dei nodi: l’elemento [j,k] della matrice rappresenta la distanza euclidea bidimensionale tra

22 il nodo j e il nodo k calcolata con la formula: d x1  x 2  y 1  y 2  ; i valori j=k (la distanza tra il nodo e se stesso) avranno ovviamente valore 0.000  energy: un elenco contente per ogni nodo dei valori che caratterizzano la tecnologia

della batteria utilizzata.  losses: contiene la matrice delle adiacenze, che associa all’elemento [j,k] della matrice la probabilità che un’informazione giunga dal nodo j al nodo k: è un valore compreso tra 0 e 1 ed esprime la qualità del link tra il nodo j e il nodo k.  neighbor: ogni riga del file è associata ad ogni della topologia, e descrive i nodi “vicini” a seconda che ci sia un link, nella forma: numero del nodo, numero dei vicini, numeri nodo dei vicini

 radio: un elenco contenente per ogni nodo dei valori che caratterizzano la tecnologia della radio utilizzata.  TinySan: contiene in cifre il numero di nodi che compongono la topologia.  topology: contiene un riepilogo riassuntivo dei file descritti in precedenza. La generazione di questi file è a carico dell’utente, e si può immaginare come per topologie con molti nodi ciò diventi un compito dispendioso soprattutto se svolto non graficamente: la topologia può essere infatti ricavata da software di simulazione che hanno come caratteristica la disposizione grafica dei nodi che compongono la topologia, in modo che l’utente abbia anche una visione globale della disposizione dei nodi e di tutto l’ambiente da modellare e simulare. Da ciò nasce l’esigenza di un tool nella progettazione della topologia che si avvicini il più possibile all’ambiente WSN rispetto ad altri software più “graficamente generici”, ma soprattutto che produca il file necessari per la modellazione e la simulazione in modo diretto, senza che l’utente vada a ricavare o modificare manualmente i file necessari al tool Failure Model WSN Generator. Ed è da quest’esigenza e dagli innumerevoli vantaggi che comporta una web-application che è nata

23 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

la necessità di realizzare uno strumento web-based per la simulazione remota di WSNs.

1.4 Motivazioni del remoting nella simulazione di WSN Le motivazioni subito evidenti nell’utilizzo di un’applicazione web-based piuttosto di un’applicazione desktop-based derivano dal concetto stesso di web application, e dalle caratteristiche che hanno decretato l’esigenza e il successo del web 2.0 e il trend attuale di migrazione verso internet:

 Disponibilità: una web application non ha bisogno di essere scaricata, installata o configurata: il digitare semplicemente l’indirizzo web rende l’applicazione subito disponibile.  Scalabilità: le applicazioni web-based possono crescere insieme all’esigenze di un’azienda; features aggiuntive possono essere implementate immediatamente e rese subito disponibili agli utilizzatori senza operazioni onerose quali installazione aggiornamenti, verifica compatibilità ambiente, etc.

 Manutenibilità: la risoluzione di bug, il miglioramento delle prestazioni e l’aggiornamento del codice in una web application possono avvenire ed essere diffuse molto più rapidamente rispetto alle applicazioni tradizionali.  Sicurezza dei dati: l’implementazione di un buon server, soprattutto se associata a tecnologie di clustering o di cloud computing, assicura la conservazione e la protezione dei dati (siao essi dati applicativi o dati utente) in caso di malfunzionamenti, virus o problemi hardware in maniera più efficiente rispetto alle

applicazioni tradizionali. L’utente accede alla web application solo con il proprio browser, e possiamo quindi immaginare che esso interagisce con una sorta di “sandbox”, un ambiente protetto gestibile solo dal software di navigazione: dal lato server inoltre un semplice servizio di backup automatico dei dati eseguito periodicamente già è sufficiente per migliorare la sicurezza del sistema rispetto ad un’applicazione che viene eseguita nel sistema non sandbox dell’utente.  Carico di lavoro: una web application può essere progettata per eseguire totalmente il

carico computazionale sul server, oppure a seconda delle esigenze e dei costi di

24 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione

gestione può distribuire le operazioni necessarie al suo corretto svolgimento sia sul client che sul server; in questo modo si può eliminare la scelta obbligatoria di un thick client per eseguire applicazioni e calcoli complessi.  Riduzione costi di gestione: la migrazione verso i thin client piuttosto che la scelta obbligata dei thick client, e l’indipendenza della web application dal sistema operativo può permettere un risparmio sui costi di licenza, sui costi delle tecnologie hardware e software.

 Accessibilità: un’applicazione web-based può essere eseguita ovunque e su qualsiasi dispositivo, compresi smartphone, PDA e moderne console da gioco; con una giusta scelta delle tecnologie software impiegate per la sua realizzazione, l’unico limite resta solo la risoluzione dello schermo dei dispositivi client e della disponibilità di una buona connessione ad internet. Alla luce di quanto detto possiamo descrivere le caratteristiche derivanti applicando uno strumento di tipo web-based al caso di simulazioni remote di WSN: è evidente come i vantaggi elencati all’inizio di questo paragrafo si riflettono nell’uso degli strumenti appena elencati da parte del modellista, ed in particolare:  L’aggiunta di nuovi modelli analitici si propaga in tempo reale ed è subito a disposizione di ogni utente che accede alla web application;  L’utente non ha bisogno di installare e configurare particolari software di modellazione e di simulazione in ogni macchina che utilizza per lo sviluppo di WSN, e può accedere all’applicazione ovunque e da ogni sistema dotato di un web browser;

 Tutto il codice gestito dalla web application non è ne visibile ne accessibile da parte dell’utente: tutto ciò che il modellista può accedere sono i dati di modellazione e simulazione, accessibili ovunque e protetti da eventuali guasti hardware e software;  Il calcolo computazionale delle simulazioni e della generazione di modelli analitici in base alla topologia della rete avviene sul server o potrebbe addirittura avvenire su un sistema distribuito di server, in modo tale che il modellista può utilizzare un normale thin client con notevoli risparmi in ambito economico.

Si può pensare che questo tipo di approccio unisca il vecchio approccio computazionale

25 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 1: Wireless Sensor Network: Modellazione e Simulazione accademico di trent’anni fa, quando l’utente immetteva i propri dati in calcolatori grandi come stanze intere e ne attendeva i risultati, al moderno web 2.0 dove l’interazione, l’accessibilità e la portabilità sono i veri punti forza.

26 Capitolo 2 Analisi dei Requisiti e Progettazione

Dopo aver dato uno sguardo d'insieme sulle reti di sensori senza filo ed analizzati i vantaggi di un tool web based per la simulazione remota di WSN, questo capitolo si occupa dapprima dei concetti chiave dei requisiti che il tool deve soddisfare, poi dei concetti chiave che il lavoro di questa tesi ha implementato, soffermandosi brevemente

sugli use case dell'applicazione. Il come questi requisiti, insieme alle caratteristiche spiegate nel primo capitolo, si riflettano nel tool implementato verrà descritto iniziando dal paragrafo 2.3, dedicato al primo passo della progettazione, e continuerà nel terzo capitolo dedicato alla scelta delle tecnologie per le Rich Internet Applications. Si sottolinea il fatto che la maggior parte della documentazione che accompagna il software (compresi SRS, Class e Sequence Diagrams, Test Cases, etc.) è stata omessa per non rendere prolisso il presente lavoro di tesi.

2.1 Web Model WSN Generator: concetti chiave Seguendo l'approccio della modellazione e simulazione descritto nella Fig. 1.5 e avendo l'obiettivo di remotizzare il tool in Java Failure Model WSN Generator, abbiamo che la nostra applicazione da implementare, denominata Web Model WSN Generator, è caratterizzata innanzitutto da una gestione multi-utente: infatti essendo una web application, l'accesso ad essa non è limitato ad un solo utente per volta, ma deve gestire

anche contemporaneamente più utenti che si collegano con il proprio browser; questo

27 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione impone un accesso protetto con username e password per ogni sessione, ma soprattutto un ambiente personalizzato per ogni utente. Ovvero ogni modellista, progettista e sviluppatore di WSN deve possedere ed accedere sul server le proprie cartelle e i propri file contenenti le topologie, i modelli, e i risultati delle proprie simulazioni. Eseguendo correttamente il primo accesso al web server, infatti, il tool Web prepara l'ambiente personalizzato per l'utente: a questo punto viene presentata l'applicazione, il cui obiettivo primario è svolgere il passo 1 descritto nel paragrafo 1.6, cioè quello in cui l’utente fornisce gli input necessari per specificare il sistema in oggetto e per configurare lo scenario da sperimentare. L'applicazione deve memorizzare il numero di nodi da modellare, la topologia della rete (con la possibilità di essere sia inviata dall'utente tramite upload oppure disegnata direttamente dalla web application) e il tempo di simulazione da valutare. A seguito di ciò l'utente può scegliere di scaricare il modello (generato oppure direttamente compilato) in file pronti per il simulatore Mobius, da simulare e valutare nel proprio computer, oppure può scegliere di far simulare il modello generato direttamente dal server, e attenderne i risultati o essere avvisato tramite e-mail quando la simulazione sarà completata: in questo caso l'utente dovrà scegliere le metriche da valutare nella simulazione (disponibilità, performance, etc.), ed al termine della simulazione (passo 5 del paragrafo 1.6) i risulati verranno presentati direttamente nella web application tramite un foglio di calcolo on-line con la possibilità di salvare, stampare ed esportare i dati ottenuti. Nel caso in cui l'utente sceglie di disegnare on-line la topologia dei nodi che compongono la rete, dovrà comparire una schermata simile ad un software di disegno, dove l'utente può disporre i nodi con un drag and drop su un piano bidimensionale e modificare, per ogni nodo, le coordinate, il tipo di radio, il tipo di tecnologia della batteria e l'applicazione installata. Nel disegnare la topologia, infine, l'utente può selezionare per la rete di nodi l'algoritmo di routing e il modello di propagazione del segnale, il quale differisce dall'ambiente scelto. Per quanto riguarda i passi 2, 3, 4 descritti nel paragrafo 1.6, se l'utente non decide di scaricare il modello generato, i parametri calcolati, i modelli analitici e la simulazione del modello analitico devono avvenire totalmente sul server, ma soprattutto i parametri statici

28 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione e dinamici, le librerie predefinite di template modello e i valori utilizzati e aggiornati dalle simulazioni devono essere nascosti dall'utente della web application; ovvero da un lato si richiede che il tool Web failure model WSN generator sia progettato in maniera da essere ampliato con altri modelli, framework, template di librerie e simulatori, ma che queste modifiche devono essere effettuate solo da chi gestisce l'applicazione e il server, in modo tale che l'utente abbia solo una scelta, non modificabile, dei modelli a disposizione. Dalla descrizione appena fatta di cosa il web tool deve completamente svolgere, il seguente lavoro di tesi si è concentrato sulle richieste fondamentali impostando un ottimo punto di partenza per il successivo completamento dell'applicazione, soprattutto perché la scelta delle tecnologie e il modo di programmazione effettuato si sono concentrate sulla massima espandibilità possibile sia per quanto riguarda il web tool sia per il tool desktop. Prima di focalizzare però in che modo e come l'espandibilità caratterizza il software implementato, questo paragrafo termina con i requisiti implementati nel tool, derivati dai concetti chiave descritti precedentemente.

Dal seguente lavoro di tesi si è richiesto che il tool Web Model WSN Generator visualizzi dapprima una schermata di accesso, dove l'utente immette username e password: all'accesso eseguito correttamente il sistema mette a disposizione, in base all'utente, delle cartelle sul server dove memorizzare la topologia della rete e i modelli generati. In seguito all'utente viene presentata una schermata in stile wizard dove dapprima esso sceglie il numero di nodi che compone la rete e il tempo di simulazione desiderato. In seguito, se l'utente noi invia con un upload un file (di estensione .zip) contenenti i dati della topologia, viene data la possibilità di disegnare la topologia della rete di sensori. Il disegno deve essere fatto in maniera visuale, nei modi descritti precedentemente, e in particolare: l'utente per ogni modo immette le coordinate e sceglie da una lista, non ancora funzionante e implementabile successivamente, la radio, la batteria e il carico di lavoro: queste liste sono tutte settate ad un valore di default, ma deve essere data la possibilità di caricare sul server i file che le caratterizzano. Nella schermata del disegno in seguito l'utente può scegliere di settare manualmente i link che compongono la topologia, oppure scegliere da una lista il modello di propagazione desiderato: il sistema si occuperà di tracciare i link tra

29 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione i nodi e di impostare per ogni collegamento la probabilità di perdita dei pacchetti, ovviamente compresa tra 0 e 1. Per aiutare la progettazione della rete, all'utente viene data la possibilità di spostare i nodi sul piano bidimensionale, di impostare la scala di riferimento e di aggiungere come sfondo al piano un'immagine che rappresenti la mappa di riferimento dove verranno predisposti i nodi. Al termine del disegno, l'utente può proseguire con la modellazione oppure cliccare sul tasto “export” e salvare sulla propria periferica il file della topologia della rete. Proseguendo con l'applicazione, all'utente viene presentata una schermata simile sia graficamente sia in termini di funzionalità al tool Failure Model WSN Generator, ovvero con delle aree testuali che rappresentano i log dell'applicazione e dei messaggi inviati alla console di sistema del server, e con i pulsanti “Generate”, “Compile model” e “Simulation” a seconda se l'utente vuole generare il modello, compilarlo o simularlo. Nel caso della generazione e della compilazione, all'utente viene dapprima mostrato il log della generazione e in seguito viene data la possibilità di scaricare il modello sorgente o il modello compilato, entrambi utilizzabili con il simulatore Mobius. Nel caso in cui venga scelta la simulazione, all'utente viene mostrata una schermata di scelta delle metriche da analizzare, e sarà avvertito che la simulazione non è ancora funzionante. Infine, tutti in passaggi elencati deve essere implementato un pulsante di “logout” che da la possibilità all'utente di ritornare alla pagina di accesso invece di chiudere la finestra del browser web e al sistema di rilasciare le risorse utilizzate per il disegno, la modellazione e la futura simulazione.

30 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione

2.2 Casi d’uso Dai requisiti appena elencati vengono qui proposti i casi d'uso principali:

Fig. 2.1 – Use Case Diagram – funzionamento principale della web application

CASO D'USO GENERAZIONE MODELLO  Pre-condizioni: l'utente ha effettuato con successo il login  Flusso di eventi: 1. L'utente imposta il numero di nodi e il tempo di simulazione 2. L'utente carica sul server il file .zip della topologia WSN

3. IF l'utente non carica il file della topologia, l'utente disegna la topologia 4. Il sistema importa la topologia in una cartella personale dell'utente 5. L'utente chiede la generazione del modello 6. Il sistema genera il modello e invia come download il file compresso del modello all'utente 7. IF L'utente sceglie anche la compilazione, il sistema genera e compila il

modello per poi consegnare il file compresso all'utente

31 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione

CASO D'USO DISEGNO TOPOLOGIA  Pre-condizioni: l'utente ha effettuato con successo il login  Flusso di eventi: 1. L'utente sceglie di disegnare una topologia WSN 2. Il sistema visualizza all'utente soltanto la parte di disegno topologia 3. L'utente chiede l'esportazione della topologia disegnata 4. Il sistema genera un file compresso contenente la topologia WSN e lo invia

all'utente

CASO D'USO SIMULAZIONE  Pre-condizioni: l'utente ha effettuato con successo il login l'utente ha terminato e compilato la modellazione della WSN  Flusso di eventi: 1. L'utente seleziona una o più metriche da valutare (caso d’uso “selezione

metriche”) 2. Il sistema memorizza le scelte dell'utente in un archivio 3. L'utente inizia la simulazione 4. Il sistema simula il modello dell'utente e lo avvisa per e-mail quando l'elaborazione è completata 5. L'utente si ricollega e chiede di visualizzare i risultati 6. Il sistema mostra i risultati in un foglio di calcolo

7. IF l'utente chiede di scaricare i risultati, il sistema manda all'utente un file .csv o .xls del foglio di calcolo visualizzato

32 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione

2.3 Diminuire l’accoppiamento In ingegneria del software, l'accoppiamento misura l'interdipendenza di due moduli (definiti come raggruppamenti di istruzioni, procedure e dichiarazioni): ad esempio, un modulo A chiama una funzione definita nel modulo B o accede ad una variabile dichiarata dal modulo B. Due moduli hanno un elevato accoppiamento se dipendono strettamente l'uno dall'altro. Per ottenere la capacità di comporre, scomporre, comprendere e modificare il software in maniera modulare, l'ingegnere del software deve progettare i moduli in

modo che abbiano alta coesione (cioè tutti gli elementi devono essere strettamente connessi) e basso accoppiamento. Questa definizione è stata la prima scelta effettuata nella progettazione del tool web-based: infatti esso si basa principalmente sull'applicazione Java desktop Failure Model WSN Generator implementata nel lavoro [4], e come prima cosa si è cercato di capire e di scomporre le classi Java del software con l'obiettivo di separare l'interfaccia grafica (che sfrutta le librerie Swing) dalla logica applicativa, in modo tale da utilizzare solo la logica

dell'applicazione nella web application. Da una prima analisi si è notato che l'accoppiamento tra l'interfaccia grafica e le classi che si occupano della generazione del modello era molto forte: come illustra il class diagram seguente, molte classi in gioco acquisivano i dati necessari alla generazione del modello di fallimento direttamente dalle JTextArea, CheckBox e ComboBox dell'istanza della classe InterfacciaInput (la GUI del tool), ma soprattutto i messaggi generati da queste classi per notificare il corretto svolgimento della generazione del modello all'utente venivano inviati

ad un oggetto del tipo JTextArea attraverso l'invocazione diretta del metodo .append.

33 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione

Fig. 2.2 – Class Diagram dell'elevato accoppiamento tra la classe InterfacciaInput ed alcune classi del tool

Tutto ciò era lecito e giustificato dal fatto che il tool desktop aveva una semplice interfaccia grafica e soprattutto che esso non era progettato per essere adattato e riutilizzato in altri ambienti, tantomeno nell'ambiente web. Nel seguente lavoro di tesi però una modifica e riprogettazione del codice di questo tool è inevitabile, e si è proseguito per questa strada raggiungendo i seguenti obiettivi:

 Lo sviluppo dell'applicazione desktop e della web application possono essere eseguiti in parallelo: eventuali correzioni di bug e migliorie del tool desktop-based verranno riflesse automaticamente nel tool web-based.  Il tool desktop-based potrà essere adattato in altri ambienti, compreso ad esempio l'esecuzione e il controllo in maniera testuale da console di sistema. Ciò è stato ottenuto principalmente implementando la classe AmbientVar e utilizzando le classi Log di Java.

34 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione

2.3.1 La classe AmbientVar La classe Java AmbientVar implementata nel progetto del tool web-based gestisce tutte le variabili necessarie alla modellazione e alla compilazione del tool failure model WSN generator. Essa è composta principalmente da metodi get e set delle variabili visualizzabili dall'interfaccia grafica del tool desktop-based, ovvero: i) numero di nodi, ii) path della topologia della rete, iii) path dei file del modello generato, iv) tempo di simulazione, v) ottimizzazione del modello. Questa classe si sovrappone tra la logica applicativa e

l'interfaccia grafica del tool, in modo tale che le scelte dell'utente dalla GUI vanno a settare i campi di AmbientVar, e le classi responsabili della generazione del modello di fallimento tramite chiamate get acquisiscono i dati configurati dalla classe InterfacciaInput a tempo di esecuzione. In aggiunta sono state implementate alcune variabili “flag” necessarie al corretto svolgimento dell'applicazione web (non sfruttate quindi dal tool desktop) ed alcuni metodi per catturare ed inviare i messaggi inviati dalle classi responsabili della generazione del modello di fallimento. Come illustra il

diagramma seguente:

Fig. 2.3 – Class Diagram dell'accoppiamento diminuito con la classe AmbientVar

35 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione

l'accoppiamento è stato diminuito in maniera soddisfacente per il progetto web, e risulterà ulteriormente diminuito sfruttando le classi Log di Java.

2.3.2 Logging L'attività di logging consiste nel registrare automaticamente eventi che vengono generati da un programma in modo da fornire una traccia che permetta di ricostruire e diagnosticare eventuali problemi. Nel linguaggio Java le possibilità di implementare il

logging sono molteplici, e tra molte soluzioni valide vanno citate Apache Log4J e Java Logging API, presente dalla versione 1.4 di Java. Entrambi i prodotti hanno una struttura comune che prevede l’utilizzo di un oggetto logger al quale viene fornito il messaggio di logging da generare in base ad una priorità predefinita. Il layout del messaggio e la destinazione finale dello stesso è separata dalla generazione e viene gestita da opportune classi che si occupano di formattare il messaggio e di inviarlo alla destinazione opportuna.

Fig.2.4 – Principali componenti logici dei framework di logging.

Questa struttura consente una notevole flessibilità in quanto distingue la fase di generazione del messaggio dalla fase di formattazione e di invio alla destinazione finale che può essere la console di sistema, un file, una e-mail , una socket o qualsiasi altra destinazione si desideri. Applicando la classe java.util.log al nostro tool desktop di generazione dei modelli di fallimento, si sono modificate le classi che inviavano messaggi dirottando questi su i due

log creati, logger (per i messaggi diretti alla console) e guiLogger (per i messaggi diretti

36 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 2: Analisi dei Requisiti e Progettazione alla JTextArea della classe InterfacciaInput) con semplici direttive del tipo:

this.varAmbiente.guiLogger.info("messaggio");

Si è proseguito poi nella creazione di un Output handler modificato a seconda dell'ambiente in cui vengono catturati i messaggi: infatti i log handler creati derivano dalla classe java.util.logging.Handler e contengono degli override dei metodi publish, close, flush e setLevel tali che il layout e la destinazione dei messaggi avvengano diversamente a seconda che si tratti dell'applicazione desktop-based o dell'applicazione web-based; in questo caso il tool desktop possiede una classe TextAreaHandler in cui il layout è del tipo:

final String message = logRecord.getMessage() + "\n" ;

e la destinazione è proprio la JTextArea della GUI:

jGuiTextArea.append(message);

Mentre l'applicazione web possiede un proprio handler, con il layout simile al layout di TextAreaHandler ma con destinazione un oggetto di tipo StringBuilder associato ad un componente di tipo Text Box del framework utilizzato:

this.sb.append(message);

E' evidente da quanto descritto come l'accoppiamento sia diminuito: il tool desktop-based e la web application sfruttano gli stessi log catturati con handler diversi: qualsiasi futura estensione di entrambi i tool può usufruire degli stessi log senza interventi al codice, creando handler diversi e personalizzandone il layout. 37 Capitolo 3 Tecnologie e Strumenti per le Rich Internet Applications

Il presente capitolo descrive il secondo passo della progettazione del tool web-based per la simulazione remota di WSN, il quale si focalizza nella ricerca effettuata sulle tecnologie per implementare la web application o, più in generale, una RIA (Rich Internet Application). Verrà illustrato quali sono le più diffuse tecnologie disponibili oggi sul

mercato, come queste riflettono alcune metriche di valutazione scelte per questo progetto, e quali sono i vantaggi e gli svantaggi di adottare un software piuttosto che un altro. La scelta e la sua motivazione della tecnologia realmente adottata per lo sviluppo di questo tool verrà affrontata nel capitolo 4, dove verrà descritto in maniera più dettagliata il framework ZK.

3.1 Le RIA e metriche di valutazione Da un breve sguardo sui requisiti del tool web based si nota subito che l’applicazione web deve riflettere quanto più possibile l’applicazione desktop del generatore dei modelli di fallimento e d’altra parte deve possedere una funzionalità di disegno che, anche se semplice, deve somigliare quanto più possibile and un’applicazione desktop di disegno diagrammi. Da ciò nasce l’esigenza di implementare non una normale web application, ma una Rich Internet Application (RIA). La differenza tra queste due applicazioni sembra sottile, ma diventa molto chiara descrivendo cosa sono RIA:

«Le Rich Internet Application (RIA) sono applicazioni web che possiedono le

38 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications caratteristiche e le funzionalità delle applicazioni desktop, senza però necessitare dell'installazione sul disco fisso.» Le RIA si caratterizzano per la dimensione interattiva, la multimedialità e per la velocità d'esecuzione: parte dell'applicazione che elabora i dati è trasferita a livello client e fornisce una pronta risposta all'interfaccia utente, mentre la gran parte dei dati e dell'applicazione rimane sul server remoto, senza appesantire il computer utente: esse si fondano perciò su un'architettura di tipo distribuito.

L'interazione con una RIA avviene in remoto, tramite un comune web browser: pertanto esse rappresentano una generazione di applicazioni che permettono un'interazione totalmente rinnovata, fondata sugli aspetti migliori delle caratteristiche funzionali e progettuali che finora erano prerogativa alternata del web o delle applicazioni desktop. Per tale livello spinto di interattività che esse offrono, le Rich Internet Application rappresentano uno dei canali migliori attraverso il quale si va imponendo il paradigma del Cloud Computing, che costituisce una nuova modalità di fruizione del software tramite architetture distribuite. Con questa premessa si sono esclusi, durante la ricerca della piattaforma software più utile all’implementazione del progetto, quei linguaggi e quelle tecnologie che si discostano dal concetto di RIA, ed in particolare sono state escluse a priori quelle tecnologie software che durante il loro funzionamento impongono i seguenti vincoli:  Il refresh della pagina sul browser web: caratteristica dei siti web in generale e vincolo necessario fino a pochi anni fa, il refresh della pagina del client riduce

drasticamente l’interazione tra client e applicazione web, ed oltretutto risulta scomodo ed inefficiente per lo sviluppatore di WSN che cerca di disegnare sul proprio browser la topologia della rete.  La disposizione e il controllo dell’interfaccia grafica diversa dalle applicazioni tradizionali: Lo sviluppatore WSN ma anche l’utente in generale sono abituati a software desktop-based che presentano interfacce grafiche i cui componenti sono tutto sommato simili: finestre, aree testuali e label, barre degli strumenti, barre di stato,

layout, canvas, etc.: si deve pertanto cercare di rendere l’uso della web application

39 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

quanto più simile all’esperienza di utilizzo delle applicazioni desktop-based.  I controlli degli input dell’utente non in tempo reale: il paradigma nel quale gli input del client vengono direttamente spediti al server e, nel caso in cui sono errati o non soddisfano determinati criteri, il server rimanda una risposta negativa al client, rende l’uso dell’applicazione lento e produce un traffico internet maggiore rispetto al caso in cui gli input del client vengono controllati direttamente dal client stesso. La scelta della piattaforma software adottata si è basata innanzitutto sui vincoli appena

esposti, e ciò ha delineato una scelta obbligata sulla tecnologia AJAX e sull’utilizzo, possibile ma non obbligatorio, del linguaggio Javascript

3.1.1 AJAX e JavaScript L'acronimo AJAX, che significa esattamente Asynchronous JavaScript And XML (JavaScript asincrono ed XML), è stato enunciato per la prima volta da Jesse Garrett, nel 18 Febbraio 2005 nel suo blog[s2]. Non si tratta di una nuova tecnologia né di

un'invenzione bensì di un concetto utilizzato per sviluppare applicativi avanzati e particolari quali Gmail, Google Maps o Google Suggest. Il concetto è in parte espresso nell'acronimo scelto, un utilizzo asincrono di Javascript che attraverso l'interfacciamento con XML, può permettere ad un client di richiamare informazioni lato server in modo veloce e trasparente, allargando gli orizzonti delle Rich Internet Applications. In alternativa a queste tecniche di interazione client/server, quando nel 1996 venne introdotto l'iframe in Internet Explorer 3, molti sviluppatori sfruttarono quest' ultimo modificando

l'attributo sorgente (src) della pagina racchiusa e simulando così un refresh trasparente di una parte di contenuti, il che emulava, in modo abbastanza sporco, un'interazione asincrona. Nel 1998 Microsoft cominciò a sviluppare una tecnologia, chiamata Remote Scripting, con lo scopo di creare una tecnica più elegante per richiamare contenuti differenti ed è in questo periodo, seppur con nome differente, che AJAX venne utilizzato per la prima volta, per poi evolversi in versioni più mature fino a diventare un oggetto vero e proprio, noto ora come XMLHttpRequest.

Il motivo principale di tanto successo è che solo ultimamente il Remote Scripting ha

40 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications suscitato lo stupore degli addetti ai lavori nel vedere cosa Google fosse riuscita a fare all'interno dei suoi applicativi senza necessità di Flash Player o Java Virtual Machine, mantenendo comunque la compatibilità con molteplici browser di utenti che per diversi motivi non potevano usufruire di Javascript. Come spesso è accaduto negli ultimi anni, molti hanno preso spunto da Google ed il web, noto per la sua immediatezza propositiva, è stato in grado in poco più di un anno di regalarci numerosi esempi di applicativi basati su AJAX, esagerando in alcuni casi nell'utilizzo ma considerando molto spesso e fin da subito, a differenza di quanto accadde per Flash ed Applets anni prima, due delle problematiche più diffuse del web attuale: accessibilità ed usabilità. L'oggetto base di questa tecnologia è ovviamente XMLHttpRequest, che a seconda del browser usato prende nomi differenti o viene richiamato in maniera differente: nel caso di Internet Explorer, ad esempio, questo oggetto è restituito da un ActiveXObject mentre nei browsers alternativi più diffusi (Mozilla, Safari, FireFox, Netscape, Opera, Internet Explorer 7 e successivi, etc.) XMLHttpRequest è supportato nativamente.

Questo oggetto permette di effettuare la richiesta di una risorsa (con HTTP) ad un server web in modo indipendente dal browser. Nella richiesta è possibile inviare informazioni, ove opportuno, sotto forma di variabili di tipo GET o di tipo POST in maniera simile all'invio dati di una form. La richiesta è asincrona, il che significa che non bisogna necessariamente attendere che sia stata ultimata per effettuare altre operazioni, stravolgendo sotto diversi punti di vista il flusso dati tipico di una pagina web. Generalmente infatti il flusso è racchiuso in due passaggi alla volta, richiesta dell'utente

(link, form o refresh) e risposta da parte del server per poi passare, eventualmente, alla nuova richiesta da parte dell' utente. Ciò che resta del vecchio flusso, il tempo di attesa, passa spesso in secondo piano ed in molti tipi di interazione è praticamente impercettibile. L'utilizzo di questa tecnologia in senso puro non può divincolarsi dalla conoscenza, anche lieve, del linguaggio Javascript, di cui ora si descrivono brevemente l'etimologia e le sue caratteristiche. JavaScript è un linguaggio di scripting orientato agli oggetti comunemente usato nei siti web. Fu originariamente sviluppato da Brendan Eich della Netscape Communications con

41 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications il nome di Mocha e successivamente di LiveScript, ma in seguito è stato rinominato "JavaScript" ed è stato formalizzato con una sintassi più vicina a quella del linguaggio Java. Esso è stato standardizzato per la prima volta tra il 1997 e il 1999 dalla ECMA con il nome ECMAScript, ed è diventato uno standard ISO a partire dal 1999 (JavaScript 1.5). La caratteristica principale di JavaScript è quella di essere un linguaggio interpretato: Il codice quindi non viene compilato bensì c'è un interprete (in JavaScript lato client esso è incluso nel browser che si sta utilizzando) che esegue riga per riga, a tempo di esecuzione, quanto trascritto nello script. JavaScript presenta quindi tutte le caratteristiche di un normale linguaggio interpretato (e di conseguenza i suoi vantaggi e svantaggi) con una sintassi analoga a quella di un linguaggio compilato (essa è relativamente simile a quella del C, del C++ e del Java), quindi con la possibilità di utilizzare funzionalità tipiche dei linguaggi di programmazione ad alto livello (strutture di controllo, cicli, etc.) e con in più anche la potenzialità di definire strutture più complesse, vicine a quelle adottate nei normali linguaggi object oriented (creazione di prototipi, istanziazione di oggetti, costruttori). Un'altra caratteristica importante di JavaScript consiste nel suo essere un linguaggio debolmente tipizzato, ovvero il tipo delle variabili può non essere assegnato in fase di dichiarazione e le variabili stesse vengono convertite in maniera automatica dall'interprete. Inoltre JavaScript è un linguaggio debolmente orientato agli oggetti: ad esempio il meccanismo dell'ereditarietà si discosta molto da Java e i suoi stessi oggetti ricordano più gli array associativi del linguaggio Perl che gli oggetti di Java o del C++. In JavaScript lato client il codice JavaScript viene eseguito interamente sul client, quindi il server non viene sollecitato. Ciò risulta essere vantaggioso in quanto con la presenza di script particolarmente complessi il server non verrebbe sovraccaricato. Di contro però, nel caso di script che presentino una considerevole mole di dati, il tempo per lo scaricamento potrebbe diventare troppo lungo. Sebbene cominciare ad utilizzare AJAX sia abbastanza semplice e le conoscenze necessarie potrebbero essere di livello molto basso, tutt'altro discorso vale per creare applicativi ed interazioni avanzate: la padronanza nell'utilizzo del DOM (Data Object

Model) per la creazione avanzata di contenuti strutturali e per la manipolazione di file

42 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

XML, e le conoscenze di (X)HTML, CSS, XML ed XSLT (anche al di fuori di ambienti di sviluppo visuali WYSIWYG come DreamWeaver, FrontPage, GoLive, etc.) fa sì che lo sviluppatore utilizzi framework che si basano su AJAX piuttosto che utilizzare direttamente questa tecnologia. D'altro canto però, la necessità di adattare vari tool disponibili per le proprie esigenze (come ad esempio google maps, fogli di calcolo open source oppure script per disegnare diagrammi) obbligano comunque la conoscenza del linguaggio Javascript.

3.1.2 Caratteristiche e metriche di valutazione dei framework Restando vincolati alla tecnologia AJAX, la scelta di un framework adatto per implementare Web Failure Model WSN Generator si è basata considerando i seguenti parametri:  Integrazione con Java: il tool desktop-based di cui si basa la web application è scritto utilizzando esclusivamente il linguaggio Java, quindi il framework scelto dovrà il più

possibile interagire ed essere compatibile con tale linguaggio, con l’obiettivo da parte dello sviluppatore di non implementare inutile codice wrapper, di adattamento.  Estensibilità: il framework deve supportare pattern e metodologie di sviluppo che permettano interventi al codice nella maniera più efficiente possibile, e magari deve essere permettere una facile integrazione con altri tool ed altri linguaggi di sviluppo diversi da Java e Javascript.  Qualità del supporto: intesa in questo senso come la capacità del framework di essere

manutenuto e migliorato nel tempo. L’affidabilità del framework deve anche riflettersi sul suo supporto dato dagli sviluppatori nel tempo, e magari suo successo ed importanza nella community del Web 2.0.  Curva di Apprendimento: il framework deve avere una curva di apprendimento più bassa possibile, tale da adattarsi ai tempi di sviluppo di un lavoro di tesi e alla disponibilità dei futuri sviluppatori nell’imparare altri linguaggi di cui non hanno un’immediata padronanza.

 Strumenti di supporto: il framework deve essere dotato di strumenti di sviluppo e di

43 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

supporto alla web appllication in modo da rendere agevole e rapida l’implementazione. Inoltre deve avere un parco di componenti a disposizione molto ampio, come ad esempio componenti grafici, strumenti di report, gestione dei database, etc.  Costi di sviluppo: sia in termini di tempo sia in termini economici, i costi di sviluppo derivanti dall’utilizzo del framework devono essere i più bassi possibile: ad esempio è preferibile utilizzare tecnologie open-source, ma deve essere un open.-source ben

documentato e supportato. Alla luce di queste caratteristiche, vengono di seguito proposti ed analizzate varie piattaforme software per lo sviluppo di RIA: ovviamente non saranno tutte le tecnologie presenti sul mercato al giorno d’oggi, ma rappresentano le più famose, valide e supportate attualmente, con uno sguardo d’attenzione ai canoni da seguire descritti precedentemente

3.2 Java Server Pages e IceFaces Come prima piattaforma software per lo sviluppo di RIA si parte da JSP (Java Server Pages), poiché fa parte della versione enterprise di Java, nota come Java EE (Java Enterprise Edition, o in passato J2EE) la quale rappresenta lo standard de facto per sviluppare applicazioni di tipo enteprise e mission critical. Java Server Pages è una tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti dinamici in formato HTML o XML. Si basa su un insieme di speciali tag con cui possono essere

invocate funzioni predefinite o codice Java (JSTL). In aggiunta, permette di creare librerie di nuovi tag che estendono l'insieme dei tag standard (JSP Custom Tag Library). Le librerie di tag JSP si possono considerare estensioni indipendenti dalla piattaforma delle funzionalità di un Web server: nel contesto della piattaforma Java, la tecnologia JSP è correlata con quella dei servlet. All'atto della prima invocazione, le pagine JSP vengono infatti tradotte automaticamente da un compilatore JSP in servlet. Una pagina JSP può quindi essere vista come una rappresentazione ad alto livello di un servlet. Per via di

questa dipendenza concettuale, anche l'uso della tecnologia JSP richiede la presenza, sul

44 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

Web server, di un servlet container, oltre che di un server specifico JSP detto motore JSP (che include il compilatore JSP); in genere, servlet container e motore JSP sono integrati in un unico prodotto (per esempio, Tomcat svolge entrambe le funzioni). Quindi le Pagine JSP sono in effetti un'estensione diretta dei Servlet Java e offrono, rispetto ad altre attuali tecnologie Server-Side, il vantaggio e la possibilità di separare la sezione di gestione delle operazioni e di produzione dei contenuti, da quello di visualizzazione vera e propria.

I vantaggi di utilizzare JSP seguono dal fatto che:  JSP supporta il contenuto dinamico basato sia sugli script che sugli elementi di tipo markup e consente agli sviluppatori di creare librerie di tag personalizzate per soddisfare eventuali necessità specifiche di determinate applicazioni.  Le pagine JSP sono compilate in modo da essere elaborate più velocemente dal server.  Le pagine JSP possono essere usate insieme alle servlet che gestiscono la logica applicativa, il modello preferito dai template engine per servel Java

 JSP è una specifica, non un prodotto. Ciò significa che i produttori possono confrontarsi con implementazioni diverse, con uno sforzo che porta a prestazioni e qualità migliori.  Essendo parte integrande di Java EE, JSP può svolgere il suo compito sia nelle applicazioni più semplici che in quelle più complesse e impegnative. Normalmente una Pagina JSP è composta da: i) porzioni di codice HTML, JavaScript, CSS e così via, non compilati dal motore Jsp (Jsp Engine) e comunemente definiti

blocchi di codice statico, e ii) porzioni di codice Java, compilati dal motore Jsp, che prendono il nome di blocchi di codice dinamico: ciò equivale a dire che utilizzando solo JSP si avrà alla fine un prodotto non RIA, ma simile alle web application tradizionali, con refresh della pagina del browser e tutto quanto descritto in precedenza. Per aggiungere la tecnologia AJAX, la tecnologia JSP può essere arricchita attraverso l’utilizzo di IceFaces. ICEFaces[s3] è un framework Ajax opensource utilizzato dagli sviluppatori Java EE per

creare ed effettuare il deploy di Rich Internet Application (RIA) usando il linguaggio

45 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

Java. ICEFaces sfrutta l'intero ecosistema di tools ed ambienti di esecuzione basati su standard Java EE, e permette di sviluppare applicazioni RIA con numerose caratteristiche sviluppate in Java senza bisogno di applet o plugin proprietari da integrare nel Browser. Le applicazioni ICEFaces sono applicazioni JSP così che non ci sia bisogno dell'utilizzo di Javascript, inoltre il meccanismo che sta alla base (Ajax) è completamente trasparente allo sviluppatore. Ciò diviene possibile da un'architettura particolare di IceFaces, formata da tre elementi:

1) Il Framework IceFaces: un'estensione del framework standard JSF con la fondamentale differenza con cui viene tratta la fase di rendering. Diversamente da JSF il rendering avviene nel DOM lato server e solo cambiamenti parziali sono lasciati al browser ed in seguito assemblati con un bridge Ajax molto leggero. Il risultato è un render fluido, effettuato solo su certi elementi della pagina. Ajax utilizza le Api inizializzate dal server ed integra il meccanismo similmente al cycle di JSF.

2) Il Bridge Ajax: presenta elementi lato server e lato client che coordinano la comunicazione (basata su Ajax) fra il browser del client e l'applicazione lato server. Il Bridge quindi si occupa di apportare i cambiamenti alla presentazione dalla fase di rendering al browser del client e del riassemblamento di questi cambiamenti nel DOM del browser per applicare i cambiamenti. Inoltre ha il compito di rilevare le interazioni dell'utente con la presentazione e di portare le azioni dell'utente indietro all'applicazione per essere processate dal JSP lifecycle. Un meccanismo chiamato

partial submit è integrato nei componenti di ICEFaces e facilita la generazione di eventi attraverso il bridge. La prima volta che la pagina viene caricata viene creato il bridge Ajax e coordina gli aggiornamenti della presentazione e la trasmissione degli eventi dell'utente per tutto il lifetime dell'applicazione. 3) La Suite di componenti di ICEFaces: la suite fornisce tutti i componenti per la costruzione dell'interfaccia grafica dell'applicazione. Include sia i componenti standard di JSP e una vasta gamma di componenti che consente allo sviluppatore di

costruire applicazioni sofisticate e dall'interfaccia intuitiva. Oltre al meccanismo

46 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

succitato dell'interazione diretta con il DOM i componenti possono utilizzare un set di effetti come il drag and drop tutto ciò con la semplice modifica di attributi così che non si debba mai ricorrere a Javascript. Applicando le metriche di valutazione del paragrafo 3.1.2 si è valutato che JSP insieme a IceFaces possiede:  Una perfetta integrazione con Java: essendo JSP parte integrante delle tecnologie Java Enterprise Edition ed essendo IceFaces basato di JSP, viene naturale da parte dello

sviluppatore Java scrivere una web application con tale linguaggio;  Un’ottima estensibilità: una web application con queste tecnologie può essere di qualsiasi dimensione, semplice o complessa: inoltre nell’architettura Java EE è integrata JSF (Java Server Faces), un’architettura basata sul pattern MVC (Model View Controller), sfruttata soprattutto da IceFaces, che ben si presta a far crescere o decrescere un progetto.  Un’ottima qualità del supporto: Java EE è la migliore tecnologia opensource sul

mercato per lo sviluppo di applicazioni enterprise, e IceFaces, nato nel 2001, è diventato un prodotto leader nel mondo dei framework complementari basati sullo standard JSF.  Bassa curva di apprendimento: rispetto agli altri framework analizzati, lo sviluppo di un’applicazione web con Java EE, JSP, JSF e IceFaces obbliga lo sviluppatore ad avere una buona padronanza di queste tecnologie, nonché una buona conoscenza dei DOM, di XML, CSS, ed HTML. Una conoscenza di questo tipo comporta

sicuramente un’implementazione ottimale di un progetto in tempi più rapidi rispetto all’utilizzo di altri framework, ma comporta anche un certo tipo di preparazione sicuramente non ottenibile in tempi brevi.  Strumenti di supporto ottimi: queste tecnologie si affidano a tool di sviluppo Java potenti e gratuiti: IBM Eclipse, Sun NetBeans, Oracle Jdeveloper. I tool di supporto ad IceFaces si integrano perfettamente con i software appena citati. Per quanto riguarda componenti di terze parti, l’edizione commerciale di IceFaces comprende, a

pagamento, moltissimi strumenti in più per lo sviluppo delle RIA: componenti come

47 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

un foglio di calcolo, un canvas per il disegno e strumenti di report devono però essere “importati” in maniera manuale.  Bassi costi di sviluppo: nonostante la formazione teorica e pratica degli sviluppatori per l’utilizzo di queste tecnologie comporti una spesa non trascurabile, si utilizzano comunque piattaforme open-source, ottimamente documentate e supportate, le quali abbattono sicuramente i costi di licenza. Java EE, JSP e IceFaces sono state le prime tecnologie analizzate per questo lavoro di

tesi, e sarebbero state sicuramente scelte per l’implementazione di Web Failure Model WSN Generator, se non fosse stato per la praticità e per la nuova (e innovativa) metodologia di sviluppo che caratterizzano il framework che si è realmente scelto.

3.3 Openlaszlo Openlaszlo[s4] è una piattaforma degna di nota soprattutto dal fatto che è stata una delle prime ad offrire librerie e strumenti opensource per lo sviluppo delle RIA.

Originariamente nota col nome di Laszlo Persentation Server (LPS), dal 2004 diventa opensource e mette a disposizione dello sviluppatore una piattaforma che produceva in output dei file .swf (letti dal browser con il plug-in Flash) che costituivano la RIA, programmata non utilizzando strumenti proprietari della Macromedia, ma attraverso un linguaggio coniato dalla stessa società fondatrice, Laszlo System Inc. Dalla versione 4.0B1 (2009) le applicazioni scritte utilizzando Openlaszlo possono essere compilate non soltanto in file flash, ma anche in file DHTML, introducendo quindi

AJAX nello sviluppo. L’intera piattaforma è basata su due componenti principali: 1) Linguaggio LZX: un linguaggio risultante dalla fusione di aspetti dichiarativi, derivanti dall’XML, con altri linguaggi tipici della programmazione Object-Oriented. 2) Openlaszlo Server: una particolare servlet Java che compila le applicazioni LZX in binari eseguibili per la macchina target. In pratica le applicazioni Laszlo possono essere sviluppate come tradizionali servlet Java, il cui output viene dinamicamente restituito al browser (in questo caso è necessario che il

WebServer abbia in esecuzione l'OpenLaszlo server) o, in alternativa, le applicazioni

48 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

Laszlo possono essere compilate da LZX in un file SWF e caricate staticamente in una pagina web esistente. Questa tecnica è nota come "SOLO deployment". Le applicazioni sviluppate in questo modo mancano di alcune funzionalità rispetto alla versione basata su servlet, come ad esempio la possibilità di interazione con Web Services tramite il protocollo SOAP e la possibilità di effettuare invocazioni a procedure remote (RPC) XML. In aggiunta, nel luglio 2009 è nato un progetto, di matrice italiana, di nome “eu4ria” che ha l’obiettivo di integrare le applicazioni Openlaszlo con le componenti lato server di un’applicazione Java EE in maniera semplice. In pratica il progetto consiste in una serie di annotations nel codice Java, dalle quali vengono generate stubs in LZX in maniera da invocare metodi di Java nel codice LZX. I criteri adottati nell’analisi dei framework fanno sì che Openlaszlo possiede:  Una scarsa integrazione con Java: nonostante Laszlo Server sia una servlet Java, lo sviluppatore utilizza prettamente il linguaggio LZX, il quale non è solo di tipo dichiarativo: il progetto eu4ria d’altronde non è ancora maturo per essere un buon

brigde tra Java e LZX, soprattutto per applicazioni complesse;  Scarsa estensibilità: benché si presti bene a progetti software di piccole e medie dimensioni, Openlaszlo si presta poco ai design pattern e all’integrazione con codice di terze parti;  Buona qualità del supporto: Openlaszlo è comunque un framework molto supportato dall’azienda e dalla comunità opensource: si può dire che al principio è partito non molto bene (offrendo in output dei file flash, tecnologia chiusa e incompatibile con

molti sistemi hardware) ma sta proseguendo una buona strada supportando l’HTML Dinamico, e l’esperienza che sta accumulando questi anni ne sta accrescendo notevolmente l’utilizzo e il supporto.  Buona curva di apprendimento: il linguaggio LZX, anche se usato solo per Openlaszlo, è molto simile a JavaScript, e sono presenti in rete molti esempi e molta documentazione per apprenderlo velocemente. L’utilizzo del progetto eu4ria per l’interfacciamento con Java comporta solo la padronanza, da parte dello sviluppatore,

dell’utilizzo delle annotations.

49 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

 Strumenti di supporto sufficienti: nonostante la poca maturità del framework, i tool di sviluppo messi a disposizione da Openlaszlo sono stabili, efficienti e gratuiti; ma l’assenza di strumenti di report, fogli di calcolo, mappe e canvas e la mancanza di integrazione di tool di terze parti si nota ed è molto forte.  Bassi costi di sviluppo: sia in termini di tempo sia in termini economici, i costi di sviluppo derivanti dall’utilizzo di Openlaszlo sono molto bassi: infatti questo framework viene spesso definito dalla comunità di sviluppatori RIA come

l’alternativa opensource ed economica ad Adobe Flex.

3.4 Adobe Flex Nonostante non abbia nessun tipo di supporto alla tecnologia AJAX, Adobe Flex[s5] è degno di menzione poiché si è affermato quale principale piattaforma tecnologica per la realizzazione di RIA: in effetti il termine Rich Internet Application è stato coniato proprio dall’azienda Macromedia (acquisita in seguito da Adobe) nel marzo del 2002[s6],

e con la tecnologia Flash Adobe ha cercato sempre di offrire un’esperienza utente innovativa rispetto alle tecnologie presenti. Dalla versione 3 (la versione attuale è la 4 ed il nome del tool di progettazione e compilazione cambia da Flex Builder a Flash Builder 4) la tecnologia Flex è diventata opensource, nonostante tutti i tool per utilizzarla siano closed e non-free. Il punto di partenza di questo framework è stato il fatto che i programmatori tradizionali di applicazioni hanno trovato impegnativo doversi adattare alla metafora di animazione

su cui la piattaforma Flash originalmente è stata sviluppata. Flex cerca di minimizzare questo problema fornendo un workflow e un modello di programmazione noto a quegli sviluppatori, attraverso l’utilizzo di un linguaggio XML denominato MXML per la stesura di interfacce utente, e tramite un linguaggio di scripting noto come Actionscript, simile a Javascript e basato anch’esso sulla programmazione ad oggetti. Flex inizialmente è stato rilasciato come una applicazione Java EE o JSP che compilano MXML e ActionScript al volo in applicazioni Flash (file binari SWF). Le versioni

successive di Flex supportano la creazione di file statici che vengono compilati nello step

50 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications di creazione e possono essere pubblicate online senza la necessità di una licenza server. Flex è già provvisto di componenti e caratteristiche come web services, remote objects, drag and drop, sortable columns, charting/graphing, built in animation effects e altre semplici interazioni. Il client viene caricato una volta sola, il workflow è migliorato moltissimo a differenza delle applicazioni non RIA (eg. PHP, ASP, JSP, ColdFusionMX) le quali richiedono l'esecuzione di interi processi per ogni azione. Il linguaggio Flex e la sua strutturazione in sorgenti MXML per la GUI ed ActionScript per la Business Logic sono studiati per distinguere la logica della programmazione dal design implementando di fatto il Design pattern MVC. Inoltre, il server Flex funziona come gateway per permettere al client di comunicare con XML Web Services le Remote Objects (come Coldfusion CFCs, classi Java, e qualsiasi altra cosa che integra Action Message Format). Un componente particolarmente utile per interfacciare Flex con Java, escludendo il commerciale WebOrb[s7], è il progetto opensource BlazeDS[s8], una tecnologia lato server che offre tre tipi di servizi:

 Remoting Service, che permette di richiamare metodi di Java object sul proprio application server direttamente dall’applicazione sviluppata in Flex;  Message Service, che fornisce un’infrastruttura di tipo publish/subscribe;  Proxy Service, che permette di effettuare richieste a servizi di tipo cross-domain BlazeDS è nato come parte integrante del componente Adobe LiveCycle Data Services ES, una suite che permette una più ampia interazione con dati e business logic di applicazioni Enterprise. Concludiamo questa breve descrizione di Flex descrivendone le caratteristiche adatte al progetto Web Failure Model WSN Generator. Per quest’applicazione web Adobe Flex presenta:  Una buona integrazione con Java: WebOrb, BlazeDS e LiveCycle Data Services sono progetti maturi ed efficienti per integrare tecnologie flash con Java, e forse lo sviluppatore di RIA impega più tempo a configurare questi servizi che ad adattare il codice Java dell’applicazione desktop-based all’interfaccia in Flash.  Buona estensibilità: la piattaforma software sviluppata da Adobe oggi si presta bene

sia per piccoli progetti in espansione che per grandi progetti di tipo enterprise.

51 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

 Ottima qualità del supporto: Macromedia ha coniato il termine RIA, ed Adobe ha sempre investito sul web dinamico. Da molti anni si è maturato in tutto il mondo il supporto e la formazione, sia in termini commerciale sia in free community.  Curva di apprendimento media: oltre alla padronanza di Java e la conoscenza di Java EE o del framework Spring, lo sviluppatore deve imparare altri due linguaggi, MXML ed ActionScript: i tempi di sviluppo rispetto alla scelta di altri framework sono mediamente più lunghi

 Buoni Strumenti di supporto: Flex Builder è basato su Eclipse, e mette subito a suo agio lo sviluppatore. Inoltre il parco software trovabile in rete di componenti per il reporting, fogli di calcolo, diagrammi e canvas è molto ampio, anche se prettamente closed e non-free.  Alti costi di sviluppo: l’SDK di Adobe Flex e BlazeDS sono gli unici prodotti privi di costi di licenza. Tutti gli altri strumenti, compreso l’editor, i diagrammi, e le tecnologie per l’accesso avanzato ad applicazioni enteprise sono a pagamento ma con

un buon supporto. Nonostante Flex sia una tecnologia stabile ed efficiente per lo sviluppo di RIA, al giorno d’oggi un punto debole resta proprio l’output in Flash che, rispetto ad AJAX, è closed- source e risulta spesso incompatibile e di scarse prestazioni in molti dispositivi client.

3.5 Echo 3 Il web framework Echo3[s9] è la prima tecnologia analizzata che unisce i vantaggi di

Openlaszlo a quelli di Adobe Flex e, insieme ad altri framework (compreso quello scelto) introduce un concetto di sviluppo RIA innovativo: adattare il modello ad oggetti Swing per lo sviluppare web application event-driven. Questo concetto, approfondito nel prossimo capitolo, fa sì che lo sviluppatore implementi rich internet applications in tempi brevi, utilizzando AJAX ma senza conoscere Javascript e il modello DOM, con la quasi totalità del codice scritto nel linguaggio Java. Infatti le applicazioni Echo3 sono compilate in byte code Java e vengono eseguite su un

server Java. Il loro Java code è eseguito dallo strato “Web Application Container” di

52 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

Echo3, che risiede sopra una Servlet Java. Dal lato browser, il “Client Engine” di Echo comunica ciò che è stato inviato dall’utente al Web Application Container tramite richieste AJAX, con il server che risponde con direttive in modo da apportare aggiornamenti incrementali allo stato del browser client. Le componenti di Echo3 sono progettate per minimizzare una comunicazione client/server il più possibile, limitandola nei tempi in cui il server deve essere notificato immediatamente di eventi (ad esempio, semplici eventi come un input dell’utente in un componente TextField non darà luogo ad una richiesta al server). La risposta del server è il minimo insieme di istruzioni per l’aggiornamento incrementale del client, in modo da riflettere uno nuovo stato della finestra del web browser. Inoltre i moduli Javascript del framework Echo3 sono caricati pigramente (lazy-loaded) al client e da lì in poi messi in cache. Un modulo sarà recuperato quando un componente che appare sul browser client lo richiede. Il codice dell’applicazione non è mai mandato al client, solo lo stato aggiornato dell’interfaccia utente.

Le applicazioni Echo3 supportano l’uso di una logica di applicazione distribuita o un SOA (Service Oriented Architecture) o possono alternativamente essere costruite per eseguirsi interamente su una singola istanza della JVM, appoggiata da un middle tier di tipo POJO (Plain Old Java Object). Questo permette agli sviluppatori di costruire applicazioni senza preoccuparsi della sicurezza della logica di applicazione distribuita – affidata a robusti framework come Spring e Hibernate: inoltre, nessun oggetto remoto ha bisogno di essere "esposto", poiché questo framework memorizza l’intero stato dell’interfaccia web dell’utente sul server. Per la scelta del framework da utilizzare, Echo 3 ha dimostrato di avere:  Un’ottima integrazione con Java: la web application può essere scritta direttamente lato server in Java utilizzando API event-driven e component-oriented oppure, dalla versione 3, utilizzando codice JavaScript lato client. La parte AJAX dell’applicazione non è obbligatoriamente a carico dello sviluppatore.  Una buona estensibilità: la possibilità di integrare Struts, Hibernate e JSF con

applicazioni di terze parti (per la maggior parte però non ancora mature) rendono

53 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

Echo 3 adatto anche per progetti di medie e grandi dimensioni  Sufficiente qualità di supporto: sia dalla società NextApp, autrice del framework, che da molte applicazioni di terze parti, sono disponibili più prodotti in fase beta che software stabile e maturo.  Bassa curva di Apprendimento: la buona documentazione a corredo e la caratteristica di Echo 3 di essere basato solo su Java e Javascript rendono l’apprendimento del framework semplice e veloce

 Strumenti di supporto sufficienti: l’editor per l’implementazione di interfacce grafiche in echo, a pagamento, non è attualmente stabile per la versione 3. I componenti di terze parti per reportistica, diagrammi e fogli di calcolo scarseggiano e spesso bisogna ricorrere a componenti esterne in JavaScript o Flash.  Bassi Costi di sviluppo: Echo 3 è nato opensource, ed i costi da sostenere si riflettono solo sul suo tool eclipse-based. Presente nel web 2.0 dal 2005, il framework Echo 3 non ancora è riuscito ad affermarsi

rispetto agli altri framework presi in esame, nonostante la presenza di molti componenti che, anche se in fase beta, lo rendono un prodotto interessante e all’avanguardia.

3.6 Google Web Toolkit Essendo più un set di tools che un vero e proprio framework, Google Web Toolkit è uno strumento degno di nota poiché ha contribuito notevolmente alla diffusione di Javascript e AJAX (le stesse Gmail e Google Maps, applicazioni che hanno destato molta curiosità

e diffusione su internet, sono web application create con questa libreria) ma soprattutto perché possono trovarsi sul web molti framework per sviluppo RIA basate su questa tecnlologia (tra i più importanti citiamo Ext GWT[s10], SmartGWT[s11] e Vaadin[s12]) Google Web Toolkit (GWT) è un framework Java per scrivere applicazioni AJAX il cui approccio è quello di permettere di scrivere le applicazioni utilizzando sempre il linguaggio Java e solo alla fine convertire (tramite il compilatore di GWT) da classi Java a codice Javascript e HTML browser compliant (Internet Explorer, Firefox, Mozilla e

Safari per ora). Infatti il ciclo di sviluppo con GWT si può riassumere nel modo

54 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications seguente: 1. Utilizzo di un IDE Java (Eclipse, Netbeans, Junit, IntelliJ, Jprofiler, ecc.) per scrivere l'applicazione scritta in linguaggio Java, con l'ausilio di alcune librerie messe a disposizione da GWT. 2. Test dell'applicazione (Hosted Mode) come codice Java compilato che gira all'interno della JVM. 3. Utilizzo del compilatore GWT per convertire le classi Java in un'applicazione web

composta da files JavaScript e HTML. 4. Verifica dell'applicazione (Web Mode) con i browser che si vuole supportare. Per implementare questo ciclo di sviluppo, GWT è composto principalmente da 4 componenti: 1. Compilatore GWT Java-to-JavaScript: converte il codice Java in codice Javascript. Deve essere utilizzato quando si vuole eseguire l'applicazione in modalità "web mode".

2. GWT Hosted Web Browser: permette di eseguire le applicazioni in modalità "hosted mode", ossia di eseguire il codice Java nella JVM senza convertire il codice in linguaggio JavaScript/HTML. Per fare questo, il browser GWT include speciali librerie per Internet Explorer su Windows e Gecko/Mozilla su Linux. 3. JRE emulation libraryGWT: Contiene le implementazioni in linguaggio Javascript delle librerie Java standard maggiormente utilizzate (package java.lang.* e java.util.*). Tutti gli altri package (ad es. java.io.*, java.net.*, ecc.) non sono

supportati nativamente da GWT. 4. GWT Web UI class library: libreria User Interface contenente un insieme di interfacce e classi che permettono di disegnare le pagine web (ad es. bottoni, text boxes, immagini, ecc.) . Questa è la libreria principale per creare applicazioni web- based basate su GWT. GWT compila i sorgenti Java compatibili con J2SE 1.4.2. Ovviamente, dovendo il compilatore fare una conversione da Java a Javascript, non è supportato tutto il linguaggio Java ma solo una parte: ad esempio il tipo long è supportato ma, non

55 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications esistendo in Javascript, questo tipo viene convertito come numero floating point double- precision; così come GWT non è in grado di utilizzare la finalizzazione degli oggetti durante il Garbage Collection in quanto non è supportato dal linguaggio Javascript, oppure GWT accetta le istruzioni di sincronizzazione ma, essendo Javascript un linguaggio single-threaded, non ha effetti in esecuzione. L’utilizzo pratico di questo set di tool opensource è di creare semplici ma potenti interfacce utente per web application: il collegamento il codice prodotto (ma anche codice Javascript proprietario) con codice sorgente Java di classi business avviene attraverso la JavaScript Native Interface (JSNI) e attraverso il meccanismo Remote Procedure Call (RPC): in particolare per far comunicare l’applicazione con il web server, è sufficiente definire le classi Java che si vogliono utilizzare nel colloquio come serializzabili ed è stesso GWT che si preoccupa del trasporto: per testare sia l’interfaccia utente che i colloqui RPC, è possibile utilizzare JUnit. Come scelta di utilizzare Google Web Toolkit per il nostro progetto abbiamo che questo framework presenta:  Una buona integrazione con Java: il codice è scritto e testato in Java e successivamente convertito in JavaScript automaticamente, ma i tipi, la gestione delle eccezioni e il multi-threading non sono completamente disponibili, e c’è bisogno di uno sforzo ulteriore da parte dello sviluppatore di separare bene ciò che può essere implementato con GWT e ciò che deve essere puramente lasciato in Java.  Una sufficiente estensibilità: essendo in sintesi una libreria che permette “traduzione”

di codice, pattern e metodologie di sviluppo sono supportate comunque, ma per la gestione di progetti di media grandezza è consigliabile comunque affidarsi ad altri framework basati su GWT piuttosto che utilizzarlo direttamente.  Buona qualità del supporto: dietro a GWT c’è Google, e versioni stabili vengono rilasciate con molte frequenza. Inoltre il progetto è molto supportato dalla community opensource.  Bassa curva di Apprendimento: basterebbe solo la conoscenza di Java per produrre

applicazioni web utilizzando GWT.

56 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications

 Strumenti di supporto sufficienti: il framework non ha a corredo strumenti particolari che estendono gli ambienti di sviluppo che già si usano per creare applicazioni con Java: anche particolari software che estendono le funzionalità dell’applicazione creata con GWT sono da ricercare altrove, per poi integrarli attraverso JSNI.  Bassi Costi di sviluppo: GWT è opensource, e i costi di sviluppo sono quelli che offre il mondo Java in generale.

3.7 Apache Click Un'alternativa interessante ai framework studiati, in particolar modo nel caso della realizzazione di RIA in ambiente J2EE, è rappresentata da Click[s13], proposto da Apache, che intende superare il modello di interazione basato su MVC, implementato da framework come Struts, per passare a un modello event driven, tipico dei framework come Swing. La progettazione di un'interfaccia con Apache Click consiste nella definizione di almeno

due entità: una classe Java che estenda la classe Page, in cui andiamo a definire tutti gli oggetti della nostra interfaccia grafica e i relativi eventi da associare agli stessi oggetti, in maniera del tutto analoga a quanto avviene in Swing. L'altra entità da definire è una pagina HTML, che si occuperà di visualizzare i controlli, precedentemente definiti, e l'output dell'interazione con la stessa interfaccia. Tutto ciò è possibile utilizzando Apache Velocity, un template-engine opensource in Java, che interagisce con gli oggetti definiti nella classe sopra descritta, utilizzando una sintassi

decisamente comprensibile. Inoltre Apache Click fornisce un discreto insieme di widget da poter utilizzare nelle RIA; si integra con framework come Spring Security per quanto riguarda la realizzazione di meccanismi di autenticazione, e cpm Cayenne per l'interazione con gli ORM. Ad Apache Click non sono state applicate le metriche descritte nel paragrafo 3.1.2 poiché non è stata considerata una scelta valida rispetto ai framework elencati in questo capitolo: i motivi principali sono stati la scarsa maturità del progetto (è il framework più

giovane, nato nel Novembre 2009) e non è all’altezza, per varietà ed estetica, dei

57 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 3: Tecnologie e strumenti per le Rich Internet Applications framework menzionati. Resta comunque una piattaforma degna di nota e da prendere in considerazione negli anni a venire poiché è basata sull’esperienza dell’Apache Software Foundation ed è incentrata su un modo di sviluppare RIA diverso e per certi versi innovativo, molto simile a quello del ZK Framework, il framework scelto per Web Failure Model WSN Generator: il direct RIA. Come riassunto dalla seguente tabella, ZK è il framework che soddisfa in pieno le metriche scelte per l’implementazione del tool web-based.

58 Capitolo 4 ZK Framework

Questo capitolo termina la fase di progettazione descrivendo il framework con cui è stata implementata la Rich Internet Application: ZK Framework[s14] della Potix Corporation. E' stato necessario suddividere questo capitolo dal precedente poiché la descrizione, le caratteristiche, le features più importanti utilizzate nel progetto meritavano una sezione a

parte: si procede quindi ad analizzare questo framework introducendo prima le sue caratteristiche, e in seguito approfondendo gli aspetti particolari che lo rendono innovativo, flessibile e potente. Verranno poi approfondite le metriche di valutazione scelte e il loro rapporto con ZK Framework, fornendo esempi pratici su questa tecnologia. Si è preferito tralasciare gli aspetti puramente di programmazione ed analizzare più in dettaglio cosa lo rende qualitativamente valido nella progettazione di un software.

4.1 Direct RIA: cos’è ZK Framework Nel vasto mondo dei framework per lo sviluppo di applicazioni web, ZK si presenta come un Web Framework basato su componenti Ajax, scritto interamente in Java e che permette di creare ricche interfacce grafiche per applicazioni web senza alcun bisogno di utilizzare il linguaggio JavaScript né Ajax. Inoltre ZK è open source, e ha adottato di recente la licenza LGPL che permette di usarlo liberamente anche in ambito commerciale. La parte centrale di ZK consiste sostanzialmente in un meccanismo "event-driven" basato su oltre

duecento componenti Ajax, e un linguaggio di mark-up (XUL/XHTML) usato per

59 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework disegnare le interfacce grafiche. A differenza di altri framework basati su Ajax, ZK non richiede al progettista né al programmatore alcuna conoscenza di Javascript per sviluppare applicazioni web basate su Ajax, poiché il cuore di questa tecnologia auto-genera il codice Javascript necessario per il corretto svolgimento dell’applicazione. Ciò si traduce nel fatto che per sviluppare una web-application bisogna conoscere, oltre a Java, soltanto un minimo di html, poiché lo sviluppo avviene come se fosse un’applicazione desktop. Questo è uno dei punti forza di questo framework, ovvero ciò che viene definito dagli stessi creatori il Direct RIA, Rich Internet Application Diretta, in cui la parte di interfaccia grafica e il controllo associato ad essa vengono sviluppate come se si stesse utilizzando una qualsiasi libreria grafica, Swing o AWT per esempio: direttamente vengono utilizzati componenti (bottoni, finestre, label, container, etc.) direttamente vengono implementati listeners sugli eventi che si vogliono monitorare (onClick, onChange, buttonPressed, etc.) e direttamente i risultati delle elaborazioni vengono mostrate al browser, come se fosse una GUI desktop, senza accedere o controllare i tipici eventi DOM della tecnologia AJAX. La semplificazione dello sviluppo di web application avviene anche attraverso il ZK User Interface Markup Language (ZUML) che consente di creare e aggiungere componenti all’interfaccia grafica (effettivamente possiamo chiamarla così, invece di pagina web) semplicemente dichiarando e chiudendo tag, così come si fa con HTML, XML e così via. Ovvero, ZK è un framework che fondamentalmente implica il modello di programmazione desktop alle applicazioni Web.

Prima di concludere questo paragrafo però, è interessante descrivere cosa ZK non è: Il framework di base non ha alcun metodo rivolto alla persistenza dei dati; ZK è stato progettato per essere più leggero possibile, e i metodi che permettono la memorizzazione di oggetti e dati in file e database vengono delegate ad altre tecnologie che, come vedremo in seguito, possono essere implementate con facilità nel framework. Inoltre non è nato per supportare molti task a livello client (per giochi 3d ad esempio) e, a meno di scrivere componenti personalizzati, non è nato per applicazioni che delegano la maggior parte del computing ai client: di questo però possono delegarsi altre tecnologie, come ad esempio

60 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

JavaFX o Flash, anch’esse supportate nativamente come integrazione.

4.2 Caratteristiche principali di ZK Framework La piattaforma software ZK è stata progettata per massimizzare l’efficienza della logica enterprise e per minimizzare i costi di sviluppo attraverso l’innovativa architettura Direct RIA. Visitando l’home page del progetto viene mostrata subito un immagine che racchiude le caratteristiche peculiari del software:

Fig. 4.1 – la semplicità e l’efficienza del framework ZK nell’immagine in home page del progetto

 definisce un linguaggio dichiarativo XML (ZUML) per le interfacce grafiche (View) che risulta essere estremamente intuitivo e molto meno prolisso del corrispondente

linguaggio XML usato dallo standard JSF;  è basato su lancio di eventi e sull’utilizzo di componenti: in questa maniera permette di utilizzare lo stesso modello di programmazione usato nelle applicazioni desktop anche per le applicazioni web. In particolare, è dotato di un supporto Ajax ad alto livello: gli input dell’utente dal web browser giungono attraverso Ajax al modello desktop dell’applicazione lato server;  si integra in maniera trasparente con Spring, Spring Web Flow, Spring Security, Jboss

Seam, JSP, JSF, Flash plugin, EJB. Oltre al supporto nativo con Hibernate, è

61 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

caratterizzato da un databinding efficiente tra annotations in-page e campi POJOs lato server;  supporto completo del CSS: componenti e interfacce grafiche sono personalizzabili tramite fogli di stile ed è possibile creare temi e skin custom;  componenti grafici avanzati, dotati di drag-and-drop, context menu (pop-up menu) e Comet server push;  permette di gestire i bookmark, ed è nativamente compatibile con i SEO (Search

Engine Optimization);  presenta numerosi componenti di terze parti come: JFreeChart, JasperReports, Google Maps, FCKeditor, Timeline, Timeplot, ExtJS, Dojo;  supporta pattern differenti per la creazione di user interface;  ZK Script: è possibile scrivere il codice di script che lega la parte business con la parte vista in molti linguaggi: Java, JRuby, Groovy, JavaScript ma anche Python e PHP.  è disponibile un ottimo editor WYSIWYG (come plugin per Eclipse) per disegnare e

avere una preview delle pagine che si stanno scrivendo;  ZK Mobile: possibilità di adattare la web application su dispositivi mobili (in particolare su Android, BlackBerry e dispositivi con Java Mobile o dotati di web browser) senza modificare la business logic e il codice backend ;  è principalmente server-centrico, ma la versione attuale supporta anche la programmazione lato client in Javascript. Le principali caratteristiche appena elencate sono sufficienti a far capire il perché sia stato

scelto questo framework per lo sviluppo di Web Failure WSN Generator: si preferisce però approfondire, nei paragrafi successivi, in che modo le funzionalità di ZK sono state utili nella realizzazione di questo lavoro di tesi.

4.3 Integrazione con Java: il funzionamento di ZK Framework La nostra web application si basa, come prima realizzazione, principalmente sul tool Failure Model WSN Generator: ed è per questo che si è scelta come prima qualità da

rilevare una perfetta integrazione con l’ambiente Java. Per comprendere come il

62 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework framework scelto si integri con quest’ambiente, basta descrivere il funzionamento che sta alla base di ogni RIA scritta utilizzando ZK Framework. Il diagramma seguente mostra che ZK è composto da tre componenti principali: ZK loader, ZK AU Engine e ZK Client Engine.

Fig. 4.2 – Componenti principali di una RIA con ZK Framework

In ascolto alle richieste degli utenti, ZK Loader carica una pagina ZK, la interpreta, e presenta i risultati ottenuti in pagine HTML in risposta a richieste di tipo URL. In particolare una pagina ZK è scritta in un linguaggio di markup chiamato ZUML. ZUML, come HTML, è usato per descrivere quali componenti creare e come rappresentarli visualmente. Questi componenti, una volta creati, rimangono disponibili finché non avviene un timeout di sessione. ZK Client Engine e ZK AU Engine (Asynchronous Update Engine) lavorano sempre insieme come "ascoltatore" e "notificatore" di messaggi: essi si scambiano eventi che scaturiscono dalle azioni richieste dall'utente nel browser, e aggiornano il DOM tree lato browser web in base a quanti componenti sono manipolati dall'applicazione: queste azioni sono alla base della programmazione guidata dagli eventi (event-driven programming model) per le web application. Il Flusso di esecuzione di una RIA con ZK Framework può essere descritto più chiaramente in questo modo.

1. Quando un utente digita l’indirizzo web o clicca su un hyperlink nel web browser,

63 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

viene fatta una richiesta al Web server: la richiesta, se l’indirizzo dell’applicazione è corretto, viene servita da ZK Loader. 2. ZK Loader carica la pagina specificata e la interpreta per creare correttamente i componenti richiesti dalla pagina. 3. Dopo aver interpretato l’intera pagina, ZK Loader presenta il risultato in una pagina HTML. La pagina HTML viene mandata al browser dell’utente insieme allo ZK Client Engine.

4. ZK Client Engine resta in ascolto nel browser per individuare qualsiasi evento scatenato dall’attività dell’utente, come ad esempio spostamenti del mouse, cambiamenti di valori, click sui componenti grafici. Appena individuato l’evento, notifica lo ZK AU Engine con una speciale richiesta Ajax. 5. Appena ricevuta la richiesta Ajax, lo ZK AU Engine aggiorna se necessario il contenuto del componente corrispondente, e notifica l’applicazione attraverso l’invocazione di un handler di eventi (se esiste).

6. Se l’applicazione lato server sceglie di cambiare il contenuto del componente, o aggiungere o rimuovere nuovi componenti, l’AU Engine spedisce il nuovo contenuto dei componenti alterati al Client Engine usando particolari richieste Ajax (ZK responses). 7. Le Zk Responses istruiscono il Client Engine ad aggiornare correttamente il DOM tree. Lo ZK Client Engine in particolare è interamente scritto in JavaScript, con il vantaggio di essere messo in cache dai browser, e quindi spedito dal server al client solo alla prima visita della web application. Tutto il procedimento appena descritto, a meno di particolari esigenze, è nascosto al programmatore e presentato al web server attraverso servlet Java. Tutta la logica che lo sviluppatore deve implementare (o, nel nostro caso, integrare) sfrutta package Java del framework ZK, e a meno di particolari componenti customizzati, non c’è bisogno di una conoscenza, neanche minima, di Javascript e Ajax: si è potuto realmente constatare come nel nostro caso l’integrazione del tool di generazione di modelli di fallimento è avvenuta in maniera semplice, utilizzando direttamente le classi interessate al

64 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

funzionamento, focalizzando l’attenzione solo alla view della web application non in maniera tradizionale, ma con una programmazione java ad eventi. In sostanza, l’impressione che si è avuta nell’implementazione dell’applicazione web-based è stata un’attenta sostituzione dell’interfaccia di tipo swing originaria con un’altra, implementata alla stessa maniera, ma che gira all’interno di un browser: ed è questo uno dei veri punti di forza e di innovazione di questo framework.

4.3.1 Framework Server-Centrico e Client-Centrico Prima di continuare ad esaminare come la piattaforma ZK si è prestata all’implementazione del tool web based, è utile analizzare come funziona l’impatto di questo framework sulle performance di una Rich Internet Application: le prestazioni sono una metrica che è risultata non cruciale per il progetto, ma è comunque una caratteristica da prendere in considerazione per futuri sviluppi del tool web-based. In realtà non esistono test affidabili per misurare quali siano le reali performance di un framework web (in

particolare di quelli esaminati nel capitolo 3), ma possiamo basarci empiricamente su una caratteristica base, ovvero quella di essere un framework server-centrico o client-centrico.

Fig. 4.3 – Workload tra Web framework Server Centrici e Client Centrici

Si può notare dalla figura precedente che nel caso di frame work client-centrici il carico

computazionale che comporta l’applicazione web, insieme a quello comportato

65 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework dall’interazione del framework con l’ambiente di esecuzione, sia distribuito sia sul client che sul server: una web application sviluppata attentamente può ridurre notevolmente il workload del server e migliorarne le prestazioni soprattutto in caso di richieste elevate e numero elevato di client connessi ad esso (ciò può essere “un’arma a doppio taglio”, poiché il codice JavaScript aumenta in proporzione alla complessità dell’applicazione stessa, e quindi diventa facile "rallentare" il browser quando si devono creare molti widget). Questo miglioramento di prestazioni va a discapito però della manutenzione del codice; infatti un’architettura di questo tipo impone quasi sicuramente che la parte che riguarda il client e la parte che riguarda il server siano scritte in due linguaggi differenti: nel nostro caso ad esempio, scegliendo ZK framework il lato client deve essere scritto interamente in JavaScript mentre la logica applicativa in Java. Nel caso di framework Server Centrici il codice applicativo gira interamente sul server, mentre il web framework si distribuisce tra server e client, in modo che ci sia una “traduzione” automatica di messaggi tra loro: questo permette la possibilità di utilizzare un solo linguaggio per gestire due ambienti, ma comporta un consumo di memoria e un workload maggiore nel server, che aumentano all’aumentare dei client connessi ad esso. ZK Framework è nato come una piattaforma server-centrica, ma a partire dalla versione 5.0 si possono scrivere applicazioni web client-centriche tramite Javascript: l’utilizzo che si è fatto per la realizzazione del tool web-.based però è stato principalmente server- centrico per i seguenti motivi: 1. si è utilizzato direttamente il runtime environment di Java e le librerie incluse nel

server: questo è un vantaggio impossibile nelle architetture client-centriche. 2. il tool web-based con l'architettura server-centrica si è integrato efficacemente con il codice dell'applicazione desktop remotizzata. 3. con il framework server-centrico, si è raggiunto l'obiettivo scrivendo molte meno righe di codice rispetto all'utilizzo client-centrico, e sono state utilizzate strutture dati e librerie scritte in Java, quindi molto più "comode" e manutenibili: si è avuto in questo modo un aumento di produttività e una riduzione dei tempi di sviluppo.

Da questi motivi c’è da dire che il discorso sulle performance non viene automaticamente

66 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

abbandonato: cioè qualora si decida di migliorare l’efficienza del tool web-based, è consigliabile di adottare tecniche di replicazione server o di cloud computing che svolgono questo compito egregiamente piuttosto che “spostare” codice verso i client: la scelta del framework da usare per scrivere la propria applicazione web infatti dovrebbe ricadere su ciò che permette di completare il lavoro nel minor tempo possibile e contemporaneamente di produrre un ottimo risultato.

4.4 Estensibilità: MVC, Spring, Hibernate ed Integrazione ZK Framework mette a disposizione in maniera nativa diverse tecniche e tool per rendere il software prodotto scalabile: queste tecniche sono opzionali (ad esempio non è necessario produrre web application tramite pattern MVC, ma è fortemente consigliato dagli stessi sviluppatori del framework) ma diventano obbligatorie qualora c’è l’esigenza di accrescere o decrescere le funzionalità dell’applicazione sviluppata mantenendo una buona manutenibilità del codice, soprattutto se questo codice deve adattarsi a progetti Java

esistenti o a servlet particolari. Tra le tecniche degne di nota, che saranno sicuramente utilizzate negli sviluppi futuri del tool web-based, vengono analizzate il pattern MVC, i tool Spring ed Hibernate, e l’integrazione di altri linguaggi e il loro rapporto con il framework ZK.

4.4.1 Il Pattern MVC con ZK Il pattern architetturale Model-View-Controller (MVC, talvolta tradotto in italiano

Modello-Vista-Controllore) è molto diffuso nello sviluppo di interfacce grafiche di sistemi software object-oriented: esso è basato sulla separazione dei compiti fra i componenti software che interpretano tre ruoli principali:  il model fornisce i metodi per accedere ai dati utili all'applicazione;  il view visualizza i dati contenuti nel model e si occupa dell'interazione con utenti e agenti;  il controller riceve i comandi dell'utente (in genere attraverso la view) e li attua

modificando lo stato degli altri due componenti).

67 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

Questo schema, fra l'altro, implica anche la tradizionale separazione fra la logica applicativa (logica di business) a carico del controller e del model, e l'interfaccia utente a carico della view. Per comprendere come l’utilizzo del pattern MVC sia importantissimo anche scrivendo semplici applicazioni, partiamo da un esempio semplice di un’applicazione scritta con ZK, ovvero una semplice finestra “Hello World”, dotata di un input box in cui, con un click sul tasto OK, viene aggiornata una label con il messaggio in input:

Fig. 4.3 – Esempio web application in ZK: Hello World

Tralasciando varie configurazioni con web server o application server (molte guide e tutorial possono sono disponibili nei wiki di ZK) il codice, abbastanza semplice e intuitivo, per generare quest’applicazione di esempio senza utilizzare il pattern MVC è il seguente:

68 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

Hello World Message:

Questo codice (salvato in index.zul nel web server) presenta prevalentemente tag nel linguaggio di markup ZUL che descrivono i componenti dell’interfaccia grafica (in questo caso una window, una label, una textbox e un button), tutti dotati di un univoco id, fondamentale per accedere al componente grafico tramite script o controller. Tramite tag è stato associato al button con id “okButton” l’evento onClick, gestito direttamente dal codice Java introdotto nel file di esempio con il tag : è da notare che il codice Java non fa parte di una classe, e che al linguaggio Java possono sostituirsi altri linguaggi a seconda dell’interesse dello sviluppatore. Lo stesso esempio riscritto utilizzando il pattern MVC è costituito da due file: il file index.zul riscritto in questo modo:

Hello World Message:

e il file HelloController.java, del package esempio, che rappresenta la classe controller

69 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework associata al file index.zul:

package esempio;

import org.zkoss.zk.ui.event.Event; import org.zkoss.zk.ui.util.GenericForwardComposer; import org.zkoss.zul.Label; import org.zkoss.zul.Textbox;

public class HelloController extends GenericForwardComposer {

protected Label lMessage; protected Textbox txMessage;

public void onClick$okButton(Event event) { String message = txMessage.getValue(); lMessage.setValue(message); } }

Si intuisce facilmente che per ottenere il pattern MVC bisogna seguire le seguenti regole:

1. Nel file ZUL il componente da controllare deve avere nel tag l’attributo apply uguale al nome della classe Java responsabile del controllo. 2. La classe Java controller deve estendere la classe GenericForwardComposer ed avere come campi almeno i componenti descritti nel file ZUL con lo stesso nome id. 3. Ogni evento che si vuole controllare deve essere intercettato da un metodo dichiarato nella forma: nomeEvento$nomeComponente (Event event)

In questo modo si applica il pattern MVC specificando che:

1) Con "Model" intendiamo sia le funzionalità di business che gli oggetti business, in pratica logica applicativa e relativi oggetti. 2) La parte "View" è un insieme di componenti grafici che compongono la pagina web (ZUL file) senza la logica di elaborazione degli eventi. 3) La parte "Controller" è una classe Java registrata su un EventListener di uno o più componenti che ha il compito di elaborare gli eventi lanciati dalla View. Seguendo questo approccio i vantaggi che ne derivano sono considerevoli: i file che si ottengono sono più “puliti”, e sono sviluppabili separatamente; ovvero i progettisti di 70 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

interfacce grafiche possono lavorare ai vari file ZUL che compongono l’interfaccia grafica, e parallelamente gli sviluppatori implementano la logica applicativa collegandosi all’interfaccia grafica con il solo attributo apply=package.classeController.

4.4.2 Spring con ZK Nell’esempio precedente abbiamo descritto come la parte Model quella contenente oggetti business e di logica applicativa: possiamo quindi far gestire gli oggetti business ad un

framework come Spring. Spring è un framework open source per lo sviluppo di applicazioni su piattaforma Java: Esso è stato largamente riconosciuto all'interno della comunità Java quale valida alternativa al modello basato su Enterprise JavaBeans (EJB). Rispetto a quest'ultimo, il framework Spring lascia una maggiore libertà al programmatore fornendo allo stesso tempo un'ampia e ben documentata gamma di soluzioni semplici adatte alle problematiche più comuni. Sebbene le peculiarità basilari di Spring possano essere adottate in qualsiasi applicazione Java, esistono numerose estensioni per la

costruzione di applicazioni web-based costruite sul modello della piattaforma Java EE. Questo ha permesso a Spring di raccogliere numerosi consensi e di essere riconosciuto anche da importanti vendor commerciali quale framework di importanza strategica. La scalabilità di cui è dotato ZK Framework ci permette di accedere al contesto di Spring allo stesso modo come si accede a un qualsiasi altro componente grafico. Come esempio, iniziamo ad aggiungere all’applicazione Hello World del paragrafo precedente il listener di Spring (nel file web.xml del web container, es. Tomcat):

contextConfigLocation /WEB-INF/classes/applicationContext.xml org.springframework.web.context.ContextLoaderListener

A questo punto definiamo un semplice servizio Spring che effettua una elaborazione sul

71 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework messaggio di saluto immesso dall’utente:

package esempio;

public class HelloService implements IHelloService{

public String processMessage(String message) { return "Ecco il messaggio: " + message; } }

In questo semplice esempio il servizio HelloService non fa nulla di complicato: aggiunge solamente un messaggio di saluto; ma in una applicazione reale possiamo legare il servizio a un catalogo che accede via JPA (Java Persistence API) a un database e questo meccanismo è completamente trasparente all’intero modulo che implementa le pagine web. Per legare il bean "helloService" al Controller HelloController, basterà dichiarare un elemento della classe HelloController che si chiami esattamente "helloService", ovvero introdurre nel file HelloController.java il campo “protected IHelloService helloService;”. Infine per ultimare l’integrazione Spring-ZK bisognerà aggiungere al file index.zul dell’esempio il tag:

.....

che permette di installare il DelegatingVariableResolver per Spring sulla componente window di ZK dell'esempio.

Grazie all’integrazione tra ZK e Spring (ma lo stesso discorso si fa con gli EJB) riusciamo

72 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

non solo a disaccoppiare elegantemente la parte modulare che implementa le interfacce grafiche (Web 2.0) e la parte modulare che implementa la business logic, ma possiamo sfruttare la features messe a disposizione da Spring (un esempio su tutte: Spring Security).

4.4.3 Hibernate con ZK Quando la web application è scritta in Java e utilizza una base di dati nel model, è utile utilizzare la piattaforma Hibernate, una soluzione opensource che fornisce un servizio di

Object-relational mapping (ORM), ovvero che gestisce la rappresentazione e il mantenimento su database relazionale di un sistema di oggetti Java. L’integrazione tra Hibernate e ZK, come Spring, è semplice ed efficiente in quanto ci permette di accedere agli oggetti persistenti messi a disposizione da Hibernate allo stesso modo come si accede a un qualsiasi altro componente grafico. Tralasciando le configurazioni su web container, le tabelle del database e le annotazioni, possiamo dire sommariamente che se abbiamo una classe Evento:

package eventi;

import java.util.Date;

public class Evento { //come esempio, I metodi get e set sono omessi public Long id; public String titolo; public Date date; public Evento() {} }

Dopo aver reso persistente la classe con Hibernate, associando ad esso il file di configurazione “OR-mapping” Evento.hmb.xml:

73 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

E dopo aver specificato una classe responsabile dell’accesso ai dati (EventDAO):

package eventi; import org.zkoss.zkplus.hibernate.*; import java.util.Date; import java.util.List;

public class EventDAO { org.hibernate.Session _session;

public EventDAO() { _session=HibernateUtil.getSessionFactory().getCurrentSession(); } public void saveOrUpdate(Evento anEvent, String title, Date date) { anEvent.setTitle(title); anEvent.setDate(date); _session.saveOrUpdate(anEvent); }

public void delete(Event anEvent) { _session.delete(anEvent); }

public Event findById(Long id) { return (Event) _session.load(Evento.class, id); }

public List findAll() { return _session.createQuery("from Event").list(); } }

74 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

il collegamento tra i componenti ZK e gli oggetti persistenti viene implementato nel file .zul dell’interfaccia grafica in questo modo:

String datestr = new SimpleDateFormat("dd/MM/yy").format(each.date);

Ovvero, tutto si riduce alla fine ad un attributo ${metodo} del componente (tabella, lista di selezione, textbox, etc.) di cui si vuole che vengano catturati i dati.

4.4.4 Integrare linguaggi in ZK Una RIA scritta utilizzando ZK Framework può essere successivamente ampliata sfruttando altri linguaggi oltre a Java:

def name = "Hello World!";

75 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

Attualmente ZK supporta oltre a Java I linguaggi JavaScript, Ruby, Groovy e Python. In alternativa è possibile estendere il supporto ad altri linguaggi manualmente, con un semplice procedimento: 1. Fornire una classe che implementa l'interfaccia org.zkoss.zk.scripting.Interpreter, oppure che derivi dalla classe org.zkoss.zk.scripting.util.GenericInterpreter (se si vuole gestire direttamente i namespaces). In alternativa, se l'interpreter supporta BSF (Bean Scripting Framework), si può derivare la classe

org.zkoss.scripting.bsh.BSFInterpreter. 2. Dichiarare il linguaggio di scripting sia nel file WEB-INF/zk.xml che in zk/config.xml:

SuperJava my.MySuperJavaInterpreter

Da come si è potuto osservare, la scalabilità di una RIA creata con ZK Framework è ottima: l’applicazione può crescere o decrescere incorporando altri linguaggi e utilizzando pattern e tool di supporto mantenendo una buona leggibilità e manutenibilità del codice.

4.5 Qualità del supporto: ZK Forge e case studies ZK è un framework ideato, progettato e manutenuto dalla società Potix di Taiwan. È una giovane società che si occupa fin dagli anni ’90 di consulenza per aziende che necessitano di sviluppare applicazioni per il web (tra gli investitori di Poitx vi sono iD Innovation, di proprietà Acer, e Asus). Questo prodotto è largamente usato nel web: il sito di ZK conta più di un milione di download in tre anni di vita (un milione e 300 nel 2010); tra i propri clienti la Potix annovera una larga varietà di società private e istituzionali, dalle più piccole alle più grandi. La piattaforma software ha più di 5 anni di vita, e soltanto dal 2007

al 2010 sono state rilasciate più di 30 versioni corrette ed aggiornate di ZK Framework.

76 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

Questo framework gode di una buona qualità del supporto, e lo testimonia anche il fatto che aziende come: Barclays, Sun Microsystems, Swiss Re, Oracle, Societe’ Generale, Alcatel-Lucent, State Grid, MMC, China Southern Power Grid (che sono degli esempi di clienti che fanno parte di Fortune 500) lo hanno utilizzato per molti progetti interni, di consulenza e di outsourcing. Nato prevalentemente come software opensource e standard- based, ha riscosso un notevole successo anche nelle free comunity: sulla rete si trovano molti forum, tutorial, guide e corsi di formazione a riguardo. In aggiunta, in collaborazione

con sourceforge, la socità Potix ha implementato ZK Forge[s15], un container di applicazioni open source create e supportate da free community. Per adesso sono presenti progetti software quali:  ZeroKode, un ambiente Web-based per lo sviluppo visuale di pagine ZUML con drag- n-drop.  Zk-Dojo, un insieme di componenti per DOJO Toolkit.  Zk-FCKEditor, un porting del noto rich text editor FCK come componente ZK.

 Zk-Gmaps, un porting di Google Maps API come componenti ZK.  Zk Jet, un plug-in per i browser Firefox e Chrome che fornisce allo sviluppatore un ambiente “sandbox” per testare applicazioni scritte in ZK. La scelta di questo framework per implementare il tool web-based, con le prospettive appena elencate, è sembrata una scelta affidabile per il futuro della web application.

4.6 Curva di apprendimento: programming skills e linguaggio ZUML Allo sviluppatore che utilizza ZK Framework per implementare la propria RIA sono richieste le sole conoscenze basi di:  Java o linguaggi java scripting engine, quali Groovy, Rhino, JRuby (Java Ruby), Jython (Java Python)  HTML e XUL In aggiunta, per sfruttare la scalabilità e tutte le features messe a disposizione da ZK, lo sviluppatore (opzionalmente) deve avere una conoscenza di Javascript e Ajax (per la

programmazione lato client), Databinding dichiarativi (per avere controllo su POJO Java

77 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

Beans) e JSTL (JavaServer Pages Standard Tag Library). Si può notare che per progetti web semplici non sono richieste conoscenze approfondite: in realtà si potrebbero sfruttare sono linguaggi di scripting senza usare la programmazione ad oggetti (con tutti gli svantaggi che ovviamente ne derivano). Per progetti più avanzati la curva di apprendimento resta comunque bassa, considerando che oltre ad una buona conoscenza di Java e della OOP lo sviluppatore deve imparare il linguaggio ZUML (ZK User Interface Markup Language).

ZUML è un linguaggio di markup basato su XML usato esclusivamente per la definizione di interfacce grafiche: il suo funzionamento può essere paragonato ai linguaggi XUL e XHTML, ma chi ha dimestichezza con pagine web e HTML (requisito ovvio per lo sviluppatore web) si trova subito a suo agio per leggerlo e comprenderlo; in aggiunta, il tool di sviluppo visuale, ZK Studio, messo a disposizione dal framework, aiuta di molto la comprensione nella definizione di componenti della RIA da implementare.

4.7 Strumenti di supporto: i tool di ZK A corredo del framework RIA ci sono ottimi strumenti di supporto, suddivisi in prodotti software creati dalla stessa Potix autrice del framework, e “tool wrapper” di software di terze parti integrabili facilmente nella piattaforma di sviluppo. Il primo software sicuramente utile al supporto di ZK è ZK Studio, un ambiente visuale di sviluppo opensource integrato come plug-in Eclipse, che fornisce allo sviluppatore strumenti intuitivi per il design UI, prototyping, sviluppo e deployment delle applicazioni

web scritte con ZK. Questo software mette a disposizione dello sviluppatore una View in Eclipse dotata di una web window, una palette di componenti ZK, una property window e un editor di file .zul : i componenti ZK possono essere inclusi nel progetto con un semplice drag and drop, che va automaticamente ad aggiornare il file .zul del progetto, oppure è possibile programmare nell’editor direttamente con i tag ZUML (compresa la funzione di autocompletamento del codice) e il risultato viene aggiornato in tempo reale nella web window. Per testare il funzionamento dell’interfaccia che si sta sviluppando con

ZK studio con il web container, il software si occupa automaticamente dei file manifest

78 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

XML necessari alla configurazione del server, e alla fine crea con poche configurazioni il file .WAR della web application. In questo modo lo sviluppatore di RIA che utilizza Eclipse come piattaforma di sviluppo non ha bisogno di tool esterni per programmare la logica applicativa e l’interfaccia utente.

Fig. 4.3 – ZK Studio in esecuzione con Web Failure Model WSN Generator

Oltre a ZK Spring e ZK JSP Tags, librerie per l’integrazione di Spring e JSP analizzate nel paragrafo precedente, il framework ZK è dotato di due software Ajax implementabili liberamente nelle proprie web application: ZK Spreadsheet[s16] e ZK Calendar. ZK Spreadsheet è un foglio di calcolo web-based con funzionalità ed interfaccia simili a Microsoft Excel, con supporto a funzioni, grafici, import ed export di file .xls, e diagrammi collaborativi. E’ un software molto utile per visualizzare, modificare ed esportare dati in applicazioni web rimanendo nel web browser, e verrà sicuramente utilizzato in Web Failure Model WSN Generator per visualizzare i risultati ottenuti dalle simulazioni. ZK Calendar è un invece un applicazione Ajax simile a Google Calendar che permette di integrare un sistema di schedulino nelle proprie applicazioni web. Dal lato client offre un’interfaccia intuitiva, con task e appuntamenti modificabili con drag and drop, mentre lato server offre una efficiente integrazione con Java, database e Web services. Non è certo un’applicazione utile per aumentare in futuro le funzionalità del tool web-based

79 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework implementato come lavoro di tesi, a meno che non si pensi di presentare all’utente uno scheduling professionale sulle simulazioni e il tempo di simulazione effettuato, ma ZK Calendar rimane comunque un’applicazione che dimostra il buon supporto del framework ZK.

Fig. 4.4 – ZK SpreadSheet ZK Calendar

Per quanto riguarda i tool di terze parti, il framework ZK offre la possibilità di integrare e gestire diversi tool sia come componenti grafici nei file .zul sia come metodi a disposizione nelle classi Java. Tra i più importanti citiamo Jasper Report per la reportistica, FCK Editor per l’editing di testi, JfreeChart per i grafici, SIMILE Timeline per la visualizzazione di eventi time-based, Google Maps per le mappe interattive, etc. L’integrazione e la gestione di questi tool viene implementata in realtà attraverso un meccanismo di “wrapping” che può essere esteso[s17] teoricamente a qualsiasi software di terze parti.

80 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 4: ZK framework

4.8 Costi di sviluppo: le versioni disponibili Il Framework ZK e il software a corredo sono opensource e rilasciati con licenza GPL nella versione 3 e LGPL nella versione 5. Inoltre la compatibilità con l’ambiente Eclipse e l’utilizzo di Java fanno sì che lo sviluppo di applicazioni web con questa tecnologia sia indipendente dal sistema operativo: ciò si riflette sui costi di sviluppo, che in termini economici sono molto bassi rispetto ad altre piattaforme software presenti sul mercato. Oltre a ciò esistono versioni due versioni commerciali del framework: Professional

Edition ed Enterprise Edition. Esse differiscono dalla versione free nell’aggiunta di nuovi componenti grafici, nell’aumento generale di performance e nel supporto tecnico e consulting; il fulcro principale però resta la community opensource del progetto, in quanto ogni release viene prima rilasciata con licenza LGPL e poi perfezionata in ambienti commerciali, e non viceversa. Per quanto riguarda i costi in termini di tempo, si è discusso precedentemente dell’innovazione di cui ZK è basato, ovvero quella di adottare una metodologia di

sviluppo di Rich Internet Applications simile allo sviluppo di Java Desktop Applications, utilizzando programmazione orientata agli oggetti e guidata dagli eventi: analizzando vari case studies di aziende che hanno sfruttato questo framework per i propri progetti si può notare un netto miglioramento in termini di tempi di sviluppo. Un piccolo esempio lo è il seguente lavoro di tesi, la cui implementazione pratica avrebbe richiesto con un approccio tradizionale tempi di sviluppo più lunghi.

81 Capitolo 5 Implementazione del tool

Il presente capitolo descrive le fasi salienti per l’implementazione del tool web-based, Web Failure Model WSN Generator. Nella tesi si è dato ampio spazio più alla progettazione che all’implementazione, e per non dilungare troppo sulla programmazione in sé, verranno descritte esclusivamente le classi create e il loro ruolo nel progetto.

Il capitolo termina sull’esposizione della funzionalità disegno topologia della WSN e su come si è utilizzato il framework per realizzarla.

5.1 Pattern MVC e struttura della RIA Per rendere il tool il più scalabile e modificabile possibile, si è adottato come prima scelta implementativa la suddivisione dei componenti software utilizzando il pattern MVC, nelle modalità elencate nel paragrafo 4.4.1. Si è scelto in particolare di racchiudere le classi del

progetto desktop-based Failure Model WSN Generator e il simulatore Mobius nel model, compresa la nuova classe AmbientVar e il log. L’interfaccia grafica desktop scritta in Swing, anche se esclusa dal funzionamento del tool web-based, resta comunque inclusa nel progetto e nel model, in quanto si è prefissato nella progettazione che in futuro entrambi i tool potranno essere sviluppati parallelamente. Nell’ambiente di sviluppo eclipse, in particolare, non si sono inglobate le classi del progetto desktop nel progetto web, ma si è creato un nuovo progetto (ZK Project) che fa riferimento al progetto esistente

del tool desktop-based: in questo modo il tempo che viene speso in configurazione (il

82 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool progetto desktop-based deve sempre rimanere aperto, e tutte le sue classi devono far parte del classpath sia dell’ambiente eclipse che del web container tomcat scelto) ha reso più efficiente e comodo lo sviluppo e il debugging di entrambi i tool.

Fig. 5.1 – struttura del tool web-based: MVC con ZK Framework

Alle componenti model è stata lasciata la possibilità di implementare un database PostgreSQL, compatibile con Mobius, in quanto nelle future implementazioni è possibile dotare questo simulatore di un archivio in cui memorizzare i risultati delle simulazioni. Non essendoci vincoli stretti di compatibilità tra il web framework ed i vari software di database, sarà possibile sfruttare l’archivio in PostgreSQL del server per memorizzare anche le credenziali degli utenti, o per associare agli utenti le metriche di valutazione

83 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

scelte per la simulazione: per questo si è lasciato un collegamento progettuale, opzionale, tra le classi controller che sfruttano quasi tutte il ZK Framework, e l’archivio dati. In particolare il componente software controller racchiude le classi che dialogano sia con i componenti ZK dell’interfaccia web, sia con i software Failure Model WSN Generator e Mobius. Oltre a tutte le classi java realizzate per il controllo, questo componente include anche il file .jar del progetto zkDiagram, un porting opensource della libreria JavaScript draw2d necessaria per implementare la funzionalità disegno topologia WSN. La view

infine è composta di soli file .zul dell’interfaccia grafica dell’applicazione web, scritti utilizzando sia il linguaggio ZUML sia HTML.

5.2 Le classi controller Fanno parte del package webfamogen.controller tutte le classi che, richiamate dai file .zul attraverso l’attributo “apply”, controllano il funzionamento della GUI web e dialogano con i software desktop installati nel server. In particolare di questo package fanno parte le

classi:  LoginBoxController: responsabile della sessione e dell’autenticazione dell’utente attraverso l’interfaccia del file login.zul. Non avendo ancora implementato un database e una tabella utenti, l’autenticazione viene eseguita con un semplice controllo tra i campi user e password: se i campi sono corretti e non vuoti, vengono sfruttati i metodi delle classi di utilità per creare i file e le cartelle necessarie al funzionamento della simulazione remota, e se già esistono viene collega la sessione

corrente con le cartelle specifiche dell’utente che ha eseguito l’accesso.  WebTopologyController: è la classe che controlla l’interfaccia principale del tool web-based, responsabile di due compiti: emulare il comportamento del tool desktop- based (sia nell’interfaccia che nelle funzionalità) e gestire le scelte utente nella modellazione e simulazione delle WSN.  ModelGeneratedUtil: è la classe che gestisce il modello generato o compilato sia dal tool desktop-based che da Mobius. Essa fornisce all’utente la possibilità di salvare i

modelli generati nel proprio sistema piuttosto che conservarli sul server, sfruttando sia

84 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

le classi di utilità dell’applicazione web sia il metodo org.zkoss.zul.Filedownload.save messo a disposizione dallo ZK Framework.  DesignerController: fa parte del package topology.designer ed è la classe controller responsabile del disegno della topologia WSN ed in particolare della disposizione corretta dei nodi, del corretto disegno dei link a seconda del metodo di propagazione selezionato, e del controllo degli input dell’utente. Essa dialoga sia con l’interfaccia grafica implementata in TopologyDesigner.zul, sia con la libreria ZKDiagram.jar, sia

con le classi di utilità.  BorderLayoutComposer: è classe che ha l’unico compito di gestire e mostrare tutti i file ZUL che compongono l’interfaccia grafica all’utente, a seconda delle sue scelte. E’ la classe con meno logica applicativa delle altre, ma è fondamentale sia per gestire il layout (di tipo border) delle pagine web sia per consentire lo sviluppo della GUI suddividendolo in più file, in modo da lavorare in maniera più organizzata.

5.3 Classi di utilità del tool web-based Così come si è proseguito per il tool desktop-based, anche per il tool web-based si sono create delle classi di utilità a supporto dell’applicazione, e in particolare a supporto delle classi controller:  WebUtil: è la classe responsabile della creazione e controllo di directory e file dell’utente correttamente autenticato al sistema. Essa fornisce metodi per la decompressione del file .zip della topologia caricata dall’utente, per la compressione

del modello generato e compilato, e per la restituzione del path delle user directories. In particolare WebUtil sfrutta i seguenti packages: java.io.File per la manipolazione dei file e directory, java.util.zip per la compressione/decompressione, org.zkoss.util.media e org.zkoss.zul.Fileupload per l’upload della topologia. I campi e i metodi di questa classe sono stati implementati in modo da essere indipendenti dal sistema operativo utilizzato per contenere il web server, in modo tale da far distinzione tra i diversi filepath creati: si è notato infatti che i filepath creati nel

sistema Windows (con carattere separatore “\”), diversi dai percorsi creati nei sistemi

85 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

Unix/Linux (con carattere separatore “/”), impedivano il corretto funzionamento del simulatore Mobius.  ZKTextBoxHandler: si occupa di gestire i log creati dall’applicazione Failure Model WSN Generator. Come descritto nel paragrafo 2.2, diminuendo l’accoppiamento tra l’interfaccia grafica e la logica applicativa del software desktop-based è stato possibile, attraverso l’utilizzo dei log Java, catturare i messaggi dell’applicazione e mostrarli all’utente o all’amministratore in qualsiasi modo si voglia, creando soltanto

un nuovo handler. In questo caso, questa classe fornisce un Handler che cattura i log dell’applicazione desktop e li invia al browser dell’utente in una ZK Text Box dell’interfaccia grafica. L’implementazione di questa classe, che eredita dalla classe Handler, ha dato inizialmente risultati imprevisti: infatti è stato difficile gestire thread generati dai log lato server (cioè in un ambiente Java ben disposto al multi-threading) che direttamente si collegano al componente grafico ZKTextBox, che viene generato in run-time sfruttando il linguaggio JavaScript, il quale non supporta nativamente il

multi-threading. Si è aggirato questo vincolo sfruttando lato server un oggetto StringBuilder e lato client un timer in ZK che aggiorna periodicamente la Text Box con il suo contenuto.  ExportUtil: insieme alle classi WSLink e WSNode, è responsabile della corretta generazione dei file della topologia WSN disegnata dall’utente nel browser. Essa viene richiamata dal controller DesignerController e sfrutta i package java.io.File e java.util.zip per creare i file coordinate.txt, distances.txt, energy.txt, losses.txt,

neighbor.txt, radio.txt, TinySan.txt e topology.txt descritti nel paragrafo 1.5. Alla fine della creazione questi file vengono compressi in un unico archivio zip e messi in download all’utente.

5.4 La view ed i file ZUL Lavorando con ZK Framework si è utilizzato un metodo molto comodo per separare e sviluppare individualmente i componenti grafici visualizzabili dall’utente. Si possono

infatti creare diversi file .zul che compongono la grafica di un progetto, ognuno con un

86 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool diverso layout grafico, diversi componenti e comportamenti, e collegarli tra di loro sia sfruttando il tag del linguaggio ZUML sia chiamando i metodi Java Executions.getCurrent().sendRedirect e Executions.createComponents messi disposizione dal framework. Ad esempio, per lanciare il tool web-based implementato bisogna digitare l’URL corretto contenente il file index.zul: all’interno di questo file, escludendo i tag che compongono la grafica della pagina web, è presente l’istruzione:

la quale non solo richiama automaticamente il file Login.zul incluso nella directory view del progetto includendolo interamente nella finestra corrente del browser, ma è indipendente dal percorso generato nel web server dopo il deployment dell’applicazione: in qualunque percorso o sistema è installato il web container tomcat, il file viene sempre richiamato in maniera corretta. Dall’altro lato, il file Login.zul è controllato dalla classe Java LoginBoxController, in cui il frammento di codice che gestisce la corretta autenticazione dell’utente è:

if (isLogged) {

WebUtil.preparadirectory(user); Executions.getCurrent().sendRedirect("/view/View.zul");

}

Il quale prepara file e directory personalizzate per l’utente e carica la pagina View.zul con un redirect del browser. Infine la pagina View richiamata dal corretto login è controllata a sua volta dalla classe controller BorderLayoutComposer la quale, a seconda della funzionalità scelta dall’utente, con questo frammento di codice:

87 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

if (item!=null) {

MenuNode node = (MenuNode)item.getValue(); Executions.createComponents(node.getLink(),contentDiv,null);

}

ricava l’URL relativo della pagina .zul scelta dall’utente attraverso node.getLink(), elimina i componenti presenti e li ricrea sfruttando la nuova pagina web e la funzione Executions.createComponents(String, Component, Map). Il meccanismo appena descritto di caricare dinamicamente le pagine web in formato .zul permette una buona scalabilità del software creato attraverso la modularità con cui si aggiungono o si eliminano pagine web necessarie al funzionamento dell’applicazione web. Nel progetto Web Failure Model WSN Generator in particolare le pagine .zul

implementate sono:  Login.zul: Window del login utente;  View.zul: Layout Container di tipo Border dell’applicazione;  Generator.zul: Window che emula graficamente il tool desktop-based;  Model_generated.zul: Floating window del risultato della generazione e compilazione del modello;  Metrics.zul: Window per la scelta delle metriche da utilizzare nella simulazione;

 TopologyDesigner.zul: Window per il disegno della topologia WSN. Per aumentare la sicurezza del tool web-based, si può impedire l’accesso diretto a queste pagine da parte dell’utente principalmente in due modi: utilizzando i metodi a disposizione della classe org.zkoss.zk.ui.Executions oppure sfruttare il più affidabile meccanismo Spring Security messo a disposizione dal web frame work Spring.

5.5 Il Disegno della Topologia: draw2d La funzionalità del disegno della topologia da parte dell’utente è stata implementata non

88 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool sfruttando direttamente ZK Framework, ma la libreria zkDiagram della Integrated Modelling. Il disegno grafico su browser web e soprattutto l’oggetto Canvas di HTML5 non è ancora supportato da ZK, e per questo motivo molti sviluppatori hanno adottato soluzioni alternative sia per implementare in tempi rapidi queste funzionalità, sia per sfruttarle nello ZK Framework: ne è un esempio zkDiagram, la quale non è altro che un porting per ZK della libreria Open-jACOB draw2d di Andreas Herz che, scritta interamente in JavaScript, permette di disegnare e modificare diagrammi di vari tipi.

Rispetto a draw2d che attualmente è diventata una libreria matura e stabile per disegnare diagrammi su browser web, zkDiagram è un porting incompleto e per certe funzionalità instabile della suddetta libreria, in quanto non fornisce al framework ZK tutte le funzionalità che draw2d possiede in Javascript: non è stato possibile utilizzare direttamente la libreria JavaScript, poiché tutto ciò che l’utente svolge nel canvas di draw2d deve essere intercettato da ZK, e il modo più semplice e rapido è utilizzare il porting. ZK Framework mette comunque a disposizione una metodologia per importare qualunque libreria scritta in Javascript nei suoi componenti grafici, ma il procedimento è lungo e tedioso per librerie con molte righe di codice, come draw2d: questo perché importare una libreria in ZK significa “sdoppiare” lo sviluppo in due parti e in due linguaggi diversi; da un lato bisogna intercettare i cambiamenti provocati dal client (libreria Javascript) e notificare al server lo stato attuale dell’applicazione, e dall’altro lato bisogna modificare la parte della sessione utente che riguarda l’uso della libreria con i cambiamenti voluti dal framework ZK lato server. Bisogna poi implementare tutte le funzioni Java che riguardano i get ed i set dei campi della libreria Javascript e sviluppare dei metodi Java che richiamano metodi JavaScript della libreria su cui fare il porting. Fortunatamente le funzionalità del porting di draw2d per ZK sono state sufficienti per realizzare la funzionalità del disegno della topologia, in quanto tutto ciò che lo sviluppatore WSN ha bisogno come oggetti di disegno sono soltanto nodi e link: in aggiunta, zkDiagram, anche se mal documentato, è un progetto opensource, ed è quindi possibile modificare ed arricchire il codice sorgente a seconda di ulteriori funzionalità richieste dal tool web-based per la simulazione remota di WSN. Allo stato attuale

89 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool quest’applicazione permette di disporre su un workspace di dimensioni personalizzabili dall’utente dei nodi wireless con proprietà modificabili di coordinate, tecnologie radio e batteria, routing, sensor board e application. Dopo la disposizione di nodi l’utente può collegare i link manualmente oppure scegliere un modello di propagazione da una lista (ad esempio, fixed Radius). Nella creazione dei link, automatica o manuale, viene creato visualmente una curva che collega i nodi in esame, con una piccola label che indica la probabilità di perdita di pacchetto.

Nell’utilizzo di ZK Framework si è notato infine come sia efficace l’utilizzo di codice HTML iniettato nel linguaggio ZUML: nei tag infatti possiamo inserire l’attributo style, il quale applica uno stile HTML al componente desiderato:

Ad esempio nel codice precedente nella GUI web è stato disposto un componente workspace di nome wrsTopology, con connessioni di tipo bezier e con stile HTML dotato di un’immagine (la cui path è ricavata con codice JavaScript) di sfondo con un motivo di riempimento: questo stile può essere modificato a tempo di esecuzione con codice Java:

if (whatBackground.equals("map_alvin")) {

this.wrsTopology.setStyle("overflow:auto; background:#FFFFFF url(/WebFAMOGEN/images/alvin-map.jpg) no-repeat; background-attachment: scroll;");

this.wrsTopology.invalidate();

}

attraverso il metodo set Style si è modificato totalmente lo stile del componente workspace

90 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

e tramite il metodo invalidate() si è forzato un refresh di tutti i componenti grafici della sessione attuale: con questo piccolo “hack” l’utente può modificare lo sfondo del workspace su cui disporre i nodi ed i link, scegliendo o caricando sul proprio spazio server un immagine di una zona reale dove disporre la WSN.

5.6 Esempi di funzionamento Il capitolo si conclude con i seguenti screenshot del tool implementato, i quali riflettono il

funzionamento descritto nel paragrafo 2.2 dedicato ai casi d’uso:

Fig. 5.2 – Login Page del tool

91 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

Fig. 5.3 – Pagina del Failure Model WSN Generator per la generazione del modello: upload della topologia

Fig. 5.4 – Generazione del modello e download del modello generato

92 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

Fig. 5.5 – Disegno della topologia WSN – Disposizione dei nodi

Fig. 5.6 – Disegno della topologia WSN – Creazione link con modello di propagazione Fixed Radius

93 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

Fig. 5.7 – Wizard per automatizzare il processo di disegno, modellazione e simulazione di una WSN

Fig. 5.8 – Wizard – scelta delle metriche di valutazione per la simulazione di WSN

94 Conclusioni

Il presente lavoro è stato diretto ad approfondire le fasi di generazione automatica di modelli analitici e a porre le basi per estendere la fase della simulazione del modello analitico generato. Partendo dal tool di generazione automatica di modelli di fallimento e dal simulatore mobius, si è implementato un tool di remoting che mette a disposizione questi strumenti in maniera semplice, rapida e con un carico computazionale esiguo da

parte dell'utente. Ciò nel più ampio disegno diretto a meglio inquadrare la progettazione e la modellazione delle reti di sensori senza filo nelle varie applicazioni ipotizzabili. Attraverso questo tool l’utente è in grado con un thin client di inserire o disegnare lo scenario topologico da modellare, ottenere automaticamente un modello analitico atto ad incentrarsi sulla dependability del sistema, scegliere le metriche da valutare e scaricare il risultato ottenuto. Inoltre è in grado di ricavare dalla topologia come viene propagata la comunicazione tra i vari nodi sensore attraverso un modello manuale, un modello di tipo

fixed radius e di altri modelli implementabili successivamente. Tutto questo via web, senza installare o configurare nulla e senza avere un calcolatore particolarmente performante. Le scelte di progetto nella realizzazione dell'applicazione web sono mirate a rendere il risultato ottenuto quanto più estensibile possibile. Successivamente, infatti, è possibile l’aggiunta di altri modelli di propagazione, di altri modelli analitici e di ulteriori metriche di valutazione che possono essere aggiunti in maniera semplice anche se si tratta di sfruttare librerie esterne o software di terze parti.

95 Realizzazione di uno strumento web-based per la simulazione remota di WSN Cap. 5: Implementazione del tool

Al fine di dimostrare quanto affermato è stato aggiunta la funzionalità del disegno della topologia della rete di sensori, la quale è una funzionalità comoda per il progettista di WSN e che è stata implementata integrando e adattando una libreria web nel progetto. La scelta del framework per l'implementazione ha da un lato avvicinato le applicazioni desktop alle applicazioni web e dall'altro ha offerto una programmazione event-driven e un linguaggio di markup tali da rendere una bassa curva di apprendimento e tempi di sviluppo relativamente brevi ed il risultato pratico ottenuto presenta caratteristiche che giustificano il trend attuale dello sviluppo delle Rich Internet Applications e del miglioramento che esse apportano al web 2.0. Le metriche adottate nella scelta delle tecnologie RIA hanno reso il prodotto software implementato adattabile al fine di ottenerne nuove funzionalità e futuri sviluppi. In particolare lo sviluppo del tool desktop-based, che può essere arricchito di altri modelli analitici, può proseguire parallelamente allo sviluppo dell’applicazione web based che funge da container per nuovi modelli di propagazione, nuove metriche di valutazione, nuovi software di simulazione e nuovi aggiornamenti dei framework di modellazione e di simulazione. L’inclusione di una piattaforma software come Spring e di un database come PostgreSQL, magari gestito da strumenti ORM (Object-relational mapping) come Hibernate, sarà sicuramente necessaria per l’user managment e per memorizzare i risultati delle simulazioni.

96

Bibliografia

[1] Marcello Cinque, Domenico Cotroneo, Catello Di Martino, Stefano Russo. “Modeling and assessing the Dependability of Wireless Sensor Networks”, 2007. [2] Catello di Martino "Resiliency assessment of wireless sensor networks: a holistic approach", 2009. [3] W.H. Sanders, J.F. Meyer. “A unified approach for specifying measures of performance, dependability, and performability”. In A. Avizienis, J. Kopetz, and

J.Laprie, editors, Dependable Computing for Critical Applications, volume 4 of Dependable Computing and Fault-Tolerant Systems, 1991. [4] Umberto Sannolo, “Generazione automatica di modelli di fallimento per la simulazione di reti WSN”, 2009. [5] D.D. Deavours, G. Clark, T. Courtney, D. Daly, S. Derisavi, J.M. Doyle, W.H. Sanders, and P.G. Webster. “The Moobius framework and its implementation” IEEE Transactions on Software Engineering, 28(10):956–969, 2002.

[6] William H. Sanders and The Board of Trustees of the University of Illinois. “Mobius, User manual”, 2006. [7] Roger S. Pressman. "Principi di Ingegneria del Software", 2007. [8] Bruce Eckel, “Thinking in Java”, 2007. [9] R. Asleson, N.T. Schutta, “Foundations of Ajax”, 2006 [10] Potix Corp. “ZK: the developer’s guide”, 2009. [11] H. Chen, R. Cheng, "ZK: Ajax Without JavaScript Framework", 2007

97

Sitografia

[s1] www.mobius.illinois.edu (Mobius tool homepage) [s2] www.adaptivepath.com/ideas/essays/archives/000385.php (Ajax Manifest) [s3] www.icefaces.org (IceFaces Homepage) [s4] www.openlaszlo.org (Openlaszlo Homepage) [s5] www.adobe.com/products/flex/ (Adobe Flex Homepage) [s6] download.macromedia.com/pub/flash/whitepapers/richclient.pdf (RIA Manifest)

[s7] www.themidnightcoders.com/products/weborb-for-java (Web-Orb Homepage) [s8] opensource.adobe.com/wiki/display/blazeds/BlazeDS/ (BlazeDS Homepage) [s9] echo.nextapp.com/site/ (Echo Framework Homepage) [s10] www.sencha.com/products/gwt/ (ExtGWT homepage) [s11] code.google.com/p/smartgwt/ (SmartWGT homepage) [s12] vaadin.com/home/ (Vaadin Homepage) [s13] click.apache.org (Apache Click Homepage)

[s14] www.zkoss.org (ZK Framework Homepage) [s15] www.zkoss.org/community/zkforge.dsp (ZK Forge) [s16] www.zkoss.org/product/zkspreadsheet.dsp (ZK Spreadsheet) [s17] docs.zkoss.org/wiki/Behind_The_Scene:_Integrating_Google_Maps (ZK Small Talk: Integration) [s18] docs.zkoss.org/wiki/Small_Talks (ZK: Small Talks) [s19] www.integratedmodelling.org/software/zk/zkdiagram.html (zkDiagram Project) [s20] www.draw2d.org/draw2d/ (draw2d Homepage)

98