Capitolo IV

Una soluzione a componenti per l'adattività al contesto

ambientale

Nel capitolo precedente abbiamo presentato un esempio di applicazione di HPPC, per la gestione delle emergenze di inondazioni. L'esempio ci ha consentito di ragionare sugli aspetti di adattività al contesto ambientale, che un sistema di questo tipo necessita. Riassumendo, abbiamo visto che un'applicazione pervasiva ad alte prestazioni è caratterizzata da parti del sistema in grado di adattarsi al contesto, per garantire un contratto di performance o per adeguare le proprie funzionalità alla situazione ambientale.

La gestione di un processo di adattività così complesso, richiede l’utilizzo di un modello di programmazione che consenta di esprimere, in modo primitivo, gli aspetti di Location e Context Awareness, le computazioni ad alte prestazioni, Fault-Tolerant, distribuite e parallele, secondo un approccio uniforme, che permetta di specificare esplicitamente i processi di adattività. Nel campo dei modelli di programmazione è naturale rivolgersi ad un approccio basato sul concetto di tecnologia a componenti, per descrivere un sistema in termini di blocchi base riusabili, usati per la sua costruzione.

Il seguente capitolo ha la seguente struttura: per prima cosa richiameremo brevemente le caratteristiche di un sistema strutturato a componenti, successivamente descriveremo un approccio generale per l'adattività al contesto, mediante l'utilizzo di componenti di diverse tipologie, infine applicheremo all'esempio applicativo, introdotto nel capitolo precedente, le idee illustrate, descrivendo nello specifico la sua strutturazione a componenti e i meccanismi di Context Awareness.

4.1 Un breve richiamo alla tecnologia a componenti

In molti modelli a componenti descritti in letteratura [30, 31, 32, 33, 34, 35], un'applicazione complessa viene descritta in termini di componenti cooperanti, dove per componente individuiamo un insieme di funzionalità del sistema riusabili. Un concetto

utilizzare una componente e di accedere alla sue specifiche funzionalità, mediante “punti di ingresso”, chiaramente definiti. Come riferito in [32] possiamo individuare due tipi di interfacce per ogni componente:

1. Import Interface: una componente ha specifiche interfacce di ingresso, una o più di una, che consentono alla componente di accedere a servizi offerti dalle altre componenti dell'applicazione.

2. Export Interface: una componente ha specifiche interfacce di uscita, una o più di una, mediante le quali le altre componenti del sistema sono in grado di accedere ai servizi offerti dalla componente stessa.

La figura 4.1 mostra le interfacce di una componente, con una simbologia [32] ormai molto diffusa.

Figura 4.1: Una componente con interfacce di import ed export.

Ogni interfaccia, sia di ingresso che di uscita, necessita di due aspetti fondamentali:

• Una parte di signature o firma che descrive le operazioni esportate dall’interfaccia o importate, a seconda che l’interfaccia sia di uscita o di ingresso.

• Una parte di behaviour che descrive la semantica della componente, in relazione a una o più di una sua interfaccia.

L’insieme delle interfacce di una componente e la loro descrizione, costituiscono il tipo della componente. Ogni componente è istanza di determinato tipo, che determina le

interfacce e i comportamenti che l’istanza deve realizzare. L’aspetto cruciale della realizzazione di un sistema a componenti, consiste nel fatto di poterle interconnettere tra loro (figura 4.2), mediante le interfacce e concordemente alla compatibilità delle loro descrizioni.

Figura 4.2: Interconnessione tra componenti per costituire un’applicazione complessa.

Una questione fondamentale nell’interconnessione è quella di stabilire la compatibilità tra le interfacce di ingresso e di uscita, che richiede una specifica sintassi e una chiara semantica per descrivere, sia la signature, che il behaviour di ognuna di esse. L’interazione tra componenti è un problema che senz’altro si pone sia in fase di progettazione di un sistema, ma non solo. Connessioni statiche tra componenti sono spesso insufficienti a modellare in modo adeguato sistemi complessi. Esiste frequentemente la necessità di realizzare interconnessioni a tempo d’esecuzione e di eliminare tali collegamenti quando necessario. Un sistema deve quindi avere la caratteristica di essere descritto attraverso istanze di componenti riusabili, con un pattern di interconnessione dinamico, in relazione alla logica della computazione o ad eventi esterni.

La progettazione in questo senso richiede l’utilizzo di un modello a componenti, che consenta tra l’altro di:

1. Definire i tipi delle componenti e le corrispondenti interfacce, descrivendo per queste sia la loro firma che il comportamento associato.

2. Definire le interconnessioni tra componenti, sia staticamente che a tempo d’esecuzione, e verificarne la compatibilità delle interfacce.

3. Derivare in modo non ambiguo il grafo dei tipi relativo alle componenti del sistema che viene progettato.

Esistono diversi modelli a componenti che realizzano più o meno formalmente i tre punti indicati, tra questi citiamo: CCA [30, 31], GCM [33], COM [34] e JavaBeans [35]. Nel seguito del capitolo supporremo di adottare un modello a componenti definito come in [32], e struttureremo l'applicazione di esempio individuando le componenti software coinvolte, le loro interfacce e le loro interazioni, descrivendo le interconnessioni, sia statiche, che a tempo d’esecuzione, in modo da realizzare i casi d’uso descritti alla fine del capitolo precedente. Nella strutturazione che daremo del sistema, cercheremo di descrivere per ogni tipo di componente i seguenti aspetti:

1. Le interfacce sia di import che di export, ed il comportamento descritto informalmente.

2. Le interconnessioni sia statiche che dinamiche tra le componenti, ed il flusso informativo realizzato mediante la comunicazione tra i servizi offerti.

3. La struttura interna delle componenti. Individueremo i moduli che realizzano i servizi offerti e descriveremo informalmente i meccanismi impiegati.

4.2 Componenti adattive al contesto ambientale

In un’applicazione Context-Aware complessa e strutturata a componenti cooperanti, alcune componenti sono adattive al contesto, ovvero sono dipendenti dalle seguenti mutazioni dell’ambiente:

1. Al cambiamento dello stato o della disponibilità delle risorse, che la componente attualmente utilizza per la sua esecuzione per esempio, comportando processi di riconfigurazione delle funzioni.

2. Al cambiamento del contesto ambientale, che comporta la necessità di riorganizzare la computazione per mantenere un certo contratto delle performance.

In questo senso si parla di componenti ad alte prestazioni, parallele, che eseguono un’elaborazione critica, con vincoli prestazionali sulle loro elaborazioni. Si tratta di riconfigurazioni delle prestazioni.

La necessità di adattarsi al contesto comporta la problematica di far interagire un insieme di componenti, con quelle entità in grado di fornire le rilevazioni sullo stato dell’ambiente, sia questo il valore di sensori ambientali, o più significativamente, un insieme di informazioni sullo stato delle risorse, sullo stato della connettività tra i dispositivi, oppure lo stato attuale di un'emergenza. A questi valori ci riferiremo nel resto del capitolo con il termine generale variabili di contesto, che ci conducono ad affrontare due problematiche:

1. Da un lato la necessità di acquisire, memorizzare e gestire i dati di contesto, che possono comportare processi di adattività delle componenti, ed eseguire eventualmente processi di reasoning o inferenza sulle informazioni dell’ambiente, per ricavarne conoscenza implicita [17, 19, 21, 36], se necessario.

2. Dall'altro l'implementazione di un meccanismo di adattività, che consenta alle componenti di eseguire le riconfigurazioni sia non funzionali che delle funzioni, in reazione ad un evento ambientale, senza interrompere la loro esecuzione, ed in modo spontaneo e trasparente rispetto all'utente finale (Pervasive Computing).

Una possibile soluzione dei due problemi enunciati può essere quella di individuare due classi di componenti, all'interno di una sistema Context-Aware:

