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

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Realizzazione di uno strumento web-based based per la simulazione remota di reti di sensori senza filo"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Realizzazione di uno strumento web-based 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

2 A mio padre e mia madre Non aetate verum ingenio apiscitur sapientia.

3 Indice Introduzione Capitolo 1. Wireless Sensor Network: Modellazione e Simulazione 1.1 Wireless Sensor Networks: Reti di Sensori senza filo 1.2 Progettare e Simulare una WSN 1.3 Il Tool Failure Model WSN Generator Il simulatore Mobius La topologia della rete 1.4 Motivazioni del remoting nella simulazione di WSN Capitolo 2. Analisi dei Requisiti e Progettazione 2.1 Web Model WSN Generator: concetti chiave 2.2 Casi d uso 2.3 Diminuire l accoppiamento La classe AmbientVar Logging Capitolo 3. Tecnologie e Strumenti per le Rich Internet Applications 3.1 Le RIA e metriche di valutazione AJAX e JavaScript Caratteristiche e metriche di valutazione dei framework 3.2 Java Server Pages e IceFaces 3.3 Openlaszlo 3.4 Adobe Flex 3.5 Echo Google Web Toolkit 3.7 Apache Click Capitolo 4. ZK Framework 4.1 Direct RIA: cos è ZK Framework 4.2 Caratteristiche principali di ZK Framework 4.3 Integrazione con Java: il funzionamento di ZK Framework Framework Server-Centrico e Client-Centrico 4.4 Estensibilità: MVC, Spring, Hibernate ed Integrazione Il Pattern MVC con ZK Spring con ZK Hibernate con ZK II

4 4.4.4 Integrare linguaggi in ZK Qualità del supporto: ZK Forge e case studies Curva di apprendimento: programming skills e linguaggio ZUML Strumenti di supporto: i tool di ZK Costi di sviluppo: le versioni disponibili 81 Capitolo 5. Implementazione del tool Pattern MVC e struttura della RIA Le classi controller Classi di utilità del tool web-based La view ed i file ZUL Il Disegno della Topologia: draw2d Esempi di funzionamento 91 Conclusioni Bibliografia Sitografia III

5 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

6 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

7 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

8 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/m 3 ) e far sì che i nodi siano tutti vicini tra loro, condizione necessaria affinché possano comunicare. 7

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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 reverseengineering 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

22 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 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

23 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 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

24 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 2 2 il nodo j e il nodo k calcolata con la formula: d x x y y ; i valori j=k (la distanza tra il nodo e se stesso) avranno ovviamente valore 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

25 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

26 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

27 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

28 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

29 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 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

30 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

31 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

32 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

33 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 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

34 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

35 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

36 Cap. 2: Analisi dei Requisiti e Progettazione 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

37 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 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 , 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

38 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

39 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

40 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

41 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 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

42 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

43 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

44 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 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

45 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

46 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

47 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

48 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 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

49 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

50 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

51 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

52 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

53 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, è closedsource 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

54 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

55 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

56 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 webbased basate su GWT. GWT compila i sorgenti Java compatibili con J2SE 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

57 Cap. 3: Tecnologie e strumenti per le Rich Internet Applications esistendo in Javascript, questo tipo viene convertito come numero floating point doubleprecision; 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

58 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 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

59 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

60 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

61 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

62 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

63 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

64 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

65 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

66 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 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

67 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 servercentrico 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

68 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 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

69 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

70 Cap. 4: ZK framework <zk> <window title="my window" border="normal" height="200px" width="200px" closable="true" sizable="true"> Hello World Message: <label id="lmessage" /> <textbox id="txmessage" /> <button id="okbutton" label="ok" onclick="ok_onclick()" /> <zscript type="java"> <![CDATA[ public void ok_onclick() { lmessage.setvalue(txmessage.getvalue()); } ]]> </zscript> </window> </zk> 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 <![CDATA[ ]]>: è 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: <zk> <window title="my window" border="normal" height="200px" apply="esempio.hellocontroller" width="200px" closable="true" sizable="true"> Hello World Message: <label id="lmessage" /> <textbox id="txmessage" /> <button id="okbutton" label="ok" /> </window> </zk> e il file HelloController.java, del package esempio, che rappresenta la classe controller 69

71 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

72 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 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): <context-param> <param-name>contextconfiglocation</param-name> <param-value> /WEB-INF/classes/applicationContext.xml </param-value> </context-param> <listener> <listener-class> org.springframework.web.context.contextloaderlistener </listener-class> </listener> A questo punto definiamo un semplice servizio Spring che effettua una elaborazione sul 71

73 Cap. 4: ZK framework messaggio di saluto immesso dall utente: <beans> <bean id="helloservice" class="esempio.helloservice"> </bean> </beans> 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: <zk> <?variable-resolver class="org.zkoss.zkplus.spring.delegatingvariableresolver"?>... </zk> 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

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

