Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

il quadro tecnico

Il contesto nei sistemi informativi: cos’è e perché è sempre più importante

Nei sistemi informativi è sempre più fondamentale distinguere l’informazione utile dal “rumore informativo”, cioè da ciò che non è rilevante per il problema applicativo del momento; in un’era di big data e dispositivi mobili. Ecco le ultime tendenze

07 Mag 2018

Fabio A. Schreiber

DEIB, Politecnico di Milano

Letizia Tanca

DEIB, Politecnico di Milano


Lo sviluppo e l’esercizio di un moderno Sistema Informativo non può oggi prescindere dal contesto nel quale si trova ad operare. Distinguere l’informazione utile dal “rumore informativo”, cioè da ciò che non è rilevante per il problema applicativo del momento, non è facile: un oggetto, una qualsiasi entità informativa o anche reale, possono essere considerati in modo diverso, anche dallo stesso utente, quando questo si trova in diverse situazioni, e cioè in contesti differenti.

Cos’è il contesto in un sistema informativo e le ultime tendenza

Semplificando al massimo, il contesto può essere visto come un insieme di variabili i cui valori possono interessare un attore e influenzarne le azioni, come ad esempio il luogo nel quale ci si trova, l’ora del giorno, il tempo atmosferico, la situazione lavorativa o la compagnia presente; un cambiamento del contesto può infatti causare un cambiamento nella rappresentazione mentale che l’attore si crea della realtà, anche se quest’ ultima non è cambiata.

Nei Sistemi Informativi, il contesto sta assumendo una rilevanza sempre maggiore in ordine a due distinti problemi: i) la necessità di ridurre il rumore informativo generato dalla enorme massa di dati e informazioni – disponibili da una miriade di sorgenti diverse – e spesso non rilevanti rispetto ad una particolare circostanza; ii) la necessità di adattare il comportamento del sistema a fronte di mutate situazioni operative e/o ambientali. Certamente le variabili che rappresentano un contesto possono essere trattate al pari di tutte le altre caratteristiche di un sistema (approccio olistico), ma il fatto di evidenziarle e gestirle in modo separato permette di strutturare le applicazioni in modo chiaro e flessibile, e costituisce la base per la realizzazioni di sistemi autoadattativi [7]. Inoltre, la grande diffusione di dispositivi mobili, quali tablet e smartphone, aumenta la necessità di contestualizzare i dati rispetto al tempo e alla localizzazione delle interrogazioni in modo da ridurre al minimo la quantità di dati trasferiti dalla risposta, risparmiando energia di trasmissione e spazio di memorizzazione.

Gli esempi di contesto nel panorama informativo digitale

Facciamo un paio di esempi: i) una persona ricopre il ruolo di “medico” in un ospedale; come tale ha accesso alla base di dati di tutte le cartelle cliniche, ma il sistema “ritaglia” solamente i dati relativi al suo contesto di lavoro. Un giorno questa persona si ammala e viene ricoverata nel suo stesso ospedale, ma il suo ruolo adesso cambia in quello di “paziente”; tutti i suoi dati personali rimangono invariati, ma il sistema modifica automaticamente la vista sulla base di dati per adattarla alla nuova situazione nella quale, ad esempio, non può accedere alle cartelle cliniche di altri pazienti. ii) Un pendio montano è attrezzato con sensori che permettono di rilevare alcuni parametri ambientali (temperatura, umidità, vibrazioni,…) che vengono inviati ad un centro di controllo dove convergono anche informazioni meteorologiche e quelle dell’Istituto Nazionale di Geofisica.

A un certo momento, vengono rilevate due brevi serie di vibrazioni a distanza ravvicinata: in un contesto “estivo”, e sismicamente “tranquillo”, tali segnali vengono interpretati come dovuti al passaggio di una coppia di caprioli, ma in un contesto “invernale”, e in presenza di segnalazioni di pericolo sismico, gli stessi segnali generano un allarme per il possibile distacco di slavine.

La Figura 1 mostra le fasi della progettazione e l’esercizio di un sistema dipendente dal contesto. Innanzitutto bisogna definire un modello che permetta di rappresentare le componenti del contesto e creare quindi uno schema che comprenda le corrispondenti variabili e le relazioni tra queste. In questa fase i valori delle variabili sono per lo più simbolici (per esempio, classi come “piccolo”, “medio”, “grande”, e non le misure effettive).

I modelli di contesto