1. Componenti Funzionali: sono le componenti che implementano le singole funzionalità del sistema, o parti di esse, necessarie per la realizzazione dei casi d’uso individuati. Alcune di queste componenti possono prevedere meccanismi di adattività, ovvero in reazione a certe situazioni (stato delle risorse, tipo di risorse disponibili, monitoraggio della connettività, etc...), la componente può reagire riconfigurando la propria elaborazione, parte di essa, o della propria struttura.

2. Componenti di Contesto: sono componenti di supporto al sistema. Ciascuna componente esegue le attività di acquisizione, memorizzazione e gestione dei dati

di contesto, mediante un modello di gestione della conoscenza tra quelli indicati nel secondo capitolo (paragrafo 2.5). Le componenti di questo tipo sono collegate ad un insieme di servizi di contesto (sensori fisici e virtuali, Resource Discovery Service, etc...), e sono in grado di comunicare tra loro per scambiarsi le informazioni sul contesto ambientale.

Nella suddivisione che è stata data, l'obiettivo è risolvere il problema dell’interazione e della dipendenza tra lo stato attuale del contesto, e l’esecuzione delle componenti funzionali Context-Aware, come indicato nella figura 4.3:

Figura 4.3: Struttura a componenti per l’adattività al contesto.

Le componenti funzionali sono interconnesse tra loro mediante interfacce funzionali, per realizzare le specifiche del sistema. Ciascuna componente adattiva si registra, inoltre, presso una o più componenti di contesto, al fine di ricevere in modo asincrono delle segnalazioni per eventi a cui è interessata. Lo scambio di registrazioni ed eventi avviene utilizzando le interfacce non funzionali, che consentono alle componenti funzionali di comunicare con le componenti di contesto. Le componenti di contesto acquisiscono i dati dall’ambiente, e nel caso si verifichino eventi per cui sono presenti delle registrazioni, provvedono ad inviare delle notifiche alle componenti funzionali interessate. La ricezione delle segnalazioni da parte delle componenti funzionali, provoca l'esecuzione di riconfigurazioni delle computazioni che, a seconda dell'evento, possono comportare

l’attivazione di diverse implementazioni alternative delle funzionalità offerte, oppure l’adattamento del calcolo per mantenere le prestazoni stabilite con i contratti di QoS. La distinzione tra interfacce non funzionali (o di contesto) e interfacce funzionali delle componenti è raffigurata nella figura 4.4.

Figura 4.4: Interfacce funzionali ed interfacce non funzionali o di contesto.

In quest’ottica il proseguimento del capitolo descrive l'esempio di applicazione per la gestione delle inondazioni, in termini di componenti di questa tipologia, e con le interazioni descritte.

4.3 Descrizione delle componenti funzionali del sistema di esempio per la

gestione delle emergenze

Nel paragrafo saranno individuate ed informalmente descritte le componenti funzionali del sistema per la gestione delle emergenze. Per prima cosa sarà fornito un quadro d’insieme delle componenti, mediante un grafo, che indica con i nodi le componenti funzionali del sistema, e con gli archi, le interazioni generiche tra le interfacce funzionali di queste, senza descriverle però nello specifico.

Figura 4.5: Grafo delle componenti funzionali dell’applicazione di esempio.

4.3.1 Componente Visual Client

La componente viene eseguita sui dispositivi mobili della Pervasive Grid, e realizza il “lato client”, consentendo agli utenti di interagire con il sistema di gestione dell'emergenza. Gli utenti possono essere soccorritori della protezione civile, responsabili della gestione dell'emergenza, oppure utenti generici, come gli abitanti dell'area colpita dall'emergenza. Questi utenti possono interagire utilizzando diverse famiglie di dispositivi mobili, tra cui:

• I telefoni cellulari di terza generazione UMTS. Con ridotte capacità di memorizzazione, visualizzazione ed elaborazione.

• I PDA (Personal Digital Assistant). Rispetto al primo caso le capacità di elaborazione, visualizzazione e memorizzazione sono spesso superiori.

• I computer laptop, con una ancor maggior capacità d’elaborazione, memorizzazione e visualizzazione delle informazioni, rispetto ai dispositivi delle classi precedenti.

La componente Visual Client implementa un’interfaccia grafica, che consente all’utente di interagire con il resto del sistema per richiedere:

1. La visualizzazione grafica dello stato attuale dell’emergenza. Viene visualizzato il livello attuale dell’inondazione nell’area interessata, e vengono visualizzate le informazioni sulle eventuali infrastrutture coinvolte (ponti, strade, edifici, etc…), mediante l’interazione con i servizi GIS del sistema. L’utente può richiedere, inoltre, di visualizzare il valore di determinati sensori ambientali, di cui viene mostrata la localizzazione sulla mappa dell’emergenza.

2. L’utente può richiedere una previsione dell’emergenza d’inondazione, indicando graficamente un’area di interesse. Nella richiesta l’utente può fornire: il tipo di modello di previsione che intende utilizzare, il tempo di completamento e l’attendibilità attesa dei risultati della simulazione. Se i parametri consentono l’esecuzione della previsione, il sistema provvede ad effettuarla, ed i risultati

verranno visualizzati graficamente dalla componente Visual Client, sul dispositivo dell’utente. Nel caso che i vincoli per la previsione siano troppo stringenti, la componente Visual Client può visualizzare un messaggio all’utente, per suggerirgli nuovi parametri per eseguire la richiesta (con tempi di completamento maggiori o con un minor grado di affidabilità dei risultati).

3. L’utente ha la possibilità di richiedere ulteriori servizi, come il supporto alle decisioni, per quanto riguarda alcuni aspetti della gestione dell’emergenza tra cui: la distribuzione delle risorse umane (soccorritori) e materiali (automezzi, attrezzature, etc…). I risultati del supporto alle decisioni sono visualizzati, dalla componente Visual Client, sul dispositivo dell’utente, per esempio direttamente sulla mappa dell’emergenza.

La componente oltre a fornire all’utente un’interfaccia grafica, consente l’interazione tra l’utente e il sistema, mediante il modulo Client Interface Module, responsabile della comunicazione con il nodo di interfaccia a cui l'utente è attualmente collegato. La figura 4.6 mostra la componente e le sue interfacce:

Figura 4.6: La componente Visual Client.

Si può notare come la componente Visual Client sia una componente Context-Aware, che implementa meccanismi di adattività delle proprie funzionalità. La dipendenza dal contesto ambientale è relativa al fatto che la corrente implementazione dell’interfaccia grafica (Application GUI) può essere diversa, in base al particolare dispositivo su cui la componente è eseguita, ed in base al tipo di utente che lo sta utilizzando. Quindi le informazioni di contesto utili in questo caso sono:

1. Classificazione dell’utente corrente: per ogni tipologia di utente, alcune funzionalità possono essere o meno previste dal Visual Client (per esempio il

supporto alle decisioni può essere una funzionalità a disposizione solo degli utenti con responsabilità organizzative).

2. Classificazione del dispositivo usato: in base alle capacità tecnologiche del dispositivo (grandezza dello schermo, risoluzione massima, capacità di memorizzazione ed elaborazione, etc…), l’interfaccia grafica può implementare alcune funzionalità (esempio la visualizzazione dei risultati di un’operazione di previsione), in modo diverso.

4.3.2 Componente Dispatcher