75 Cap. 4: ZK framework <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping- 3.0.dtd"> <hibernate-mapping> <class name="eventi.evento" table="events"> <id name="id" column="event_id"> <generator class="native"/> </id> <property name="date" type="timestamp" column="event_date"/> <property name="title"/> </class> </hibernate-mapping> 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

76 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: <zk> <zscript><![cdata[ import java.util.date; import java.text.simpledateformat; import events.evento; import events.eventdao; //ricava tutti gli elementi dal database List allevents = new EventDAO().findAll(); ]]></zscript> <listbox id="lbxevents"> <listhead> <listheader label="title" width="200px"/> <listheader label="date" width="100px"/> </listhead> <listitem foreach="${allevents}" value="${each}"> <listcell label="${each.title}"/> <zscript> String datestr = new SimpleDateFormat("dd/MM/yy").format(each.date); </zscript> <listcell label="${datestr}"/> </listitem> </listbox> </zk> 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 Integrare linguaggi in ZK Una RIA scritta utilizzando ZK Framework può essere successivamente ampliata sfruttando altri linguaggi oltre a Java: <button onclick="javascript:do_something_in_js()"/> <zscript language="groovy"> def name = "Hello World!"; </zscript> 75

77 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: <zscript-config> <language-name>superjava</language-name> <interpreter-class> my.mysuperjavainterpreter </interpreter-class> </zscript-config> 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

78 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 standardbased, 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 dragn-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

79 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

80 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

81 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

82 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

83 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 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

84 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

85 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 desktopbased (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

86 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

87 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

88 Cap. 5: Implementazione del tool diverso layout grafico, diversi componenti e comportamenti, e collegarli tra di loro sia sfruttando il tag <include> 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: <include src="/view/login.zul"></include> 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

89 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

90 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

91 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: <workspace router="bezier" id="wrstopology" style="background:#ffffff url(${c:encodeurl('/images/square_tiled.gif')}) repeat;"> </workspace> 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

92 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

93 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

94 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

95 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

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

Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo 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

Dettagli

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale tesi di laurea inventario comunale Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo Ing. Luigi Pontillo candidato Michele Vitelli Matr. 534 2170 Redazione dell Inventario

Dettagli

SISTEMA DI MONITORAGGIO AMBIENTALE TRAMITE WSN

SISTEMA DI MONITORAGGIO AMBIENTALE TRAMITE WSN Università degli Studi di Pavia Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SISTEMA DI MONITORAGGIO AMBIENTALE TRAMITE WSN Relatore: Prof. Paolo Ettore Gamba Correlatore:

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

Master SIT Settembre 2006. Corso Web & GIS - Master in Sistemi Informativi Territoriali AA 2005/2006. Chiara Renso. ISTI- CNR c.renso@isti.cnr.

Master SIT Settembre 2006. Corso Web & GIS - Master in Sistemi Informativi Territoriali AA 2005/2006. Chiara Renso. ISTI- CNR c.renso@isti.cnr. COSTRUIRE APPLICAZIONI WEB GIS: SERVIZI E STRATEGIE Corso - Master in Sistemi Informativi Territoriali AA 2005/2006 ISTI- CNR c.renso@isti.cnr.it I servizi WebGIS...1 Download di dati...3 Visualizzazione

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

il Mac e lo studio legale: primi passi in EasyLex

il Mac e lo studio legale: primi passi in EasyLex _tutorial Come approcciare il software per la gestione degli studi legali che accompagna gli utenti della Mela dai lontani tempi di Mac OS Francesco Pignatelli il Mac e lo studio legale: primi passi in

Dettagli

MIGLIORA L EFFICIENZA OPERATIVA LEAN PRODUCTION SOLUTIONS. www.imytech.it

MIGLIORA L EFFICIENZA OPERATIVA LEAN PRODUCTION SOLUTIONS. www.imytech.it MIGLIORA L EFFICIENZA OPERATIVA LEAN PRODUCTION SOLUTIONS www.imytech.it «NON È VERO CHE ABBIAMO POCO TEMPO, LA VERITÀ È CHE NE PERDIAMO MOLTO» Lucius Annaeus Seneca MIGLIORA LA PRODUZIONE CON WERMA SIGNALTECHNIK

Dettagli

Realizzazione di un sistema di logging prototipale per la piattaforma

Realizzazione di un sistema di logging prototipale per la piattaforma tesi di laurea Realizzazione di un sistema di logging prototipale per la piattaforma Android Anno Accademico 2011 / 2012 relatore Ch.mo prof. Marcello Cinque candidato Dario De Meis Matr. 528 / 741 Smartphone

Dettagli

USER GUIDE. Manuale operativo per l utilizzo dell applicativo per il monitoraggio remoto Aditech Life REV 1

USER GUIDE. Manuale operativo per l utilizzo dell applicativo per il monitoraggio remoto Aditech Life REV 1 USER GUIDE Manuale operativo per l utilizzo dell applicativo per il monitoraggio remoto Aditech Life REV 1 SOMMARIO Introduzione... 3 Sensore BioHarness... 3 OVERVIEW BIOHARNESS 3.0 BT/ECHO... 4 OVERVIEW

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

Dettagli

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE INTRODUZIONE L ingegneria del software è la disciplina tecnologica e gestionalerelativa alla realizzazione sistematica e alla manutenzione di un software rispettando

Dettagli

Application note. CalBatt NomoStor per i sistemi di accumulo di energia

Application note. CalBatt NomoStor per i sistemi di accumulo di energia 1. Panoramica Application note CalBatt NomoStor per i sistemi di accumulo di energia Gli Energy Management Systems () sono dispositivi atti al controllo dei flussi di energia dalle sorgenti di produzione

Dettagli

idaq TM Manuale Utente

idaq TM Manuale Utente idaq TM Manuale Utente Settembre 2010 TOOLS for SMART MINDS Manuale Utente idaq 2 Sommario Introduzione... 5 Organizzazione di questo manuale... 5 Convenzioni... Errore. Il segnalibro non è definito. Installazione...

Dettagli

> Gestione Invalidi Civili <

> Gestione Invalidi Civili < > Gestione Invalidi Civili < GUIDA RAPIDA ALL'UTILIZZO DEL PRODOTTO (rev. 1.3) INSTALLAZIONE, ATTIVAZIONE E CONFIGURAZIONE INIZIALE ESECUZIONE DEL SOFTWARE INSERIMENTO ANAGRAFICA RICERCA ANAGRAFICA INSERIMENTO

Dettagli

Progettazione e sviluppo di una web application per la generazione di dati simulati per un sistema di assistenza alla guida attraverso Google Maps

Progettazione e sviluppo di una web application per la generazione di dati simulati per un sistema di assistenza alla guida attraverso Google Maps UNIVERSITA' DEL SALENTO FACOLTA' DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA DELL INFORMAZIONE Progettazione e sviluppo di una web application per la generazione di dati simulati per un sistema di assistenza

Dettagli

ECDL Base. ECDL Full Standard

ECDL Base. ECDL Full Standard http://www.nuovaecdl.it/ Modulo ECDL Base ECDL Full Standard ECDL Standard Computer Essentials Sì Sì Sì (1) Online Essentials Sì Sì Sì (1) Word Processing Sì Sì Sì (1) Spreadsheets Sì Sì Sì (1) IT Security

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

Albano Squizzato ingsquizzato@libero.it. Moodle-manuale. manuale per il docente. Generazione Web 2013-14 - G9

Albano Squizzato ingsquizzato@libero.it. Moodle-manuale. manuale per il docente. Generazione Web 2013-14 - G9 Albano Squizzato ingsquizzato@libero.it Moodle-manuale manuale per il docente Generazione Web 2013-14 - G9 Come utilizzare Moodle La versatilità di Moodle consente la totale personalizzazione dell interfaccia,

Dettagli

SIMULAZIONE E ANALISI SOFTWARE PER MACCHINE UTENSILI

SIMULAZIONE E ANALISI SOFTWARE PER MACCHINE UTENSILI SIMULAZIONE E ANALISI SOFTWARE PER MACCHINE UTENSILI Antonio Scippa u macchine utensili u Ottimizzare i parametri per una lavorazione di fresatura su macchina a controllo numerico significa sfruttare in

Dettagli

Client XProtect Accesso al sistema di sorveglianza

Client XProtect Accesso al sistema di sorveglianza Client XProtect Accesso al sistema di sorveglianza Tre modalità di visualizzazione della videosorveglianza Per accedere facilmente alla videosorveglianza, Milestone offre tre interfacce utente flessibili:

Dettagli

WE500 APPLICATION NOTES GESTIONE DELLE ACQUE

WE500 APPLICATION NOTES GESTIONE DELLE ACQUE WE500 APPLICATION NOTES GESTIONE DELLE ACQUE 1 INTRODUZIONE I sistemi di telecontrollo ed il monitoraggio diventano sempre più importanti nell'ampliamento delle reti di distribuzione idrica ed in particolar

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB Avviso Pubblico PROV-BR 02/2013 PO FSE 2007/2013 ASSE II OCCUPABILITA' Formazione per Inserimento-Reinserimento Lavorativo Approvato con D.D. n.85 del 24/01/2014, pubblicata sul BURP n. 17 del 06/02/2014

Dettagli

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante CONOSCENZE DI INFORMATICA 1) Una periferica di input è: A) il mouse B) il monitor C) la stampante 2) Una memoria in sola lettura con la particolarità di essere cancellata in particolari condizioni è detta:

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

