Montalti - "Context aware applications" (2011, master thesys ITA)

ALMA MATER STUDIORUM
`
UNIVERSITA DI BOLOGNA

Seconda Facolt` di Ingegneria
a
Corso di Laurea Specialistica in Ingegneria Informatica

SVILUPPO DI APPLICAZIONI CONTEXT-AWARE
SU SMARTPHONE: UN APPROCCIO AD AGENTI
BASATO SULLA PIATTAFORMA JACA-ANDROID

Elaborata nel corso di: Sistemi Concorrenti e di Rete LS

Tesi di Laurea di: Relatore:
ALESSANDRO MONTALTI Prof. ALESSANDRO RICCI
Co-relatori:
ANDREA SANTI

ANNO ACCADEMICO 2010–2011
SESSIONE II

PAROLE CHIAVE

contest-awareness
mobile computing
smartphone
agent-oriented programming
JaCa-Android

Indice

Introduzione 1

1 Evoluzione dei dispositivi e delle applicazioni mobile 5
1.1 Tipologie di dispositivi mobile . . . . . . . . . . . . . . . . . 6
1.2 Sistemi operativi mobile . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Apple Mac iOS . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Google Android . . . . . . . . . . . . . . . . . . . . . 13
1.2.3 Windows Phone . . . . . . . . . . . . . . . . . . . . . 18
1.3 Smart Mobile Applications . . . . . . . . . . . . . . . . . . . 21

2 Ubiquitous computing e context-awareness 23
2.1 Ubiquitous computing model . . . . . . . . . . . . . . . . . . 24
2.1.1 Storia del modello . . . . . . . . . . . . . . . . . . . . 26
2.2 Il “contesto” . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 I primi approcci al contesto . . . . . . . . . . . . . . 29
2.2.2 Una duplice visione del contesto . . . . . . . . . . . . 30
2.2.3 Deﬁnizione operativa . . . . . . . . . . . . . . . . . . 32
2.2.4 Categorie di contesto . . . . . . . . . . . . . . . . . . 33
2.3 Mobile context-awareness . . . . . . . . . . . . . . . . . . . . 35
2.3.1 I primi approcci alla context-awareness . . . . . . . . 36
2.3.2 Deﬁnizione operativa . . . . . . . . . . . . . . . . . . 37
2.3.3 Caratteristiche delle applicazioni context-aware . . . 38
2.3.4 Applicazione agli smartphone . . . . . . . . . . . . . 42
2.3.5 Sicurezza e privacy in ambito mobile . . . . . . . . . 43
2.4 Alcuni esempi di applicazioni . . . . . . . . . . . . . . . . . 45
2.4.1 ContextPhone . . . . . . . . . . . . . . . . . . . . . . 45
2.4.2 UbiPhone . . . . . . . . . . . . . . . . . . . . . . . . 50

vii

2.5 Ulteriori scenari applicativi . . . . . . . . . . . . . . . . . . . 54
2.5.1 Realt` aumentata . . . . . . . . . . . . . . . . . . . .
a 54
2.5.2 Context-aware gaming . . . . . . . . . . . . . . . . . 55

3 Progettazione di applicazioni context-aware mobile 57
3.1 Un approccio agent-oriented . . . . . . . . . . . . . . . . . . 58
3.1.1 Agenti intelligenti . . . . . . . . . . . . . . . . . . . . 59
3.2 Middleware support . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.1 Architetture mobile ad agenti . . . . . . . . . . . . . 63
3.2.2 La scelta di JaCa-Android . . . . . . . . . . . . . . . 65

4 La piattaforma JaCa-Android 67
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2 La piattaforma JaCa-Android . . . . . . . . . . . . . . . . . 68
4.3 Il modello di programmazione JaCa-Android . . . . . . . . . 72
4.3.1 Programmare gli agenti in Jason . . . . . . . . . . . . 73
4.3.2 Programmare gli artefatti in CArtAgO . . . . . . . . 76
4.3.3 Gestione dei workspaces . . . . . . . . . . . . . . . . 78
4.4 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5 Un caso di studio: LaggerCalendar 81
5.1 Descrizione dello scenario . . . . . . . . . . . . . . . . . . . . 82
5.1.1 Informazioni contestuali richieste . . . . . . . . . . . 83
5.2 Principali scenari applicativi e casi d’uso . . . . . . . . . . . 84
5.3 Architettura dell’applicazione . . . . . . . . . . . . . . . . . 86
5.3.1 Progettazione degli artefatti . . . . . . . . . . . . . . 86
5.3.2 Progettazione degli agenti . . . . . . . . . . . . . . . 88
5.4 Alcuni dettagli implementativi . . . . . . . . . . . . . . . . . 89
5.4.1 Implementazione degli artefatti . . . . . . . . . . . . 89
5.4.2 Implementazione degli agenti . . . . . . . . . . . . . 91
5.5 Scenari reali di funzionamento . . . . . . . . . . . . . . . . . 95
5.6 Considerazioni conclusive . . . . . . . . . . . . . . . . . . . . 98

Conclusioni 99

A Acronimi 101

Ringraziamenti 111

viii

Introduzione

Negli ultimi anni l’avanzamento della ricerca e della tecnologia in ambito
mobile ha portato allo sviluppo di dispositivi sempre pi` potenti dal punto di
u
vista computazionale, equipaggiati con una vasta gamma di sensori (camera,
accelerometro, giroscopio, GPS, ecc...) e capaci di connettersi alla rete
tramite il supporto di tecnologie di ultima generazione (Bluetooth, 2G, 3G,
4G, WiFi). Questo trend, in continua e costante crescita, ha aperto pian
piano la porta a molti nuovi scenari applicativi, abbattendo le barriere legate
alla scarsit` di risorse disponibili sui dispositivi mobile ed aprendo le porte
a
allo sviluppo delle moderne smart mobile application.
Questi apparecchi, eredi dell’ormai obsoleto telefono cellulare, ne man-
tengono per` la caratteristica principale: la portabilit`. Gli smartphones so-
o a
no, infatti, dispositivi molto personali, concepiti per accompagnare l’utente
dovunque egli vada; per questo motivo appaiono particolarmente interes-
santi per la ricerca nell’ambito del pervasive computing, in quanto possono
accedere, grazie ai sensori con i quali sono equipaggiati, ad una miriade di
informazioni riguardanti le attivit` del proprio possessore.
a
Le informazioni contestuali, che vanno dalla posizione attuale dell’uten-
te alla lista degli appuntamenti o dei contatti in rubrica, hanno pian piano
cominciato a giocare un ruolo importante per le applicazioni e per i servizi,
rendendoli sempre pi` personalizzati e “smart”. La context-awareness
u
rappresenta gi` parte integrante delle abituali applicazioni business, ma
a
il trend attuale l’ha ormai battezzata aspetto critico in ambito mobile e
nell’ubiquitous computing, dove i dispositivi hanno il compito di adattare
il proprio comportamento in base ai servizi disponibili nell’ambiente
corrente. Nonostante il fatto che il contesto si stia quindi aﬀermando
come una nozione centrale per questo ambito emergente di applicazioni, il
supporto esplicito alla context-awareness nei linguaggi di programmazione
e negli ambienti di sviluppo mainstream ` ancora decisamente scarso. La
e

1

2

necessit` di schematizzare ed ingegnerizzare lo sviluppo di tale categoria
a
di applicazioni, porta inesorabilmente a cercare astrazioni che riducano
la complessit` di questi sistemi e che ne modellino ad alto livello le
a
caratteristiche, permettendo agli sviluppatori di focalizzare l’attenzione
unicamente sul comportamento specifico dell’applicazione stessa.

L’obiettivo di questa tesi ` quello di investigare un livello di astrazione
e
agent-oriented, considerando in particolare il modello BDI come architet-
tura di riferimento per lo sviluppo di agenti intelligenti al fine di modellare
applicazioni context-aware, dimostrando come le caratteristiche di reatti-
vit`, pro-attivit` e adattamento richieste da questi sistemi possano essere
a a
facilmente soddisfatte tramite l’utilizzo di tali entit` computazionali. No-
a
nostante non sia l’unica soluzione progettuale adottabile, verr` dimostrato,
a
con l’ausilio della letteratura disponibile in materia, come questo approccio
rappresenti un livello di partenza efficace per semplificare e sistematizzare
lo sviluppo di questa categoria di applicazioni.
Nel capitolo 1 viene descritta l’evoluzione dei moderni smartphone, for-
nendo una panoramica generale dei dispositivi e delle piattaforme di svi-
luppo (sistemi operativi mobile) attualmente in commercio; questa breve
introduzione aiuta ad inquadrare le nuove tecnologie a disposizione e le
innovative potenzialit` di cui dispongono, come base di partenza per la
a
progettazione di applicazioni realmente “smart”.
Nel capitolo successivo viene invece posta particolare attenzione alla no-
zione di contesto, introdotta inizialmente nell’ambito dell’ubiquitous compu-
ting e poi arricchita di un nuovo significato con l’introduzione delle tecno-
logie mobile: con l’aiuto della letteratura sono state fornite numerose defi-
nizioni di contesto e di context-awareness, identificando le caratteristiche di
questa tipologia di applicazioni. Inoltre, per comprendere meglio gli aspetti
trattati, sono state presentate due piattaforme di esempio context-aware,
ContextPhone e UbiPhone, che forniscono servizi dipendenti dal contesto.
Nel capitolo 3 ` stata analizzata la programmazione di tale categoria
e
di applicazioni, proponendo un approccio ad agenti intelligenti, secondo il
modello BDI, per catturare ad alto livello le caratteristiche chiave presenta-
te nel capitolo precedente. Particolare fondamentale per poter affrontare e
presentare in pratica lo sviluppo di una applicazione context-aware, ` la ri-
e
cerca di un middleware software che fornisca il giusto supporto per l’utilizzo
questa astrazione concettuale. Tra le piattaforme analizzate in letteratura,

2

3

si ` deciso di sfruttare le potenzialit` del framework JaCa-Android per lo
e a
sviluppo di un’applicazione reale: l’architettura della piattaforma ed il mo-
dello di programmazione ad agenti e artefatti ` stato descritto in dettaglio
e
nel capitolo 4. A supporto di questa analisi, sono stati forniti brevi stralci
di codice relativi ad un semplice esempio di applicazione.
Infine, il capitolo 5 presenta la progettazione e lo sviluppo di una
applicazione context-aware portata come caso di studio per esemplificare
l’approccio finora descritto e per dimostrarne gli effettivi vantaggi.

