UNIVERSITÀ DEGLI STUDI DI TRIESTE                      FACOLTÀ DI INGEGNERIA             CORSO DI LAUREA IN INGEGNERIA INF...
INDICE1! INTRODUZIONE .......................................................................................................
1    INTRODUZIONE    Le emergenze provocate dal verificarsi di eventi naturali straordinari è negli ultimianni un tema ric...
Fig. 2: eventi disastrosi tra il 1998 e il 2009, nei paesi membri del EEA (European Environment Agency).Fig. 3: perdite um...
Fig. 4: perdite economiche complessive tra il 1998 e il 2009, nei paesi membri del EEA.   L’impatto che queste calamità ha...
Si può suddividere la gestione in quattro ambiti principali:   1. Conoscenza del rischio:           •   Raccolta sistemati...
Uno dei sistemi già esistenti di gestione dell’informazione legata alle emergenze èl’Emergency Alert System (EAS), attivo ...
2     ANALISI E PROGETTAZIONE    In questo capitolo vengono descritte le caratteristiche del protocollo CAP nel paragrafo2...
La struttura del messaggio offre le seguenti possibilità:   •   Individuazione         geografica   flessibile,   utilizza...
c. <urgency>: indica l’urgenza di eseguire le istruzioni contenute nel          messaggio.      d. <severity>: indica il l...
alert                                                      Legenda:   Message ID (identifier)                             ...
2.2     Definizione dei requisiti   In questo paragrafo verranno individuati e definiti i requisiti che l’applicazione dov...
codice Java. Per una trattazione più dettagliata di Java si rimanda al sito dellosviluppatore. [6]   Per il primo requisit...
<instruction> A High Condition is declared when there is a high riskof terrorist attacks. In addition to the Protective Me...
Fig. 8: diagramma delle classi   La classe CapViewer rappresentata in Fig. 8 sarà deputata alla gestione della grafica etr...
Diversamente, la classe MsgParser sarà deputata alla gestione del codice XML condue metodi (operations): MsgParser(), che ...
3     REALIZZAZIONE    In questo terzo capitolo vengono trattati prima l’utilizzo dell’interfaccia grafica, nelparagrafo 3...
Fig. 10: visualizzazione di un elemento testuale             Fig. 11: visualizzazione di un elemento testuale             ...
3.2   Implementazione   In questo paragrafo verrà analizzato il funzionamento interno dell’applicazione,commentando le sce...
invocando il metodo parseElement(null, 1). Il significato dei parametri saràspiegato in seguito.   In questa parte verrà t...
interfaccia grafica perché l’indirizzo viene fornito in maniera forzata (cfr. §3.2.2)all’applicazione. In un eventuale svi...
trattare opportunamente le possibili selezioni su ognuna di esse. Se la lista che hagenerato l’evento è di livello 1, allo...
4    CONCLUSIONI    In questo capitolo verrà verificato se gli obiettivi che sono stati fissati nel capitolo 1 esviluppati...
Il prodotto del presente lavoro è, come in precedenza detto, un prototipo.Nell’eventualità di proseguirne lo sviluppo, pos...
Appendice A 1   package CapViewer; 2 3   import javax.microedition.lcdui.*; 4   import javax.microedition.midlet.*; 5 6   ...
76                        display.setCurrent(frm); 77                   } 78               } else if(d == select2){ // if ...
Appendice B 1   package CapViewer; 2 3   import   java.io.IOException; 4   import   java.io.InputStream; 5   import   java...
75                           continue; 76                       } 77                       // if el_name is a only-text el...
Bibliografia[1] Edward Bryant, "Introduction to Natural Hazards," in Natural Hazards, 2nd ed.     Wollongong, New South Wa...
Upcoming SlideShare
Loading in...5
×

Formato e trasmissione di messaggi di allerta per la gestione di emergenze ambientali