Esistono diversi modelli di contesto nella letteratura [1]; in [2] è descritta una struttura ad albero – il Context Dimension Tree (CDT) – costituito da tre insiemi di nodi: le dimensioni del contesto (nodi neri), i valori che possono essere assunti da ciascuna dimensione (nodi bianchi), e infine attributi (nodi quadrati). Nodi bianchi e nodi neri si alternano scendendo lungo l’albero fino ad arrivare al livello di dettaglio richiesto. Un elemento di contesto è dato dalla coppia <dimensione=valore>; un contesto è quindi costituito da un insieme di nodi neri per ciascuno dei quali viene specificato un unico nodo bianco. Gli attributi sono parametri il valore dei quali può essere desunto dinamicamente dall’ambiente, ad esempio mediante sensori, oppure fornito direttamente dall’utente al momento dell’esecuzione. Un attributo può essere utilizzato per rappresentare un numero elevato di valori quando sia poco agevole o impossibile enumerarli tutti (p. e.: valori numerici quali le coordinate GPS) oppure per selezionare istanze specifiche dall’insieme di valori rappresentati da un nodo bianco. Nella Figura 2 è rappresentato un semplice modello di contesto relativo al rischio idrogeologico; in presenza di un’allerta sismica di magnitudine maggiore di 3 e in presenza di una forte nevicata, il rischio di slavine è considerato elevato. Tale valutazione avviene però nella seconda fase, nella quale sono acquisiti dal campo i valori fisici delle variabili sia per quanto riguarda gli elementi del contesto che per quanto riguarda le funzionalità del sistema.

Qualora la combinazione di elementi identifichi un particolare contesto, questo viene abilitato e il sistema inizia a comportarsi con la relativa modalità – per esempio utilizzando una particolare vista ritagliata sulla base di dati [2] oppure attivando una procedura [3]- fino a quando persistono le condizioni specificate (fase 3) .

La figura 3 mostra il codice per l’esempio di rischio slavine citato sopra e la sua interpretazione risulta abbastanza intuitiva: la seconda riga specifica le condizioni nelle quali è vero il contesto “pericolo di slavine”, in tal caso ogni 5 minuti si valuta il valore massimo di una serie di misure di temperatura e di accelerazione, campionate ogni minuto dai sensori, e viene emesso un segnale di allarme.

CREATE CONTEXT avalanche_danger

ACTIVE IF seism_event_mag ³ 3 AND meteo_trend = warming OR meteo_trend = snowing

ON ENABLE:

EVERY 5min SELECT max_temp, max_vibration

SET alarm

SAMPLING EVERY 1min

ON DISABLE:

EVERY 60min SELECT temp, vibration

STOP alarm

SAMPLING EVERY 15min

EXECUTE IF EXIST termometer OR accelerometer OR alarm

REFRESH EVERY 30MIN

Fig. 3

Quando la condizione di contesto, che viene verificata ogni 30 minuti, non è vera o viene a cessare, la frequenza di campionamento viene rallentata, ottenendo un risparmio di energia, e l’allarme viene disattivato. Il linguaggio usato è la versione contestuale di PerLa, linguaggio simile a SQL creato al Politecnico di Milano per la gestione dei dati in sistemi pervasivi [4, 5, 6], con il quale è possibile acquisire e manipolare dati provenienti da sensori e da servizi web.

L’approccio descritto si rivolge in particolare alla contestualizzazione partendo dai dati; altri approcci per ottenere sistemi il comportamento dei quali dipende dal contesto si basano su caratteristiche proprie dei linguaggi di programmazione, quali i COP (Contex-Oriented Programming Languages) [3, 8]. La presenza di fonti eterogenee richiede inoltre operazioni, non sempre semplici, di integrazione dei relativi dati; di ciò si parlerà in un prossimo articolo (vedi: context dimension model).

______________________________________________________________________________________

[1] Bolchini C., Curino C.A., Quintarelli E., Schreiber F.A., Tanca L. – A Data-oriented Survey of Context Models – ACM SIGMOD Record, Vol.36, n. 4, p.19-26, (2007)
[2] Bolchini C., Orsi G., Quintarelli E., Schreiber F. A., Tanca L. – Progettazione dei dati con l’uso del contesto – Mondo Digitale, n. 3, pp.11-26, (2008)
[3] Schreiber F. A., Panigati E. – Context-aware Self Adapting Systems: a Ground for the Cooperation of Data, Software, and Services – International Journal of Next-Generation Computing, Vol. 8, No. 1, pp.32-61, (2017)
[4] Schreiber F. A., Tanca L., Camplani R., Viganò D. – Pushing context-awareness down to the core: more flexibility for the PerLa language– Electronic Proceedings of the 6th PersDB 2012 Workshop (Co-located with VLDB), Istanbul, Aug. 31, pp. 1-6, (2012)
[5] Schreiber F.A., Camplani R., Fortunato M., Marelli M., Rota G. – PerLa: A Language and Middleware Architecture for Data Management and Integration in Pervasive Information Systems – IEEE Transactions on Software Engineering, Vol. 38, n. 2, pp. 478-496, (2012)
[6] http://perlawsn.sourceforge.net/index.php
[7] Mens K. et Al. – Modeling and Managing Context-Aware Systems’ Variability – IEEE Software, Nov/Dec. 2017, pp. 59-63, (2017)
[8] Hirschfeld R., Costanza P., Nierstrasz O. – Context-Oriented Programming – Journal Object Technology, Vol. 7, No. 3, pp. 125-151, (2008)