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 AMBIENTALI
Laureando: Relatore:
Simone Maver Prof. Ing. Raffaela Cefalo
ANNO ACCADEMICO 2009/2010

2. INDICE
1! 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. 1 INTRODUZIONE
Le emergenze provocate dal verificarsi di eventi naturali straordinari è negli ultimi
anni un tema ricorrente nei fatti di cronaca, si pensi ad esempio ai terremoti verificatisi in
Abruzzo nel 2009 e sull’isola di Haiti nel 2010, fino al maremoto d’inizio 2011 nel
Pacifico, con il conseguente tsunami che ha interessato il Giappone. Considerando un
intervallo più ampio di tempo si nota che il numero di eventi disastrosi che accade nel
mondo è 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 il
rischio 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, come
calamità naturali o incidenti industriali. L’aumento di queste cause negli ultimi anni
evidenzia la vulnerabilità della collettività, dal punto di vista sociale, economico e
territoriale.
Limitando la rilevazione degli eventi al solo territorio europeo l’andamento rimane
crescente e alcuni paesi europei sono interessati da una quantità considerevole di questi
avvenimenti in un arco temporale di circa dieci anni, com’è mostrato in Fig. 2. Questi
avvenimenti hanno conseguenze pesanti sia considerando il numero di persone coinvolte
(Fig. 3), sia sul fronte dei danni economici che provocano e delle risorse necessarie per
farvi fronte (Fig. 4).
3

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. 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 varia
secondo il tipo di evento. Ma è possibile individuare uno schema generale per la gestione
della situazione d’emergenza che essi creano; la Fig. 5 descrive qual è la catena degli
interventi 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 a
lungo termine.
Fig. 5: ciclo di gestione delle calamità.
5

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 punti
2 e 3, in particolare su come avviene o potrebbe avvenire, lo smistamento delle
informazioni in seguito all’evento. Infatti, la possibilità di raggiungere in maniera rapida
ed efficace tutti i soggetti coinvolti è un obiettivo importante per prevenire e limitare i
danni provocati da questi eventi naturali. Prendendo come riferimento lo schema presente
in Fig. 6, verranno esaminati il formato da utilizzare per il messaggio di allerta e come
potrebbe usufruirne un utente che lo riceve su un dispositivo mobile.
Fig. 6: schema di gestione delle informazioni a seguito di una calamità
6

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 trattazione
completa ed esaustiva rimandiamo alla pagina dedicata sul sito della Federal
Communications 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 formato
perché inquadrato in un progetto più ampio relativo al Disaster Management coordinato
dalla 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 in
grado di gestire e visualizzare su un dispositivo mobile il contenuto di un messaggio di
allerta formato secondo il CAP.
Questa tesi è articolata come segue: nella prima parte avverrà un’analisi del CAP che
porterà a individuare alcuni requisiti del prototipo. Definiti tutti i requisiti nel paragrafo
2.2, seguirà una breve descrizione delle tecnologie utilizzate per lo sviluppo (cfr. §2.3) e
la struttura dell’applicazione (cfr. §2.4). Nel capitolo 3 verrà trattata la parte di
realizzazione, in cui tratteremo l’interfaccia grafica e il funzionamento interno
dell’applicazione.
7