Un sistema per l'emulazione delle reti su cluster di macchine virtuali Anno Accademico 2007/2008

Un sistema per l'emulazione delle reti su cluster di macchine virtuali Anno Accademico 2007/2008 tesi di laurea Un sistema per l'emulazione delle reti su cluster di macchine virtuali Anno Accademico 2007/2008 relatore Ch.mo prof. Roberto Canonico correlatore ing. Pasquale Di Gennaro candidato Roberto

Dettagli

COOKIES PRIVACY POLICY DI BANCA PROFILO

COOKIES PRIVACY POLICY DI BANCA PROFILO COOKIES PRIVACY POLICY DI BANCA PROFILO Indice e sommario del documento Premessa... 3 1. Cosa sono i Cookies... 4 2. Tipologie di Cookies... 4 3. Cookies di terze parti... 5 4. Privacy e Sicurezza sui

Dettagli

1.2.1.1 DEFINIZIONE DI SOFTWARE

1.2.1.1 DEFINIZIONE DI SOFTWARE Software 1.2 1.2.1.1 DEFINIZIONE DI SOFTWARE Il computer non è in grado di svolgere alcun compito autonomamente Esso può eseguire svariati compiti soltanto se viene opportunamente istruito Ciò avviene

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

Un Sistema per il Monitoraggio di Reti di Sensori da Terminali Mobili