363

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
363
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Formato e trasmissione di messaggi di allerta per la gestione di emergenze ambientali

  1. 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESI DI LAUREA IN INGEGNERIA INFORMATICA FORMATO E TRASMISSIONE DI MESSAGGI DI ALLERTA PER LA GESTIONE DI EMERGENZE AMBIENTALILaureando: Relatore:Simone Maver Prof. Ing. Raffaela Cefalo ANNO ACCADEMICO 2009/2010
  2. 2. INDICE1! INTRODUZIONE ........................................................................................................ 3!2! ANALISI E PROGETTAZIONE ............................................................................... 8! 2.1! CAP (Common Alerting Protocol) .......................................................................... 8! 2.2! Definizione dei requisiti ........................................................................................ 12! 2.3! Scelta delle tecnologie ........................................................................................... 12! 2.4! Struttura dell’applicazione .................................................................................... 13!3! REALIZZAZIONE .................................................................................................... 17! 3.1! Interfaccia grafica .................................................................................................. 17! 3.2! Implementazione ................................................................................................... 19! 3.2.1! Funzionamento generale ................................................................................. 19! 3.2.2! La classe CapViewer ...................................................................................... 19! 3.2.3! La classe MsgParser ....................................................................................... 20!4! CONCLUSIONI ......................................................................................................... 23!Ringraziamenti ................................................................................................................. 24!Appendice A ..................................................................................................................... 25!Appendice B ...................................................................................................................... 27!Bibliografia ....................................................................................................................... 29!Indice delle figure ............................................................................................................. 29! 2
  3. 3. 1 INTRODUZIONE Le emergenze provocate dal verificarsi di eventi naturali straordinari è negli ultimianni un tema ricorrente nei fatti di cronaca, si pensi ad esempio ai terremoti verificatisi inAbruzzo nel 2009 e sull’isola di Haiti nel 2010, fino al maremoto d’inizio 2011 nelPacifico, con il conseguente tsunami che ha interessato il Giappone. Considerando unintervallo più ampio di tempo si nota che il numero di eventi disastrosi che accade nelmondo è in evidente aumento, come si può apprezzare in Fig. 1. Fig. 1: numero di eventi disastrosi rilevati tra il 1900 e il 2001 nel mondo [1]. L’UNISDR (United Nations International Strategy for Disaster Reduction) definisce ilrischio come la combinazione tra la probabilità di un evento e le sue conseguenze [2]negative . Questi eventi di emergenza possono essere indotti da svariate cause, comecalamità naturali o incidenti industriali. L’aumento di queste cause negli ultimi annievidenzia la vulnerabilità della collettività, dal punto di vista sociale, economico eterritoriale. Limitando la rilevazione degli eventi al solo territorio europeo l’andamento rimanecrescente e alcuni paesi europei sono interessati da una quantità considerevole di questiavvenimenti in un arco temporale di circa dieci anni, com’è mostrato in Fig. 2. Questiavvenimenti hanno conseguenze pesanti sia considerando il numero di persone coinvolte(Fig. 3), sia sul fronte dei danni economici che provocano e delle risorse necessarie perfarvi fronte (Fig. 4). 3
  4. 4. Fig. 2: eventi disastrosi tra il 1998 e il 2009, nei paesi membri del EEA (European Environment Agency).Fig. 3: perdite umane tra il 1998 e il 2009, nei paesi membri del EEA (European Environment Agency). 4
  5. 5. Fig. 4: perdite economiche complessive tra il 1998 e il 2009, nei paesi membri del EEA. L’impatto che queste calamità hanno sui luoghi e sulle persone coinvolte variasecondo il tipo di evento. Ma è possibile individuare uno schema generale per la gestionedella situazione d’emergenza che essi creano; la Fig. 5 descrive qual è la catena degliinterventi da attuare per fare fronte ai diversi aspetti che caratterizzano l’emergenza,trattando sia le azioni da porre in atto nell’immediatezza dopo la calamità, sia le azioni alungo termine. Fig. 5: ciclo di gestione delle calamità. 5
  6. 6. Si può suddividere la gestione in quattro ambiti principali: 1. Conoscenza del rischio: • Raccolta sistematica di dati riguardanti gli eventi. • Valutazione del rischio a seconda dei fattori geografici e ambientali. 2. Monitoraggio del territorio e servizio di allarme: • Sviluppo di sistemi di monitoraggio dei parametri legati ai disastri. • Creazione di un servizio di allarme accurato e tempestivo a tutti i livelli (internazionale-nazionale-locale). 3. Diffusione e comunicazione, i cui obiettivi sono: Massima capillarità nella distribuzione e forma chiara e semplice degli avvisi. 4. Miglioramento della capacità di risposta, in cui si vuole arrivare creazione di apparati nazionali e locali capaci di fronteggiare le calamità. Nel contesto appena delineato il lavoro presentato in questa tesi è focalizzato sui punti2 e 3, in particolare su come avviene o potrebbe avvenire, lo smistamento delleinformazioni in seguito all’evento. Infatti, la possibilità di raggiungere in maniera rapidaed efficace tutti i soggetti coinvolti è un obiettivo importante per prevenire e limitare idanni provocati da questi eventi naturali. Prendendo come riferimento lo schema presentein Fig. 6, verranno esaminati il formato da utilizzare per il messaggio di allerta e comepotrebbe usufruirne un utente che lo riceve su un dispositivo mobile. Fig. 6: schema di gestione delle informazioni a seguito di una calamità 6
  7. 7. Uno dei sistemi già esistenti di gestione dell’informazione legata alle emergenze èl’Emergency Alert System (EAS), attivo negli Stati Uniti d’America. Per una trattazionecompleta ed esaustiva rimandiamo alla pagina dedicata sul sito della FederalCommunications Commission [3] del governo americano. Il formato scelto in questo studio per la codifica dei messaggi di allerta è il CAP –Common Alerting Protocol (d’ora in poi CAP). La scelta è ricaduta su questo formatoperché inquadrato in un progetto più ampio relativo al Disaster Management coordinatodalla professoressa Raffaela Cefalo, relatrice di questa tesi. L’analisi del protocollo CAPè riportata nella parte iniziale del capitolo 2. Scopo del presente lavoro è giungere alla creazione di un prototipo di applicazione ingrado di gestire e visualizzare su un dispositivo mobile il contenuto di un messaggio diallerta formato secondo il CAP. Questa tesi è articolata come segue: nella prima parte avverrà un’analisi del CAP cheporterà a individuare alcuni requisiti del prototipo. Definiti tutti i requisiti nel paragrafo2.2, seguirà una breve descrizione delle tecnologie utilizzate per lo sviluppo (cfr. §2.3) ela struttura dell’applicazione (cfr. §2.4). Nel capitolo 3 verrà trattata la parte direalizzazione, in cui tratteremo l’interfaccia grafica e il funzionamento internodell’applicazione. 7
  8. 8. 2 ANALISI E PROGETTAZIONE In questo capitolo vengono descritte le caratteristiche del protocollo CAP nel paragrafo2.1, per passare nel paragrafo 2.2 alla definizione dei requisiti che dovrà soddisfare lanostra applicazione e infine alle scelte per lo sviluppo nei paragrafi 2.3 e 2.4.2.1 CAP (Common Alerting Protocol) LOASIS (Organization for the Advancement of Structured Information Standards,http://www.oasis-open.org/) è un consorzio no-profit che coordina lo sviluppo epromuove l’adozione di standard aperti per la distribuzione di informazioni a livelloglobale. In particolare si occupa di standard per la sicurezza, per le-business e perapplicazioni di pubblica utilità. Il CAP è uno di questi standard, in fase di approvazione, ed è un formato progettatoper lo scambio di avvisi demergenza su diversi tipi di rete. Il documento di riferimentoprodotto dall’OASIS è il Common Alerting Protocol Version 1.2 [4]. Il protocollo permettedi creare messaggi da poter distribuire contemporaneamente su diversi sistemi dallerta,incrementando lefficacia degli avvisi e semplificandone la distribuzione. I principi allabase dello sviluppo di questo protocollo sono i seguenti: • Interoperabilità: possibilità di utilizzare i messaggi formati secondo il CAP su tutti i tipi di sistemi di informazione per le emergenze. • Completezza: un messaggio conforme al CAP deve poter contenere tutte le informazioni essenziali caratterizzanti l’emergenza. • Implementazione semplice: l’utilizzo dei messaggi CAP non deve richiedere particolari competenze tecniche. • Struttura XML semplice e portabile: la codifica di riferimento avviene tramite un documento XML, ma la struttura del messaggio rimane sufficientemente astratta per permetterne l’adattamento ad altri schemi di codifica. • Formato multiuso: lo schema del CAP prevede diverse tipologie per il messaggio stesso (allerta, aggiornamento, etc.), destinate a diversi utilizzi (allerta in corso, esercitazione, test, etc.). • Familiarità: l’informazione deve poter essere fruibile sia a utenza esperta, sia a utenza generica. • Utilizzo interdisciplinare e internazionale. 8
  9. 9. La struttura del messaggio offre le seguenti possibilità: • Individuazione geografica flessibile, utilizzando modelli basati su latitudine/longitudine e su rappresentazioni geospaziali in tre dimensioni. • Invio di messaggi multilingua e con destinatari multipli. • Validazione e scadenza temporale dei messaggi. • Funzioni di cancellazione/aggiornamento dei messaggi. • Modelli per la definizione di messaggi di allerta completi e validi. • Compatibilità con sistemi di firma digitale. • Supporto per immagini e audio digitali. In Fig. 7 è illustrata la generica struttura del messaggio. Esso è articolato in quattroparti più ampie, dette segmenti, le quali contengono a loro volta specifiche informazioniriguardo all’evento cui si riferiscono. Segue una breve descrizione degli elementi delmessaggio. Per una trattazione più approfondita si rimanda al documento prodottodall’OASIS [4].I segmenti sono: 1. <alert>: è il segmento principale ed è sempre presente, fornisce gli elementi principali necessari a caratterizzare il messaggio. L’OASIS definisce come obbligatori – cioè devono essere presenti nel messaggio – i seguenti elementi: a. <identifier>: contiene il codice per identificare il messaggio. b. <sender>: contiene l’identificatore del mittente. c. <sent>: contiene data e ora di creazione del messaggio. d. <status>: contiene il codice che indica il trattamento appropriato del messaggio. e. <msgType>: specifica la natura del messaggio di allerta. f. <scope>: contiene un codice che indica l’utenza cui è rivolto il messaggio. I restanti elementi sono opzionali. 2. <info>: questo segmento è opzionale ed è correlato con <alert>; contiene elementi necessari per delineare e caratterizzare l’evento oggetto del messaggio. Nel caso in cui sia presente, l’OASIS definisce come obbligatori i seguenti elementi: a. <category>: contiene il codice che identifica la tipologia in cui rientra l’evento. b. <event>: contiene il nome dell’evento. 9
  10. 10. c. <urgency>: indica l’urgenza di eseguire le istruzioni contenute nel messaggio. d. <severity>: indica il livello di minaccia dell’evento, a persone/cose. e. <certainty>: indica l’affidabilità delle informazioni contenute nel messaggio. I restanti elementi sono opzionali.3. <resource>: questo segmento è opzionale ed è correlato con <info>; contiene elementi utilizzati per specificare l’eventuale materiale allegato al messaggio (foto, video, audio, etc., dell’evento). Nel caso in cui sia presente, i seguenti elementi sono definiti come obbligatori: a. <resourceDesc>: contiene un testo leggibile descrivente il tipo e il contenuto della risorsa allegata, ad es. “foto” oppure “video”. b. <mimeType>: contiene il codice del tipo e sottotipo dello standard MIME [Multipurpuose Internet Mail Extension, cfr. RFC 2046] della risorsa. I restanti elementi sono opzionali.4. <area>: questo elemento è opzionale ed è correlato anch’esso con <info>; contiene informazioni per descrivere l’area coinvolta nell’evento. se viene utilizzato <area>, l’unico elemento obbligatorio è: a. <areaDesc>: contiene una descrizione testuale dell’area interessata. Anche in questo segmento, i restanti elementi sono opzionali. 10
  11. 11. alert Legenda: Message ID (identifier) Elementi in grassetto sono Sender ID (sender) obbligatori; Sent Date/Time (sent) Message status (status) Elementi in corsivo assumono Message Type (msgType) valore predefinito quando non Source (source) vengono specificati precisi Scope (scope) valori; Restriction (restriction) Addresses (addresses) Lasterisco (*) indica che Handling Code (code) * lelemento può avere più Note (note) occorrenze nello stesso Reference IDs (references) messaggio. Incident Ids (incidents) info * Language (language) Resource Event category (category)* Description (resourceDesc) Event Type (event) MIME Type (mimeType) Response Type (responseType)* File Size (size) Urgency (urgency) Severity (severity) * URI (uri) Dereferenced URI (derefUri) Certainty (certainty) Digest (digest) Audience (audience) Event Code (eventCode)* Effective Date/Time (effective) Onset Date/time (onset) Expiration Date/Time (expires) area Sender Name (senderName) Area Description (areaDesc) Headline (headline) Area Polygon (polygon)* Event Description (description) Area Circle (circle)* Instruction (instruction) Area Geocode (geocode)* Information URL (web) * Altitude (altitude) Contact Info (contact) Ceiling (ceiling) Parameter (parameter)* Fig. 7: struttura del messaggio di allerta (fonte OASIS [4])Dall’analisi appena compiuta del documento contenente le specifiche del protocollo CAP,è possibile individuare alcuni requisiti che dovrà soddisfare l’applicazione che verrà poisviluppata. 11
  12. 12. 2.2 Definizione dei requisiti In questo paragrafo verranno individuati e definiti i requisiti che l’applicazione dovràsoddisfare, in funzione dell’analisi effettuata nel paragrafo 2.1 e di ulteriori esigenze. Dall’analisi del paragrafo 2.1 si individua il principale requisito. Infatti, l’applicazionedovrà essere in grado di gestire un messaggio conforme al CAP e quindi un file XML(abbiamo preso come riferimento la struttura già fornita dall’OASIS [4]), estraendo leinformazioni utili all’utente e tralasciando le informazioni di formattazione necessarie performare il documento XML. Inoltre per restare concordi con la caratteristica diinteroperabilità e portabilità dello standard CAP, l’applicazione dovrà essere indipendentedalla piattaforma sulla quale sarà eseguita. Considerando dove il messaggio potrebbe essere utilizzato, si distinguono due ambitiprincipali: una sala di coordinamento e/o smistamento delle informazioni di un ente che sioccupa di emergenze (ad es. protezione civile e forze dell’ordine) e l’utente in movimento(ad es. un utente generico coinvolto nell’emergenza o un operatore afferente a uno deglienti precedentemente citati). Nel nostro caso è stata scelta la seconda tipologia d’utenza –l’utente in movimento. Perciò l’utilizzo si suppone che avverrà su dispositivi mobili, iquali hanno due caratteristiche da considerare nello sviluppo: la dimensione delloschermo su cui visualizzare le informazioni e le ridotte risorse di calcolo ememorizzazione.Riassumendo, viene stilato un elenco dei requisiti dell’applicazione: 1. Gestione ed estrazione di informazioni da un documento XML. 2. Indipendenza dalla piattaforma di esecuzione. 3. Necessità di esecuzione su dispositivi mobili.2.3 Scelta delle tecnologie In questo paragrafo ci si soffermerà su quali tecnologie sono state scelte e utilizzateper lo sviluppo, alla luce dei requisiti individuati nel paragrafo 2.2. Considerati il secondo e il terzo requisito, la scelta sul sistema di sviluppo è ricadutasul Java Micro Edition System Development Kit 3.0 [5](d’ora in poi Java ME SDK). Illinguaggio Java in generale non dipende dall’architettura e dal sistema su cui vieneeseguito, purché questo sistema/architettura possieda gli strumenti per interpretare il 12
  13. 13. codice Java. Per una trattazione più dettagliata di Java si rimanda al sito dellosviluppatore. [6] Per il primo requisito e per la scelta del sistema di sviluppo appena compiuta, laricerca di una libreria che permettesse la gestione di un documento XML ha portato ascegliere la libreria kXML la quale fornisce le funzionalità necessarie. Non verràapprofondita in maniera esaustiva la composizione della libreria ma si rimanda al sitodello sviluppatore [7] contenente il codice sorgente e la documentazione. Saranno trattaticomunque con la necessaria precisione nel capitolo 3 quegli elementi della libreria chesono stati utilizzati per lo sviluppo.2.4 Struttura dell’applicazione Avendo fissato alcuni riferimenti per lo sviluppo nei paragrafi 2.2 e 2.3, verrà definitain questo paragrafo la struttura che avrà l’applicazione. Innanzitutto viene scelto disuddividerla in due parti: la prima destinata alla gestione della parte grafica, la secondaalla gestione del codice XML componente il messaggio. Per la parte grafica vengono effettuate le scelte che seguono: come si può vederenell’esempio 1, il codice XML è organizzato in una sorta di livelli – segmento <alert> dacui discende il segmento <info> a cui fanno riferimento i segmenti <resource> e <area> –e ogni livello a sua volta può contenere un numero variabile di elementi.<?xml version = “1.0” encoding = “UTF-8”?><alert xmlns = “urn:oasis:names:tc:emergency:cap:1.2”> <identifier>43b080713727</identifier> <sender>hsas@dhs.gov</sender> <sent>2003-04-02T14:39:01-05:00</sent> <status>Actual</status> <msgType>Alert</msgType> <scope>Public</scope> <info> <category>Security</category> <event>Homeland Security Advisory System Update</event> <urgency>Immediate</urgency> <severity>Severe</severity> <certainty>Likely</certainty> <senderName>U.S. Government, Department of HomelandSecurity</senderName> <headline>Homeland Security Sets Code ORANGE</headline> <description>The Department of Homeland Security has elevated theHomeland Security Advisory System threat level to ORANGE / High inresponse to intelligence which may indicate a heightened threat ofterrorism.</description> 13
  14. 14. <instruction> A High Condition is declared when there is a high riskof terrorist attacks. In addition to the Protective Measures taken inthe previous Threat Conditions, Federal departments and agencies shouldconsider agency-specific Protective Measures in accordance with theirexisting plans.</instruction> <web>http://www.dhs.gov/dhspublic/display?theme=29</web> <parameter> <valueName>HSAS</valueName> <value>ORANGE</value> </parameter> <resource> <resourceDesc>Image file (GIF)</resourceDesc> <mimeType>image/gif</mimeType> <uri>http://www.dhs.gov/dhspublic/getAdvisoryImage</uri> </resource> <area> <areaDesc>U.S. nationwide and interests worldwide</areaDesc> </area> </info></alert> Esempio 1: codice XML di un messaggio di allerta conforme al CAP (fonte: OASIS [4]) Inoltre l’Esempio 1 evidenzia che gli elementi all’interno dei segmenti hanno contenutidi lunghezza disomogenea tra loro e una visualizzazione completa – elemento insieme acontenuto – potrebbe portare a saturare l’area visibile dello schermo costringendo l’utentea scorrere un lista eccessivamente lunga. Allora si ritiene opportuno scegliere divisualizzare la lista degli elementi senza il contenuto; sarà l’utente, selezionandol’elemento, a visualizzare il contenuto cui è interessato. Per quanto riguarda la parte di gestione del codice XML, l’applicazione dovrà esserein grado di accedere al codice, scorrendolo per estrarre le informazioni richieste. Inparticolare dovrà essere in grado di collezionare gli elementi contenuti in ogni segmento erestituirli in una forma tale da permettere la creazione di una lista, oltre a poter estrarre ilvalore che ogni elemento contiene, quando necessario. Il diagramma delle classivisualizzato in Fig. 8 tiene conto delle scelte appena effettuate. 14
  15. 15. Fig. 8: diagramma delle classi La classe CapViewer rappresentata in Fig. 8 sarà deputata alla gestione della grafica etra gli attributi (attributes) compaiono gli elementi necessari per la formazione delle listee per la visualizzazione del contenuto del messaggio. Tra i metodi (operations) di questaclasse quelli di maggior interesse sono CapViewer() e commandAction(), i qualisi occuperanno rispettivamente della gestione complessiva – grafica e logica – e dellagestione delle interazioni tra utente e applicazione. I restanti metodi sono necessari per lagestione generica dell’applicazione e si occuperanno delle seguenti operazioni:startApp() si occuperà dell’avvio e delle operazioni che avvengono durante ilnormale funzionamento, pauseApp() di gestire un eventuale stato di applicazione inpausa e, infine, destroyApp() si occuperà delle operazioni necessarie per terminarel’applicazione. 15
  16. 16. Diversamente, la classe MsgParser sarà deputata alla gestione del codice XML condue metodi (operations): MsgParser(), che si occuperà dell’accesso al file contenenteil codice XML e parseElement(), che si occuperà di estrazione/gestionedell’informazione richiesta dall’utente. L’interazione tra le due classi avverrà nel seguente modo: quando necessario, la classeCapViewer invocherà uno dei due metodi della classe MsgParser, a secondadell’operazione da effettuare; in figura questa interazione è indicata con una genericaassociazione di nome parser. Entrambe le classi faranno parte dello stesso package Java.Questo significa che sono stati posti alcuni vincoli sull’accessibilità di attributi e metodidi entrambe le classi. Infatti, mediante i modificatori di accesso – indicati dalle keywordJava public, protected e private – gli elementi della classe saranno accessibili dachiunque, se dichiarati public; solo da altri membri del package, se dichiarati protected; esolo da membri della stessa classe, se dichiarati private. Una trattazione più completa dimetodi e attributi delle classi presenti nel diagramma avverrà nel capitolo 3. 16
  17. 17. 3 REALIZZAZIONE In questo terzo capitolo vengono trattati prima l’utilizzo dell’interfaccia grafica, nelparagrafo 3.1, e in seguito come funziona internamente l’applicazione, nel paragrafo 3.2.3.1 Interfaccia grafica L’interfaccia all’avvio si presenta come in Fig. 9: Fig. 9: applicazione avviata sull’emulatore facente parte del Java ME SDKÈ presente una lista degli elementi contenuti nel segmento principale, cioè <alert> e iltasto “Exit”, utilizzato per chiudere l’applicazione; per visualizzare il contenuto di unelemento è necessario evidenziarlo e usare il tasto di selezione del dispositivo.A seconda del contenuto dell’elemento verrà visualizzata una schermata differente: • Per elementi contenenti solo informazioni testuali verrà visualizzata una schermata come in Fig. 10, contenente il nome dell’elemento e il valore che esso assume; se questo elemento ha più campi al suo interno, essi verranno elencati come in Fig. 11, ma non sarà possibile interagire con essi. 17
  18. 18. Fig. 10: visualizzazione di un elemento testuale Fig. 11: visualizzazione di un elemento testuale contenente più campi • Per elementi composti a loro volta da liste complesse, cioè con elementi contenenti ulteriori elementi testuali, sarà visualizzata una lista interattiva, come in Fig. 12,in cui sarà necessario evidenziare e selezionare l’elemento desiderato: Fig. 12: visualizzazione di un elemento complesso 18
  19. 19. 3.2 Implementazione In questo paragrafo verrà analizzato il funzionamento interno dell’applicazione,commentando le scelte fatte per entrambe le classi progettate nel paragrafo 2.4. Nellaparte iniziale avverrà la descrizione della gestione delle operazioni dopo l’avviodell’applicazione e in seguito si entrerà nel dettaglio dei due moduli che la compongono,identificabili nelle due classi CapViewer e MsgParser.3.2.1 Funzionamento generale Una volta avviata l’applicazione, il costruttore della classe CapViewer inizializzerà lecomponenti necessarie a disegnare l’interfaccia grafica iniziale e successivamente forniràalla classe MsgParser le informazioni necessarie per individuare il file contenente ilmessaggio che si vuole visualizzare. A questo punto, la classe MsgParser potrà accedereal file rendendolo accessibile alla classe CapViewer, mediante i suoi metodi. Avendoaccesso al file, CapViewer potrà creare una lista degli elementi del primo livello (cioècontenuti nel segmento <alert>) e renderla visibile sulla schermata correntedell’interfaccia grafica. Ora che l’interfaccia è visibile, l’applicazione reagirà solo aun’azione dell’utente, che potrà scegliere di terminare l’applicazione oppure visualizzareil contenuto di un elemento della lista appena generata.3.2.2 La classe CapViewer Tutti i numeri di linea di codice citati in questo paragrafo riguardano l’Appendice A.Tralasciando le prime linee contenenti le dichiarazioni delle librerie da importare, siponga attenzione alle linee [10,18], contenenti le dichiarazioni delle variabili utilizzate inseguito. L’unica variabile inizializzata è file, con la stringa contenente l’indirizzo dellarisorsa. La variabile è stata inizializzata in questo modo perché l’individuazione e ilrecupero dell’indirizzo della risorsa non sono tra gli obbiettivi del presente sviluppo. All’interno del costruttore della classe – linee [20,29] – avviene l’inizializzazione dellevariabili necessarie per la gestione dell’interfaccia grafica. Segue il metodostartApp(), al cui interno viene acquisito il controllo dello schermo del dispositivo sucui è eseguita l’applicazione; inoltre alla linea [34] viene chiamata la classe MsgParser acui viene fornito l’indirizzo della risorsa su cui operare. Alle linee [36,37] viene creata lalista degli elementi contenuti nel segmento <alert> del messaggio, in particolare 19
  20. 20. invocando il metodo parseElement(null, 1). Il significato dei parametri saràspiegato in seguito. In questa parte verrà trattato il metodo commandAction(Command c,Displayable d): viene attivato ogni volta che si verifica un evento su uno deicomponenti di tipo Command presenti in un componente di tipo Displayable e al suointerno avvengono una serie di controlli su quale dei suddetti componenti ha originatol’evento. Comprende la gestione di: • Utilizzo del tasto “Exit” che porta a terminare l’applicazione. • Selezione di un elemento di una lista, con gestione differente per elementi differenti e appartenenti a diverse liste. • Utilizzo del tasto “Back” per tornare alla visualizzazione precedente.La parte più complessa e articolata è la gestione della selezione di un elemento di unalista perché le operazioni da eseguire, oltre a dipendere dalla specifica lista, dipendonoanche da quale elemento viene scelto. Per alcuni sarà sufficiente mostrarne il contenuto inun apposito componente grafico, per altri sarà necessario creare una nuova lista.3.2.3 La classe MsgParser Tutti i numeri di linea di codice citati in questo paragrafo riguardano l’Appendice B.Le prime linee anche qui sono dedicate alla dichiarazione delle librerie necessarie perpermettere la regolare esecuzione. Seguono le dichiarazioni degli attributi di questaclasse. Questa classe espone i seguenti metodi, accessibili solamente all’interno delpackage CapViewer grazie all’utilizzo del modificatore d’accesso protected: voidMsgParser(String filename) e String[] parseElement(Stringel_name, int level). Il primo metodo è il costruttore della classe e riceve come parametro, sotto forma distringa di caratteri, l’indirizzo dal quale recuperare la risorsa. Nell’intervallo di linee dicodice che va dalla linea [21] alla [32] viene utilizzato un costrutto try-catch nel qualeavviene un tentativo di aprire un canale di comunicazione verso il file contenente ilmessaggio e, nel caso non dovesse andare a buon fine e fosse sollevata un’eccezione diinput/output, viene specificata la gestione dell’eccezione. La gestione dell’eccezione èrimasta volutamente generica e allo stato attuale non fornisce nessuna notifica tramite 20
  21. 21. interfaccia grafica perché l’indirizzo viene fornito in maniera forzata (cfr. §3.2.2)all’applicazione. In un eventuale sviluppo futuro in cui la risorsa sarà indicata dall’utente,potrà essere implementata una gestione più specifica delle eccezioni. Invece nel caso incui si riesca ad avere accesso alla risorsa, viene estratto il suo elemento radice e associatoalla variabile root. Creata un’istanza della classe MsgParser, sarà disponibile il metodo String[]parseElement(String el_name, int level) per estrarre elementi dalmessaggio di allerta. Questo metodo accetta come parametri il nome dell’elemento che sivuole estrarre (ricavato dalla selezione sulla lista corrente) e il livello della lista sullaquale avviene la selezione (il livello è determinato dalla posizione che ha all’interno deldocumento l’elemento che ha generato la lista); il metodo restituisce come risultato unarray di stringhe. La scelta del tipo di variabile da restituire è basata sul fatto che nella gerarchia delleclassi che compongono la libreria LCDUI utilizzata per la parte grafica, è presente ilcomponente List che dispone di un costruttore che accetta un array di stringhe comeparametro per formare la lista. La possibilità appena descritta è stata valutata una sceltapiù conveniente rispetto all’aggiunta di ogni voce della lista singolarmente. All’interno del metodo parseElement(…), nelle prime due linee si trovano ladichiarazioni di due variabili: un array di stringhe str_arr e una variabile v_str, ditipo Vector. La prima serve per restituire il risultato dell’esecuzione del metodo ma non èpossibile crearla e modificarla in maniera dinamica, operazione di cui vi è necessitàperché il numero di elementi da inserire nell’array non è noto a priori in quantodipendente dalla scelta dell’utente. Ed è questo il motivo che porta a scegliere unavariabile di tipo Vector, che permette di aggiungere elementi in coda a quelli già presentifino al raggiungimento della sua capacità (di default pari a 10) e una volta raggiunta lacapacità corrente, viene raddoppiata. In alternativa è prevista la possibilità di specificarecapacità iniziale e la quantità di nuovi elementi da aggiungere al raggiungimento dellacapacità specificata. Nella parte successiva del metodo si trova la gestione dell’estrazione dell’elementoselezionato. Questa sezione del codice organizzata in modo che il primo controllo vengafatto sul livello della lista in cui è avvenuta la selezione – linee [39] e [65] – per poter 21
  22. 22. trattare opportunamente le possibili selezioni su ognuna di esse. Se la lista che hagenerato l’evento è di livello 1, allora vengono fatti una serie di ulteriori controlli sulnome dell’elemento. Il primo controllo consiste nel verificare se il nome non è specificato(ossia il parametro assume valore null) allora significa che bisogna generare la listadegli elementi contenuti nella radice. Questa operazione viene fatta scorrendo tutto ilcontenuto della radice e selezionando solo gli elementi XML (la libreria kXML prevededei valori fissi con cui confrontare il tipo dell’elemento). I controlli successivi sonoutilizzati per trovare ed estrarre il contenuto dell’elemento, il cui nome è stato passatomediante l’apposito parametro el_name. Una volta estratto viene aggiunto alla variabilev_str. Un controllo è destinato in maniera specifica alla selezione della voce <info>:infatti questo segmento contiene a sua volta più elementi e viene ricavato solo il nome diciascun elemento e aggiunto a v_str, in modo da raccogliere le voci che comporrannola lista da cui effettuare la selezione. Se la selezione avviene su una lista di livello 2 il procedimento è simile: viene estrattoil contenuto dell’elemento selezionato e aggiunto a v_str. Gli elementi che godono diuna gestione particolare sono <eventCode>, <parameter>, <resource> e <area>. I primidue contengono due attributi, di cui viene estratto il nome e il valore, aggiungendoli allavariabile Vector. I secondi richiedono un’operazione più complessa simile a quella messain atto per <info>, perché contengono al loro interno un elenco di elementi di cui bisognaricavare il nome e il contenuto. La differenza rispetto a <info> sta nel fatto che anzichécreare una lista interattiva, viene generata una lista che mostra il nome e il contenutocontemporaneamente. Effettuati tutti i controlli necessari e debitamente arricchita la variabile Vector v_str,quest’ultima avrà una dimensione che rimarrà fissa per la corrente esecuzione del metodo.Quindi alle linee [124,126] avviene il trasferimento del contenuto di v_str nell’arraystr_arr, che verrà restituito come risultato dell’esecuzione del metodo. 22
  23. 23. 4 CONCLUSIONI In questo capitolo verrà verificato se gli obiettivi che sono stati fissati nel capitolo 1 esviluppati nella fase di progettazione sono stati raggiunti. L’obiettivo primario era, apartire dallo studio del protocollo CAP, la creazione di una applicazione in grado digestire un messaggio di allerta formato secondo il suddetto protocollo. Il risultato raggiunto è un prototipo, infatti non è destinato all’utilizzo nella forma incui si trova ma necessita di alcune aggiunte e migliorie, che verranno illustrate tra breve.Il prototipo nel suo insieme è composto da due classi che si occupano sia della gestionedella parte grafica, sia della manipolazione ed estrazione del contenuto del messaggio. Riprendendo i requisiti esposti nel paragrafo 2.2, bisogna fare alcune considerazioni: 1. Gestione ed estrazione di informazioni da un documento XML: questo requisito è stato parzialmente soddisfatto perché l’applicazione è in grado di scorrere il documento XML con il quale viene formato il messaggio di allerta, ma allo stato attuale non è sempre in grado di gestire correttamente la presenza di occorrenze multiple di uno stesso elemento. 2. Indipendenza dalla piattaforma di esecuzione: questo requisito è stato rispettato, infatti avendo utilizzato Java come linguaggio per lo sviluppo è possibile servirsi del prototipo sviluppato su tutti i dispositivi che possono adoperare la Java Virtual Machine, necessaria per interpretare ed eseguire il codice Java. 3. Necessità di esecuzione su dispositivi mobili: la scelta di utilizzare il linguaggio Java, in particolare nella versione dedicata ai [5] dispositivi mobili (Java ME ), permette l’esecuzione dell’applicazione su dispositivi mobili. Sono state effettuate alcune prove sullo smartphone Sony- Ericsson P1i ed è stata rilevata qualche incongruenza nella parte di interfaccia grafica, rispetto all’emulatore utilizzato durante lo sviluppo. Queste incongruenze sono dovute al fatto che le impostazioni del dispositivo possono sovrapporsi a quelle specificate dall’applicazione in esecuzione. 23
  24. 24. Il prodotto del presente lavoro è, come in precedenza detto, un prototipo.Nell’eventualità di proseguirne lo sviluppo, possiamo individuare alcune aggiunte omigliorie che si potrebbero apportare. Innanzitutto è necessario rendere il modulo digestione del messaggio di allerta capace di gestire occorrenze multiple degli elementi delmessaggio, in modo da evitare problemi di visualizzazione qualora si presentasse unmessaggio contenente più occorrenze di alcuni elementi.Allo stato attuale il file contenente il messaggio viene fornito in maniera forzataall’applicazione, includendolo nei file che compongono l’eseguibile. Nel caso in cui sidecida di distribuire l’applicativo a più utenti questa soluzione non è più percorribile esarà necessario sviluppare un’alternativa alla situazione quella appena descritta. Unapossibile soluzione potrebbe essere permettere all’utente la selezione del messaggio davisualizzare.Un ulteriore sviluppo potrebbe essere restituire in formato grafico le informazionicontenute nel messaggio di allerta, in modo che l’utente possa capire più rapidamentequale area è interessata dall’evento e se potrebbe trovarsi coinvolto. A sfavore dellavisualizzazione grafica potrebbero influire le risorse limitate di cui potrebbe disporre ildispositivo mobile utilizzato.Ringraziamenti Un caloroso ringraziamento va alla mia famiglia e al dottor Ugo Cheracci che hannocondiviso gioie e dolori di questo percorso di studi, insieme agli insostituibili compagnidi studio Andrea e Cristian. Un grazie particolarmente affettuoso è per Claudia che mi ha incoraggiato nella partefinale e più impegnativa del suddetto percorso. E infine grazie alla professoressa Raffaela Cefalo e all’astrofisica Claudia Paparini peril lavoro svolto assieme. 24
  25. 25. Appendice A 1 package CapViewer; 2 3 import javax.microedition.lcdui.*; 4 import javax.microedition.midlet.*; 5 6 /** 7 * @author simonemaver 8 */ 9 public class CapViewer extends MIDlet implements CommandListener{10 private String file = "/files/ex2.xml";11 private MsgParser parser;1213 protected Display display;14 protected List select1, select2, select3;15 protected Form frm, frm2;16 protected StringItem si, si2;17 protected Command exitCmd;18 protected Command backCmd;1920 public CapViewer(){21 exitCmd = new Command("Exit", Command.EXIT, 2);22 backCmd = new Command("Back", Command.BACK, 2);23 frm = new Form("");24 frm2 = new Form("");25 si = new StringItem("", "");26 si2 = new StringItem("", "");27 frm.append(si);28 frm2.append(si2);29 } //costructor3031 public void startApp(){32 display = Display.getDisplay(this);3334 parser = new MsgParser(file); // from source file create a MsgParser object35 // create list containing the tags of the first level of CAP message36 select1 = new List("Message Content: ", List.IMPLICIT,37 parser.parseElement(null,1), null);38 select1.addCommand(exitCmd);39 select1.setFitPolicy(Choice.TEXT_WRAP_ON);40 select1.setCommandListener(this);41 display.setCurrent(select1);42 frm.addCommand(backCmd);43 frm.setCommandListener(this);44 frm2.addCommand(backCmd);45 frm2.setCommandListener(this);46 }4748 public void pauseApp(){}4950 public void destroyApp(boolean unconditional){}5152 public void commandAction(Command c, Displayable d){53 // manage command events on Displayables like Form54 if(c == exitCmd){55 destroyApp(false);56 notifyDestroyed();57 }58 if(c == List.SELECT_COMMAND){ // manage selection on a list59 int list_level;60 if(d == select1){ // if first level list is displayed61 list_level = 1; // set the level of the selection62 String selection = select1.getString(select1.getSelectedIndex());63 // get the text of the selected entry64 if(selection.equals("info")){65 // info contains complex tags: a list of these tags will be created and shown66 select2 = new List(selection.toUpperCase(), List.IMPLICIT,67 parser.parseElement(selection, list_level), null);68 select2.addCommand(backCmd);69 select2.setFitPolicy(Choice.TEXT_WRAP_ON);70 select2.setCommandListener(this);71 display.setCurrent(select2);72 } else{73 // for text-only tags a StringItem will be filled with tag content and shown74 si.setLabel(selection);75 si.setText(parser.parseElement(selection, list_level)[0]); 25
  26. 26. 76 display.setCurrent(frm); 77 } 78 } else if(d == select2){ // if second level list is displayed 79 list_level = 2; // set the level of the selection 80 String selection2 = select2.getString(select2.getSelectedIndex()); 81 // get the text of the selected entry 82 if(selection2.equals("eventCode") || selection2.equals("parameter")){ 83 // eventCode & parameter contain more than one text-only tags 84 si2.setLabel(selection2 + "n"); 85 // set on a StringItem all the tags and their contents 86 String str = ""; 87 for(int i = 0; i < parser.parseElement(selection2, list_level).length; 88 i++){ 89 str += parser.parseElement(selection2, list_level)[i]; 90 } 91 si2.setText(str); 92 display.setCurrent(frm2); 93 } else if(selection2.equals("resource") || selection2.equals("area")){ 94 // resource & area contain complex tags: a list will be created and shown 95 select3 = new List(selection2.toUpperCase(), List.IMPLICIT, 96 parser.parseElement(selection2, list_level), null); 97 select3.addCommand(backCmd); 98 select3.setFitPolicy(Choice.TEXT_WRAP_ON); 99 select3.setCommandListener(this);100 display.setCurrent(select3);101 } else{102 // for text-only tags a StringItem will be filled with tag content and shown103 si2.setLabel(selection2);104 si2.setText(parser.parseElement(selection2, list_level)[0]);105 display.setCurrent(frm2);106 }107 }108 }109 if(c == backCmd){ // manage back-command events110 if(d == frm || d == select2){111 display.setCurrent(select1);112 }113 if(d == frm2 || d == select3){114 display.setCurrent(select2);115 }116 }117 }118 } // class CapViewer 26
  27. 27. Appendice B 1 package CapViewer; 2 3 import java.io.IOException; 4 import java.io.InputStream; 5 import java.io.InputStreamReader; 6 import java.util.Vector; 7 import org.kxml.Xml; 8 import org.kxml.kdom.*; 9 import org.kxml.parser.*;1011 /**12 * @author simonemaver13 */14 public class MsgParser{15 private XmlParser parser = null;16 private Document doc;17 private Element root;1819 protected MsgParser(String filename){20 doc = new Document();21 try{22 InputStream in = this.getClass().getResourceAsStream(filename);23 InputStreamReader is = new InputStreamReader(in);24 parser = new XmlParser(is);25 doc.parse(parser);26 parser = null;27 } catch(IOException ioe){28 System.err.println(ioe);29 ioe.printStackTrace();30 parser = null;31 doc = null;32 }33 root = doc.getRootElement();34 }3536 protected String[] parseElement(String el_name, int level){37 String[] str_arr = null; // string array for return results38 Vector v_str = new Vector(); // vector for dynamic creation of results39 if(level == 1){ // entered when user make choice on a first level list40 if(el_name == null){ // used for alert element parsing41 for(int i = 0; i < root.getChildCount(); i++){42 // to scroll through items that do concern us:43 if(root.getType(i) == Xml.ELEMENT){44 // extracts the useful elements and add it to the Vector45 v_str.addElement(root.getElement(i).getName());46 }47 } // for(int i...48 // if el_name is a only-text element:49 } else if(root.getElement(el_name).getType(0) == Xml.TEXT){50 // extract the content and add it to the Vector51 v_str.addElement(root.getElement(el_name).getText());52 } else if(el_name.equals("info")){ // if el_name is a info element53 for(int j = 0; j < root.getElement("info").getChildCount(); j++){54 // to skip items that do not concern us:55 if(root.getElement("info").getType(j) != Xml.ELEMENT){56 continue;57 }58 if(root.getElement("info").getElement(j).getType(0) == Xml.TEXT){59 v_str.addElement(root.getElement("info").getElement(j).getName());60 continue;61 }62 v_str.addElement(root.getElement("info").getElement(j).getName());63 } // for(int j...64 } // else if(el_name.equals("info"))...65 } else if(level == 2){ // entered when user make choice on a second level list66 // if el_name is a only-text element:67 if(root.getElement("info").getElement(el_name).getType(0) == Xml.TEXT){68 v_str.addElement(root.getElement("info").getElement(el_name).getText());69 // processes complex elements that contain only-text elements:70 } else if(el_name.equals("eventCode") || el_name.equals("parameter")){71 for(int i = 0; i <72 root.getElement("info").getElement(el_name).getChildCount(); i++){73 if(root.getElement("info").getElement(el_name).getType(i) !=74 Xml.ELEMENT){ 27
  28. 28. 75 continue; 76 } 77 // if el_name is a only-text element: 78 79 if(root.getElement("info").getElement(el_name).getElement(i).getType(0) == Xml.TEXT){ 80 v_str.addElement("-" + 81 root.getElement("info").getElement(el_name).getElement(i).getName() + ": "); 82 83 v_str.addElement(root.getElement("info").getElement(el_name).getElement(i).getText() + 84 "n"); 85 continue; 86 } 87 } // for(int i... 88 // processes complex elements that contain other complex elements: 89 } else if(el_name.equals("resource") || el_name.equals("area")){ 90 for(int i = 0; i < 91 root.getElement("info").getElement(el_name).getChildCount(); i++){ 92 if(root.getElement("info").getElement(el_name).getType(i) != 93 Xml.ELEMENT){ 94 continue; 95 } 96 97 if(root.getElement("info").getElement(el_name).getElement(i).getType(0) == Xml.TEXT){ 98 99 v_str.addElement(root.getElement("info").getElement(el_name).getElement(i).getName() + ":"100 +101 root.getElement("info").getElement(el_name).getElement(i).getText());102 continue;103 }104105 v_str.addElement(root.getElement("info").getElement(el_name).getElement(i).getName());106 for(int j = 0; j <107 root.getElement("info").getElement(el_name).getElement(i).getChildCount(); j++){108109 if(root.getElement("info").getElement(el_name).getElement(i).getType(j) != Xml.ELEMENT){110 continue;111 }112113 if(root.getElement("info").getElement(el_name).getElement(i).getElement(j).getType(0) ==114 Xml.TEXT){115 v_str.addElement("-" +116 root.getElement("info").getElement(el_name).getElement(i).getElement(j).getName() + ": "117 + root.getElement("info").getElement(el_name).getElement(i).getElement(j).getText());118 continue;119 }120 } // for(int j...121 } // for(int i...122 } // if(el_name.equals("resource")...123 } // if(level == 2)124 str_arr = new String[v_str.size()]; // conversion Vector to String[]125 for(int i = 0; i < v_str.size(); i++){126 str_arr[i] = (String)v_str.elementAt(i);127 }128 return str_arr;129 } // method parseElement130 } // class MsgParser 28
  29. 29. Bibliografia[1] Edward Bryant, "Introduction to Natural Hazards," in Natural Hazards, 2nd ed. Wollongong, New South Wales, Australia: Cambridge University Press, New York.[2] UNISDR. United Nations International Strategy for Disaster Reduction — Terminology. [Online]. http://www.preventionweb.net/english/professional/terminology/v.php?id=503[3] Federal Communications Commission, governo USA. [Online]. http://www.fcc.gov/cgb/consumerfacts/eas.html[4] OASIS, "Common Alertin Protocol version 1.2," OASIS, Techinal Committee Standard Specifications 2010.[5] Oracle. Java ME - the Most Ubiquitous Application Platform for Mobile Devices. [Online]. http://www.oracle.com/technetwork/java/javame/overview/index.html[6] Oracle. Oracle Technology Network for Java Developers. [Online]. http://www.oracle.com/technetwork/java/index.html[7] kXML. [Online]. http://kxml.objectweb.org/software/downloads/Indice delle figureFig. 1: numero di eventi disastrosi rilevati tra il 1900 e il 2001 nel mondo [1]. ................... 3!Fig. 2: eventi disastrosi tra il 1998 e il 2009, nei paesi membri del EEA (EuropeanEnvironment Agency). ......................................................................................................... 4!Fig. 3: perdite umane tra il 1998 e il 2009, nei paesi membri del EEA (EuropeanEnvironment Agency). ......................................................................................................... 4!Fig. 4: perdite economiche complessive tra il 1998 e il 2009, nei paesi membri del EEA. 5!Fig. 5: ciclo di gestione delle calamità................................................................................. 5!Fig. 6: schema di gestione delle informazioni a seguito di una calamità ............................ 6!Fig. 7: struttura del messaggio di allerta (fonte OASIS [4]) ................................................ 11!Fig. 8: diagramma delle classi ........................................................................................... 15!Fig. 9: applicazione avviata sull’emulatore facente parte del Java ME SDK .................... 17!Fig. 10: visualizzazione di un elemento testuale ............................................................... 18!Fig. 11: visualizzazione di un elemento testuale contenente più campi ............................ 18!Fig. 12: visualizzazione di un elemento complesso ........................................................... 18!Esempio 1: codice XML di un messaggio di allerta conforme al CAP (fonte: OASIS [4]) 14 29

×