8. 2 ANALISI E PROGETTAZIONE
In questo capitolo vengono descritte le caratteristiche del protocollo CAP nel paragrafo
2.1, per passare nel paragrafo 2.2 alla definizione dei requisiti che dovrà soddisfare la
nostra applicazione e infine alle scelte per lo sviluppo nei paragrafi 2.3 e 2.4.
2.1 CAP (Common Alerting Protocol)
L'OASIS (Organization for the Advancement of Structured Information Standards,
http://www.oasis-open.org/) è un consorzio no-profit che coordina lo sviluppo e
promuove l’adozione di standard aperti per la distribuzione di informazioni a livello
globale. In particolare si occupa di standard per la sicurezza, per l'e-business e per
applicazioni di pubblica utilità.
Il CAP è uno di questi standard, in fase di approvazione, ed è un formato progettato
per lo scambio di avvisi d'emergenza su diversi tipi di rete. Il documento di riferimento
prodotto dall’OASIS è il Common Alerting Protocol Version 1.2 [4]. Il protocollo permette
di creare messaggi da poter distribuire contemporaneamente su diversi sistemi d'allerta,
incrementando l'efficacia degli avvisi e semplificandone la distribuzione. I principi alla
base 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. 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 quattro
parti più ampie, dette segmenti, le quali contengono a loro volta specifiche informazioni
riguardo all’evento cui si riferiscono. Segue una breve descrizione degli elementi del
messaggio. Per una trattazione più approfondita si rimanda al documento prodotto
dall’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. 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. 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) L'asterisco (*) indica che
Handling Code (code) * l'elemento 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à poi
sviluppata.
11

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’applicazione
dovrà 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 le
informazioni utili all’utente e tralasciando le informazioni di formattazione necessarie per
formare il documento XML. Inoltre per restare concordi con la caratteristica di
interoperabilità e portabilità dello standard CAP, l’applicazione dovrà essere indipendente
dalla piattaforma sulla quale sarà eseguita.
Considerando dove il messaggio potrebbe essere utilizzato, si distinguono due ambiti
principali: una sala di coordinamento e/o smistamento delle informazioni di un ente che si
occupa 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 degli
enti 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, i
quali hanno due caratteristiche da considerare nello sviluppo: la dimensione dello
schermo su cui visualizzare le informazioni e le ridotte risorse di calcolo e
memorizzazione.
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 utilizzate
per lo sviluppo, alla luce dei requisiti individuati nel paragrafo 2.2.
Considerati il secondo e il terzo requisito, la scelta sul sistema di sviluppo è ricaduta
sul Java Micro Edition System Development Kit 3.0 [5](d’ora in poi Java ME SDK). Il
linguaggio Java in generale non dipende dall’architettura e dal sistema su cui viene
eseguito, purché questo sistema/architettura possieda gli strumenti per interpretare il
12

13. codice Java. Per una trattazione più dettagliata di Java si rimanda al sito dello
sviluppatore. [6]
Per il primo requisito e per la scelta del sistema di sviluppo appena compiuta, la
ricerca di una libreria che permettesse la gestione di un documento XML ha portato a
scegliere la libreria kXML la quale fornisce le funzionalità necessarie. Non verrà
approfondita in maniera esaustiva la composizione della libreria ma si rimanda al sito
dello sviluppatore [7] contenente il codice sorgente e la documentazione. Saranno trattati
comunque con la necessaria precisione nel capitolo 3 quegli elementi della libreria che
sono 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à definita
in questo paragrafo la struttura che avrà l’applicazione. Innanzitutto viene scelto di
suddividerla in due parti: la prima destinata alla gestione della parte grafica, la seconda
alla gestione del codice XML componente il messaggio.
Per la parte grafica vengono effettuate le scelte che seguono: come si può vedere
nell’esempio 1, il codice XML è organizzato in una sorta di livelli – segmento <alert> da
cui 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 Homeland
Security</senderName>
<headline>Homeland Security Sets Code ORANGE</headline>
<description>The Department of Homeland Security has elevated the
Homeland Security Advisory System threat level to ORANGE / High in
response to intelligence which may indicate a heightened threat of
terrorism.</description>
13

14. <instruction> A High Condition is declared when there is a high risk
of terrorist attacks. In addition to the Protective Measures taken in
the previous Threat Conditions, Federal departments and agencies should
consider agency-specific Protective Measures in accordance with their
existing 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 contenuti
di lunghezza disomogenea tra loro e una visualizzazione completa – elemento insieme a
contenuto – potrebbe portare a saturare l’area visibile dello schermo costringendo l’utente
a scorrere un lista eccessivamente lunga. Allora si ritiene opportuno scegliere di
visualizzare la lista degli elementi senza il contenuto; sarà l’utente, selezionando
l’elemento, a visualizzare il contenuto cui è interessato.
Per quanto riguarda la parte di gestione del codice XML, l’applicazione dovrà essere
in grado di accedere al codice, scorrendolo per estrarre le informazioni richieste. In
particolare dovrà essere in grado di collezionare gli elementi contenuti in ogni segmento e
restituirli in una forma tale da permettere la creazione di una lista, oltre a poter estrarre il
valore che ogni elemento contiene, quando necessario. Il diagramma delle classi
visualizzato in Fig. 8 tiene conto delle scelte appena effettuate.
14