Un Sistema per il Monitoraggio di Reti di Sensori da Terminali Mobili tesi di laurea Anno Accademico 2008/2009 relatori Ch.mo prof. Stefano Russo Ch.mo prof. Marcello Cinque candidato Luca Trevisani Matr. 534/1047 Monitoraggio Contesto Studio di fenomeni e grandezze ambientali

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

Accesso alle applicazioni protetto. Ovunque.

Accesso alle applicazioni protetto. Ovunque. Scheda tecnica Accesso alle applicazioni protetto. Ovunque. Utenti mobili protetti Nelle organizzazioni odierne, ai responsabili IT viene spesso richiesto di fornire a diversi tipi di utente l'accesso

Dettagli

CESI. A4524310 Rapporto FIA Informatica e Automazione Approvato Pag. 1/19. Sistema di supervisione della test facility: verifica funzionale

CESI. A4524310 Rapporto FIA Informatica e Automazione Approvato Pag. 1/19. Sistema di supervisione della test facility: verifica funzionale Rapporto FIA Informatica e Automazione Approvato Pag. 1/19 Cliente Ricerca di Sistema (secondo periodo) Oggetto Sistema di supervisione della test facility: verifica funzionale Ordine L17950Z Note GENDIS21

Dettagli

Utilizzo Gestione dei file

Utilizzo Gestione dei file Utilizzo Gestione dei file Info su questo bollettino tecnico L'intento di questo bollettino tecnico è di aiutare gli sviluppatori FileMaker esperti a comprendere meglio e ad applicare le migliori metodologie

Dettagli

Analisi e utilizzo di un framework per lo sviluppo di applicazioni web

Analisi e utilizzo di un framework per lo sviluppo di applicazioni web tesi di laurea Anno Accademico 2011/2012 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Fabio De Paolis candidato Michele Basile Matr. 534/3239 Web Development Frameworks Nella realizzazione di

Dettagli

Server e Gateway VSoIP Pro

Server e Gateway VSoIP Pro IP video Server e Gateway VSoIP Pro Software VSoIP Server 3.2 14/12/2012- G215/2/I Caratteristiche principali VSoIP 3.2 Suite è il sistema di gestione video GANZ per reti Ethernet basato su una reale topologia

Dettagli

Il mio sito utilizza. Cosa devo fare? GL CONSULTING - www.glconsulting.com 031 6872783 info@glconsulting.com

Il mio sito utilizza. Cosa devo fare? GL CONSULTING - www.glconsulting.com 031 6872783 info@glconsulting.com Il mio sito utilizza Cosa devo fare? GL CONSULTING - www.glconsulting.com 031 6872783 info@glconsulting.com Il contesto Il 2 giugno 2015 è scaduto il termine per attuare le prescrizioni del Garante in

Dettagli

Questa scelta è stata suggerita dal fatto che la stragrande maggioranza dei navigatori usa effettivamente IE come browser predefinito.