La componente Dispatcher è una componente eseguita su ogni nodo d’interfaccia. Come è già è stato spiegato precedentemente, ogni nodo d’interfaccia è in grado di gestire un’area geografica di sua stretta competenza (chiamata cella), che comporta la gestione da parte del nodo sia delle informazioni ambientali relative alla sua area, sia la gestione degli utenti presenti fisicamente in quella cella, che intendono interagire con il sistema mediante i loro dispositivi mobili. Su ciascuno di questi dispositivi è eseguita un’istanza della componente Visual Client, in grado di interagire con la componente Dispatcher del nodo d’interfaccia della corrispondente cella di copertura. La componente Dispatcher è in grado di ricevere e gestire le richieste da parte delle istanze delle componenti Visual Client, interagendo con le altre componenti del sistema e fornendo le dovute risposte ai dispositivi degli utenti, per la visualizzazione dei risultati. La figura 4.7 riassume la struttura e il funzionamento della componente Dispatcher e delle sue interfacce:

Un’istanza della componente Dispatcher riceve dalle componenti Visual Client, degli utenti, uno stream di richieste, per operazioni che la stessa esegue rispondendo con uno stream di risultati. L’esecuzione delle richieste viene realizzata dal modulo Request Switching, e può essere descritta informalmente come in figura 4.8.

Figura 4.8: Comportamento della componente Dispatcher.

Le richieste ricevute possono essere le seguenti:

1. Richiesta dello stato attuale dell’emergenza data un’area d’interesse.

2. Richiesta di una previsione dell’emergenza, data un’area d’interesse e alcuni ulteriori parametri forniti dall’utente (tempo di completamento, precisione richiesta, eventuale tipo di algoritmo di previsione, etc…).

3. Richiesta d’esecuzione del supporto alle decisioni,data un’area di interesse e uno specifico stato d’emergenza (anche previsionale precedentemente ottenuto).

Dal grafo si evince come il compito di un’istanza della componente Dispatcher sia prevalentemente quello di:

1. Acquisire le informazioni utili dai sensori ambientali locali al nodo d’interfaccia su cui si trova eseguita (mediante l’interazione con la componente Sensor Data Manager).

2. Acquisire le informazioni utili,dai sensori ambientali associati a celle diverse da quella considerata, mediante l’interazione con la componente External Data Broker).

3. Inviare richieste di previsioni alla componente Forecasting Component del nodo d’interfaccia.

4. Inviare richieste di supporto alle decisioni alla componente DSS Component del nodo d’interfaccia.

Nel figura 4.8 vengono indicate le scelte dipendenti dal contesto. Nel caso in cui l’utente richieda lo stato attuale dell’emergenza, data un’area d’interesse, la componente Dispatcher provvede ad acquisire i dati ambientali del fiume dai sensori locali. Nel caso in cui il dispositivo, su cui è eseguita la componente Visual Client che ha inviato la richiesta, abbia sufficienti capacità di calcolo (esempio un computer laptop), i dati primitivi dei sensori, ottenuti dalla componente Dispatcher, sono inviati al dispositivo mobile, in modo che questo effettivamente elabori i risultati fornendo una descrizione dello stato dell’emergenza sullo schermo del dispositivo. Nel caso invece in cui, il dispositivo mobile non sia sufficientemente potente, la componente Dispatcher elabora i dati dell’emergenza localmente sul nodo d’interfaccia, fornendo i risultati già pronti per la visualizzazione alla componente Visual Client. In questi termini la componente Dispatcher esegue un diverso comportamento, dipendente da una specifica informazione di contesto, il tipo di dispositivo dell’utente che ha emesso la richiesta che è in corso di soddisfacimento.

L’adattività della componente Dispatcher può essere evidente anche in altri aspetti. La componente è infatti un punto critico per le prestazioni del sistema, in quanto riceve le richieste degli utenti, comunica con le altre componenti, e richiede loro l’esecuzione di determinate operazioni, fornedo i corrispondenti risultati. Si può quindi prevedere che la

componente sia in grado di riconfigurarsi per rispettare certi contratti relativi alle prestazioni, che possono dipendere dal contesto dell’emergenza. Infatti, nel caso in cui la cella in cui ci troviamo sia in uno stato d’emergenza, è possibile richiedere prestazioni diverse alla componente Dispatcher, che può adattarsi modificando la propria implementazione, per esempio adottando implementazioni parallele del modulo Request Switching. In una prima analisi questo potrebbe essere implementato mediante un paradigma farm, in cui ogni worker esegue, per ogni richiesta ricevuta, le operazioni descritte in figura 4.8.

In conclusione possiamo quindi supporre che la componente Dispatcher si registri presso le componenti di contesto, per l’ottenimento di eventi relativi:

1. Tipo di dispositivo che emette la richiesta alla componente Dispatcher.

2. Stato di classificazione dell’emergenza della cella di competenza del nodo d’interfaccia su cui è eseguita la componente Dispatcher.

4.3.3 Componente Sensor Data Collector

Come abbiamo già illustrato, ogni nodo d’interfaccia copre e gestisce un’area limitata del sistema di gestione delle inondazioni (cella). Su ogni nodo d’interfaccia viene eseguita un’istanza della componente Sensor Data Collector, responsabile dell’acquisizione delle informazioni di monitoraggio sull’attività del fiume della cella corrispondente. I sensori sono in grado di produrre uno stream di informazioni, che sono trasmesse al nodo d’interfaccia dell’area geografica su cui questi si trovano dislocati. La struttura della componente Sensor Data Collector è rappresentata nella figura 4.9.

La componente Sensor Data Collector riceve uno stream di informazioni dai sensori sull’attività del fiume. La componente si occupa della memorizzazione sul nodo (modulo Data Storage Manager) dei dati ricevuti, in base alla tipologia di dato e alla specifica zona dove è stato ottenuto (il sensore che lo ha prodotto), individuando informazioni temporali (timestamp) per ogni specifica misurazione.

Sulle informazioni ricevute la componente può eseguire anche calcoli statistici (media, varianza, etc…), che verranno memorizzati insieme al resto delle informazioni ottenute (modulo Statistical Data Generation).

4.3.4 Componente Sensor Data Manager

Su ogni nodo d’interfaccia viene eseguita un’istanza della componente Sensor Data Manager, responsabile della gestione delle informazioni memorizzate dalla componente Sensor Data Collector, relativamente ad una specifica cella di copertura. La componente riceve le richieste da parte delle componenti Dispatcher ed External Data Broker, per l’acquisizione di informazioni sullo stato dell’inondazione nella cella. La richiesta ricevuta deve indicare:

1. Il tipo di informazioni che è necessario ottenere: informazioni sulla velocità del fiume, informazioni sul livello dell’acqua, etc….

2. L’area di interesse di cui vogliamo acquisire le informazioni. La componente Sensor Data Manager trasmetterà solo le informazioni ottenute dai sensori che coprono totalmente o parzialmente quell’area (purché appartenga alla cella di copertura del nodo d’interfaccia sui cui la componente SDM è eseguita).

3. Un tempo iniziale, a partire dal quale è necessario trasmettere le informazioni. La componente Sensor Data Manager provvede a trasmettere le sole informazioni il cui timestamp è superiore a quello indicato nella richiesta..

Una prima strutturazione informale della componente Sensor Data Manager è fornita nella figura 4.10.

Figura 4.10: La componente Sensor Data Manager.

Il modulo Sensor Data Responder ricevere uno stream di richieste e produce uno stream di output, su cui sono forniti i risultati dei dati ambientali per ogni specifica richiesta ricevuta. Le richieste sono provenienti dalle componenti eseguite sullo stesso nodo d’interfaccia dell’istanza della componente Sensor Data Manager considerata:

1. Richieste provenienti dalla componente Dispatcher, relativamente allo stato attuale dell’emergenza richiesto da un utente.

2. Richieste provenienti dalla componente External Data Broker. Sono richieste provenienti da altre celle del sistema.

3. Richieste provenienti da componenti Forecasting Component e DSS Component locali al nodo d’interfaccia. Sono richieste per l’ottenimento dei dati ambientali necessari all’esecuzione, rispettivamente di previsioni e di modelli di supporto alle decisioni.