15. Fig. 8: diagramma delle classi
La classe CapViewer rappresentata in Fig. 8 sarà deputata alla gestione della grafica e
tra gli attributi (attributes) compaiono gli elementi necessari per la formazione delle liste
e per la visualizzazione del contenuto del messaggio. Tra i metodi (operations) di questa
classe quelli di maggior interesse sono CapViewer() e commandAction(), i quali
si occuperanno rispettivamente della gestione complessiva – grafica e logica – e della
gestione delle interazioni tra utente e applicazione. I restanti metodi sono necessari per la
gestione generica dell’applicazione e si occuperanno delle seguenti operazioni:
startApp() si occuperà dell’avvio e delle operazioni che avvengono durante il
normale funzionamento, pauseApp() di gestire un eventuale stato di applicazione in
pausa e, infine, destroyApp() si occuperà delle operazioni necessarie per terminare
l’applicazione.
15

16. Diversamente, la classe MsgParser sarà deputata alla gestione del codice XML con
due metodi (operations): MsgParser(), che si occuperà dell’accesso al file contenente
il codice XML e parseElement(), che si occuperà di estrazione/gestione
dell’informazione richiesta dall’utente.
L’interazione tra le due classi avverrà nel seguente modo: quando necessario, la classe
CapViewer invocherà uno dei due metodi della classe MsgParser, a seconda
dell’operazione da effettuare; in figura questa interazione è indicata con una generica
associazione 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 metodi
di entrambe le classi. Infatti, mediante i modificatori di accesso – indicati dalle keyword
Java public, protected e private – gli elementi della classe saranno accessibili da
chiunque, se dichiarati public; solo da altri membri del package, se dichiarati protected; e
solo da membri della stessa classe, se dichiarati private. Una trattazione più completa di
metodi e attributi delle classi presenti nel diagramma avverrà nel capitolo 3.
16

