La struttura di una applicazione riprende quella del modello di ASSIST, formata da un insieme di moduli che cooperano attraverso l’invio di dati su stream. I singoli moduli mantengono tutte le caratteristiche viste nel capitolo 4: possono essere al loro interno sequenziali o paralleli, e sono espressi con gli stessi costrutti. Vista la relativa indipendenza tra moduli, abbiamo deciso di inserire i concetti di adattivit`a e context awareness all’interno di ogni modulo, e non al livello dell’intera applicazione.
Per semplificare la modellazione abbiamo separato la logica dell’applica- zione in “strati” cooperanti, come illustrato in figura 5.1.
• RED: rappresenta lo strato “applicativo”, modella i moduli computa- zionali le interazioni tra essi.
• BLUE: lo strato di gestione del comportamento dell’applicazione, per- mette di introdurre adattivit`a e context-awareness nel modello.
• GREEN: modella le interfacce di contesto, le cui informazioni sono utilizzate dallo strato blu per prendere decisioni.
5.3.1
RED
In questo strato ritroviamo la concezione di applicazione tipica di ASSIST: un grafo generico di moduli eventualmente paralleli collegati da stream, che modellano l’aspetto “computazionale” di una applicazione pervasiva. Defi- nire adattivit`a a livello dei singoli moduli richiede in essi la predisposizione ad eseguire differenti computazioni, adatte a differenti risorse e contesti. Le varie implementazioni di un modulo sono perci`o definite a questo strato, e l’interazione con il BLUE permette di cambiarle in base all’ambiente attua- le. Questa variazione avviene sui singoli moduli in modo indipendente: non vogliamo che la riconfigurazione di un modulo richieda modifiche a quelli a lui collegati, per non incorrere in effetti “a catena”.
5.3.2
BLUE
Vediamo ora lo strato che ci permette di definire i comportamenti adattivi di una applicazione; questo non era presente in ASSIST e, insieme al green, incapsula le principali novit`a di ASSISTANT.
A questo strato l’applicazione `e vista come un insieme di entit`a, i Mana- ger, che implementano le politiche adattive dell’applicazione. Interagiscono con il green, dal quale ricevono eventi per acquisire conoscenza del contesto, e in base a queste informazioni e allo stato dei moduli possono richiedere al red un cambio di comportamento. Abbiamo detto che i differenti compor- tamenti (implementazioni) sono gi`a disponibili nel red, che per`o non decide autonomamente se e quando utilizzarli.
Durante lo sviluppo di ASSISTANT abbiamo pensato ad uno schema “partizionato” per i manager. Concettualmente potremmo avere un unico manager che ha una visione di tutte le informazioni del contesto e comanda tutti i moduli del red, ma abbiamo pensato ad una suddivisione che rispec- chiasse in modo pi`u naturale il concetto di adattivit`a dei singoli moduli. Per questo, come nella figura, abbiamo esattamente un manager per ogni modulo. I manager, a questo punto, hanno bisogno solo di una parte delle informazioni di contesto, quelle richieste per il singolo modulo. Per questo motivo, spesso useremo il termine Manager per indicare il manager del singolo modulo.
Nella figura sono presenti anche connessioni tra manager. Riteniamo quest’ultime fondamentali, nell’ottica di poter definire anche delle politiche adattive per l’intera applicazione; in questo modo un manager pu`o richiedere modifiche dei comportamenti anche sugli altri moduli.
I manager hanno inoltre la possibilit`a di richiedere una modifica dell’allo- cazione dei moduli sulle risorse, necessaria per gestire un ambiente fortemente dinamico come quello del pervasive computing.
Infine assumiamo i manager come entit`a robuste ed affidabili, sempre presenti all’interno dell’applicazione. Per questo potrebbero essere necessarie tecniche di replicazione che ne garantiscano la presenza anche in caso di disconnessioni o guasti.
Le informazioni del contesto e delle risorse arrivano ai manager sotto forma di eventi. In questo modo possiamo unificare la gestione di adattivit`a e context-awareness: in entrambi i casi ci aspettiamo infatti una modifica del comportamento dell’applicazione; possiamo perci`o dire che, in base al tipo di evento ricevuto dal manager, questi chieder`a una modifica dell’applicazione, ottenendo:
• un comportamento adattivo se l’evento era relativo alle risorse attualmente disponibili;
• un comportamento context-aware se l’evento era relativo ad infor- mazioni del contesto.
Ovviamente, perch´e questa tecnica sia funzionale e abbastanza generale per descrivere molte tipologie di applicazioni pervasive, `e necessario avere una astrazione di evento molto potente; prevediamo la possibilit`a di definizione di eventi da parte del programmatore, l’utilizzo di tecniche di inferenza e di algoritmi paralleli per derivare nuovi eventi complessi.
L’utilizzo di eventi rende i moduli concettualmente reattivi, perch´e modifi- cano il loro comportamento al verificarsi di una determinata condizione. Que- sto modello, per quanto potente, non permette la definizione nativa di com- portamenti proattivi (come quelli di Aura), in cui il sistema cerca di prevedere le necessit`a future e su queste previsioni basa il proprio comportamento.
Siamo comunque convinti, anche se questo aspetto `e da studiare e speri- mentare, che questo modello permetta di emulare comportamenti proattivi, tramite la definizione di eventi complessi che possono essere generati, a par- tire dagli eventi ottenuti dal contesto, con meccanismi di previsione analoghi a quelli di Aura; in questo modo, a differenza di Aura, i meccanismi previsio- nali possono essere specificati dal programmatore, offrendo anche maggiore flessibilit`a.
5.3.3
GREEN
Lo strato verde modella “il contesto”, le modalit`a con cui le informazioni catturate dall’ambiente (ad esempio tramite sensori) vengono gestite ed ela- borate per formare gli eventi utilizzati dall’applicazione. Modella anche il flusso di informazioni opposto, ovvero quello dall’applicazione verso gli at- tuatori presenti nell’ambiente. `E quindi definito in funzione del blue, ma pu`o essere utilizzato anche dal red.
Si noti come, infatti, in alcuni casi le informazioni di contesto potreb- bero essere utilizzate anche a livello applicativo, non per gestire la context- awareness, ma come dati da elaborare. Nell’applicazione di gestione delle emergenze, ad esempio, i dati raccolti da un insieme di sensori sono utilizzati per eseguire gli algoritmi previsionali. Allo stesso modo, questo permet- te al programmatore di definire eventi “complessi”, derivati da una post- elaborazione dei dati acquisiti dalle interfacce di contesto. Questo pu`o essere ottenuto semplicemente utilizzando dei moduli (comuni parmod) che tratta- no i dati ricevuti dal contesto come stream, li elaborano e producono nuovi eventi. Vedremo successivamente come introdurre tutte queste possibilit`a all’interno del modello di ASSISTANT.
In questa ottica, gli eventi non vengono prodotti solo dallo strato green, ma anche dal red e (abbiamo visto prima) dallo stesso blue per la coordina- zione di manager. Abbiamo perci`o differenti fonti di generazione di eventi. Tra queste, il green rappresenta sicuramente una parte importante: tutti e soli i dispositivi che non sono “programmati” direttamente dall’utente. Rappresenta infatti la modalit`a con cui le entit`a esterne all’applicazione, e programmate da altri, interagiscono con essa.
Nella nostra ottica le interfacce nel green non sono scritte dal programma- tore, ma piuttosto dai produttori di sensori o dagli sviluppatori del modello.
Spendiamo un’ultima parola per chiarire il significato di questi strati. In- nanzitutto, non sono da confondersi con i livelli. La rappresentazione grafica in questo senso pu`o essere fuorviante, in quanto questi tre si trovano tutti al livello applicativo, e modellano differenti aspetti della stessa applicazione. Non sono implementati uno sopra l’altro, ma cooperano tra loro. In questo senso, il BLUE utilizza i dati ottenuti dal GREEN, ma quest’ultimo non `e il supporto del primo, piuttosto saranno implementati tutti dal supporto di ASSISTANT.