In tutti i casi il modulo Sensor Data Responder gestisce le richieste acquisendo i dati sullo stato dell’inondazione, ed inviando i risultati alla componente richiedente.

La componente Sensor Data Manager è una componente Context-Aware, in grado di adattare il proprio comportamento/prestazioni al contesto circostante. Per quanto riguarda le prestazioni, possiamo immaginare che la componente debba rispettare un determinato contratto sulle performance, per esempio relativamente al tempo di servizio per ogni singola richiesta ricevuta. Il contratto dipende da aspetti di contesto, per esempio legati allo

stato d’emergenza della cella di copertura del nodo d’interfaccia su cui la componente è eseguita. Nel caso di situazioni d’emergenza, si può supporre che il modulo Sensor Data Responder sia realizzato mediante un’implementazione parallela, per esempio task-parallel tipo farm.

Oltre all'adattività delle prestazioni, la componente implementa l'adattività delle sue funzioni, in relazione al contesto ambientale. In particolar modo la componente è interessata ad informazioni contestuali sullo stato della connettività tra il nodo d’interfaccia su cui è eseguita, e i sensori ambientali del fiume della cella corrispondente. In situazioni dove viene rilevato uno stato della connettività limitato o assente, per cui le informazioni dei sensori non sono aggiornate, la componente Sensor Data Manager può decidere di simulare queste informazioni, utilizzando le informazioni presenti prima della mancanza di connettività, in modo da eseguire modelli predittivi dei dati. Si tratta di un’adattività dell’implementazione del modulo Sensor Data Responder, ed in questo processo si distinguono due casi:

1. Se lo stato di connettività con i sensori è “sufficiente”, i dati sono acquisiti dalla componente e trasmessi alle componente richiedente, come da normale funzionamento.

2. Nel caso in cui la connettività tra specifici sensori e il nodo d’interfaccia sia “insufficiente”, la componente provvede a simulare i dati mancanti, mediante l’esecuzione di modelli predittivi, e fornisce i risultati delle previsioni alla componente richiedente, come da interfaccia.

In prima analisi quindi, possiamo prevedere che la componente Sensor Data Manager sia registrata presso le componenti di contesto, per ottenere eventi relativi al cambiamento delle seguenti informazioni contestuali:

1. Lo stato della connettività tra gli specifici sensori della cella e il nodo d’interfaccia.

2. Lo stato d’emergenza della cella relativa al nodo d’interfaccia.

in modo da adattare le prestazioni e le funzioni in relazione agli eventi ambientali ricevuti, come descritto precedentemente.

4.3.5 Componente External Data Broker

La componente External Data Broker (EDB) è in grado di interfacciare una cella di copertura con le altre celle del sistema. Il suo compito è quello consentire la condivisione dei dati sull’emergenza relativamente ad una cella, con il resto del sistema. Per questa ragione possiamo considerare connesse in rete tutte le istanze della componente EDB, ciascuna eseguita su un nodo d’interfaccia specifico. La figura 4.11 rappresenta questo concetto di interconnessione:

Figura 4.11: Rete di broker del sistema di gestione dell’emergenza.

Consideriamo un’istanza della componente External Data Broker, eseguita su un nodo d’interfaccia del sistema. Questa può eseguire le seguenti richieste:

1. Richieste dalla cella locale per informazioni su celle remote: sono richieste provenienti da altre componenti eseguite sullo stesso nodo d’interfaccia (componente Dispatcher, Forecasting Component e DSS Component), relativamente all’acquisizione di determinate informazioni sull’emergenza di responsabilità di altre celle di copertura. La componente EDB si occupa di inoltrare le richieste, in modo che raggiungano la componente EDB remota della cella di destinazione. Una volta che le informazioni delle altre celle di copertura sono state acquisiste, la componente EDB remota si occupa di trasmetterle alla componente EDB richiedente.

2. Richieste da celle remote per informazioni sulla cella locale: sono richieste provenienti da altre istanze remote della componente EDB, relativamente ad altre celle. La componente EDB locale si occupa di gestire queste richieste, acquisendo le informazioni dei sensori locali dalla componente Sensor Data Manager, e trasmettendo i risultati alla componente EDB remota richiedente.

3. Richieste dalla cella locale o da celle remote per informazioni esterne al sistema: alcuni nodi d’interfaccia del sistema sono fisicamente connessi a reti esterne di back-end, che possono fornire servizi di supporto al sistema di previsione e gestione delle emergenze d’inondazione. Tali servizi possono essere caratterizzati in due distinte tipologie: servizi per dati meteorologici, in grado di fornire informazioni sulle precipitazioni a breve, medio e lungo termine, e servizi GIS per acquisire informazioni sulla presenza di determinate strutture importanti per l’emergenza (presenza di abitazioni, strade, ferrovie, etc…).

La componente External Data Broker è una componente critica, con il compito principale d’integrare le componenti software appartenenti alle diverse celle del sistema, e a sistemi esterni di supporto. Nella figura sottostante 4.12 viene visualizzata, sia la parte della componente presente in ogni istanza, che la parte della componente adibita alla gestione delle interazioni tra la cella e sistemi esterni. Questa seconda parte della componente è presente solo nel caso in cui il nodo d’interfaccia sia fisicamente connesso a sistemi di back-end esterni.

Nella componente possiamo individuare tre distinti moduli, con diverse funzionalità di base:

1. Local Request Executer: si tratta del modulo adibito alla gestione delle richieste ricevute dalle componenti locali del nodo d’interfaccia: Dispatcher, Forecasting Component e DSS Component, e destinate a componenti EDB di altre celle remote.

2. Request Routing Module: si tratta del modulo adibito alla gestione di due tipologie di richieste: richieste ricevute da componenti EDB remote e destinate ad altre componenti EDB di altre celle (routing delle richieste), oppure richieste provenienti da componenti EDB remote e dirette alla componente EDB locale.

3. External Request Executer: modulo opzionale presente solo se la componente è eseguita su un nodo d’interfaccia collegato a sistemi esterni. Si occupa di effettuare richieste per dati meteo o GIS ricevuti da componenti locali della cella, o da istanze di componenti External Data Broker di altre celle.

Nella figura 4.13 viene descritto, in modo informale, il comportamento della componente External Data Broker, in relazione alle diverse tipologie di richieste:

Figura 4.13: Comportamento della componente External Data Broker.

Dai grafici di cui sopra emerge come la componente External Data Broker sia dipendente dal contesto circostante. In particolar modo la componente è in grado di eseguire le sue funzionalità in modo diverso, a seconda dello stato di connettività tra diverse istanze della componente EDB su diversi nodi d’interfaccia, ed in base alla connettività tra la componente e i servizi esterni a cui essa risulta collegata. Nel caso di situazioni di corretta connettività, la componente si comporta come è stato descritto in precedenza. Altrimenti questa è in grado di eseguire modelli predittivi, per simulare quelle informazioni che, a causa dell’elevata dinamicità del sistema, non sono realmente disponibili.

La componente EDB è una componente fondamentale per l’integrazione del sistema, mediante l’interconnessione in una rete di tutte le componenti EDB di ogni nodo d’interfaccia. Le prestazioni della componente possono essere dipendenti da particolari contratti di QoS, che vengono stabiliti in relazione allo stato d’emergenza delle singole celle del sistema. Possiamo prevedere, in relazione alla specifica condizione d’emergenza in cui ci troviamo, diverse implementazioni, anche parallele dei moduli Local Request Executer, Request Routing Module ed External Request Executer. In questo senso, quindi, la componente possiede aspetti di Context Awareness, e si registra presso le componenti di contesto per l’ottenimento degli eventi relativi a:

1. Lo stato della connettività tra i nodi d’interfaccia del sistema (e quindi tra le singole istanze delle componenti External Data Broker).

2. Lo stato della connettività tra i nodi d’interfaccia del sistema e sistemi esterni di back-end (sistemi per previsioni meteo e sistemi per dati GIS).

3. Lo stato dell’emergenza della cella, del nodo d’interfaccia su cui è correntemente eseguita la componente EDB.

4.3.6 Componente Meteo Data Broker e GIS Data Broker

Le componenti Meteo Data Broker e GIS Data Broker del sistema sono adibite all’interfacciamento dell’applicazione con sistemi esterni, che forniscono servizi di supporto tra cui:

1. Servizi per previsioni meteorologiche: interazione tra il sistema di esempio e un sistema di previsioni meteo, di una specifica istituzione.

2. Servizi per ottenimento dei dati GIS: interazione tra il sistema d’esempio e un sistema esterno, per l’acquisizione di informazioni georeferenziate su punti di interesse di un’area geografica.

Alcuni nodi d’interfaccia sono interconnessi con sistemi esterni, come cluster di macchine, servizi esterni per dati meteo e servizi per dati GIS. Nel caso di questi nodi d’interfaccia, la componente External Data Broker prevede, come abbiamo visto, un modulo aggiuntivo, responsabile dell’interconnessione con i servizi esterni (External Request Executer).

Per l’interazione tra un nodo d’interfaccia e un sistema esterno, è prevista però l’esecuzione sul sistema di back-end di una componente specifica, in grado d’interfacciare i servizi con il nostro sistema di trattamento delle emergenze di inondazioni. Nel caso di servizi meteo e GIS abbiamo: la componente Meteo Data Broker e la componente GIS Data Broker. Di seguito sarà informalmente descritta la prima, ma la descrizione è speculare anche nel secondo caso. La figura 4.14 mostra la componente e le sue interfacce:

Figura 4.14: La componente Meteo Data Broker.

La componente Meteo Data Broker riceve le richieste dalle componenti External Data Broker a lei connesse. Il modulo External Data Module provvede a inoltrare le richieste al sistema esterno che interfaccia. Le risposte ricevute vengono trasmesse poi alla componente External Data Broker richiedente del sistema.

4.3.7 Componente Forecasting Component e DSS Component

Ogni nodo d’interfaccia prevede un’istanza della componente Forecasting Component, che è in grado di eseguire i modelli previsionali dell’emergenza d’inondazione. La struttura della componente è quella rappresentata nella figura 4.15.

Figura 4.15: La componente Forecasting Component.

La componente Forecasting Component è strutturata in tre moduli sperati. Il primo di questi, il Forecasting Request Manager, è responsabile della ricezione delle richieste di previsione da parte della componente Dispatcher del nodo d’interfaccia. Le richieste prevedono i seguenti parametri:

1. L’area geografica interessata dalla previsione.

2. L’intervallo temporale della previsione (esempio è richiesta la simulazione per i prossimi 15 minuti).

3. L’affidabilità dei risultati di previsione (in base al quale viene scelto l’algoritmo con cui si esegue la previsione).

4. Il tempo di completamento massimo, per l’operazione di previsione.

Il modulo Data Acquisition si occupa di acquisire tutti i dati necessari al processo di previsione. I dati locali alla cella sono richiesti alla componente Sensor Data Manager locale, i dati appartenenti ad altre celle oppure di servizi esterni, vengono invece richiesti alla componente External Data Broker. Una volta acquisite tutte le informazioni necessarie, il modulo Simulation Model si occupa di eseguire la previsione, e al termine di questa, fornire i risultati alla componente Dispatcher.

L’esecuzione del modulo Simulation Model è l’aspetto critico della componente per quanto riguarda le prestazioni. La sua implementazione può essere diversa, in relazione a:

1. Il particolare modello di previsione, che può essere fornito con la richiesta mediante plug-in.

2. Il base all’intervallo temporale della previsione (se a breve, medio o lungo termine), all’affidabilità dei risultati e al massimo tempo di completamento richiesto, il Simulation Model può decidere di eseguire con diverse implementazioni (staticamente definite), il modello di previsione dell’inondazione, a meno che non venga fornito dinamicamente mediante plug-in da chi fa la richiesta.

3. Una volta scelto il modello per la previsione, la componente Forecasting Component deve monitorare l’esecuzione del modello, garantendo le prestazioni stabilite. Il modello può quindi essere eseguito con diverse implementazioni parallele, anche riconfigurabili dinamicamente dalla componente stessa (riconfigurazioni delle performance). I processi delle implementazioni parallele possono essere distribuiti sui nodi della Pervasive Grid disponibili, sia il nodo d’interfaccia (che può essere parallelo), sia nodi “fissi” o mobili disponibili, in modo da realizzare un’elaborazione distribuita delle previsioni.

4. La scelta del modello da eseguire e la sua implementazione può dipendere anche da variabili contestuali come lo stato d’emergenza della cella/celle su cui si fa la simulazione.

La componente si registra presso le componenti di contesto, per ricevere, sia eventi che segnalino il cambiamento dello stato d’emergenza delle celle su cui è in corso una richiesta di previsione, che per eventi sul monitoraggio delle prestazioni delle previsioni computate.

Infine, per quanto riguardala componente DSS Component, questa riceve le richieste dalla componente Dispatcher, per eseguire modelli di supporto alle decisioni sull’emergenza. La struttura della componente e gli aspetti di adattività sono analoghi a quanto è stato descritto per la componente Forecasting Component, con la differenza che il modulo Simulation Model si occupa di eseguire modelli di supporto alle decisioni, anziché modelli previsionali dell’emergenza.

4.4 Le componenti di contesto (Context Control Component)

Nei paragrafi precedenti sono state descritte le componenti dell’applicazione che realizzano le funzionalità di base del sistema di gestione delle inondazioni, in modo da comprendere e descrivere gli aspetti di adattività e dinamicità delle computazioni da loro realizzate.

In questo paragrafo, invece, l’obiettivo è la descrizione delle componenti del sistema adibite alla raccolta, gestione ed utilizzo delle informazioni di contesto, che prendono nome di Context Control Component (CCC) o anche componenti di contesto. Le componenti di contesto hanno cioè lo scopo di acquisire, gestire ed utilizzare le informazioni contestuali ottenute dalle interfacce di contesto. Nel seguito del testo sarà prima descritta la struttura e il funzionamento di queste componenti, e poi successivamente la metodologia d’interazione con le altre componenti funzionali del sistema, per realizzare i processi d’adattività.

In base alle spiegazioni che sono state date sulle interazioni tra componenti funzionali e di contesto, il sistema ha la struttura a livelli come mostrato nella figura 4.16. Nel caso della nostra applicazione, possiamo supporre che un’istanza della componente CCC venga eseguita su ciascun nodo d’interfaccia e su ciascun dispositivo mobile usato dagli utenti.

Figura 4.16: Struttura a livelli dell’applicazione di esempio.

Come si evince dalla figura 4.17, una componente di contesto può essere suddivisa in tre specifici moduli, adibiti rispettivamente al processo di acquisizione, memorizzazione e gestione dei dati ambientali: il Context Retrieval Module (CRM), il Context Storage Module (CSM) e il Context Management Module (CMM).

Figura 4.17: La Context Control Component e la sua struttura.

4.4.1 Il Context Retrieval Module

Questo modulo è adibito alla raccolta delle informazioni di contesto, ottenute da diverse sorgenti dette anche context data provider, tra cui:

1. Interfacce di contesto: le interfacce di contesto possono essere più o meno intelligenti. Possiamo avere servizi generici, per esempio in grado di fornire dati sulle prestazioni delle componenti funzionali del sistema, oppure sensori, in grado di fornire misurazioni sullo stato dell’ambiente. In quest’ultimo caso sono informazioni di basso livello, primitive, che spesso richiedono opportune trasformazioni per poter essere utilizzabili. Le informazioni di contesto prodotte possono riguardare la banda disponibile, lo stato della connettività, il tipo di dispositivo usato, il tipo di utente collegato, ma anche eventualmente altre informazioni ambientali, che possono influenzare il comportamento delle componenti funzionali.

2. Informazioni fornite dall’utente: Un’altra fonte di informazioni di contesto possono essere le preferenze degli utenti (user profile), tra cui la “storia” delle ultime richieste, i tipi di input che sono stati forniti, etc…

3. Informazioni fornite da terze parti: sono informazioni scambiate con terze parti, per esempio ricevute da altre componenti CCC. Le componenti di contesto hanno la possibilità di poter comunicare tra di loro, in modo da scambiarsi informazioni sul contesto. Questo è particolarmente utile nel caso di contesto partizionato, in cui ogni CCC è collegata ad un certo numero di interfacce di contesto, e le informazioni ottenute da queste possono essere scambiate tra le componenti.

Il valore delle informazioni di contesto non dipende solo dall’informazione stessa, ma anche da alcune proprietà connesse, come la precisione dei dati e la loro età. A questo proposito le informazioni contestuali possono essere associate a timestamp, che definiscono l’età dei dati. Il Context Retrieval Module è formato a sua volta da tre moduli: l’Information Requester (IR), l’Information Forwarder (IF) e l’Information Comparator (IC). La figura 4.18 riassume la struttura del Context Retrieval Module.

Come abbiamo già descritto, le componenti Context-Aware del nostro sistema hanno la necessità di ottenere delle segnalazioni sulle variazioni del contesto, in modo da adattarsi conseguentemente. Per questo le componenti funzionali si registrano presso le componenti di contesto, in modo da ricevere specifici eventi relativi ad una variabile contestuale (esempio la banda di un collegamento).

Figura 4.18: La struttura del Cotext Retrieval Module.

La registrazione è presa in carico dal modulo Context Management Module, che si occupa di indicare al Context Retrieval Module (ed in particolar modo all’Information Requester), di monitorare il valore delle variabili contestuali per cui sono state ricevute delle registrazioni. Le richieste sono rivolte all’Information Forwarder, responsabile dell’acquisizione vera e propria delle informazioni fornite dai provider con cui è in grado di comunicare. In letteratura [37] sono descritte, in particolar modo, tre diverse modalità di acquisizione dei dati di contesto:

1. Ricezione Pull-Based dei dati di contesto: L’Information Requester invia una richiesta esplicita all’Information Forwarder per ottenere un certo tipo di dato di contesto. L’IF acquisisce dai provider il valore corrente del dato di contesto richiesto, e lo invia all modulo IR tramite l’Information Comparator.

2. Ricezione Interval-Based dei dati di contesto: L’Information Requester invia una richiesta iniziale all’Information Forwarder, per ottenere periodicamente il valore di un certo tipo di dato contestuale, indicando un opportuno intervallo di tempo. L’IF provvede ad ottenere periodicamente l’aggiornamento del valore del dato di contesto richiesto, ed inviare (tramite Information Comparator), ad ogni intervallo di tempo, i valori all’IR, finché questo non elimina la richiesta con un messaggio esplicito.

3. Ricezione Event-Based dei dati di contesto: L’Information Requester effettua una richiesta presso l’Information Forwarder, per ottenere una segnalazione ogni qual volta una certa variabile contestuale subisce un determinato cambiamento. L’IF si occupa di monitorare il valore del dato ed inviare l’evento di notifica quando necessario, con il nuovo valore all’Information Requester (tramite Information Comparator), finché l’IR non termina la richiesta con un messaggio esplicito.

I dati trasmessi dall’Information Forwarder sono ricevuti dal modulo Information Comparator, che nel caso più semplice si limita a trasmettere i risultati. E’ possibile comunque che più provider siano in grado di fornire i dati di contesto richiesti, in questo caso le informazioni raccolte sono inviate all’IC, con il compito di individuare l’informazione più attendibile da inviare all’IR. L’IC è quindi una componente che esegue una fase di filtraggio, se necessaria. La figura 4.19 riassume il funzionamento del modulo Context Retrieval Module e di tutte le sue parti:

Figura 4.19: Operazioni eseguite dal Context Retrieval Module.

Il Context Retrieval Module è inoltre responsabile della comunicazione tra componenti di contesto per lo scambio di informazioni ambientali. A questo proposito il modulo Information Requester è in grado di:

1. Ricevere richieste da altre CCC, per informazioni contestuali che è in grado di acquisire da interfacce di contesto connesse localmente. In questo caso le informazioni vengono acquisite ed inoltrate alla componente di contesto richiedente.

2. Inviare richieste per informazioni di contesto ad altre componenti CCC, che sono collegate alle interfacce di contesto necessarie alla loro acquisizione. I dati verranno trasmessi dalle altre componenti CCC al modulo Information Forwarder, come “informazioni da terze parti”.

4.4.2 Il Context Storage Module

Questo modulo è adibito alla memorizzazione persistente delle informazioni di contesto, acquisiste dal Context Retrieval Module. Il modulo deve gestire in modo efficiente la memorizzazione dei dati ambientali, memorizzando i dati aggiornati e le informazioni rilevanti. Questa necessità scaturisce dal fatto che la componente di contesto può essere eseguita su un vasta tipologia di dispositivi, anche mobili, che possono avere limiti seri di capacità di memorizzazione. Due aspetti sono relativi ai dati contestuali:

1. Il contenuto vero e proprio dell’informazione di contesto che è stata acquisita. Questo può essere rappresentato con un modello Key-Value Model (vedi paragrafo 2.5), ovvero una coppia chiave-valore. Per esempio: device_pda = “Imobile phone V95” per indicare il tipo di dispositivo usato da un determinato utente.

2. Come l’informazione è relazionata ad altre informazioni di contesto. Questo specifica il valore semantico dell’informazione contestuale. Per esempio relazioni tra dispositivi e utenti o tra dispositivi e luoghi in cui questi si trovano. Un modo diffuso in letteratura [17, 19, 20, 21, 36] per rappresentare un insieme di concetti e le loro relazioni, è quello di ricorrere all’uso di un’ontologia, per rappresentare concetti e loro relazioni.

I due aspetti sono gestiti dal Context Storage Module in modo separato. Per il primo si può considerare di avere un “contenitore” di coppie chiave-valore, dove sono memorizzate

tutte le coppie che rappresentano informazioni contestuali aggiornate. Per il secondo, possiamo immaginare di avere un modulo in grado di associare un valore semantico alle coppie ed a insiemi di coppie, per esempio mediante un’ontologia, oppure utilizzando una diversa forma di modello della conoscenza, come quelli accennati nel paragrafo 2.5. Possiamo quindi individuare due moduli nel CSM, il Fact Storage Module (FSM) e il Semantic Management Module (SMM), come mostrato in figura 4.20.

Figura 4.20: Struttura del Context Storage Module.

L’Information Requester nel Context Retrieval Module, trasmette nuove coppie chiave-valore al Context Storage Module. Le nuove coppie sono ricevute dal FSM, che si occupa di memorizzarle efficientemente, associando degli attributi utili alla loro gestione (un timestamp che indica l’istante a cui si riferisce la misurazione, l’ultimo utilizzo della coppia, quante volte è stata usata, etc…). Questi attributi possono essere utilizzati dal FSM per eseguire algoritmi di rimozione delle coppie, nel caso in cui ci sia la necessità di liberare memoria per nuove memorizzazioni.