17. 3 REALIZZAZIONE
In questo terzo capitolo vengono trattati prima l’utilizzo dell’interfaccia grafica, nel
paragrafo 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 il
tasto “Exit”, utilizzato per chiudere l’applicazione; per visualizzare il contenuto di un
elemento è 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. 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. 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. Nella
parte iniziale avverrà la descrizione della gestione delle operazioni dopo l’avvio
dell’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à le
componenti necessarie a disegnare l’interfaccia grafica iniziale e successivamente fornirà
alla classe MsgParser le informazioni necessarie per individuare il file contenente il
messaggio che si vuole visualizzare. A questo punto, la classe MsgParser potrà accedere
al file rendendolo accessibile alla classe CapViewer, mediante i suoi metodi. Avendo
accesso al file, CapViewer potrà creare una lista degli elementi del primo livello (cioè
contenuti nel segmento <alert>) e renderla visibile sulla schermata corrente
dell’interfaccia grafica. Ora che l’interfaccia è visibile, l’applicazione reagirà solo a
un’azione dell’utente, che potrà scegliere di terminare l’applicazione oppure visualizzare
il 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, si
ponga attenzione alle linee [10,18], contenenti le dichiarazioni delle variabili utilizzate in
seguito. L’unica variabile inizializzata è file, con la stringa contenente l’indirizzo della
risorsa. La variabile è stata inizializzata in questo modo perché l’individuazione e il
recupero dell’indirizzo della risorsa non sono tra gli obbiettivi del presente sviluppo.
All’interno del costruttore della classe – linee [20,29] – avviene l’inizializzazione delle
variabili necessarie per la gestione dell’interfaccia grafica. Segue il metodo
startApp(), al cui interno viene acquisito il controllo dello schermo del dispositivo su
cui è eseguita l’applicazione; inoltre alla linea [34] viene chiamata la classe MsgParser a
cui viene fornito l’indirizzo della risorsa su cui operare. Alle linee [36,37] viene creata la
lista degli elementi contenuti nel segmento <alert> del messaggio, in particolare
19

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 dei
componenti di tipo Command presenti in un componente di tipo Displayable e al suo
interno avvengono una serie di controlli su quale dei suddetti componenti ha originato
l’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 una
lista perché le operazioni da eseguire, oltre a dipendere dalla specifica lista, dipendono
anche da quale elemento viene scelto. Per alcuni sarà sufficiente mostrarne il contenuto in
un 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 per
permettere la regolare esecuzione. Seguono le dichiarazioni degli attributi di questa
classe. Questa classe espone i seguenti metodi, accessibili solamente all’interno del
package CapViewer grazie all’utilizzo del modificatore d’accesso protected: void
MsgParser(String filename) e String[] parseElement(String
el_name, int level).
Il primo metodo è il costruttore della classe e riceve come parametro, sotto forma di
stringa di caratteri, l’indirizzo dal quale recuperare la risorsa. Nell’intervallo di linee di
codice che va dalla linea [21] alla [32] viene utilizzato un costrutto try-catch nel quale
avviene un tentativo di aprire un canale di comunicazione verso il file contenente il
messaggio e, nel caso non dovesse andare a buon fine e fosse sollevata un’eccezione di
input/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. 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 in
cui si riesca ad avere accesso alla risorsa, viene estratto il suo elemento radice e associato
alla variabile root.
Creata un’istanza della classe MsgParser, sarà disponibile il metodo String[]
parseElement(String el_name, int level) per estrarre elementi dal
messaggio di allerta. Questo metodo accetta come parametri il nome dell’elemento che si
vuole estrarre (ricavato dalla selezione sulla lista corrente) e il livello della lista sulla
quale avviene la selezione (il livello è determinato dalla posizione che ha all’interno del
documento l’elemento che ha generato la lista); il metodo restituisce come risultato un
array di stringhe.
La scelta del tipo di variabile da restituire è basata sul fatto che nella gerarchia delle
classi che compongono la libreria LCDUI utilizzata per la parte grafica, è presente il
componente List che dispone di un costruttore che accetta un array di stringhe come
parametro per formare la lista. La possibilità appena descritta è stata valutata una scelta
più conveniente rispetto all’aggiunta di ogni voce della lista singolarmente.
All’interno del metodo parseElement(…), nelle prime due linee si trovano la
dichiarazioni di due variabili: un array di stringhe str_arr e una variabile v_str, di
tipo 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 quanto
dipendente dalla scelta dell’utente. Ed è questo il motivo che porta a scegliere una
variabile di tipo Vector, che permette di aggiungere elementi in coda a quelli già presenti
fino al raggiungimento della sua capacità (di default pari a 10) e una volta raggiunta la
capacità corrente, viene raddoppiata. In alternativa è prevista la possibilità di specificare
capacità iniziale e la quantità di nuovi elementi da aggiungere al raggiungimento della
capacità specificata.
Nella parte successiva del metodo si trova la gestione dell’estrazione dell’elemento
selezionato. Questa sezione del codice organizzata in modo che il primo controllo venga
fatto sul livello della lista in cui è avvenuta la selezione – linee [39] e [65] – per poter
21

22. trattare opportunamente le possibili selezioni su ognuna di esse. Se la lista che ha
generato l’evento è di livello 1, allora vengono fatti una serie di ulteriori controlli sul
nome 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 lista
degli elementi contenuti nella radice. Questa operazione viene fatta scorrendo tutto il
contenuto della radice e selezionando solo gli elementi XML (la libreria kXML prevede
dei valori fissi con cui confrontare il tipo dell’elemento). I controlli successivi sono
utilizzati per trovare ed estrarre il contenuto dell’elemento, il cui nome è stato passato
mediante l’apposito parametro el_name. Una volta estratto viene aggiunto alla variabile
v_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 di
ciascun elemento e aggiunto a v_str, in modo da raccogliere le voci che comporranno
la lista da cui effettuare la selezione.
Se la selezione avviene su una lista di livello 2 il procedimento è simile: viene estratto
il contenuto dell’elemento selezionato e aggiunto a v_str. Gli elementi che godono di
una gestione particolare sono <eventCode>, <parameter>, <resource> e <area>. I primi
due contengono due attributi, di cui viene estratto il nome e il valore, aggiungendoli alla
variabile Vector. I secondi richiedono un’operazione più complessa simile a quella messa
in atto per <info>, perché contengono al loro interno un elenco di elementi di cui bisogna
ricavare 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 contenuto
contemporaneamente.
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’array
str_arr, che verrà restituito come risultato dell’esecuzione del metodo.
22