3

Capitolo 1

Evoluzione dei dispositivi e
delle applicazioni mobile

I dispositivi mobile di oggi sono strumenti multi-funzionali con la capacit` a
di supportare un vastissimo range di applicazioni sia per il business che
per l’utilizzo privato. I PDA e qualsiasi nuova categoria di smart-phones
permettono agli utenti di accedere a numerosissimi servizi, dalle email al-
l’instant messaging, ed hanno una potenza computazionale che permette
loro di svolgere molti compiti spesso demandati all’utilizzo di un computer,
come la modifica di documenti o la navigazione internet. Anzi, i dispositivi
mobile sono spesso visti come un’“estensione” del proprio computer: difatti,
il lavoro svolto fuori dall’ufficio o in viaggio pu` essere sincronizzato in un
o
secondo momento, tramite procedure sempre pi` trasparenti all’utente, con
u
l’ordinario flusso di lavoro nella propria postazione, riflettendo le modifiche
alle nuove informazioni.
L’evoluzione e lo sviluppo di questi dispositivi ha concentrato l’attenzio-
ne su un nuovo paradigma di interazione uomo-macchina, il mobile compu-
ting: questo approccio concettuale assume che i dispositivi computazionali
siano trasportati durante il loro utilizzo standard, seguendo l’utente du-
rante lo svolgimento delle sue normali attivit`. Lo sforzo per superare i
a
vincoli fisici (alimentazione, portabilit`, usabilit`, ecc...) insieme alle nuove
a a
prospettive di utilizzo, ne hanno fatto un settore tecnologico di primaria
importanza sia nell’ambito commerciale che di ricerca negli ultimi anni. I
tre aspetti principali di questo settore, approfonditi nelle sezioni successive,
sono l’hardware, il software e la comunicazione mobile.

5

CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE
6 APPLICAZIONI MOBILE
1.1 Tipologie di dispositivi mobile
Il termine “dispositivo mobile” sta ad indicare un’ampia gamma di stru-
menti elettronici di consumo. Generalmente, ` utilizzato per descrivere
e
dispositivi che si connettono al web, ma risulta comunque una definizione
decisamente ristretta delle reali potenzialit` di questi strumenti. In gene-
a
rale, i dispositivi mobile sono progettati specificatamente per favorire por-
tabilit` ed usabilit` durante gli spostamenti dell’utente, sono tipicamente
a a
soggetti ad un utilizzo intermittente in ambienti inusuali (in contrapposi-
zione al classico desktop), supportando varie tipologie di comunicazione e
scambio di dati. Fanno parte di questa categoria una crescente gamma di
strumenti che vanno dai personal digital assistant agli wearable computers
(letteralmente, computer indossabili), passando per i pi` diffusi notebook e
u
smartphones. Inoltre, viste le crescenti capacit` computazionali e le nuove
a
features offerte da lettori MP3 e fotocamere digitali, spesso anche questi
`
dispositivi vengono annoverati all’interno di questa classe. E necessario co-
munque sottolineare che l’evoluzione tecnologica sta portando lentamente
ad un’integrazione delle funzioni di comunicazione con quelle di computa-
zione, rendendo meno netta la divisione tra queste tipologie di dispositivi.
Le principali categorie di mobile devices dal punto di vista commerciale
sono le seguenti (vedi anche figura 1.1):
• Personal Digital Assistance (PDA): chiamati anche palmari o
pocket computers, sono dispositivi che uniscono elementi di com-
putazione, telefonici/fax, internet e di networking all’interno di un
singolo strumento. Un tipico PDA pu` funzionare da cellulare, fax,
o
browser internet ed agenda personale. A differenza di molti computer
portatili, la maggior parte dei PDA sono provvisti di una particolare
“penna”, in quanto utilizzano la scrittura come input al posto della
consueta tastiera; questo implica quindi che forniscano funzionalità
incorporate per il riconoscimento calligrafico. La categoria dei
PDA annovera comunque anche dispositivi che utilizzano la classica
tastiera come tipologia di input, chiamati in questo caso datapad.
Inoltre, molti PDA possiedono funzioni di riconoscimento vocale che
permette loro di reagire a comandi espressi a voce dagli utenti.

Esempi di PDA: Palm Pilot, Revo, Sony Clie, Hewlett-Packard Jornado,
Casio Cassiopedia, Compaq iPaq, Toshiba Pocket PC e altri.

6

APPLICAZIONI MOBILE 7

(a) PDA (PalmTX ) (b) Smartphone (iPhone) (c) TabletPC (LE1700 )

Figura 1.1: Principali tipologie di smart devices

• Smartphones: sono telefoni di fascia alta che combinano le funzioni
di un personal digital assistant (PDA) con quelle di un telefono cel-
lulare. I modelli attuali generalmente possono essere utilizzati come
media player portatili o fotocamere con touchscreen ad alta risoluzio-
ne. Vengono di solito equipaggiati con una molteplicit` di sensori e
a
possibilit` di connessione web, dal GPS all’accelerometro, dalla con-
a
nettivit` wi-fi all’accesso mobile a banda larga. Il termine “smartpho-
a
ne” ` utilizzato in generale per descrivere telefoni che incapsulano una
e
capacit` computazionale e funzioni di connettivit` molto maggiori di
a a
un telefono standard, nonostante non sia presente una definizione uf-
ficiale delle caratteristiche che distinguono i due apparecchi. Inoltre,
dato il rapido sviluppo tecnologico, spesso telefoni attuali considerati
“standard” possono avere capacit` che superano telefoni considera-
a
ti “smart” qualche anno fa, facendo s` che le definizioni cambino col
ı
tempo.

Attualmente, mentre un telefono standard ` tipicamente basato su
e
un firmware proprietario, uno smartphone solitamente installa un
sistema operativo pi` aperto e completo. I principali esempi di sistemi
u
operativi mobile presenti sul mercato verranno forniti al paragrafo
1.2. Questi sistemi possono essere installati su differenti modelli di
telefoni, che durante il loro utilizzo riceveranno vari aggiornamenti
software, per poter risolvere problematiche di sistema o rimanere al
passo con lo sviluppo software attuale. Inoltre uno smartphone pu` o
lanciare applicazioni sviluppate da terzi, grazie all’utilizzo delle API
messe a disposizione.

7


Esempi di smartphones: Apple iPhone, Samsung Galaxy, HTC Desire,
LG Optimus, Acer Liquid, Sony Ericsson Xperia e altri.

• Tablet PC: un tablet computer, o semplicemente tablet, ` un compu-
e
ter mobile, pi` grande di un telefono cellulare o un PDA, integrato in
u
un touch-screen a schermo piatto. Tipicamente, la forma primaria di
input di questo dispositivo ` il tocco dello schermo, per questo privile-
e
gia l’utilizzo di tastiere virtuali o digital pen piuttosto che una tastiera
fisica. Il termine “tablet personal computer” si deve alla Microsoft,
che intorno agli anni 2000 ha cercato di definire ed introdurre questo
dispositivo, anche se la reale percezione del tablet come nuova classe
di dispositivi di consumo ` stata raggiunta con la release di iPad da
e
parte di Apple nel 2010. Negli ultimi anni, il tablet sta conquistando
una fascia di mercato sempre maggiore, attirando l’attenzione di molti
produttori e sviluppatori, configurandosi come l’anello di congiunzio-
ne tra i pi` attuali smartphone ed i personal computers: sempre pi`
u u
spesso vengono equipaggiati di sistemi operativi all’avanguardia, con
caratteristiche molto simili ai relativi OS dell’una o dell’altra fascia di
dispositivi.

Esempi di tablet PC: Apple iPad, Samsung Galaxy Tab, Toshiba
Portege, Fujitsu Lifebook, Motion Computing, IBM Thinkpad.

1.2 Sistemi operativi mobile
Un sistema operativo mobile, chiamato anche mobile OS, ` un sistema ope-
e
rativo che comanda un dispositivo mobile, con caratteristiche simili ai si-
stemi operativi standard installati su un personal computer. Essendo per` o
installati su dispositivi con caratteristiche e vincoli sostanzialmente diver-
si, presentano alcune differenze: sono generalmente pi` leggeri dal punto
u
di vista della computazione, in quanto installati su apparecchi con capa-
cit` ed autonomia relativamente limitate, e devono supportare differenti
a
forme di input (touch-screen, digital pen, ecc..) e funzioni di connettivit` a
(collegamento a reti mobili, Wi-Fi, GPS, ecc...).

8


1.2.1 Apple Mac iOS

iOS (conosciuto anche come iPhone
OS prima di giugno 2010) ` il sistema
e
operativo mobile progettato da Apple.
Sviluppato originariamente per iPho-
ne, ` stato poi esteso per supportare
e
i principali dispositivi mobili Apple,
come iPod Touch, iPad e Apple TV.
Apple non permette attualmente la li-
cenza per l’installazione di iOS su di-
spositivi hardware realizzati da terzi;
allo stesso modo le applicazioni posso-
no essere realizzate su questa piatta-
forma unicamente utilizzando le mo-
dalit` e le API messe a disposizione
a
da Apple; per questi motivi, iOS vie-
ne considerato, di fatto, un sistema Figura 1.2: Schermata e logo
closed, in contrapposizione al nuovo di Apple iOS
sistema operativo Android.

Storia
Il sistema operativo fu svelato, insieme all’iPhone, alla MacWorld Confe-
rence & Expo 1 il 9 gennaio 2007, e lanciato commercialmente nel giugno
dello stesso anno. All’inizio, la strategia di marketing di Apple non aveva
presupposto un nome per questo sistema, limitandosi a riferirsi a questo
come una versione particolare di OS X. Inoltre, in questa prima versione,
non erano supportate applicazioni sviluppate da terzi. Solo nel febbraio
2008 Apple mise a disposizione degli sviluppatori un apposito Software De-
velopment Kit (SDK) per lo sviluppo di applicazioni su iPhone, rilasciando
il mese successivo una nuova versione del sistema chiamato “iPhone OS ”.
Solo dopo il suo utilizzo anche su altri dispositivi come iPod Touch e iPad,
1
il MacWorld Conference & Expo ` una ﬁera che si svolge annualmente nelle prime
e
settimane di gennaio negli Stati Uniti, con conferenze dedicate alla piattaforma Apple
Macintosh.