Questa scelta è stata suggerita dal fatto che la stragrande maggioranza dei navigatori usa effettivamente IE come browser predefinito. Pagina 1 di 17 Installazione e configurazione di applicazioni Installare e configurare un browser Come già spiegato nelle precedenti parti introduttive di questo modulo un browser è una applicazione (lato

Dettagli

ECDL Base. Moduli compresi: Descrizione.

ECDL Base. Moduli compresi: Descrizione. ECDL Base Com'è facilmente deducibile anche dal nome, la certificazione ECDL Base attesta il livello essenziale di competenze informatiche e web del suo titolare, aggiornate alle funzionalità introdotte

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

RETI DI CALCOLATORI. Che cosa sono gli IS e gli ES?

RETI DI CALCOLATORI. Che cosa sono gli IS e gli ES? RETI DI CALCOLATORI Domande di riepilogo Quinta Esercitazione Che cosa sono gli IS e gli ES? Il termine Intermediate System (IS) è un termine OSI che indica un nodo (tipicamente un router) che ha capacità

Dettagli

ECONORMA S.a.s - Prodotti e Tecnologie per l Ambiente

ECONORMA S.a.s - Prodotti e Tecnologie per l Ambiente ECONORMA S.a.s - Prodotti e Tecnologie per l Ambiente Sistema di monitoraggio wireless per collaudi A.T.P. Prodotto dalla ECONORMA S.a.s., questo sistema portatile è stato progettato tenendo in considerazione

Dettagli

Cookie Policy. Questo documento contiene le seguenti informazioni:

Cookie Policy. Questo documento contiene le seguenti informazioni: Cookie Policy Il sito web di ASSOFERMET, con sede a Milano (Mi), in VIA GIOTTO 36 20145, Titolare, ex art. 28 d.lgs. 196/03, del trattamento dei Suoi dati personali La rimanda alla presente Policy sui

Dettagli

Facoltà di Ingegneria

Facoltà di Ingegneria Facoltà di Ingegneria Corso di laurea in Ingegneria dell Informazione FONDAMENTI DI INFORMATICA PRIMA PARTE Manuale di Installazione dell ECMs SharePoint PROFESSORE: STUDENTE: Prof. Mario Bochicchio Paiano

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

DESIGN PATTERN ESERCITAZIONE PREPARAZIONE ALL ESAME, PARTE II INGEGNERIA DEL SOFTWARE. La soluzione corretta è la c)

DESIGN PATTERN ESERCITAZIONE PREPARAZIONE ALL ESAME, PARTE II INGEGNERIA DEL SOFTWARE. La soluzione corretta è la c) DESIGN PATTERN Barrare con una X la lettera del diagramma delle classi che fra i seguenti rappresenta in modo corretto il design pattern architetturale Model View Controller (MVC) ESERCITAZIONE PREPARAZIONE

Dettagli

LE RETI DI COMUNICAZIONE

LE RETI DI COMUNICAZIONE LE RETI DI COMUNICAZIONE (Prima parte) Settembre 2002 I diritti di riproduzione, di memorizzazione elettronica e di adattamento totale o parziale con qualsiasi mezzo, compresi i microfilm e le copie fotostatiche

Dettagli

Wordpress corso base. Mario Marino Corso Base Wordpress

Wordpress corso base. Mario Marino Corso Base Wordpress Wordpress corso base Mario Marino Corso Base Wordpress introduzione Cosa sappiamo fare adesso e cosa vorremmo sapere fare alla fine del corso Parole chiave Sito / Blog Database CMS Client / Server Account

Dettagli

Corso di Web programming Modulo T3 A2 - Web server

Corso di Web programming Modulo T3 A2 - Web server Corso di Web programming Modulo T3 A2 - Web server 1 Prerequisiti Pagine statiche e dinamiche Pagine HTML Server e client Cenni ai database e all SQL 2 1 Introduzione In questa Unità si illustra il concetto

Dettagli

Il progetto di ricerca Ellade

Il progetto di ricerca Ellade Il progetto di ricerca Ellade Ellade ELectronic Live ADaptive Learning Gruppo di lavoro Università degli Studi della Calabria, Dipartimento di Matematica Università degli Studi Mediterranea di Reggio Calabria,

Dettagli

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo SISTEMA DI TELECONTROLLO RILHEVA GPRS (CARATTERISTICHE DEL VETTORE GPRS E SICUREZZE ADOTTATE) Abstract: Sicurezza del Sistema di Telecontrollo Rilheva Xeo4 ha progettato e sviluppato il sistema di telecontrollo

Dettagli

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006 tesi di laurea Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ing. Massimo Ficco candidato Giorgio

Dettagli

Siti internet: privacy cookie.

Siti internet: privacy cookie. Passione Portiere www.passioneportiere.it Roma 3 settembre 2015 Siti internet: privacy cookie. Il 3 giugno 2015 è entrato in vigore il Regolamento del Garante della privacy recante individuazione delle

Dettagli

Automazione di Test di Sistemi Embedded. Sintesi

Automazione di Test di Sistemi Embedded. Sintesi UNIVERSITÀ DEGLI STUDI DI MILANO - BICOCCA Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Informatica Sistemistica e Comunicazione Corso di Laurea Magistrale in Informatica Automazione