23. 4 CONCLUSIONI
In questo capitolo verrà verificato se gli obiettivi che sono stati fissati nel capitolo 1 e
sviluppati nella fase di progettazione sono stati raggiunti. L’obiettivo primario era, a
partire dallo studio del protocollo CAP, la creazione di una applicazione in grado di
gestire un messaggio di allerta formato secondo il suddetto protocollo.
Il risultato raggiunto è un prototipo, infatti non è destinato all’utilizzo nella forma in
cui 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 gestione
della 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. Il prodotto del presente lavoro è, come in precedenza detto, un prototipo.
Nell’eventualità di proseguirne lo sviluppo, possiamo individuare alcune aggiunte o
migliorie che si potrebbero apportare. Innanzitutto è necessario rendere il modulo di
gestione del messaggio di allerta capace di gestire occorrenze multiple degli elementi del
messaggio, in modo da evitare problemi di visualizzazione qualora si presentasse un
messaggio contenente più occorrenze di alcuni elementi.
Allo stato attuale il file contenente il messaggio viene fornito in maniera forzata
all’applicazione, includendolo nei file che compongono l’eseguibile. Nel caso in cui si
decida di distribuire l’applicativo a più utenti questa soluzione non è più percorribile e
sarà necessario sviluppare un’alternativa alla situazione quella appena descritta. Una
possibile soluzione potrebbe essere permettere all’utente la selezione del messaggio da
visualizzare.
Un ulteriore sviluppo potrebbe essere restituire in formato grafico le informazioni
contenute nel messaggio di allerta, in modo che l’utente possa capire più rapidamente
quale area è interessata dall’evento e se potrebbe trovarsi coinvolto. A sfavore della
visualizzazione grafica potrebbero influire le risorse limitate di cui potrebbe disporre il
dispositivo mobile utilizzato.
Ringraziamenti
Un caloroso ringraziamento va alla mia famiglia e al dottor Ugo Cheracci che hanno
condiviso gioie e dolori di questo percorso di studi, insieme agli insostituibili compagni
di studio Andrea e Cristian.
Un grazie particolarmente affettuoso è per Claudia che mi ha incoraggiato nella parte
finale e più impegnativa del suddetto percorso.
E infine grazie alla professoressa Raffaela Cefalo e all’astrofisica Claudia Paparini per
il lavoro svolto assieme.
24

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;
12
13 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;
19
20 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 } //costructor
30
31 public void startApp(){
32 display = Display.getDisplay(this);
33
34 parser = new MsgParser(file); // from source file create a MsgParser object
35 // create list containing the tags of the first level of CAP message
36 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 }
47
48 public void pauseApp(){}
49
50 public void destroyApp(boolean unconditional){}
51
52 public void commandAction(Command c, Displayable d){
53 // manage command events on Displayables like Form
54 if(c == exitCmd){
55 destroyApp(false);
56 notifyDestroyed();
57 }
58 if(c == List.SELECT_COMMAND){ // manage selection on a list
59 int list_level;
60 if(d == select1){ // if first level list is displayed
61 list_level = 1; // set the level of the selection
62 String selection = select1.getString(select1.getSelectedIndex());
63 // get the text of the selected entry
64 if(selection.equals("info")){
65 // info contains complex tags: a list of these tags will be created and shown
66 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 shown
74 si.setLabel(selection);
75 si.setText(parser.parseElement(selection, list_level)[0]);
25

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 shown
103 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 events
110 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. 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.*;
10
11 /**
12 * @author simonemaver
13 */
14 public class MsgParser{
15 private XmlParser parser = null;
16 private Document doc;
17 private Element root;
18
19 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 }
35
36 protected String[] parseElement(String el_name, int level){
37 String[] str_arr = null; // string array for return results
38 Vector v_str = new Vector(); // vector for dynamic creation of results
39 if(level == 1){ // entered when user make choice on a first level list
40 if(el_name == null){ // used for alert element parsing
41 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 Vector
45 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 Vector
51 v_str.addElement(root.getElement(el_name).getText());
52 } else if(el_name.equals("info")){ // if el_name is a info element
53 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 list
66 // 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. 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 }
104
105 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++){
108
109 if(root.getElement("info").getElement(el_name).getElement(i).getType(j) != Xml.ELEMENT){
110 continue;
111 }
112
113 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 parseElement
130 } // class MsgParser
28

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 figure
Fig. 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 (European
Environment Agency). ......................................................................................................... 4!
Fig. 3: perdite umane tra il 1998 e il 2009, nei paesi membri del EEA (European
Environment 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