9


nel giugno 2010 Apple ha rinominato iPhone OS solamente “iOS ”, licen-
ziando il brand da Cisco che da oltre dieci anni utilizzava lo stesso nome
per il sistema operativo installato sui suoi router.

Interfaccia utente
L’interfaccia utente di iOS ` basata sul concetto di manipolazione diretta,
e
utilizzando gesture multi-touch: in questo modo ` possibile controllare
e
alcuni elementi grafici, come bottoni, slider ed interruttori, che veicolano
l’interazione con il dispositivo. La risposta immediata agli input dell’utente
fornisce un’interfaccia fluida per l’interazione, che pu` avvenire tramite il
o
semplice tocco o con l’utilizzo di varie gesture supportate (come swipe, tap,
pinch e reverse pinch), che in base al contesto in cui sono eseguite assumono
un differente significato. Inoltre, gli accelerometri interni sono utilizzati da
alcune applicazioni per rispondere allo shaking (letteralmente, scuotimento)
del dispositivo o alla rotazione in tre dimensioni, che assumono la funzione
di input alternativo.

Figura 1.3: Architettura di iOS

10


La piattaforma iOS
Come sistema operativo, iOS ` derivato da Mac OS X, con cui condivide
e
la fondazione sul sistema Darwin2 , per cui ` di fatto un sistema basato su
e
architettura Unix per natura.
Dal punto di vista architetturale, iOS presenta quattro livelli di astra-
zione, mostrati in figura 1.3: il livello Core OS, il livello Core Services, il
Media Layer e il livello Cocoa Touch [2]. Ai livelli pi` bassi ci sono i servizi
u
fondamentali e le tecnologie su cui si basano tutte le applicazioni; pi` inu
alto, i livelli contengono tecnologie e servizi pi` sofisticati.
u

1. Cocoa Touch layer: contiene i framework chiave per lo sviluppo
di applicazioni su iOS. Questo livello definisce le infrastrutture
base delle applicazioni ed il supporto per tecnologie chiave come
il multi-tasking ed il multi-touch, insieme ad altri servizi di alto livello.

Tra i servizi implementati citiamo: il multitasking, il supporto per la
stampa, la protezione dei dati, l’Apple push notification, il supporto
per il riconoscimento delle gestures, il file sharing ed il peer-to-peer.
Tra i framework a disposizione, invece: l’Address Book UI, l’Event
Kit UI, il Game Kit, il Map Kit ed il Message UI.

2. Media layer: contiene le tecnologie grafiche, audio e video orientate
allo sviluppo di applicazioni che focalizzano l’attenzione sulla espe-
rienza multimediale dell’utente su dispositivo mobile. Le primitive
all’interno di questo livello, infatti, aiutano lo sviluppatore a proget-
tare applicazioni con alti standard audio e visivi, oltre che fornire il
supporto per lo streaming del segnale su Apple TV o altri ricevitori
non proprietari (tramite la tecnologia AirPlay).