Dettagli

2009. STR S.p.A. u.s. Tutti i diritti riservati

2009. STR S.p.A. u.s. Tutti i diritti riservati 2009. STR S.p.A. u.s. Tutti i diritti riservati Sommario COME INSTALLARE STR VISION CPM... 3 Concetti base dell installazione Azienda... 4 Avvio installazione... 4 Scelta del tipo Installazione... 5 INSTALLAZIONE

Dettagli

Un architettura per lo streaming multimediale in ambiente distribuito

Un architettura per lo streaming multimediale in ambiente distribuito tesi di laurea Anno Accademico 2012/2013 relatore Ch.mo prof. Simon Pietro Romano correlatori Ing. Tobia Castaldi candidato Alessandro Arrichiello Matr. M63/43 Contesto: o Content Distribution Networks

Dettagli

IL SISTEMA DI HELP DESK UNA APPLICAZIONE WEB PER LA GESTIONE DEI SERVIZI DI ASSISTENZA E SUPPORTO

IL SISTEMA DI HELP DESK UNA APPLICAZIONE WEB PER LA GESTIONE DEI SERVIZI DI ASSISTENZA E SUPPORTO IL SISTEMA DI HELP DESK UNA APPLICAZIONE WEB PER LA GESTIONE DEI SERVIZI DI ASSISTENZA E SUPPORTO INDICE INTRODUZIONE...3 GLOSSARIO...4 PARTE PRIMA...6 1. GUIDA UTENTE PER L USO DEL SISTEMA DI HELP DESK...6

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

Dettagli

Sme.UP Web Application

Sme.UP Web Application Sme.UP Web Application Web Application Web.UP Una interfaccia web per i vostri dati gestionali Il modulo applicativo Web.UP fornisce al progettista di siti Internet una serie di potenti strumenti per l'integrazione

Dettagli

Guida alle applicazioni di Web Clipping

Guida alle applicazioni di Web Clipping Guida alle applicazioni di Web Clipping Copyright Copyright 1998-2000 Palm, Inc. o consociate. Tutti i diritti riservati. Graffiti, Palm OS e Palm.Net sono marchi di fabbrica registrati. Palm è un marchio

Dettagli

Uno strumento per il deployment automatico di performance test su piattaforme per la distribuzione di dati

Uno strumento per il deployment automatico di performance test su piattaforme per la distribuzione di dati tesi di laurea Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Controneo correlatore Ing. Christiancarmine Esposito candidato Antonella Niola Matr. 534/158 .:: Contesto ::. www.cosmiclab.it Il

Dettagli

Il sistema operativo TinyOS

Il sistema operativo TinyOS tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo candidato Giovanni Chierchia Matr. 534 / 804 ::. Obiettivi del lavoro di tesi Studio del sistema operativo TinyOS Studio

Dettagli

COOKIES PRIVACY POLICY. Il sito web di. Onoranze funebri Castiglioni di Castiglioni A. Via Valle 11 46040 Cavriana Mantova

COOKIES PRIVACY POLICY. Il sito web di. Onoranze funebri Castiglioni di Castiglioni A. Via Valle 11 46040 Cavriana Mantova COOKIES PRIVACY POLICY Il sito web di Onoranze funebri Castiglioni di Castiglioni A. Via Valle 11 46040 Cavriana Mantova Titolare, ex art. 28 d.lgs. 196/03, del trattamento dei Suoi dati personali La rimanda

Dettagli

Breve introduzione allo sviluppo WEB. a cura di Ciro Attanasio - ciro.attanasio@email.cz

Breve introduzione allo sviluppo WEB. a cura di Ciro Attanasio - ciro.attanasio@email.cz Breve introduzione allo sviluppo WEB a cura di Ciro Attanasio - ciro.attanasio@email.cz Partiamo (1 di 1) Come funziona il WEB e quali tecnologie lo compongono Cos è un Client (1 di 2) Un client, in informatica,

Dettagli

Informativa Privacy sito web www.labruzoleseelettrica.it

Informativa Privacy sito web www.labruzoleseelettrica.it Informativa Privacy sito web www.labruzoleseelettrica.it (Codice in materia di protezione dei dati personali art. 13 D.L.gs 196/2003) EDITORE del sito ai sensi del provvedimento del Garante Privacy n.

Dettagli

LINEE GUIDA PER LA STESURA DELLE SPECIFICHE TECNICO FUNZIONALI DEL SISTEMA DI GIOCO PER LE SCOMMESSE SU EVENTI SIMULATI