Il modulo SMM si occupa invece della gestione del valore semantico delle coppie. In base al modello utilizzato (ontologie, reti semantiche, etc...), vengono associate delle relazioni tra le coppie chiave-valore, che sono state acquisite e memorizzate. Per esempio:

device_pda = “Imobile phone V95” current_user = “Gabriele Mencagli”

La prima coppia indica il tipo di dispositivo usato, la seconda un utente. Le due coppie possono essere collegate con una relazione di “utilizzo dispositivo”, che indica che il dispositivo indicato dalla prima coppia è utilizzato dall’utente individuato dalla seconda.

4.4.3 Context Management Module

Il modulo Context Management Module è responsabile dello svolgimento di attività di trasformazione e di reasonging/inferenza sui dati di contesto. E’ inoltre una parte estremamente critica delle componenti di contesto, in quanto gestisce le registrazioni per eventi da parte delle componenti funzionali del sistema, in modo da innescare conseguentemente processi di adattività.

La figura 4.21 riassume la struttura del Context Management Module e dei suoi sotto-moduli:

Figura 4.21: Struttura del Context Management Module.

Il Context Management Module si occupa nello specifico di tre separate attività di gestione delle informazioni contestuali, che vengono eseguite da tre moduli specifici:

1. Trasformazioni dei dati di contesto, eseguite dal Context Trasformation Module (CTM). Esempio la modifica dell’unità di misura con cui è stata effettuata una misurazione da un certo sensore.

2. Processi di reasoning/inferenza sui dati di contesto, eseguiti dal Context Inference Module (CIM) in base al modello con cui viene rappresentata la conoscenza.

3. Registrazione e sollevamento di eventi di contesto, inviati alle componenti Context-Aware del sistema e gestiti dal Context Event Register (CER).

Le componenti funzionali possono adattare il loro comportamento al verificarsi di eventi contestuali che non sono semplicemente il risultato dei sensori. Possiamo avere, in generale, componenti che necessitano di conoscere la presenza di situazioni ambientali che non sono esplicite nel contesto, ma che devono essere inferite dai dati a disposizione. Per esempio, una componente può essere in grado di utilizzare alternativamente un insieme di implementazioni diverse, ciascuna attivata quando l’utente si trova in una specifica situazione, oppure sta svolgendo una determinata attività. In questo caso la componente è dipendente dal contesto circostante, deve avere cioè la capacità di conoscere la condizione dell’ambiente, ed inferire da questo lo stato in cui si trova l’utente. Per esempio potrebbe inferire che l’utente è occupato, dal fatto che è in corso una chiamata al suo telefono cellulare, oppure perché l’utente sta utilizzando un software per rispondere ad una email sul computer del suo ufficio.

Figura 4.22: Descrizione dell’attività di reasoning/inferenza del CMM.

L’obiettivo quindi è quello di derivare nuove informazioni implicite da fatti e concetti che si hanno a disposizione, utilizzando specifiche regole di derivazione. Nel caso

dell’adozione delle ontologie, come modello semantico per i dati di contesto, esistono diversi sistemi di inferenza e di reasoning, ne sono un esempio i sistemi: Racer [38], Pellet [39] e FaCT [40]. Assumendo l’adozione di un’ontologia per rappresentare il contesto, la figura 4.22 riassume in modo informale, senza scendere nei dettagli che esulano dagli obiettivi di questa tesi, come il Context Inference Module possa inferire nuovi fatti dalle informazioni disponibili, mediante specifiche regole di inferenza .

4.4.4 Il Context Event Register

Per terminare la descrizione delle componenti di contesto, in questo paragrafo ci occuperemo di spiegare il funzionamento del Context Event Register. L’idea di base, per implementare il processo di adattività, è quella di ricorrere ad un sistema di notifiche di eventi di contesto. Ovvero si utilizza un pattern (figura 4.23) basato sul classico meccanismo publish-subscribe [41], in cui le componenti funzionali si registrano presso una o più componenti di contesto, in modo da ricevere in modo asincrono degli eventi quando determinate situazioni di contesto si verificano. Il meccanismo di notifica separa tutte le attività di acquisizione, memorizzazione ed inferenza delle informazioni di contesto, dalla realizzazione delle componenti funzionali e dei loro meccanismi di adattività.

Figura 4.23: Publisher-Subscriber pattern tra componenti.

Con l’attività di registrazione, una componente Context-Aware segnala quali sono le informazioni contestuali che influenzano il suo comportamento, innescando processi di adattività delle funzioni e/o prestazioni. Prendiamo un caso concreto, relativo al sistema di

gestione dell’emergenza. La componente Sensor Data Manager (SDM) è una componente funzionale Context-Aware, eseguita su un nodo di interfaccia e responsabile dell’accesso/gestione dei dati prodotti dai sensori ambientali collegati a quel nodo. Come abbiamo visto, la componente è interessata a due tipi di informazioni contestuali:

1. Lo stato della connettività tra i sensori ambientali e il nodo d’interfaccia, mediante rete wireless.

2. Lo stato della cella gestita dal nodo d’interfaccia su cui si trova eseguita la componente SDM. Lo stato può indicare un livello di gravità dell’emergenza (alto, medio, basso, o più complesso), che dipendo, per esempio, dal livello dell’inondazione, dalle strutture coinvolte o presenti (zona cittadina oppure zona rurale).

Entrambe le informazioni contestuali influenzano l’esecuzione della componente. Nel primo caso, infatti, in caso di scarsa connettività, la componente SDM deve essere in grado di processare le richieste eseguendo dei modelli predittivi dei dati non ottenibili. Nel secondo caso, invece, la situazione d’emergenza è importante, in quanto le prestazioni richieste alla componente possono essere diverse. Nella richiesta di registrazione, che la componente sottomette alla componente di contesto (per esempio quella eseguita sul medesimo nodo di interfaccia), deve essere esplicitato:

1. La componente che effettua la richiesta di registrazione. La componente deve essere identificabile in modo univoco all’interno del sistema.

2. Le tipologie di informazioni contestuali a cui la componente è interessata.

Il modulo Context Event Register riceve le richieste di registrazione da parte delle componenti Context-Aware, con indicati gli eventi a cui la componente è interessata. L’evento è espresso indicando delle condizioni su un insieme di variabili contestuali (stato della banda di rete, capacità energetica residua di un nodo mobile, etc…). La figura 4.24 descrive la struttura del modulo Context Event Register (CERC), indicando le interazioni corrispondenti.

Figura 4.24: Struttura del Context Event Register.

Le richieste vengono gestite dal Registration Manager (RM), che si occupa di validare la richiesta (verificando che le informazioni contestuali possano essere ottenibili dai provider a disposizione dell’istanza della componente CCC). La richieste validate vengono registrate nell’Event Storage (ES), dove viene memorizzato per ogni componente funzionale l’insieme delle variabili contestuali a cui è interessata. La registrazione per un evento comporta la necessità che il RM richieda, al modulo Context Retrieval Module, l’inizio dell’ottenimento dei dati contestuali relativi alla richiesta di registrazione. L’Event Generation Manager (EGM) si occupa di ricevere le notifiche dal Context Storage Module, relativamente alla presenza di nuove instanze di informazioni di contesto. L’EGM provvede ad identificare le componenti funzionali che sono registrate, per ricevere eventi collegati a quelle informazioni contestuali, ed invia le notifiche alle corrispondenti componenti.

Ovviamente, una componente funzionale può terminare in qualsiasi momento la registrazione per determinati eventi. In questo caso la richiesta deve essere fatta esplicitamente, indicando le informazioni contestuali per cui la componente non vuole più ricevere notifiche. La richiesta viene ricevuta dal Registration Manager, che si occupa di aggiornare le registrazioni nell’Event Storage, cancellando le richieste per le variabili contestuali relativamente a quella componente funzionale. La figura 4.25 descrive informalmente il processo di registrazione per un evento di contesto.