Tra i framework contenuti in questo livello, citiamo: l’Assets Library,
il Core Audio, il Core Graphics, il Core MIDI, il Core Video, il Media
Player, l’OpenAL e l’OpenGL.
2
Darwin ` un sistema operativo POSIX-compliant e open-source, rilasciato da Apple
e
nei primi anni 2000. Sviluppato in C e C++, ` costituito principalmente da Apple, ma
e
con contributi fondamentali da altri progetti software open-source (come NeXTSTEP,
`
BSD e altri). E compatibile con le Single Unix Specification e le applicazioni Unix POSIX.

11


3. Core Services layer: contiene i servizi fondamentali del sistema,
che tutte le applicazioni utilizzano. Anche se uno sviluppatore non
utilizza direttamente queste primitive, molti dei servizi principali del
sistema sono realizzati basandosi sulle tecnologie contenute in questo
livello.

Tra le funzioni di alto livello, sono implementati: i Block Objects,
SQlite ed il supporto XML.
Tra i framework a disposizione, abbiamo invece: l’AddressBook, il
Core Data, il Core Foundation, il Core Location, il Core Media, il
Core Telephony, l’Event Kit, il Foundation, il Mobile Core Services, il
System Configuration, il Quick Look e lo Store Kit.

4. Core OS layer: contiene tutte le feature di basso livello su cui sono
basate tutte le altre tecnologie ed i framework citati in precedenza.
Nel caso si debba gestire la sicurezza o l’interfacciamento con dispo-
sitivi hardware esterni, ` necessario utilizzare i framework definiti in
e
questo livello.

I framework principali che costituiscono il Core OS sono:
l’Accelerate, l’External Accessory, il Security ed infine il System.

Ovviamente, un progettista pu` decidere, in base alle proprie necessit`,
o a
di utilizzare servizi e framework di alto livello, piuttosto che viceversa: i
framework di alto livello introducono astrazioni che rendono la scrittura
del codice pi` agile in quanto incapsulano funzioni molto complesse; in
u
ogni caso i livelli a pi` bassa astrazione rimangono comunque disponibili a
u
quegli sviluppatori che volessero gestire in completa autonomia ogni aspetto
di interfacciamento con il sistema.

Development e deployment in iOS
Apple fornisce per gli sviluppatori iOS SDK che fornisce tutte le inter-
facce, gli strumenti e le risorse per sviluppare applicazioni iOS sul proprio
computer Macintosh Intel-based.

12


Le librerie condivise e le risorse sono organizzate in pacchetti denomi-
nati frameworks, organizzati a loro volta in livelli gerarchici di astrazione,
come descritto nella sezione precedente. Visto che iOS ` basato su piatta-
e
forma Unix, molte delle tecnologie che compongono il livello Core OS sono
direttamente derivate da tecnologie open-source.
Altri componenti importanti dell’SDK sono:

• Strumenti XCode: contengono gli strumenti necessari per sviluppare
un’applicazione su iOS, incluse alcune principali applicazioni: l’am-
biente di sviluppo XCode, l’editor visuale Interface Builder ed il
tool di debugging Instruments.

• iOS Simulator: un’applicazione che simula lo stack di iOS su sistema
operativo Mac OS X, permettendo il test in locale delle applicazioni.

• iOS Developer Library: la documentazione concettuale di tutte le
tecnologie utilizzate.

1.2.2 Google Android

Android ` un sistema operativo per
e
dispositivi mobile come smartphone e
tablet, sviluppato dalla Open Handset
Alliance guidata da Google Inc. La
maggior parte del codice scritto per
la piattaforma Android ` stato reso
e
disponibile sotto Apache licence, una
licenza software ad utilizzo gratuito:
per questo motivo, il sistema ` di fat-
e
to open e, nonostante sia stato lan-
ciato sul mercato da minor tempo ri-
spetto ad altri sistemi operativi, van-
ta gi` una forte presenza di sviluppa-
a
tori che hanno esteso le funzionalit` a
del sistema tramite la progettazione Figura 1.4: Schermata e logo
di apps. di Google Android

13


Storia
La piattaforma Android ` un prodotto della Open Handset Alliance, un
e
gruppo di organizzazioni che collaborano con lo scopo di sviluppare un siste-
ma mobile per un telefono all’avanguardia. Questa organizzazione, guidata
da Google, include pi` di 80 compagnie tra cui operatori mobili, produttori
u
di dispositivi portatili, produttori di componenti, sviluppatori software e
compagnie di marketing.
Il primo dispositivo mobile sul mercato equipaggiato con Android ` sta-
e
to il G1 realizzato da HTC e fornito da T-Mobile nel 2007. Questo telefono
` stato disponibile solo dopo un anno di speculazioni, in cui sono state rese
e
disponibili solo alcune versioni incrementali di un SDK, come strumento
principale di sviluppo. Quando la data di lancio del G1 si avvicin`, il team
o
di Android distribu` una versione 1.0 dell’SDK e le applicazioni per questa
ı
piattaforma cominciarono realmente ad emergere. Per incentivare l’inno-
vazione, Google ha sponsorizzato due contest chiamati “Android Developer
Challenge”, dove sono stati messi a disposizione milioni di dollari per in-
crementare lo sviluppo di applicazioni innovative su piattaforma Android.
Qualche mese dopo il G1, fu lanciato anche l’Android Market, permettendo
agli utenti di visionare e scegliere le applicazioni direttamente dai propri
telefoni.

La piattaforma Android
Android consiste in un kernel basato su Linux, con un middleware, librerie
e API scritti in C; inoltre sono fornite applicazioni software lanciate
all’interno di un framework applicativo che include librerie compatibili con
Java e basate su Apache Harmony. Android utilizza una macchina virtuale
chiamata Dalvik virtual machine con compilazione just-in-time per lanciare
applicazioni compilate in linguaggio Java. I layer software che costituiscono
la piattaforma sono presentati in ﬁgura 1.5 [9].

1. Applicazioni: Android viene fornito di un set di applicazioni stan-
dard (dette anche core applications), tra cui client email, gestore SMS,
calendario, mappe, browser, contatti e altri. Tutte queste applicazio-
ni (oltre ovviamente a quelle scritte da terzi) utilizzano il linguaggio
Java.

14


2. Application Framework: rendendo disponibile una piattaforma di
sviluppo aperta, Android offre agli sviluppatori la possibilit` di crea-
a
re applicazioni estremamente interessanti ed innovative: i progettisti,
infatti, hanno completo accesso alle API dello stesso framework utiliz-
zato dalle core application, potendo cos` sfruttare al meglio l’hardware
ı
del dispositivo mobile. L’architettura delle applicazioni ` progettata
e
per favorire il riutilizzo dei componenti ed ogni applicazione che pub-
blica i servizi implementati pu` essere a sua volta utilizzata da altre
o
per sviluppare funzioni pi` complesse (in base comunque ai vincoli di
u
sicurezza forzati dal framework stesso).
Sottesi ad ogni applicazione, ci sono un insieme di sistemi e servizi,
tra cui:
• Un corposo set di Views (viste) che possono essere utilizzate per
la progettazione di un’applicazione: tra queste viste sono incluse
griglie, liste, text box, bottoni ed altri componenti;
• Content Providers che permettono alle applicazioni di ac-
cedere a dati di altre applicazioni, oppure condividere i
propri;
• Un Resource Manager che fornisce l’accesso a risorse come
grafiche, file di layout, ecc...
• Un Notification Manager che d` la possibilit` ad ogni ap-
a a
plicazione di visualizzare notifiche personalizzate sulla barra di
stato;
• Un Activity Manager che gestisce il ciclo di vita delle
applicazioni e fornisce uno stack di navigazione comune.
3. Librerie: include una serie di librerie scritte in C/C++ utilizzate
da vari componenti del sistema; queste estensioni sono rese disponi-
bili agli sviluppatori tramite l’Android Application Framework. Alcu-
ne delle librerie principali sono elencate di seguito: Media Libraries,
Surface Manager, SGL, 3D libraries, SQLite e FreeType.
4. Kernel Linux: Android si basa sulla versione 2.6 di Linux per i servizi
di sistema come la sicurezza, il management della memoria, lo stack
di rete e il modello dei driver. Il kernel agisce inoltre da abstraction
layer tra l’hardware ed il resto del sistema.

15


Figura 1.5: Architettura di Android

Come accennato in precedenza, le applicazioni Android sono scritte in
linguaggio Java e per questo lanciate su una virtual machine: non si tratta
in questo caso della classica Java Virtual Machine (JVM), ma di un compo-
nente open-source chiamato Dalvik virtual machine. Questa tecnologia
` stata scritta con l’obiettivo di poter lanciare pi` istanze di virtual machine
e u
efficientemente sullo stesso dispositivo: ogni applicazione (contenuta in un
file eseguibile .dex, ottimizzato per un utilizzo minimo della memoria) viene
infatti lanciata all’interno di un’istanza della Dalvik VM, che a sua volta
risiede all’interno di un processo Linux gestito dal kernel (come mostrato
in figura 1.6). La Dalvik VM si basa sul kernel Linux per le funzionalit` di a
basso livello come il multi-tasking ed un’efficiente gestione della memoria.

Development e deployment in Android

Il requisito principale per progettare applicazioni su piattaforma Android
` l’SDK Android fornito da Google. E’ disponibile inoltre un plugin,
e
denominato “Android Developer Tool ”, che permette di sviluppare appli-
cazioni all’interno dei principali ambienti di programmazione Java, come

16


Figura 1.6: Esecuzione di un’applicazione Android

ad esempio l’IDE Eclipse3 : questi tool di sviluppo forniscono un ambiente
Java sensibile al contesto, oltre che aiuto e suggerimenti lungo la program-
mazione; una volta che il codice ` stato compilato correttamente, l’Android
e
Developer Tool si occupa del corretto impacchettamento dei dati e della
compilazione del ﬁle manifest AndroidManifest.xml, necessario per ogni
applicazione.
All’interno dell’SDK, sono presenti anche vari tool command-line per
il debugging delle applicazioni realizzate; i principali e pi` comunemente
u
utilizzati sono:
• Android Emulator: questo emulatore permette di testare le proprie
applicazioni su un device virtuale oppurtunamente conﬁgurato, per
valutarne performance e corretto comportamento;
• Android Debug Bridge: consiste in due programmi, uno server e
l’altro client-side, per la connessione al telefono da remoto.
`
E importante sottolineare che, data la versatilit` dell’utilizzo di Java
a
come linguaggio di programmazione, lo sviluppo di applicazioni Android
pu` avvenire su tutti i principali sistemi operativi disponibili (Microsoft
o
Windows, Mac OS X, Linux).
3
disponibile all’indirizzo http://www.eclipse.org.

17


1.2.3 Windows Phone
Windows Phone (prima conosciuto
col nome Windows Phone 7 Series) ` e
il sistema operativo mobile sviluppato
da Microsoft ed il successore della
piattaforma Windows Mobile. Con
questo nuovo sistema, Microsoft oﬀre
un’interfaccia utente rinnovata con
l’utilizzo del linguaggio di design
Metro, che si occupa sia dell’inte-
grazione con i servizi Microsoft e
con quelli sviluppati da terzi, sia
dell’utilizzo performante dell’hard-
ware di cui dispone il dispositivo.
Windows Phone richiede alcuni
requisiti hardware minimi per il suo
corretto funzionamento, ma, come
Android, ` progettato per funzionare
e
su diﬀerenti piattaforme e chipset
hardware. Per questo motivo ` stato
e
scelto come linguaggio principale
di programmazione C#, in quanto
rende possibile una compilazione run-
time tramite “Common Language Figura 1.7: Schermata e logo
Runtime” (CLR, una virtual machine di Windows Phone
proprietaria).

Storia
Il lavoro per una sostanziale update del precedente Windows Mobile inizi` o
nei primi mesi del 2004 sotto il nome di “Photon”, ma visti gli scarsi risultati
iniziali il lavoro fu cancellato. Successivamente, nel 2008, Microsoft riun` ı
un team per lo sviluppo di un nuovo sistema operativo mobile e nel 2009
fu realizzato Windows Phone, anche se alcuni ritardi costrinsero Microsoft
a sviluppare Windows Mobile 6.5 come release provvisoria.

18


Il nome Windows Phone 7 rappresenta di fatto il rinnovamento del vec-
chio OS mobile di Microsoft Windows Mobile : il 5 febbraio 2010 al Mobile
World Congress 2010 di Barcellona, Microsoft svel` per la prima volta Win-
o
dows Phone e ne rivel` altri dettagli il mese successivo al MIX 2010. La
o
versione finale dell’SDK fu resa disponibile per gli sviluppatori da settembre
dello stesso anno.
Nell’ottobre del 2010 sono stati lanciati sul mercato dieci dispositivi
che montano Windows Phone, fabbricati da HTC, Dell, Samsung e LG.
Successivamente, nel febbraio del 2011 ` stata annunciata una partnership
e
tra Nokia e Microft, per far diventare Windows Phone il sistema operativo
primario sui dispositivi realizzati dalla casa finlandese.

Architettura
L’architettura di Windows Phone 7 ` basata sul kernel Windows Embedded
e
CE 6.0 ed ` logicamente divisa in tre livelli principali: i componenti relativi
e
al kernel-mode ed al user-mode (il livello software), oltre ai componenti
hardware [21]. Il diagramma in figura 1.8 mostra i componenti primari
dell’architettura.

Figura 1.8: Architettura di Windows Phone

19


1. Componenti Kernel-mode: il kernel di Windows Phone OS 7.0
fornisce i servizi fondamentali del sistema, come la gestione della me-
moria, dei processi e dello scheduling dei threads. Gli obiettivi princi-
pali di questo sistema sono le performance, la sicurezza e la robustezza
della piattaforma.

2. Componenti User-mode: i principali componenti che fanno parte
di questo livello sono:

• l’host dei servizi (file ServicesD.exe) che ` sostanzialmente un
e
processo che gestisce i servizi di lunga durata che non hanno
bisogno di accesso diretto all’hardware o al kernel (librerie DLL
dinamiche); ` stato utilizzato un kernel unificato dove ogni sotto-
e
sistema ` caricato dinamicamente come una DLL: l’utilizzo di
e
questa tipologia di kernel migliora le performance generali poich´
e
ogni chiamata di funzione pu` essere eseguita senza chiamate
o
incrociate ai processi.
• l’user-mode driver host (file UDevices.exe) che contiene tutti i
driver utente a cui ` consentito un accesso ristretto alla memoria,
e
in modo da prevenire azioni potenzialmente dannose;
• la shell di Windows Phone 7.0 (file TelShell.exe) che controlla
l’interfaccia utente del dispositivo;
• il phone dialer (file Cprog.exe) che ` un’applicazione che gestisce
e
i servizi di chiamata, in quanto al suo interno sono implementate
le funzioni per la ricezione e l’invio di una telefonata;
• l’application platform che rappresenta la piattaforma su cui tutte
le applicazioni sviluppate per Windows Phone risiedono.

3. Hardware: l’hardware ` costituito da tutti i sensori e le tecnologie
e
con cui ` equipaggiato lo smartphone su cui ` stato installato il si-
e e
stema; Windows Phone ` in grado di gestire questi elementi in base
e
all’attuale configurazione del dispositivo, adattando la sua esecuzione.
`
E comunque richiesta una configurazione hardware minima per una
corretta esecuzione.

20


Development e deployment in Windows Phone

Qualsiasi applicazione si intenda sviluppare, il punto di partenza della pro-
gettazione ` la Windows Phone Application Platform [22]: questa
e
piattaforma definisce i componenti centrali comuni a tutti gli sviluppatori.
Nello specifico, l’Application Platform contiene tutti gli strumenti per lo
sviluppo, per l’esecuzione runtime, per la progettazione di servizi e cloud-
computing. Oltre alla piattaforma base, ` possibile valutare estensioni per
e
la progettazione di funzionalit` accessorie.
a
L’ambiente di sviluppo primario per la progettazione di un’applicazione
per Windows Phone ` Microsoft Visual Studio 2010, combinato con
e
alcuni tool specifici, come il Windows Phone Emulator, che fornisce un
supporto per definire, progettare, effettuare il debugging ed il deployment
delle proprie applicazioni.

1.3 Smart Mobile Applications
Le piattaforme operative introdotte in precedenza forniscono nuove ed in-
novative funzionalit` per lo sviluppo di applicazioni di nuova generazione:
a
del resto, l’avanzamento tecnologico ha messo a disposizione degli sviluppa-
tori dispositivi sempre pi` potenti dal punto di vista computazionale e dei
u
sensori con cui vengono equipaggiati, aumentandone esponenzialmente gli
ambiti di utilizzo. Per questo motivo, le tipologie di applicazioni supportate
da questi dispositivi si sono evolute profondamente negli ultimi anni, grazie
alla possibilit` di poter disporre ed elaborare nuove informazioni ottenute
a
dal contesto dell’utente o direttamente dalla rete.
Da un lato, quindi, le applicazioni realizzate per questa tipologia di
dispositivi di nuova generazione hanno accesso a nuove fonti di dati che
permettono loro di avere un comportamento smart, letteralmente “intelli-
gente”, capace di adattarsi alla situazione esterna realizzando funzionalit` a
innovative. Dall’altro, l’introduzione di questi nuovi scenari introduce nuove
sfide legate allo sviluppo di applicazioni mobile, vista la difficolt` crescen-
a
te. Queste applicazioni avranno quindi a che fare con problematiche legate
alla concorrenza tra processi, all’interazione asincrona con differenti servizi
(web-services, social networks, client email) e dovranno presentare un com-
portamento incentrato sull’utente, indirizzato dalle informazioni specifiche

21


sull’attuale contesto (la posizione geografica del dispositivo, la presenza di
connettivit` nelle vicinanze, ecc...).
a
Questi nuovi scenari hanno spinto molti brand ed aziende a buttarsi sul
mercato mobile, realizzando le proprie applicazioni diffuse spesso a titolo
gratuito, con lo scopo di promuovere e migliorare il proprio servizio o sem-
plicemente pubblicizzare la propria azienda. La concorrenza che si ` venuta
e
a creare in questo settore di sviluppo, ha quindi portato a nuovi standard
per lo sviluppo di applicazioni smart, dando notevole importanza all’usa-
bilit` ed all’interfaccia grafica, oltre agli aspetti implementativi menzionati
a
in precedenza. Un’interfaccia intuitiva ed accattivante rende utilizzabile
un’applicazione molto sofisticata a tutti gli utenti, rivolgendosi quindi ad
un insieme di clienti pi` vasto e recettivo. Inoltre, nell’ottica di un merca-
u
to fortemente saturo e competitivo, questo aspetto assume un’importanza
commerciale pi` spiccata, oltre che prettamente funzionale.
u

22

Capitolo 2

Ubiquitous computing e
context-awareness

Negli ultimi anni, uno dei principali filoni di ricerca relativi all’interazione
uomo-macchina (human-computer interaction, o HCI ) ` stato l’esplorazione
e
di nuove forme di interazione ottenute unendo le nuove tecnologie sviluppa-
te con il mondo fisico in cui viviamo e lavoriamo. Questo campo di ricerca
ha assunto negli anni molte denominazioni, ciascuna focalizzata su un par-
ticolare aspetto o modello di interazione (ubiquitous computing, pervasive
computing, context-aware computing, ecc...). Al di l` della nomenclatura
a
utilizzata, l’idea centrale rimane invariata: seguendo il trend attuale di svi-
luppo di dispositivi low-cost e low-power, l’ubiquitous computing propone
un futuro digitale nel quale la computazione sia incorporata nella struttu-
ra del mondo intorno a noi. In questo mondo, l’esperienza primaria della
computazione non avviene pi` attraverso i tradizionali desktop computers,
u
ma piuttosto con una serie di dispositivi computazionalmente avanzati: se-
condo questa visione, il mondo intorno a noi pu` diventare l’interfaccia per
o
la computazione e le possibilit` di interazione diventano molteplici.
a
Questa visione del futuro sviluppo tecnologico porta con s´ alcune pro-
e
blematiche relative all’ambito di ricerca. In particolare, ` lecito chiedersi
e
quanto la computazione possa essere resa “sensibile” e possa adattarsi di-
namicamente alle variazioni dell’ambiente fisico o sociale attorno ad essa.
Quando una persona parla con un’altra, entrambe hanno la possibilit` di a
utilizzare informazioni circostanziali implicite (o contesto) per ampliare la
comunicazione. Questo meccanismo risulta particolarmente impoverito nel-

23

CAPITOLO 2. UBIQUITOUS COMPUTING E
24 CONTEXT-AWARENESS

la tradizionale forma di interazione per la computazione, viste le metodolo-
gie per fornire input alle macchine; per questo motivo, nella maggior parte
dei casi, i computer non hanno la capacit` di sfruttare al massimo il contesto
a
attorno a loro.
Lo scenario appena descritto pone l’accento sul concetto di contesto
e sul ruolo centrale che assume in questo ambito di ricerca. Miglioran-
do l’accesso dei computer al contesto, possiamo arricchire l’interazione
uomo-macchina e rendere possibile lo sviluppo di servizi nuovi e funzionali.
Soprattutto in questa era tecnologica in cui la computazione si sta spostan-
do “off the desktop” (cio` lontano dai soli personal computer, trasferendosi
e
in vari dispositivi disseminati nel mondo fisico), l’importanza di adattare la
computazione alle informazioni ottenute dall’ambiente circostante risulta
di centrale importanza.

Per poter utilizzare al meglio questa fonte di informazioni, bisogna in-
nanzitutto comprendere cosa si intenda esattamente per contesto e come
debba essere utilizzato, in modo da scegliere unicamente le informazioni
utili per l’applicazione o il servizio che si desidera sviluppare e in modo da
supportare in maniera corretta e coerente le reazioni a cambiamenti dell’en-
vironment locale. Per questo motivo, partendo dal modello dell’ubiquitous
computing, di seguito verr` definito e caratterizzato il concetto di contesto,
a
discutendone la particolare importanza nell’applicazione all’ambito mobile.

2.1 Ubiquitous computing model
L’ubiquitous computing ` un modello di interazione uomo-macchina in
e
cui la computazione delle informazioni ` stata profondamente integrata ne-
e
gli oggetti e nelle attivit` della vita quotidiana. Durante lo svolgimento
a
ordinario delle proprie attivit`, la persona che “utilizza” l’ubiquitous com-
a
puting sfrutta numerosi dispositivi computazionali simultaneamente, senza
per forza essere consapevole del loro utilizzo.
Questo modello ` generalmente considerato l’evoluzione del desktop com-
e
puting, in cui l’utente individuale aziona consciamente una singola apparec-
chiatura per uno scopo specifico. Pi` formalmente, l’ubiquitous computing
u
` definito come “macchine che vengono inserite nell’ambiente umano invece
e
che forzare l’uomo ad entrare nel loro”, sottolineando la possibilit`, durante
a

24

CONTEXT-AWARENESS 25

ogni nostra attivit`, di accedere a capacit` elaborative per soddisfare ogni
a a
necessit`, in maniera pressoch´ trasparente.
a e
Il paradigma dell’ubiquitous computing viene anche descritto come per-
vasive computing, ambient intelligence, ecc... dove ognuno di questi termini
enfatizza aspetti leggermente differenti. In generale, utilizzando il termine
ubiquitous computing si vogliono privilegiare gli aspetti legati alla elevata
mobilit` e pervasivit` della capacit` elaborativa nell’ambiente fisico (come
a a a
mostrato nel prospetto in figura 2.1).

Figura 2.1: Aspetti principali dell’ubiquitous computing

In base alle definizioni fornite finora, possiamo riassumere di seguito le
caratteristiche pi` importanti di questo modello computazionale:
u

• Trasparenza nell’interazione: soprattutto in ambiente mobile, l’in-
terazione uomo-macchina deve superare il semplice uso di tastiera e
mouse, utilizzando interfacce non convenzionali che aiutino l’utente.
A questo scopo, la ricerca ha portato allo sviluppo di strumenti in
grado di riconoscere la scrittura, i gesti e la voce.

• Conoscenza del contesto: questo grado di conoscenza permette
all’applicazione di sapere dove, quando e perch´ un’azione ` stata
e e
intrapresa e di utilizzare questa conoscenza (spesso implicita) per
completare nuovi compiti.

25


• Cattura automatica delle esperienze: i dispositivi devono avere
la capacit` di memorizzare, gestire e rivedere le esperienze che acca-
a
dono durante il loro utilizzo. Questo tipo di dispositivi devono quindi
avere la possibilit` di memorizzare un grande numero di informazio-
a
ni, immagini e commenti, e possono essere riutilizzati in momenti
successivi.

Tra gli aspetti principali presentati finora, si pu` notare come sia gi`
o a
emersa la profonda importanza della conoscenza del contesto per il para-
digma dell’ubiquitous computing: questa caratteristica, approfondita mag-
giormente in seguito, render` possibile non solo l’adattamento del compor-
a
tamento delle applicazioni in base a quello che succede intorno a loro, ma
sar` la spinta principale per la previsione delle necessit` dell’utente stesso.
a a

2.1.1 Storia del modello
Il termine ubiquitous computing ` stato coniato da Mark Weiser intorno al
e
1988, durante la docenza come chief technologist (ingegnere capo), presso il
Palo Alto Research Center (PARC) della Xerox1 .
Riconoscendo che l’estensione della potenza della computazione agli
scenari quotidiani avrebbe necessitato della conoscenza di fenomeni sociali,
culturali e psicologici oltre il proprio ambito, Weiser fu influenzato da
molte discipline lontane dalla computer science, fra cui filosofia, feno-
menologia, antropologia, psicologia, post-modernismo e sociologia della
scienza. Come da lui dichiarato, “l’ubiquitous computing d` il nome alla
a
terza era tecnologica: all’inizio sono stati costruiti i mainframes, grandi
e costosi computers condivisi da molte persone; fino ai primi anni del
nuovo millennio ` stata la volta dell’era del personal computer, in cui
e
uomo e macchina interagivano tra loro su una scrivania (desktop, da cui
prende nome il modello), non sempre in maniera semplice. La successiva
evoluzione ` quindi rappresentata dall’ubiquitous computing, o era di
e
‘calma tecnologica’, in cui la tecnologia recede andando a far parte dello
sfondo delle nostre vite”.

1
la Xerox ` una delle aziende leader nella produzione di stampanti e fotocopiatrici.
e
Negli anni settanta produceva anche computer e proprio in quegli anni apr` un grande
ı
centro di ricerca a Palo Alto, California (lo Xerox PARC, appunto), che successivamente
si ` separato dalla casa madre nel 2002.
e

26


Figura 2.2: Ere della computer science secondo Weiser

Figura 2.3: Trend di sviluppo dell’ubiquitous computing

27


Un contributo significativo in questo campo ` stato fornito inoltre dal
e
MIT, in particolare dal consorzio Things that Thinks 2 (diretto da Hiroshi
Ishii, Joseph A. Paradiso e Rosalind Picard) presso i Media Lab, oltre al
lavoro di ricerca realizzato presso il CSAIL3 , sotto il nome di Project Oxygen.
Altri enti che hanno fornito contributi significativi sono il Georgia Tech’s
College of Computing, il NYU’s Interactive Telecommunications Program, il
Dipartimento di Informatica dell’University of California, Irvine, Microsoft
Research, Intel Research and Equator, l’Ajou University UCRi & CUS.

2.2 Il “contesto”
Introducendo l’ambito dell’ubiquitous computing, si ` potuto notare come
e
una delle caratteristiche fondamentali delle macchine che popolano la no-
stra quotidianit` debba essere la possibilit` di riconoscere le informazioni
a a
relative alla situazione in cui la computazione si svolge, o in altre parole
di contestualizzare la computazione. L’importanza di questa caratteristica,
emersa prepotentemente nella prima met` degli anni novanta, ha portato
a
allo sviluppo di un filone di ricerca autonomo chiamato context-aware
computing, argomento particolarmente attuale nel panorama di ricerca
corrente.
Nella maggior parte dei servizi attualmente sviluppati (es. i principali
portali online, come Google, Amazon, ecc...), in maniera trasparente all’u-
tente si ricerca di utilizzare anche solo le pi` esplicite informazioni conte-
u
stuali, come lo posizione, la lingua o il dispositivo utilizzato, per migliorare
l’esperienza dell’utente. Al contrario, altre informazioni interessanti non
vengono tenute in considerazione, come ad esempio il tempo speso all’in-
terno del sistema, l’azienda di appartenenza o la mansione dell’utente, a
causa della difficolt` di recuperare queste informazioni. Dove queste infor-
a
mazioni siano disponibili, la context-awareness pu` aiutarci a sfruttare i
o
dati rilevanti relativi al contesto.
Una semplice possibilit` per recuperare queste informazioni ` chiederle
a e
esplicitamente all’utente: questo per` implica che il sistema cos` svilup-
o ı
2
Things that Thinks ` uno dei principali filoni di ricerca presso i Media Labs, con
e
l’obiettivo di inserire dispositivi di computazione sia nell’ambiente che negli oggetti
quotidiani, http://ttt.media.mit.edu/.
3
Computer Science and Artificial Intelligence Laboratory presso il MIT, http://www.
csail.mit.edu/.

28


pato abbia un insieme predefinito di contesti, che pu` tradursi in pratica
o
con il tralasciare alcune configurazioni rilevanti del contesto oppure, nella
pi` immediata delle ipotesi, provvedere ad un cambiamento del contesto
u
unicamente su richiesta. Inoltre, gli utenti potrebbero essere preoccupati
della loro privacy e non voler rivelare al sistema il proprio attuale contesto,
fornendo informazioni sbagliate. Per questi motivi, un approccio statico
di questo tipo non si adatta bene all’ambiente dinamico ed al principio di
trasparenza che si vuole ricercare. Di seguito verr` indagato innanzitutto
a
il reale significato di “contesto”, per poi definire in dettaglio le principali
caratteristiche che vengono richieste alle applicazioni context-aware.

2.2.1 I primi approcci al contesto
Prima di passare alle applicazioni pratiche dei concetti precedentemente
introdotti, appare necessario sviluppare una specifica definizione di contesto
che possa essere utilizzata in maniera distintiva nel campo del context-aware
computing. Per fare questo sono state analizzate numerose definizioni
dei ricercatori che hanno lavorato in questo ambito e hanno proposto
una propria definizione all’interno del loro lavoro. In generale, molte
persone capiscono tacitamente cosa sia il contesto, ma hanno difficolt` ad a
esplicitarlo, enumerando spesso esempi o utilizzando sinonimi di contesto.

Nel lavoro che per primo introduce il termine “context-aware” nel 1994,
Schilit and Theimer [18] si riferiscono al contesto come posizione, vicinanza
tra due entit` (siano queste oggetti o persone) e relativi cambiamenti alle
a
entit` stesse. Queste tipologie di definizioni che descrivono il contesto attra-
a
verso esempi sono per` difficili da applicare. Quando vogliamo determinare
o
se un certo tipo di informazione sia contenuta nella definizione di contesto
o meno, non ` chiaro come utilizzare la precedente definizione per risolvere
e
il problema.
Altre definizioni hanno semplicemente fornito dei sinonimi di contesto:
ad esempio, spesso si sono riferiti al contesto come ambiente o situazione.
Come nel caso delle definizioni tramite esempi, anche questa tipologia di
definizione risulta difficilmente applicabile in pratica. Le definizioni fornite
da Schilit e Pascoe sono comunque le pi` vicine alla definizione operazionale
u
che ricerchiamo. Schilit [17] afferma che gli aspetti importanti del conte-
sto rispondono a tre domande fondamentali: dove sei, cosa possiedi con te

29


e quali risorse sono nelle vicinanze. Pascoe [12], invece, definisce il con-
testo come il sottoinsieme di stati fisici o concettuali di interesse per una
particolare entit`. Queste definizioni sono entrambe troppo specifiche: in
a
generale, il contesto ` tutto quello che risulta rilevante riguardo all’intera
e
situazione e l’insieme degli utenti. Per questo non ` possibile elencare quali
e
aspetti di ogni situazioni siano rilevanti, in quanto questi variano da situa-
zione a situazione. Le definizioni presentate finora non esauriscono quindi
la trattazione.

2.2.2 Una duplice visione del contesto
Nonostante sia spesso considerato un ambito lontano dall’informatica,
un’attenzione particolare va alle possibili interpretazioni del contesto nel-
l’ambito sociale. Oltre alle definizioni precedentemente elencate, Dourish
[7] suggerisce che la nozione di contesto nell’ambito dell’ubiquitous com-
puting abbia una duplice origine. Da una parte, ` una nozione tecnica,
e
che offre agli sviluppatori di sistemi nuovi modi di concettualizzare le
azioni umane e le relazioni tra queste azioni ed i sistemi computazionali.
Dall’altra, invece, ` anche una nozione derivata dalle scienze sociali,
e
prestando un’attenzione analitica verso alcuni aspetti dell’ambito sociale.
Tuttavia, trasferire le idee tra questi differenti domini intellettuali, risulta
allo stesso tempo interessante ma inaspettatamente difficile: le idee, infatti,
devono essere comprese all’interno dell’ambito intellettuale che fornisce
loro un significato. Per questo, le difficolt` di traduzione di questi concet-
a
ti da un ambito all’altro rappresentano un problema di primaria importanza.

In linea di massima, Dourish afferma che le teorie sviluppate in questo
campo appartengono a tre categorie: positiviste, fenomenologiche e critiche.
Le teorie positiviste derivano dalla tradizione razionale, empirica e scienti-
fica. Per analogia con le modalit` con cui le teorie scientifiche cercano di
a
semplificare i fenomeni complessi osservabili per ridurre ogni comportamen-
to ad una legge matematica sottesa, le teorie positiviste cercano di ridurre
i fenomeni sociali a modelli essenziali o semplificati che catturino pattern
generali. Di conseguenza, le teorie positiviste ricercano descrizioni oggettive
e indipendenti dei fenomeni sociali, astraendo dai dettagli relativi all’occa-
sione o ambiente particolare, spesso a favore della ricerca di trend statistici

30


o modelli idealizzati. Queste teorie, inoltre, sono per natura quantitative o
matematiche.
In evidente contrasto con queste caratteristiche delle teorie positiviste,
le teorie fenomenologiche hanno un orientamento soggettivo e qualitativo.
La soggettivit` di queste teorie sta nel fatto che queste osservano i fatti non
a
trasformando la componente sociale in una realt` oggettiva, ma basandosi
a
sulla capacit` degli individui e dei gruppi di riconoscere ed orientarsi attra-
a
verso quello che accade intorno a loro. Secondo questa visione, i fatti sociali
sono le propriet` emergenti della comunicazione, non predefinite o assolute,
a
ma negoziate e contestate, soggette a continui processi di interpretazione e
re-interpretazione. La fenomenologia non pone un’attenzione analitica sul-
l’idea di un mondo esterno stabile che sia percepito da tutti senza problemi;
al contrario, propone l’idea di un mondo che, per come ` percepito, sia es-
e
senzialmente l’insieme delle interpretazioni. Queste teorie affermano che,
ad esempio, le categorie astratte non sono classi che esistono a priori nella
realt`, ma sono imposte nel mondo dagli utenti stessi tramite le interazioni
a
che vengono effettuate tra di loro e con le classi stesse.
Le teorie critiche tendono ad avere un pi` ampio scopo. Questo tipo di
u
teorie, associate spesso alla Frankfurt School e ai teorici Adorno, Horkhei-
mer, Marcuse e Foucault, sono essenzialmente un’estensione dell’analisi
marxista. Il materialismo marxista sostiene che le condizioni sociali ed
economiche sono la conseguenza di un processo storico di evoluzione, e
riflettono un sistema dinamico (e generalmente non equo) in evoluzione,
di potenza e di controllo tra categorie sociali. Essenzialmente, la natura
dell’esistenza umana ` il prodotto di condizioni sociali ed economiche che
e
ripropongono la medesima distribuzione storica di potenza e di controllo
della societ` al proprio interno. Queste teorie estendono il materialismo
a
storico oltre il “prodotto” sociale ed economico della societ` stessa, dimo-
a
strando che le idee, la lingua e le modalit` di pensiero sono condizionate
a
allo stesso modo.

Nonostante Dourish abbia incluso per completezza le teorie critiche, c’` e
un’importante differenza tra le teorie positiviste e fenomenologiche. La
rilevanza di questa distinzione ` che gli approcci ingegneristici (inclusi i
e
principali approcci nel campo dell’ubiquitous computing) ereditano una tra-
dizione positivista, mentre molti approcci alle analisi sociali rilevanti per la
modellazione della HCI sono legati ad una metodologia fenomenologica. Da

31


una parte, gli approcci positivisti postulano che la causa della vita sociale
sia indipendente dall’osservatore, dall’altra le teorie fenomenologiche affer-
mano che le opere e l’interpretazione sono le sfaccettature principali di ogni
azione sociale. I costrutti analitici delle motivazioni positiviste alle azioni
sociali sono i risultati delle azioni sociali stesse; in questo modo sono intrin-
secamente collegati e quindi non possono essere separati o resi indipendenti.
Per questo motivo, le due posizioni sono incompatibili.
Allo stesso modo, con argomentazioni simili si dimostra che il concetto di
“contesto” contrappone la tradizione ingegneristica positivista e la tradi-
zione sociale fenomenologica, incompatibili come affermato in precedenza.
Conseguentemente, per poter utilizzare coerentemente il concetto di “con-
testo” all’interno dello sviluppo di un sistema complesso, bisogna in primo
luogo fornirne una descrizione pi` accurata.
u

2.2.3 Definizione operativa
Si deve ai ricercatori Anind K. Dey and Gregory D. Abowd [5] nel 2001 la
definizione di contesto ormai pi` diffusa e citata:
u

Il contesto rappresenta ogni informazione che pu` essere utiliz-
o
zata per caratterizzare la condizione di una entit`. Una entit` `
a ae
una persona, un posto o un oggetto considerato rilevante ai fini
dell’interazione tra un utente e un’applicazione, inclusi l’utente
e l’applicazione stessi.

Questa definizione rende pi` semplice per uno sviluppatore identificare
u
il contesto per un determinato scenario di un’applicazione. Se una por-
zione di informazione pu` essere utilizzata per caratterizzare la condizione
o
di un partecipante all’interazione, allora questa informazione fa parte del
“contesto”. Prendiamo, ad esempio, un’applicazione context-aware cano-
nica, come una guida turistica indoor nella sua versione mobile. Le entit` a
presenti in questo modello sono ovviamente l’utente, l’applicazione ed i siti
turistici. Consideriamo ora due altre possibili informazioni relative a questo
scenario: il tempo atmosferico e la presenza di altre persone. Utilizzando
la definizione, l’obiettivo ora ` quello di discriminare se facciano parte o
e
meno del “contesto”. Il tempo atmosferico non influenza l’applicazione, in
quanto questa verr` utilizzata indoor; per questo motivo, non ` considerata
a e
“contesto”. La presenza di altre persone, invece, pu` essere utilizzata per
o

32


caratterizzare la condizione corrente: se un utente sta viaggiando con altre
persone, allora i luoghi che gli altri visitano potrebbero essere di partico-
lare interesse per lui. Per questo motivo, questa informazione pu` essere
o
considerata “contesto”.
Un’assunzione generale ` che il contesto consista unicamente in infor-
e
mazioni implicite, anche se questa distinzione risulta alquanto restrittiva.
Secondo la definizione operazionale precedentemente presentata, il conte-
sto pu` essere sia implicitamente che esplicitamente indicato dall’utente.
o
Ad esempio, sia che l’identit` di un utente sia riconosciuta implicitamente
a
tramite un processo di visione artificiale, sia che venga fornita dall’utente
stesso tramite un’apposita form di login, questa informazione fa comunque
parte del contesto. In generale, i ricercatori si sono spesso rivolti verso
le informazioni implicite in quanto i margini di esplorazione dell’interazio-
ne uomo-macchina in questo campo sono molto pi` interessanti sfruttando
u
questa tipologia di informazioni.

2.2.4 Categorie di contesto
Una categorizzazione delle principali tipologie di contesto potrebbe aiutare
i progettisti di applicazioni context-aware ad identificare le informazioni del
contesto pi` utili per la loro applicazione. Possiamo partire dalle precedenti
u
definizioni di contesto, presentate nella sezione 2.2.1, per identificare queste
categorie. Ryan e al. [14] suggeriscono come tipologie di contesto la posi-
zione, l’ambiente, l’identit` ed il tempo. Schilit e al. [17], invece, elencano
a
come aspetti principali del contesto dove sei, con chi sei e che risorse sono
disponibili nelle vicinanze.
Le applicazioni context-aware ricercano la risposta alle domande chi `, e
dov’` e cosa sta facendo una data entit` e utilizzano queste informazioni
e a
per determinare il perch´ una situazione si stia verificando. L’applicazione
e
in realt` non determina realmente il perch´ una situazione si sia verificata,
a e
ma il progettista deve riuscire a farlo. Lo sviluppatore, infatti, utilizza la
conoscenza delle condizioni attuali e delle sue cause per codificare determi-
nate azioni nell’applicazione. Riprendendo l’esempio della guida turistica
presentato nella sezione 2.2.3, un utente fornito di notebook si avvicina ad
un luogo per lui interessante e le informazioni rilevanti riguardo quel luogo
vengono visualizzate dinamicamente sul computer. In questa situazione, il
progettista ha codificato nell’applicazione la consapevolezza che, quando un

33


utente si avvicina ad un determinato luogo (il contesto prossimo), il suo
comportamento dimostri interesse verso il luogo stesso (il perch´ ), per cui
e
l’applicazione ha il compito di mostrare le informazioni rilevanti al riguardo
(l’azione).
Ci sono certe tipologie di contesto che sono, in pratica, pi` importanti
u
di altre. In particolare, posizione, identit`, attivit` e tempo. L’unica
a a
differenza tra questo elenco e la definizione fornita da Ryan e al. ` l’utilizzo
e
del termine “attivit` ” piuttosto che “ambiente”: mentre il termine “ambien-
a
te” ` un sinonimo di contesto e non aiuta nella sua definizione, l’utilizzo di
e
“attivit` ” risponde alla fondamentale domanda ‘cosa sta accadendo nella
a
situazione corrente’. Le categorie fornite da Schilit e al., invece, includono
unicamente informazioni riguardo a posizione e indentit`, mentre per ca-
a
ratterizzare una situazione, c’` bisogno anche di informazioni riguardo alle
e
attivit` svolte e al tempo. La posizione, l’identit`, il tempo e l’attivit`
a a a
costituiscono dunque le tipologie primarie di contesto, necessarie per ca-
ratterizzare la situazione corrente di una particolare entit`: queste tipologie
a
di contesto non solo rispondono alle domande chi, cosa, dove e quando, ma
funzionano anche come indici rispetto ad altre fonti di informazioni con-
testuali. Ad esempio, data l’identit` di una persona, possiamo acquisire
a
numerose altre informazioni collegate, come il numero di telefono, l’indiriz-
zo, le email, la data di nascita, la lista degli amici, le relazioni con altre
persone dell’ambiente, ecc... Con la posizione di una persona, possiamo de-
terminare quali altri oggetti o persone siano nelle vicinanze e quali azioni
stiano avvenendo nell’ambiente circostante. Da questi esempi, dovrebbe es-
sere evidente che le tipologie primarie relative ad un’entit` possono essere
a
utilizzate come indici per ottenere le tipologie secondarie di contesto per
la stessa entit` (es. l’indirizzo email), oppure le tipologie primarie per una
a
differente entit` (es. persone nello stesso luogo).
a
In questa categorizzazione iniziale, troviamo un semplice sistema a due
livelli: le quattro parti primarie del contesto gi` identificate rappresentano
a
il primo livello. Tutte le rimanenti tipologie di contesto rappresentano il
secondo livello. Le parti secondarie del contesto condividono una caratteri-
stica comune: possono essere indicizzate tramite il contesto primario, perch´ e
sono attributi dell’entit` tramite il contesto primario. Ad esempio, il nu-
a
mero di telefono di un utente fa parte del contesto secondario e pu` essere
o
ottenuto utilizzando l’identit` dell’utente stesso come indice in uno spazio
a
informativo, come una rubrica telefonica. Ci sono alcune situazioni in cui

34


sono necessarie svariate informazioni del contesto primario come indice in
uno spazio informativo. Le previsioni del tempo, ad esempio, sono un’in-
formazione relativa al contesto in una guida turistica outdoor, che utilizza
queste informazioni per pianificare delle visite: per ottenere una previsione,
sono necessarie sia la posizione che la data per cui la previsione ` richiesta.
e
Questa caratterizzazione aiuta i progettisti a scegliere il contesto adat-
to per la propria applicazione, a strutturare il contesto da utilizzare ed a
ricercare altri contesti rilevanti. Le quattro tipologie principali di contesto
indicano il tipo di informazioni necessarie per caratterizzare una situazione
ed il loro utilizzo come indici fornisce un modo di utilizzo ed organizzazio-
ne del contesto stesso. Ora che ` stata fornita una definizione operativa
e
di contesto ed una categorizzazione delle informazioni che ne fanno parte,
possiamo passare ad analizzare i modi di utilizzarlo. Nella sezione successi-
va verranno caratterizzate le applicazioni context-aware e le loro principali
caratteristiche.

2.3 Mobile context-awareness

Come gi` accennato in precedenza, il campo del context-aware computing
a
rappresenta uno dei filoni di ricerca pi` battuti negli ultimi anni. Soprat-
u
tutto nell’era in cui lo sviluppo tecnologico ha portato alla realizzazione di
una fascia di dispositivi sempre pi` compatti e portatili (denominati mobile
u
devices), sfruttare il contesto in cui un’applicazione viene lanciata appare
una prerogativa sempre pi` fondamentale. Negli ultimi anni, infatti, l’im-
u
piego di questi dispositivi ha spostato definitivamente la computazione dal
classico contesto desktop, aprendo infinite possibilit` di utilizzo e nuove ra-
a
mificazioni applicative. Tramite i sensori a disposizione, si pu` raccogliere
o
una miriade di informazioni riguardo all’utente ed al contesto attorno a lui,
cos` come ` stato definito nella sezione 2.2.3: tracciando i comportamenti
ı e
del proprio proprietario ed analizzando i dati cos` ottenuti, il dispositivo
ı
non solo pu` svolgere funzioni utili in relazione al contesto attuale, ma mo-
o
dellare ed anticipare le intenzioni dell’utente. Questo rappresenta realmente
il nuovo livello di context-awareness che si ricerca dalle applicazioni mobile
all’avanguardia.

35


2.3.1 I primi approcci alla context-awareness

La prima definizione delle applicazioni context-aware fornita da Schilit e
Theimer nel 1994 [18] ha ristretto la definizione da “applicazioni sempli-
cemente a conoscenza del contesto”, ad “applicazioni che si adattano al
contesto”. Comunque sia, ` universalmente riconosciuto che il primo lavo-
e
ro di ricerca nel campo della context-awareness ` l’Olivetti Active Badge,
e
sviluppato nel 1992. Successivamente, ci sono stati numerosi tentativi di
definire il context-aware computing, di cui di seguito vengono riportati i
principali. Context-aware ` diventato in qualche modo sinonimo di altri
e
termini spesso citati nell’informatica: adaptive, reactive, situated, context-
sensitive e environment-directed. Le precedenti definizioni di context-aware
computing rientrano in due macro-categorie: quelle che utilizzano il contesto
e quelle che si adattano al contesto.
Per primo verr` discusso il caso pi` generale di utilizzo del contesto.
a u
Hull e al. [10] e Pascoe e al. [12] definiscono il context-aware computing
come l’abilit` di dispositivi computazionali di individuare e percepire, in-
a
terpretare e reagire all’ambiente locale di un utente e del dispositivo stesso.
Dey [4] limita invece la context-awareness all’interfaccia uomo-macchina,
come opposto dell’applicazione sottesa. In seguito, Dey e al. [6] iniziano
ad introdurre la nozione di “adattamento” definendo la context-awareness
come il lavoro che avrebbe portato all’automazione di un sistema software
basato sulla conoscenza del contesto dell’utente. Salber e al. [15] defini-
scono la context-awareness come l’abilit` di fornire la massima flessibilit`
a a
da parte di un servizio computazionale basato sulla percezione real-time del
contesto. Le seguenti definizioni si riconducono, invece, alla pi` specifica
u
categoria “adattamento al contesto”. Molti ricercatori definiscono le ap-
plicazioni context-aware come applicazioni che dinamicamente modificano
o adattano il loro comportamento in base al contesto dell’utente o dell’ap-
plicazione. Pi` specificamente, Ryan [14] ne parla come applicazioni che
u
monitorano gli input forniti da sensori ambientali e permettono agli uten-
ti di selezionare una configurazione da un range di contesti fisici o logici,
in base ai propri interessi o attivit` attuali. Questa definizione risulta ad-
a
dirittura pi` restrittiva rispetto alle precedenti in quanto identifica gi` le
u a
modalit` con cui le applicazioni operano in relazione al contesto. Brown
a
[3] definisce invece le applicazioni context-aware come servizi che autono-
mamente forniscono informazioni e/o agiscono in base al contesto attuale

36


dell’utente, percepito da appositi sensori. Fornisce inoltre una visione ulte-
riormente ristretta affermando che queste azioni possono concretizzarsi nel
presentare informazioni all’utente, eseguire un programma coerentemente
con il contesto attuale o configurare un apposito layout grafico. Infine,
l’ultima definizione analizzata ` quella del ricercatore Fickas e al. [8] che
e
definiscono le applicazioni environment-directed (termine praticamente uti-
lizzato come sinonimo di context-aware) come applicazioni che monitorano i
cambiamenti nell’ambiente e adattano il loro comportamento in base a linee
guida predefinite, configurate dall’utente.

2.3.2 Definizione operativa
Come per quanto riguarda il concetto di “contesto”, riportiamo di seguito
la definizione dei ricercatori Dey e Abowd [5], ormai largamente diffusa:

Un sistema ` context-aware se utilizza il contesto per fornire
e
all’utente informazioni rilevanti e/o servizi, dove la rilevanza
dipende dal compito dell’utente stesso.

Anche in questo caso ` stata scelta una definizione generale di context-
e
aware computing. Le definizioni pi` specifiche della categoria “adattamento
u
al contesto” richiedono che il comportamento di un’applicazione sia modi-
ficato per essere considerata context-aware. Quando si prova ad applicare
queste definizioni per discriminare le applicazioni context-aware, si scopre
che si adattano difficilmente. Ad esempio, un’applicazione che semplice-
mente mostri il contesto dell’ambiente in cui risiede l’utente non modifica il
suo comportamento, ma ` sicuramente context-aware. Se invece utilizziamo
e
le definizioni meno generali, queste applicazioni non sarebbero classificate
in questo modo. Per questo ` stata scelta una definizione pi` generale, che
e u
possa descrivere tutte le applicazioni di questa tipologia.
Questa definizione, infatti, ` pi` generale di quella fornita da Hull e al. o
e u
da Pascoe e al.: loro impongono che i sistemi context-aware da loro descritti
individuino, interpretino e rispondano al contesto. La descrizione operativa
fornita sopra, invece, necessita unicamente che rispondano al contesto, per-
mettendo che l’individuazione e l’interpretazione del contesto sia effettuata
da altre entit` computazionali. Inoltre differisce dalle altre definizioni gene-
a
rali fornite nella sezione 2.3.1, in quanto focalizza l’attenzione sull’utente,
non limitando la consapevolezza (awareness) all’interfaccia applicativa, non

37


richiedendo che l’applicazione svolga servizi automatizzati ed, infine, non
richiedendo un’acquisizione real-time del contesto.

2.3.3 Caratteristiche delle applicazioni context-aware
Nella sezione 2.2 ` gi` stata introdotta l’importanza di un approccio di-
e a
namico e non intrusivo nella rilevazione del contesto dell’utente, evitan-
do la presenza di contesti predefiniti a cui ricondurre i casi reali: questa
staticit`, spesso dovuta alla mancanza di informazioni concettuali disponi-
a
bili, si concretizza spesso nella richiesta esplicita di informazioni all’utente,
portando in primis ad una minor utilizzabilit` del sistema. Queste carat-
a
teristiche rappresentano quindi le linee guida generali durante la progetta-
zione di applicazioni context-aware. Per comprendere pi` a fondo il campo
u
della context-awareness, nelle sezioni successive verranno presentate alcune
caratteristiche comuni a queste tipologie di applicazioni.

Categorizzazione di Schilit
All’interno di questo filone di ricerca, sono stati due i principali tentativi
di sviluppare una tassonomia simile. Il primo si deve a Schilit e al. [17] ed
` costituito da due dimensioni ortogonali: se la computazione ` recuperare
e e
un’informazione o eseguire un comando o se invece ` eseguito manualmente
e
o automaticamente. Le applicazioni che recuperano manualmente informa-
zioni per l’utente in base al contesto disponibile, sono chiamate applicazioni
di selezione prossima. Questa ` una tecnica di interazione dove ` presentata
e e
una lista di oggetti (printers) o luoghi (offices), in cui gli oggetti rilevanti
per l’utente sono enfatizzati o resi pi` facili da scegliere. Invece, le appli-
u
cazioni che recuperano automaticamente informazioni per l’utente in base
al contesto disponibile, sono classificate come riconfigurazione contestuale
automatica. Questa ` una tecnica di livello o di sistema che crea un legame
e
automatico con una risorsa disponibile in base al contesto corrente. Un’al-
tra categoria consiste nelle applicazioni che eseguono manualmente comandi
dell’utente in base al contesto attuale, classificate quindi come applicazio-
ni a comando contestuale. Sono in pratica servizi eseguibili resi disponibili
tramite il contesto dell’utente o la cui esecuzione ` modificata in base al
e
contesto dell’utente. Infine, le applicazioni che eseguono automaticamente
comandi per l’utente basandosi sul contesto disponibile, utilizzano azioni

38


context-triggered. Quest’ultima tipologia di servizi ` eseguita automatica-
e
mente quando la giusta combinazione del contesto si delinea ed ` basata
e
sull’applicazione di semplici regole “se-quindi”.

Categorizzazione di Pascoe
Pi` recentemente Pascoe ha proposto anche una tassonomia delle caratte-
u
`
ristiche context-aware. E presente una considerevole sovrapposizione con
la tassonomia appena illustrata, ma vi sono comunque differenze cruciali.
Pascoe [12] ha sviluppato una tassonomia che ha lo scopo di identificare le
principali caratteristiche nell’ambito della context-awareness, in contrappo-
sizione con la tassonomia presentata in precedenza, che identificava le classi
delle applicazioni context-aware. In realt`, le caratteristiche presentate di
a
seguito possono essere mappate con semplicit` sulle classi di applicazioni
a
descritte nella tassonomia di Schilit.

Percezione contestuale Questa prima caratteristica fa riferimento all’abi-
lit` di percepire le informazioni relative al contesto e presentarle al-
a
l’utente, aumentando la capacit` sensoriale dell’utente stesso. Questa
a
caratteristica appare molto simile alla selezione prossima, eccetto che
in questo caso l’utente non deve necessariamente selezionare uno degli
elementi di contesto per ottenere ulteriori informazioni (es. il contesto
potrebbe essere l’informazione richiesta).

Adattamento contestuale Rappresenta l’abilit` di eseguire o modificare un
a
servizio automaticamente, in base al contesto attuale; si riconduce
direttamente alle azioni context-triggered di Schilit.

Rilevazione di risorse contestuali Permette alle applicazioni context-aware
di localizzare ed utilizzare risorse e servizi rilevanti nel contesto dell’u-
tente; viene mappata sulla categoria della riconfigurazione contestuale
automatica.

Aumento contestuale Consiste nell’abilit` di associare dati digitali al con-
a
testo dell’utente. Ad esempio, un utente pu` creare una nota virtuale
o
fornendo i dettagli riguardo ad un televisore rotto ed allegare la nota
alla televisione. Quando un altro utente si avviciner` alla televisione
a
o cercher` di utilizzarla, visualizzer` prima la nota virtuale lasciata.
a a

39

Montalti - "Context aware applications" (2011, master thesys ITA)

Montalti - "Context aware applications" (2011, master thesys ITA)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Montalti - "Context aware applications" (2011, master thesys ITA)

Similar to Montalti - "Context aware applications" (2011, master thesys ITA) (20)

Montalti - "Context aware applications" (2011, master thesys ITA)