LINEE GUIDA PER LA STESURA DELLE SPECIFICHE TECNICO FUNZIONALI DEL SISTEMA DI GIOCO PER LE SCOMMESSE SU EVENTI SIMULATI LINEE GUIDA PER LA STESURA DELLE SPECIFICHE TECNICO FUNZIONALI DEL SISTEMA DI GIOCO PER LE SCOMMESSE SU EVENTI SIMULATI Premessa... 2 Percorso della verifica di conformità... 2 Documento specifiche tecnico-funzionali

Dettagli

GUIDA UTENTE FATTURA IMPRESA

GUIDA UTENTE FATTURA IMPRESA GUIDA UTENTE FATTURA IMPRESA (Vers. 4.5.0) Installazione... 2 Prima esecuzione... 5 Login... 6 Funzionalità... 7 Documenti... 8 Creazione di un nuovo documento... 9 Ricerca di un documento... 17 Calcolare

Dettagli

Sviluppo di applicazioni mobili su piattaforma Maemo

Sviluppo di applicazioni mobili su piattaforma Maemo tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Marcello Cinque candidato Giovanni Fortini Matr. 534/2169 Contesto e contributo Sistemi operativi per dispositivi mobili Sviluppo di un applicazione

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

21/02/2013 MANUALE DI ISTRUZIONI DELL APPLICAZIONE SID GENERAZIONE CERTIFICATI VERSIONE 1.0

21/02/2013 MANUALE DI ISTRUZIONI DELL APPLICAZIONE SID GENERAZIONE CERTIFICATI VERSIONE 1.0 MANUALE DI ISTRUZIONI DELL APPLICAZIONE SID GENERAZIONE VERSIONE 1.0 PAG. 2 DI 39 INDICE 1. PREMESSA 4 2. INSTALLAZIONE 5 3. ESECUZIONE 6 4. STRUTTURA DELLE CARTELLE 7 5. CARATTERISTICHE GENERALI DELL

Dettagli

Soluzioni innovative nella manutenzione e nella logistica in contesti Smart City

Soluzioni innovative nella manutenzione e nella logistica in contesti Smart City Soluzioni innovative nella manutenzione e nella logistica in contesti Smart City SMART CITY- VISIONE DI UN SISTEMA DI SISTEMI Ing. Massimo Povia L importanza della Logistica e della Manutenzione nel contesto

Dettagli

Progettazione di reti AirPort

Progettazione di reti AirPort apple Progettazione di reti AirPort Indice 1 Per iniziare con AirPort 5 Utilizzo di questo documento 5 Impostazione Assistita AirPort 6 Caratteristiche di AirPort Admin Utility 6 2 Creazione di reti AirPort

Dettagli

Cube è usato in più di 2000 città e 70 paesi nel mondo. Cube si fonda su più di 25 anni di ricerca, sviluppo e applicazione.

Cube è usato in più di 2000 città e 70 paesi nel mondo. Cube si fonda su più di 25 anni di ricerca, sviluppo e applicazione. brochure tecnica di cube Cube è la suite di modellazione dei trasporti più popolare del mondo. Cube è il sistema più completo e diffuso sistema per l analisi dei sistemi di trasporto nel mondo. Con Cube

Dettagli

COOKIES POLICY. 2. Tipologie di Cookies utilizzati da parte del sito www.elleservizi.it e/o delle aziende e dei marchi che ne fanno parte

COOKIES POLICY. 2. Tipologie di Cookies utilizzati da parte del sito www.elleservizi.it e/o delle aziende e dei marchi che ne fanno parte COOKIES POLICY Questa cookies policy contiene le seguenti informazioni : 1. Cosa sono i Cookies. 2. Tipologie di Cookies. 3. Cookies di terze parti. 4. Privacy e Sicurezza sui Cookies. 5. Altre minacce

Dettagli

Università degli studi Roma Tre. Sensor Networks: Evolution, Opportunities and Challanges. Andrea Gasparri

Università degli studi Roma Tre. Sensor Networks: Evolution, Opportunities and Challanges. Andrea Gasparri Università degli studi Roma Tre : Evolution, Opportunities and Challanges Introduzione 1 Una rete di sensori è una collezione di nodi che collaborano per la raccolta di dati e per il loro processamento

Dettagli

Manuale Utente CryptoClient

Manuale Utente CryptoClient Codice Documento: CERTMOB1.TT.DPMU12005.01 Firma Sicura Mobile Telecom Italia Trust Technologies S.r.l. - Documento Pubblico Tutti i diritti riservati Indice degli argomenti... 1 Firma Sicura Mobile...

Dettagli

La Skills Card relativa alle certificazioni Nuova ECDL è svincolata dalla singola certificazione.

La Skills Card relativa alle certificazioni Nuova ECDL è svincolata dalla singola certificazione. ECDL Standard Descrizione. La certificazione ECDL Standard si proprone come un'alternativa più ricca rispetto alla certificazione ECDL Base è più flessibile della certificazione ECDL Full Standard. La