Figura 4.25: Comportamento del Context Event Register.

Tornando al caso particolare della componente Sensor Data Manager, questa si registra presso la componente di contesto del suo nodo di interfaccia, per ricevere informazioni sullo stato della connettività tra i sensori ambientali e il nodo, e per ricevere aggiornamenti sullo stato d’emergenza della propria cella. Con la registrazione, la componente di contesto si prenota per ricevere eventi asincroni rispetto alla sua esecuzione, relativi a questi concetti. In particolar modo verrà notificato un cambiamento del livello di connettività tra un sensore ambientale e il nodo d’interfaccia, oppure nel caso in cui cambi il livello d’emergenza della cella, in modo che la componente possa adattarsi.

4.5 L’adattività nelle componenti funzionali

Nel paragrafi precedenti sono state descritte le componenti funzionali e di contesto, in modo da comprendere gli aspetti di adattività di un sistema complesso, come quello

introdotto nel terzo capitolo. Nel seguito, invece, verrà analizzata in modo più specifico la struttura di una generica componente funzionale, caratterizzando le entità responsabili del processo di adattività.

Come è già stato detto, le componenti funzionali di un’applicazione Context-Aware possono esporre:

• Interfacce Funzionali: sono interfacce di input e di output, relative alle richieste e alle relative risposte delle funzionalità offerte dalla componente.

• Interfacce non Funzionali: nel nostro caso sono interfacce che consentono l’interazione tra la componente funzionale e le componenti di contesto.

Una panoramica della struttura di una componente adattativa è fornita nel dettaglio dalla figura 4.26.

Figura 4.26: Struttura di massima di una generica componente funzionale.

La parte funzionale di una componente è strutturata da un insieme di moduli cooperati, che realizzano certe parti delle funzionalità offerte dalla componente. Ogni modulo può prevedere diverse implementazioni alternative (comportamenti o behaviour). In un certo

istante solo un comportamento può essere attivo per ogni modulo, quello che è utilizzato per servire la richiesta corrente. Nella figura 4.26 sono individuati in grigio i moduli che realizzano il framework di adattività, propri di ogni specifica componente adattiva del sistema. Il framework è caratterizzato da:

1. Adaptation Policy Rules: ogni componente funzionale Context-Aware specifica una politica di adattività, costituita da regole che indicano le reazioni della componente al contesto ambientale. Queste, in particolar modo, specificano gli eventi a cui è interessata la componente e quali reazioni devono essere attivate. Le regole di adattività vengono esplicitate mediante un opportuno formalismo, che indica gli eventi e le reazioni sulla computazione o struttura dei moduli.

2. Adaptation Policy Module: è il modulo responsabile del processo di registrazione alle componenti di contesto. Gli eventi connessi alle regole della politica, stabiliscono delle condizioni su un certo insieme di variabili di contesto. Per esempio un evento può essere un’espressione nella logica del primo ordine di un insieme di predicati, relativi al valore di variabili di contesto. La necessità di determinare quando l’evento si verifica, comporta la registrazione della componente funzionale presso un insieme di Context Control Component, che sono in grado di fornire segnalazioni sul valore di una o più variabili di contesto, in modo da determinare quando un evento si verifica.

3. Component Adaptator Module: si tratta del modulo più complesso del framework di adattività. Il suo compito è duplice:

• Realizzare le modifiche al comportamento di uno o più moduli della componente. La reazione prevede due possibili aspetti: sostituire dinamicamente l’implementazione di un modulo, o di sue parti, con un’altra implementazione associata al nuovo contesto che è stato segnalato, oppure nel riconfigurare la computazione del modulo, per mantenere certi vincoli di qualità del servizio, come le prestazioni in generale.

• Il Component Adaptator Module è inoltre responsabile per la scelta di quando e dove nella computazione fare il processo di adattività, che può

comportare la sostituizione dinamica dell’implementazione di un modulo con un’altra, o la ristrutturazione della computazione corrente. Devono essere scelti dei punti nell’elaborazione che consentano di fare le modifiche, mantenendo la consistenza dei dati fino ad ora prodotti per esempio.

4.5.1 Descrizione iniziale delle politiche di adattività

Ogni componente funzionale esprime la propria adattività mediante un insieme di regole, che sono utilizzate per specificare due aspetti chiave:

1. Gli eventi di contesto a cui la componente è interessata. Gli eventi vengono definiti in base a condizioni e vincoli su determinate variabili di contesto. Gli identificatori delle variabili di contesto devono essere condivisi con le componenti di contesto su cui la richiesta verrà registrata, per cui è necessaria una fase di negoziazione iniziale.

2. Le reazioni corrispondenti alla ricezione degli eventi del primo punto, che possono indicare riconfigurazioni sia delle funzioni che non funzionali.

Le regole di politica di adattività (Adaptation Policy Rules) possono quindi avere una struttura stabilita dal seguente pseudo-codice:

RULE nome_regola ON evento

DO BEHAVIOUR “Modulo_della_Componente->Riconfigurazione” [IF vincolo];

La prima riga stabilisce il nome univoco della regola della componente. La seconda riga, preceduta dalla parola chiave ON, stabilisce l’evento che è precondizione all’attivazione della regola. La terza riga della regola, preceduta dalla parola chiave DO BEHAVIOUR, stabilisce la riconfigurazione sulla componente da eseguire. Oltre a definire le regole che formano la politica di adattività, è necessario definire anche gli

eventi che le regole utilizzano come precondizioni. La definizione di un nuovo evento può seguire un semplice formalismo del tipo:

NEW EVENT nome_evento

CONDITION condizioni_verificate_sull’evento;

La prima riga, con le parole chiave NEW EVENT, stabilisce la dichiarazione di un nuovo evento di contesto con un nome univico nella politica. Questo rappresenta il nome che dovrà essere riportato dopo la parola chiave ON, nelle regole che lo utilizzeranno come precondizione. L’aspetto critico della definizione di un nuovo evento, rappresenta la seconda riga della definizione, ovvero le condizioni relative. Le condizioni rappresentano dei vincoli sul valore di determinate variabili contestuali, i cui identificatori devono essere condivisi con la componente di contesto, o comunque devono essere messi in corrispondenza con dati di contesto acquisibili con le Context Control Component, dopo una fase di negoziazione iniziale.

NEW EVENT low_connectivity_Status

CONDITION bandwidth <= 100 AND deviceType = “PDA”;

Per esempio consideriamo una componente che adatta il proprio comportamento in base al contesto di connettività. Se il livello della rete wireless del dispositivo su cui è eseguita, è “buono”, la componente esegue le sue funzionalità con un’implementazione che utilizza la rete wireless, nel caso contrario, la componente utilizza una diversa implementazione che fa riferimento ad una rete tradizionale:

NEW EVENT Wireless_Active

CONDITION connectivityWirelessStatus >= soglia;

NEW EVENT Wireless_Down

CONDITION connectivityWirelessStatus < soglia;

RULE regola_di_esempio1 ON Wireless_Active

RULE regola_di_esempio2 ON Wireless_Down

DO BEHAVIOUR NetworkModule->WiredBehaviour;

La presenza di queste regole comporta la registrazione da parte della componente funzionale alla componente di contesto, richiedendo il monitoraggio dello stato della variabile “connectivityWirelessStatus”, posta in relazione alla banda di comunicazione della rete wireless utilizzata. Ad ogni cambiamento della variabile, la componente di contesto invia una segnalazione alla componente funzionale. A seguito della segnalazione dal contesto, il modulo Adaptation Policy Module identifica gli eventi che sono verificati, determina le regole attive, e richiede le conseguenti operazioni di riconfigurazione sui moduli della componente, al Component Adaptator Module.