Dettagli

Ridisegnare i Sistemi Operativi per una Nuova Sicurezza

Ridisegnare i Sistemi Operativi per una Nuova Sicurezza Andrea Pasquinucci, Febbraio 2013 pag. 1 / 6 Ridisegnare i Sistemi Operativi per una Nuova Sicurezza Sommario I nuovi strumenti informatici, dagli smartphone ai tablet che tanto ci sono utili nella vita

Dettagli

Università degli Studi di Genova Facoltà di Ingegneria. Tesi di Laurea in Ingegneria Elettronica

Università degli Studi di Genova Facoltà di Ingegneria. Tesi di Laurea in Ingegneria Elettronica Università degli Studi di Genova Facoltà di Ingegneria Tesi di Laurea in Ingegneria Elettronica Performance measurement system per la gestione di eventi industriali complessi Candidato: Adriano Moretti

Dettagli

Facendo uso di questo Sito si acconsente il nostro utilizzo di cookie in conformità con la presente Cookie Policy.

Facendo uso di questo Sito si acconsente il nostro utilizzo di cookie in conformità con la presente Cookie Policy. Cookie Con riferimento al provvedimento Individuazione delle modalità semplificate per l informativa e l acquisizione del consenso per l uso dei cookie 8 maggio 2014 (pubblicato sulla Gazzetta Ufficiale

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Mon Ami 3000 Touch Interfaccia di vendita semplificata per monitor touchscreen

Mon Ami 3000 Touch Interfaccia di vendita semplificata per monitor touchscreen Prerequisiti Mon Ami 3000 Touch Interfaccia di vendita semplificata per monitor touchscreen L opzione Touch è disponibile per le versioni Vendite, Azienda Light e Azienda Pro; per sfruttarne al meglio

Dettagli

Lezione E1. Sistemi embedded e real-time

Lezione E1. Sistemi embedded e real-time Lezione E1 Sistemi embedded e real-time 3 ottobre 2012 Dipartimento di Ingegneria Civile e Ingegneria Informatica Università degli Studi di Roma Tor Vergata SERT 13 E1.1 Di cosa parliamo in questa lezione?

Dettagli

LA PROFESSIONE DEL WEB DESIGNER

LA PROFESSIONE DEL WEB DESIGNER LA PROFESSIONE DEL WEB DESIGNER Lezione 1 1 Web Design Lafiguracentralenelprogettodiunsitowebèilwebdesigner:eglisioccupadell'aspetto visivo e del coinvolgimento emotivo di siti Web business to business

Dettagli

Breve introduzione per coloro che vanno di fretta

Breve introduzione per coloro che vanno di fretta Marco Lazzeri Sommario Verifica della versione del Java plug-in... 1 Esegui l'autenticazione (login)... 2 Individua il raggruppamento di stazioni su cui operare... 3 Seleziona il periodo di richiesta dei

Dettagli

per immagini guida avanzata Organizzazione e controllo dei dati Geometra Luigi Amato Guida Avanzata per immagini excel 2000 1

per immagini guida avanzata Organizzazione e controllo dei dati Geometra Luigi Amato Guida Avanzata per immagini excel 2000 1 Organizzazione e controllo dei dati Geometra Luigi Amato Guida Avanzata per immagini excel 2000 1 Il raggruppamento e la struttura dei dati sono due funzioni di gestione dati di Excel, molto simili tra

Dettagli

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 tesi di laurea Anno Accademico 2006/2007 Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Marcello Cinque candidato Antonio Alonzi Matr.

Dettagli

Normativa sui Cookie cosa dice la legge, come adeguarsi e quali siti lo devono fare

Normativa sui Cookie cosa dice la legge, come adeguarsi e quali siti lo devono fare Normativa sui Cookie cosa dice la legge, come adeguarsi e quali siti lo devono fare Nella giornata del 3 giugno 2015 è entrata in vigore in Italia la tanto discussa cookie law conformemente a quanto stabilito

Dettagli

INFORMAZIONI GENERALI SUI COOKIES

INFORMAZIONI GENERALI SUI COOKIES Con riferimento al provvedimento Individuazione delle modalità semplificate per l informativa e l acquisizione del consenso per l uso dei cookie 8 maggio 2014 (pubblicato sulla Gazzetta Ufficiale n. 126

Dettagli

La presente "Cookie Policy" (la nostra politica relativa all uso di cookie) viene applicata sul nostro sito

La presente Cookie Policy (la nostra politica relativa all uso di cookie) viene applicata sul nostro sito La presente "Cookie Policy" (la nostra politica relativa all uso di cookie) viene applicata sul nostro sito Internet, comprese le pagine su piattaforme di terze parti (ad esempio Facebook o YouTube), e

Dettagli