Your SlideShare is downloading. ×
Montalti - "Context aware applications" (2011, master thesys ITA)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

742
views

Published on

Master thesys.

Master thesys.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
742
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ALMA MATER STUDIORUM ` UNIVERSITA DI BOLOGNA Seconda Facolt` di Ingegneria a Corso di Laurea Specialistica in Ingegneria InformaticaSVILUPPO DI APPLICAZIONI CONTEXT-AWARESU SMARTPHONE: UN APPROCCIO AD AGENTIBASATO SULLA PIATTAFORMA JACA-ANDROID Elaborata nel corso di: Sistemi Concorrenti e di Rete LSTesi di Laurea di: Relatore:ALESSANDRO MONTALTI Prof. ALESSANDRO RICCI Co-relatori: ANDREA SANTI ANNO ACCADEMICO 2010–2011 SESSIONE II
  • 2. PAROLE CHIAVE contest-awareness mobile computing smartphone agent-oriented programming JaCa-Android
  • 3. Alla mia famiglia.
  • 4. IndiceIntroduzione 11 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 . . . . . . . . . . . . . . . . . . . 212 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 Definizione 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 Definizione 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
  • 5. 2.5 Ulteriori scenari applicativi . . . . . . . . . . . . . . . . . . . 54 2.5.1 Realt` aumentata . . . . . . . . . . . . . . . . . . . . a 54 2.5.2 Context-aware gaming . . . . . . . . . . . . . . . . . 553 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 . . . . . . . . . . . . . . . 654 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 785 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 . . . . . . . . . . . . . . . . . . . . 98Conclusioni 99A Acronimi 101Ringraziamenti 111 viii
  • 6. IntroduzioneNegli ultimi anni l’avanzamento della ricerca e della tecnologia in ambitomobile ha portato allo sviluppo di dispositivi sempre pi` potenti dal punto di uvista computazionale, equipaggiati con una vasta gamma di sensori (camera,accelerometro, giroscopio, GPS, ecc...) e capaci di connettersi alla retetramite il supporto di tecnologie di ultima generazione (Bluetooth, 2G, 3G,4G, WiFi). Questo trend, in continua e costante crescita, ha aperto pianpiano la porta a molti nuovi scenari applicativi, abbattendo le barriere legatealla scarsit` di risorse disponibili sui dispositivi mobile ed aprendo le porte aallo 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 ano, infatti, dispositivi molto personali, concepiti per accompagnare l’utentedovunque egli vada; per questo motivo appaiono particolarmente interes-santi per la ricerca nell’ambito del pervasive computing, in quanto possonoaccedere, grazie ai sensori con i quali sono equipaggiati, ad una miriade diinformazioni 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 pianocominciato a giocare un ruolo importante per le applicazioni e per i servizi,rendendoli sempre pi` personalizzati e “smart”. La context-awareness urappresenta gi` parte integrante delle abituali applicazioni business, ma ail trend attuale l’ha ormai battezzata aspetto critico in ambito mobile enell’ubiquitous computing, dove i dispositivi hanno il compito di adattareil proprio comportamento in base ai servizi disponibili nell’ambientecorrente. Nonostante il fatto che il contesto si stia quindi affermandocome una nozione centrale per questo ambito emergente di applicazioni, ilsupporto esplicito alla context-awareness nei linguaggi di programmazionee negli ambienti di sviluppo mainstream ` ancora decisamente scarso. La e 1
  • 7. 2necessit` di schematizzare ed ingegnerizzare lo sviluppo di tale categoria adi applicazioni, porta inesorabilmente a cercare astrazioni che riducanola complessit` di questi sistemi e che ne modellino ad alto livello le acaratteristiche, permettendo agli sviluppatori di focalizzare l’attenzioneunicamente sul comportamento specifico dell’applicazione stessa. L’obiettivo di questa tesi ` quello di investigare un livello di astrazione eagent-oriented, considerando in particolare il modello BDI come architet-tura di riferimento per lo sviluppo di agenti intelligenti al fine di modellareapplicazioni context-aware, dimostrando come le caratteristiche di reatti-vit`, pro-attivit` e adattamento richieste da questi sistemi possano essere a afacilmente soddisfatte tramite l’utilizzo di tali entit` computazionali. No- anostante non sia l’unica soluzione progettuale adottabile, verr` dimostrato, acon l’ausilio della letteratura disponibile in materia, come questo approcciorappresenti un livello di partenza efficace per semplificare e sistematizzarelo 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 breveintroduzione aiuta ad inquadrare le nuove tecnologie a disposizione e leinnovative potenzialit` di cui dispongono, come base di partenza per la aprogettazione 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 diquesta tipologia di applicazioni. Inoltre, per comprendere meglio gli aspettitrattati, 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 edi applicazioni, proponendo un approccio ad agenti intelligenti, secondo ilmodello BDI, per catturare ad alto livello le caratteristiche chiave presenta-te nel capitolo precedente. Particolare fondamentale per poter affrontare epresentare in pratica lo sviluppo di una applicazione context-aware, ` la ri- ecerca di un middleware software che fornisca il giusto supporto per l’utilizzoquesta astrazione concettuale. Tra le piattaforme analizzate in letteratura, 2
  • 8. 3si ` deciso di sfruttare le potenzialit` del framework JaCa-Android per lo e asviluppo di un’applicazione reale: l’architettura della piattaforma ed il mo-dello di programmazione ad agenti e artefatti ` stato descritto in dettaglio enel capitolo 4. A supporto di questa analisi, sono stati forniti brevi stralcidi codice relativi ad un semplice esempio di applicazione. Infine, il capitolo 5 presenta la progettazione e lo sviluppo di unaapplicazione context-aware portata come caso di studio per esemplificarel’approccio finora descritto e per dimostrarne gli effettivi vantaggi. 3
  • 9. 4 4
  • 10. Capitolo 1Evoluzione dei dispositivi edelle applicazioni mobileI dispositivi mobile di oggi sono strumenti multi-funzionali con la capacit` adi supportare un vastissimo range di applicazioni sia per il business cheper l’utilizzo privato. I PDA e qualsiasi nuova categoria di smart-phonespermettono agli utenti di accedere a numerosissimi servizi, dalle email al-l’instant messaging, ed hanno una potenza computazionale che permetteloro di svolgere molti compiti spesso demandati all’utilizzo di un computer,come la modifica di documenti o la navigazione internet. Anzi, i dispositivimobile sono spesso visti come un’“estensione” del proprio computer: difatti,il lavoro svolto fuori dall’ufficio o in viaggio pu` essere sincronizzato in un osecondo momento, tramite procedure sempre pi` trasparenti all’utente, con ul’ordinario flusso di lavoro nella propria postazione, riflettendo le modifichealle 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 computazionalisiano trasportati durante il loro utilizzo standard, seguendo l’utente du-rante lo svolgimento delle sue normali attivit`. Lo sforzo per superare i avincoli fisici (alimentazione, portabilit`, usabilit`, ecc...) insieme alle nuove a aprospettive di utilizzo, ne hanno fatto un settore tecnologico di primariaimportanza sia nell’ambito commerciale che di ricerca negli ultimi anni. Itre aspetti principali di questo settore, approfonditi nelle sezioni successive,sono l’hardware, il software e la comunicazione mobile. 5
  • 11. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE6 APPLICAZIONI MOBILE1.1 Tipologie di dispositivi mobileIl termine “dispositivo mobile” sta ad indicare un’ampia gamma di stru-menti elettronici di consumo. Generalmente, ` utilizzato per descrivere edispositivi che si connettono al web, ma risulta comunque una definizionedecisamente ristretta delle reali potenzialit` di questi strumenti. In gene- arale, i dispositivi mobile sono progettati specificatamente per favorire por-tabilit` ed usabilit` durante gli spostamenti dell’utente, sono tipicamente a asoggetti ad un utilizzo intermittente in ambienti inusuali (in contrapposi-zione al classico desktop), supportando varie tipologie di comunicazione escambio di dati. Fanno parte di questa categoria una crescente gamma distrumenti che vanno dai personal digital assistant agli wearable computers(letteralmente, computer indossabili), passando per i pi` diffusi notebook e usmartphones. Inoltre, viste le crescenti capacit` computazionali e le nuove afeatures 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 lentamentead 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 commercialesono 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`a 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
  • 12. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI 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
  • 13. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE8 APPLICAZIONI MOBILE 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 mobileUn sistema operativo mobile, chiamato anche mobile OS, ` un sistema ope- erativo che comanda un dispositivo mobile, con caratteristiche simili ai si-stemi operativi standard installati su un personal computer. Essendo per` oinstallati su dispositivi con caratteristiche e vincoli sostanzialmente diver-si, presentano alcune differenze: sono generalmente pi` leggeri dal punto udi vista della computazione, in quanto installati su apparecchi con capa-cit` ed autonomia relativamente limitate, e devono supportare differenti aforme di input (touch-screen, digital pen, ecc..) e funzioni di connettivit` a(collegamento a reti mobili, Wi-Fi, GPS, ecc...). 8
  • 14. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 91.2.1 Apple Mac iOSiOS (conosciuto anche come iPhoneOS prima di giugno 2010) ` il sistema eoperativo mobile progettato da Apple.Sviluppato originariamente per iPho-ne, ` stato poi esteso per supportare ei 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 ada Apple; per questi motivi, iOS vie-ne considerato, di fatto, un sistema Figura 1.2: Schermata e logoclosed, in contrapposizione al nuovo di Apple iOSsistema operativo Android.StoriaIl sistema operativo fu svelato, insieme all’iPhone, alla MacWorld Confe-rence & Expo 1 il 9 gennaio 2007, e lanciato commercialmente nel giugnodello stesso anno. All’inizio, la strategia di marketing di Apple non avevapresupposto un nome per questo sistema, limitandosi a riferirsi a questocome una versione particolare di OS X. Inoltre, in questa prima versione,non erano supportate applicazioni sviluppate da terzi. Solo nel febbraio2008 Apple mise a disposizione degli sviluppatori un apposito Software De-velopment Kit (SDK) per lo sviluppo di applicazioni su iPhone, rilasciandoil 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 fiera che si svolge annualmente nelle prime esettimane di gennaio negli Stati Uniti, con conferenze dedicate alla piattaforma AppleMacintosh. 9
  • 15. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE10 APPLICAZIONI MOBILEnel giugno 2010 Apple ha rinominato iPhone OS solamente “iOS ”, licen-ziando il brand da Cisco che da oltre dieci anni utilizzava lo stesso nomeper il sistema operativo installato sui suoi router.Interfaccia utenteL’interfaccia utente di iOS ` basata sul concetto di manipolazione diretta, eutilizzando gesture multi-touch: in questo modo ` possibile controllare ealcuni elementi grafici, come bottoni, slider ed interruttori, che veicolanol’interazione con il dispositivo. La risposta immediata agli input dell’utentefornisce un’interfaccia fluida per l’interazione, che pu` avvenire tramite il osemplice 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 assumonoun differente significato. Inoltre, gli accelerometri interni sono utilizzati daalcune applicazioni per rispondere allo shaking (letteralmente, scuotimento)del dispositivo o alla rotazione in tre dimensioni, che assumono la funzionedi input alternativo. Figura 1.3: Architettura di iOS 10
  • 16. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 11La piattaforma iOSCome sistema operativo, iOS ` derivato da Mac OS X, con cui condivide ela fondazione sul sistema Darwin2 , per cui ` di fatto un sistema basato su earchitettura 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, ilMedia Layer e il livello Cocoa Touch [2]. Ai livelli pi` bassi ci sono i servizi ufondamentali e le tecnologie su cui si basano tutte le applicazioni; pi` inualto, 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 enei primi anni 2000. Sviluppato in C e C++, ` costituito principalmente da Apple, ma econ 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
  • 17. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE12 APPLICAZIONI MOBILE 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 adi utilizzare servizi e framework di alto livello, piuttosto che viceversa: iframework di alto livello introducono astrazioni che rendono la scritturadel codice pi` agile in quanto incapsulano funzioni molto complesse; in uogni caso i livelli a pi` bassa astrazione rimangono comunque disponibili a uquegli sviluppatori che volessero gestire in completa autonomia ogni aspettodi interfacciamento con il sistema.Development e deployment in iOSApple fornisce per gli sviluppatori iOS SDK che fornisce tutte le inter-facce, gli strumenti e le risorse per sviluppare applicazioni iOS sul propriocomputer Macintosh Intel-based. 12
  • 18. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 13 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- eforma Unix, molte delle tecnologie che compongono il livello Core OS sonodirettamente 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 AndroidAndroid ` un sistema operativo per edispositivi mobile come smartphone etablet, sviluppato dalla Open HandsetAlliance guidata da Google Inc. Lamaggior parte del codice scritto perla piattaforma Android ` stato reso edisponibile sotto Apache licence, unalicenza software ad utilizzo gratuito:per questo motivo, il sistema ` di fat- eto 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- atori che hanno esteso le funzionalit` adel sistema tramite la progettazione Figura 1.4: Schermata e logodi apps. di Google Android 13
  • 19. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE14 APPLICAZIONI MOBILEStoriaLa piattaforma Android ` un prodotto della Open Handset Alliance, un egruppo di organizzazioni che collaborano con lo scopo di sviluppare un siste-ma mobile per un telefono all’avanguardia. Questa organizzazione, guidatada Google, include pi` di 80 compagnie tra cui operatori mobili, produttori udi dispositivi portatili, produttori di componenti, sviluppatori software ecompagnie di marketing. Il primo dispositivo mobile sul mercato equipaggiato con Android ` sta- eto 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 reseedisponibili solo alcune versioni incrementali di un SDK, come strumentoprincipale di sviluppo. Quando la data di lancio del G1 si avvicin`, il team odi 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 DeveloperChallenge”, 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, permettendoagli utenti di visionare e scegliere le applicazioni direttamente dai propritelefoni.La piattaforma AndroidAndroid consiste in un kernel basato su Linux, con un middleware, libreriee API scritti in C; inoltre sono fornite applicazioni software lanciateall’interno di un framework applicativo che include librerie compatibili conJava e basate su Apache Harmony. Android utilizza una macchina virtualechiamata Dalvik virtual machine con compilazione just-in-time per lanciareapplicazioni compilate in linguaggio Java. I layer software che costituisconola piattaforma sono presentati in figura 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
  • 20. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 15 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
  • 21. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE16 APPLICAZIONI MOBILE Figura 1.5: Architettura di Android Come accennato in precedenza, le applicazioni Android sono scritte inlinguaggio Java e per questo lanciate su una virtual machine: non si trattain 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 machinee uefficientemente sullo stesso dispositivo: ogni applicazione (contenuta in unfile eseguibile .dex, ottimizzato per un utilizzo minimo della memoria) vieneinfatti lanciata all’interno di un’istanza della Dalvik VM, che a sua voltarisiede all’interno di un processo Linux gestito dal kernel (come mostratoin figura 1.6). La Dalvik VM si basa sul kernel Linux per le funzionalit` di abasso livello come il multi-tasking ed un’efficiente gestione della memoria.Development e deployment in AndroidIl requisito principale per progettare applicazioni su piattaforma Android` l’SDK Android fornito da Google. E’ disponibile inoltre un plugin,edenominato “Android Developer Tool ”, che permette di sviluppare appli-cazioni all’interno dei principali ambienti di programmazione Java, come 16
  • 22. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 17 Figura 1.6: Esecuzione di un’applicazione Androidad esempio l’IDE Eclipse3 : questi tool di sviluppo forniscono un ambienteJava sensibile al contesto, oltre che aiuto e suggerimenti lungo la program-mazione; una volta che il codice ` stato compilato correttamente, l’Android eDeveloper Tool si occupa del corretto impacchettamento dei dati e dellacompilazione del file manifest AndroidManifest.xml, necessario per ogniapplicazione. All’interno dell’SDK, sono presenti anche vari tool command-line peril debugging delle applicazioni realizzate; i principali e pi` comunemente uutilizzati sono: • Android Emulator: questo emulatore permette di testare le proprie applicazioni su un device virtuale oppurtunamente configurato, 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 acome linguaggio di programmazione, lo sviluppo di applicazioni Androidpu` avvenire su tutti i principali sistemi operativi disponibili (Microsoft oWindows, Mac OS X, Linux). 3 disponibile all’indirizzo http://www.eclipse.org. 17
  • 23. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE18 APPLICAZIONI MOBILE1.2.3 Windows PhoneWindows Phone (prima conosciutocol nome Windows Phone 7 Series) ` eil sistema operativo mobile sviluppatoda Microsoft ed il successore dellapiattaforma Windows Mobile. Conquesto nuovo sistema, Microsoft offreun’interfaccia utente rinnovata conl’utilizzo del linguaggio di designMetro, che si occupa sia dell’inte-grazione con i servizi Microsoft econ quelli sviluppati da terzi, siadell’utilizzo performante dell’hard-ware di cui dispone il dispositivo.Windows Phone richiede alcunirequisiti hardware minimi per il suocorretto funzionamento, ma, comeAndroid, ` progettato per funzionare esu differenti piattaforme e chipsethardware. Per questo motivo ` stato escelto come linguaggio principaledi programmazione C#, in quantorende possibile una compilazione run-time tramite “Common Language Figura 1.7: Schermata e logoRuntime” (CLR, una virtual machine di Windows Phoneproprietaria).StoriaIl lavoro per una sostanziale update del precedente Windows Mobile inizi` onei primi mesi del 2004 sotto il nome di “Photon”, ma visti gli scarsi risultatiiniziali il lavoro fu cancellato. Successivamente, nel 2008, Microsoft riun` ıun team per lo sviluppo di un nuovo sistema operativo mobile e nel 2009fu realizzato Windows Phone, anche se alcuni ritardi costrinsero Microsofta sviluppare Windows Mobile 6.5 come release provvisoria. 18
  • 24. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 19 Il nome Windows Phone 7 rappresenta di fatto il rinnovamento del vec-chio OS mobile di Microsoft Windows Mobile : il 5 febbraio 2010 al MobileWorld Congress 2010 di Barcellona, Microsoft svel` per la prima volta Win- odows Phone e ne rivel` altri dettagli il mese successivo al MIX 2010. La oversione finale dell’SDK fu resa disponibile per gli sviluppatori da settembredello stesso anno. Nell’ottobre del 2010 sono stati lanciati sul mercato dieci dispositiviche montano Windows Phone, fabbricati da HTC, Dell, Samsung e LG.Successivamente, nel febbraio del 2011 ` stata annunciata una partnership etra Nokia e Microft, per far diventare Windows Phone il sistema operativoprimario sui dispositivi realizzati dalla casa finlandese.ArchitetturaL’architettura di Windows Phone 7 ` basata sul kernel Windows Embedded eCE 6.0 ed ` logicamente divisa in tre livelli principali: i componenti relativi eal kernel-mode ed al user-mode (il livello software), oltre ai componentihardware [21]. Il diagramma in figura 1.8 mostra i componenti primaridell’architettura. Figura 1.8: Architettura di Windows Phone 19
  • 25. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE20 APPLICAZIONI MOBILE 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
  • 26. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLEAPPLICAZIONI MOBILE 21Development e deployment in Windows PhoneQualsiasi applicazione si intenda sviluppare, il punto di partenza della pro-gettazione ` la Windows Phone Application Platform [22]: questa epiattaforma definisce i componenti centrali comuni a tutti gli sviluppatori.Nello specifico, l’Application Platform contiene tutti gli strumenti per losviluppo, per l’esecuzione runtime, per la progettazione di servizi e cloud-computing. Oltre alla piattaforma base, ` possibile valutare estensioni per ela progettazione di funzionalit` accessorie. a L’ambiente di sviluppo primario per la progettazione di un’applicazioneper Windows Phone ` Microsoft Visual Studio 2010, combinato con ealcuni tool specifici, come il Windows Phone Emulator, che fornisce unsupporto per definire, progettare, effettuare il debugging ed il deploymentdelle proprie applicazioni.1.3 Smart Mobile ApplicationsLe piattaforme operative introdotte in precedenza forniscono nuove ed in-novative funzionalit` per lo sviluppo di applicazioni di nuova generazione: adel resto, l’avanzamento tecnologico ha messo a disposizione degli sviluppa-tori dispositivi sempre pi` potenti dal punto di vista computazionale e dei usensori con cui vengono equipaggiati, aumentandone esponenzialmente gliambiti di utilizzo. Per questo motivo, le tipologie di applicazioni supportateda questi dispositivi si sono evolute profondamente negli ultimi anni, graziealla possibilit` di poter disporre ed elaborare nuove informazioni ottenute adal contesto dell’utente o direttamente dalla rete. Da un lato, quindi, le applicazioni realizzate per questa tipologia didispositivi di nuova generazione hanno accesso a nuove fonti di dati chepermettono loro di avere un comportamento smart, letteralmente “intelli-gente”, capace di adattarsi alla situazione esterna realizzando funzionalit` ainnovative. Dall’altro, l’introduzione di questi nuovi scenari introduce nuovesfide legate allo sviluppo di applicazioni mobile, vista la difficolt` crescen- ate. Queste applicazioni avranno quindi a che fare con problematiche legatealla 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
  • 27. CAPITOLO 1. EVOLUZIONE DEI DISPOSITIVI E DELLE22 APPLICAZIONI MOBILEsull’attuale contesto (la posizione geografica del dispositivo, la presenza diconnettivit` nelle vicinanze, ecc...). a Questi nuovi scenari hanno spinto molti brand ed aziende a buttarsi sulmercato mobile, realizzando le proprie applicazioni diffuse spesso a titologratuito, con lo scopo di promuovere e migliorare il proprio servizio o sem-plicemente pubblicizzare la propria azienda. La concorrenza che si ` venuta ea creare in questo settore di sviluppo, ha quindi portato a nuovi standardper lo sviluppo di applicazioni smart, dando notevole importanza all’usa-bilit` ed all’interfaccia grafica, oltre agli aspetti implementativi menzionati ain precedenza. Un’interfaccia intuitiva ed accattivante rende utilizzabileun’applicazione molto sofisticata a tutti gli utenti, rivolgendosi quindi adun insieme di clienti pi` vasto e recettivo. Inoltre, nell’ottica di un merca- uto fortemente saturo e competitivo, questo aspetto assume un’importanzacommerciale pi` spiccata, oltre che prettamente funzionale. u 22
  • 28. Capitolo 2Ubiquitous computing econtext-awarenessNegli ultimi anni, uno dei principali filoni di ricerca relativi all’interazioneuomo-macchina (human-computer interaction, o HCI ) ` stato l’esplorazione edi nuove forme di interazione ottenute unendo le nuove tecnologie sviluppa-te con il mondo fisico in cui viviamo e lavoriamo. Questo campo di ricercaha assunto negli anni molte denominazioni, ciascuna focalizzata su un par-ticolare aspetto o modello di interazione (ubiquitous computing, pervasivecomputing, context-aware computing, ecc...). Al di l` della nomenclatura autilizzata, l’idea centrale rimane invariata: seguendo il trend attuale di svi-luppo di dispositivi low-cost e low-power, l’ubiquitous computing proponeun futuro digitale nel quale la computazione sia incorporata nella struttu-ra del mondo intorno a noi. In questo mondo, l’esperienza primaria dellacomputazione non avviene pi` attraverso i tradizionali desktop computers, uma piuttosto con una serie di dispositivi computazionalmente avanzati: se-condo questa visione, il mondo intorno a noi pu` diventare l’interfaccia per ola computazione e le possibilit` di interazione diventano molteplici. a Questa visione del futuro sviluppo tecnologico porta con s´ alcune pro- eblematiche relative all’ambito di ricerca. In particolare, ` lecito chiedersi equanto 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 autilizzare informazioni circostanziali implicite (o contesto) per ampliare lacomunicazione. Questo meccanismo risulta particolarmente impoverito nel- 23
  • 29. CAPITOLO 2. UBIQUITOUS COMPUTING E24 CONTEXT-AWARENESSla tradizionale forma di interazione per la computazione, viste le metodolo-gie per fornire input alle macchine; per questo motivo, nella maggior partedei casi, i computer non hanno la capacit` di sfruttare al massimo il contesto aattorno a loro. Lo scenario appena descritto pone l’accento sul concetto di contestoe sul ruolo centrale che assume in questo ambito di ricerca. Miglioran-do l’accesso dei computer al contesto, possiamo arricchire l’interazioneuomo-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 ein vari dispositivi disseminati nel mondo fisico), l’importanza di adattare lacomputazione alle informazioni ottenute dall’ambiente circostante risultadi centrale importanza. Per poter utilizzare al meglio questa fonte di informazioni, bisogna in-nanzitutto comprendere cosa si intenda esattamente per contesto e comedebba essere utilizzato, in modo da scegliere unicamente le informazioniutili per l’applicazione o il servizio che si desidera sviluppare e in modo dasupportare in maniera corretta e coerente le reazioni a cambiamenti dell’en-vironment locale. Per questo motivo, partendo dal modello dell’ubiquitouscomputing, di seguito verr` definito e caratterizzato il concetto di contesto, adiscutendone la particolare importanza nell’applicazione all’ambito mobile.2.1 Ubiquitous computing modelL’ubiquitous computing ` un modello di interazione uomo-macchina in ecui la computazione delle informazioni ` stata profondamente integrata ne- egli oggetti e nelle attivit` della vita quotidiana. Durante lo svolgimento aordinario delle proprie attivit`, la persona che “utilizza” l’ubiquitous com- aputing sfrutta numerosi dispositivi computazionali simultaneamente, senzaper forza essere consapevole del loro utilizzo. Questo modello ` generalmente considerato l’evoluzione del desktop com- eputing, 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 inveceeche forzare l’uomo ad entrare nel loro”, sottolineando la possibilit`, durante a 24
  • 30. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 25ogni nostra attivit`, di accedere a capacit` elaborative per soddisfare ogni a anecessit`, 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 terminienfatizza aspetti leggermente differenti. In generale, utilizzando il termineubiquitous computing si vogliono privilegiare gli aspetti legati alla elevatamobilit` e pervasivit` della capacit` elaborativa nell’ambiente fisico (come a a amostrato nel prospetto in figura 2.1). Figura 2.1: Aspetti principali dell’ubiquitous computing In base alle definizioni fornite finora, possiamo riassumere di seguito lecaratteristiche 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
  • 31. CAPITOLO 2. UBIQUITOUS COMPUTING E26 CONTEXT-AWARENESS • 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 aemersa 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- atamento delle applicazioni in base a quello che succede intorno a loro, masar` la spinta principale per la previsione delle necessit` dell’utente stesso. a a2.1.1 Storia del modelloIl termine ubiquitous computing ` stato coniato da Mark Weiser intorno al e1988, durante la docenza come chief technologist (ingegnere capo), presso ilPalo Alto Research Center (PARC) della Xerox1 . Riconoscendo che l’estensione della potenza della computazione agliscenari quotidiani avrebbe necessitato della conoscenza di fenomeni sociali,culturali e psicologici oltre il proprio ambito, Weiser fu influenzato damolte discipline lontane dalla computer science, fra cui filosofia, feno-menologia, antropologia, psicologia, post-modernismo e sociologia dellascienza. Come da lui dichiarato, “l’ubiquitous computing d` il nome alla aterza era tecnologica: all’inizio sono stati costruiti i mainframes, grandie costosi computers condivisi da molte persone; fino ai primi anni delnuovo millennio ` stata la volta dell’era del personal computer, in cui euomo e macchina interagivano tra loro su una scrivania (desktop, da cuiprende nome il modello), non sempre in maniera semplice. La successivaevoluzione ` quindi rappresentata dall’ubiquitous computing, o era di e‘calma tecnologica’, in cui la tecnologia recede andando a far parte dellosfondo delle nostre vite”. 1 la Xerox ` una delle aziende leader nella produzione di stampanti e fotocopiatrici. eNegli 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 successivamentesi ` separato dalla casa madre nel 2002. e 26
  • 32. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 27 Figura 2.2: Ere della computer science secondo Weiser Figura 2.3: Trend di sviluppo dell’ubiquitous computing 27
  • 33. CAPITOLO 2. UBIQUITOUS COMPUTING E28 CONTEXT-AWARENESS Un contributo significativo in questo campo ` stato fornito inoltre dal eMIT, in particolare dal consorzio Things that Thinks 2 (diretto da HiroshiIshii, Joseph A. Paradiso e Rosalind Picard) presso i Media Lab, oltre allavoro di ricerca realizzato presso il CSAIL3 , sotto il nome di Project Oxygen.Altri enti che hanno fornito contributi significativi sono il Georgia Tech’sCollege of Computing, il NYU’s Interactive Telecommunications Program, ilDipartimento di Informatica dell’University of California, Irvine, MicrosoftResearch, Intel Research and Equator, l’Ajou University UCRi & CUS.2.2 Il “contesto”Introducendo l’ambito dell’ubiquitous computing, si ` potuto notare come euna delle caratteristiche fondamentali delle macchine che popolano la no-stra quotidianit` debba essere la possibilit` di riconoscere le informazioni a arelative alla situazione in cui la computazione si svolge, o in altre paroledi contestualizzare la computazione. L’importanza di questa caratteristica,emersa prepotentemente nella prima met` degli anni novanta, ha portato aallo sviluppo di un filone di ricerca autonomo chiamato context-awarecomputing, argomento particolarmente attuale nel panorama di ricercacorrente. Nella maggior parte dei servizi attualmente sviluppati (es. i principaliportali online, come Google, Amazon, ecc...), in maniera trasparente all’u-tente si ricerca di utilizzare anche solo le pi` esplicite informazioni conte- ustuali, come lo posizione, la lingua o il dispositivo utilizzato, per migliorarel’esperienza dell’utente. Al contrario, altre informazioni interessanti nonvengono tenute in considerazione, come ad esempio il tempo speso all’in-terno del sistema, l’azienda di appartenenza o la mansione dell’utente, acausa della difficolt` di recuperare queste informazioni. Dove queste infor- amazioni siano disponibili, la context-awareness pu` aiutarci a sfruttare i odati rilevanti relativi al contesto. Una semplice possibilit` per recuperare queste informazioni ` chiederle a eesplicitamente 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 el’obiettivo di inserire dispositivi di computazione sia nell’ambiente che negli oggettiquotidiani, http://ttt.media.mit.edu/. 3 Computer Science and Artificial Intelligence Laboratory presso il MIT, http://www.csail.mit.edu/. 28
  • 34. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 29pato abbia un insieme predefinito di contesti, che pu` tradursi in pratica ocon il tralasciare alcune configurazioni rilevanti del contesto oppure, nellapi` immediata delle ipotesi, provvedere ad un cambiamento del contesto uunicamente su richiesta. Inoltre, gli utenti potrebbero essere preoccupatidella loro privacy e non voler rivelare al sistema il proprio attuale contesto,fornendo informazioni sbagliate. Per questi motivi, un approccio staticodi questo tipo non si adatta bene all’ambiente dinamico ed al principio ditrasparenza che si vuole ricercare. Di seguito verr` indagato innanzitutto ail reale significato di “contesto”, per poi definire in dettaglio le principalicaratteristiche che vengono richieste alle applicazioni context-aware.2.2.1 I primi approcci al contestoPrima di passare alle applicazioni pratiche dei concetti precedentementeintrodotti, appare necessario sviluppare una specifica definizione di contestoche possa essere utilizzata in maniera distintiva nel campo del context-awarecomputing. Per fare questo sono state analizzate numerose definizionidei ricercatori che hanno lavorato in questo ambito e hanno propostouna propria definizione all’interno del loro lavoro. In generale, moltepersone capiscono tacitamente cosa sia il contesto, ma hanno difficolt` ad aesplicitarlo, 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, vicinanzatra due entit` (siano queste oggetti o persone) e relativi cambiamenti alle aentit` stesse. Queste tipologie di definizioni che descrivono il contesto attra- averso esempi sono per` difficili da applicare. Quando vogliamo determinare ose un certo tipo di informazione sia contenuta nella definizione di contestoo meno, non ` chiaro come utilizzare la precedente definizione per risolvere eil 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 didefinizione risulta difficilmente applicabile in pratica. Le definizioni forniteda Schilit e Pascoe sono comunque le pi` vicine alla definizione operazionale uche ricerchiamo. Schilit [17] afferma che gli aspetti importanti del conte-sto rispondono a tre domande fondamentali: dove sei, cosa possiedi con te 29
  • 35. CAPITOLO 2. UBIQUITOUS COMPUTING E30 CONTEXT-AWARENESSe quali risorse sono nelle vicinanze. Pascoe [12], invece, definisce il con-testo come il sottoinsieme di stati fisici o concettuali di interesse per unaparticolare entit`. Queste definizioni sono entrambe troppo specifiche: in agenerale, il contesto ` tutto quello che risulta rilevante riguardo all’intera esituazione e l’insieme degli utenti. Per questo non ` possibile elencare quali easpetti di ogni situazioni siano rilevanti, in quanto questi variano da situa-zione a situazione. Le definizioni presentate finora non esauriscono quindila trattazione.2.2.2 Una duplice visione del contestoNonostante 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, eche offre agli sviluppatori di sistemi nuovi modi di concettualizzare leazioni umane e le relazioni tra queste azioni ed i sistemi computazionali.Dall’altra, invece, ` anche una nozione derivata dalle scienze sociali, eprestando un’attenzione analitica verso alcuni aspetti dell’ambito sociale.Tuttavia, trasferire le idee tra questi differenti domini intellettuali, risultaallo stesso tempo interessante ma inaspettatamente difficile: le idee, infatti,devono essere comprese all’interno dell’ambito intellettuale che fornisceloro un significato. Per questo, le difficolt` di traduzione di questi concet- ati da un ambito all’altro rappresentano un problema di primaria importanza. In linea di massima, Dourish afferma che le teorie sviluppate in questocampo 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 asemplificare i fenomeni complessi osservabili per ridurre ogni comportamen-to ad una legge matematica sottesa, le teorie positiviste cercano di ridurrei fenomeni sociali a modelli essenziali o semplificati che catturino patterngenerali. Di conseguenza, le teorie positiviste ricercano descrizioni oggettivee indipendenti dei fenomeni sociali, astraendo dai dettagli relativi all’occa-sione o ambiente particolare, spesso a favore della ricerca di trend statistici 30
  • 36. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 31o modelli idealizzati. Queste teorie, inoltre, sono per natura quantitative omatematiche. 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 atrasformando la componente sociale in una realt` oggettiva, ma basandosi asulla capacit` degli individui e dei gruppi di riconoscere ed orientarsi attra- averso quello che accade intorno a loro. Secondo questa visione, i fatti socialisono le propriet` emergenti della comunicazione, non predefinite o assolute, ama negoziate e contestate, soggette a continui processi di interpretazione ere-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- esenzialmente l’insieme delle interpretazioni. Queste teorie affermano che,ad esempio, le categorie astratte non sono classi che esistono a priori nellarealt`, ma sono imposte nel mondo dagli utenti stessi tramite le interazioni ache vengono effettuate tra di loro e con le classi stesse. Le teorie critiche tendono ad avere un pi` ampio scopo. Questo tipo di uteorie, associate spesso alla Frankfurt School e ai teorici Adorno, Horkhei-mer, Marcuse e Foucault, sono essenzialmente un’estensione dell’analisimarxista. Il materialismo marxista sostiene che le condizioni sociali edeconomiche sono la conseguenza di un processo storico di evoluzione, eriflettono un sistema dinamico (e generalmente non equo) in evoluzione,di potenza e di controllo tra categorie sociali. Essenzialmente, la naturadell’esistenza umana ` il prodotto di condizioni sociali ed economiche che eripropongono la medesima distribuzione storica di potenza e di controllodella societ` al proprio interno. Queste teorie estendono il materialismo astorico oltre il “prodotto” sociale ed economico della societ` stessa, dimo- astrando che le idee, la lingua e le modalit` di pensiero sono condizionate aallo stesso modo. Nonostante Dourish abbia incluso per completezza le teorie critiche, c’` eun’importante differenza tra le teorie positiviste e fenomenologiche. Larilevanza di questa distinzione ` che gli approcci ingegneristici (inclusi i eprincipali approcci nel campo dell’ubiquitous computing) ereditano una tra-dizione positivista, mentre molti approcci alle analisi sociali rilevanti per lamodellazione della HCI sono legati ad una metodologia fenomenologica. Da 31
  • 37. CAPITOLO 2. UBIQUITOUS COMPUTING E32 CONTEXT-AWARENESSuna parte, gli approcci positivisti postulano che la causa della vita socialesia indipendente dall’osservatore, dall’altra le teorie fenomenologiche affer-mano che le opere e l’interpretazione sono le sfaccettature principali di ogniazione sociale. I costrutti analitici delle motivazioni positiviste alle azionisociali 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 primoluogo fornirne una descrizione pi` accurata. u2.2.3 Definizione operativaSi deve ai ricercatori Anind K. Dey and Gregory D. Abowd [5] nel 2001 ladefinizione 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 uil contesto per un determinato scenario di un’applicazione. Se una por-zione di informazione pu` essere utilizzata per caratterizzare la condizione odi 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` apresenti in questo modello sono ovviamente l’utente, l’applicazione ed i sitituristici. Consideriamo ora due altre possibili informazioni relative a questoscenario: il tempo atmosferico e la presenza di altre persone. Utilizzandola definizione, l’obiettivo ora ` quello di discriminare se facciano parte o emeno del “contesto”. Il tempo atmosferico non influenza l’applicazione, inquanto questa verr` utilizzata indoor; per questo motivo, non ` considerata a e“contesto”. La presenza di altre persone, invece, pu` essere utilizzata per o 32
  • 38. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 33caratterizzare la condizione corrente: se un utente sta viaggiando con altrepersone, allora i luoghi che gli altri visitano potrebbero essere di partico-lare interesse per lui. Per questo motivo, questa informazione pu` essere oconsiderata “contesto”. Un’assunzione generale ` che il contesto consista unicamente in infor- emazioni 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. oAd esempio, sia che l’identit` di un utente sia riconosciuta implicitamente atramite un processo di visione artificiale, sia che venga fornita dall’utentestesso tramite un’apposita form di login, questa informazione fa comunqueparte del contesto. In generale, i ricercatori si sono spesso rivolti versole informazioni implicite in quanto i margini di esplorazione dell’interazio-ne uomo-macchina in questo campo sono molto pi` interessanti sfruttando uquesta tipologia di informazioni.2.2.4 Categorie di contestoUna categorizzazione delle principali tipologie di contesto potrebbe aiutarei progettisti di applicazioni context-aware ad identificare le informazioni delcontesto pi` utili per la loro applicazione. Possiamo partire dalle precedenti udefinizioni di contesto, presentate nella sezione 2.2.1, per identificare questecategorie. 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 acome aspetti principali del contesto dove sei, con chi sei e che risorse sonodisponibili nelle vicinanze. Le applicazioni context-aware ricercano la risposta alle domande chi `, edov’` e cosa sta facendo una data entit` e utilizzano queste informazioni e aper determinare il perch´ una situazione si stia verificando. L’applicazione ein realt` non determina realmente il perch´ una situazione si sia verificata, a ema il progettista deve riuscire a farlo. Lo sviluppatore, infatti, utilizza laconoscenza delle condizioni attuali e delle sue cause per codificare determi-nate azioni nell’applicazione. Riprendendo l’esempio della guida turisticapresentato nella sezione 2.2.3, un utente fornito di notebook si avvicina adun luogo per lui interessante e le informazioni rilevanti riguardo quel luogovengono visualizzate dinamicamente sul computer. In questa situazione, ilprogettista ha codificato nell’applicazione la consapevolezza che, quando un 33
  • 39. CAPITOLO 2. UBIQUITOUS COMPUTING E34 CONTEXT-AWARENESSutente si avvicina ad un determinato luogo (il contesto prossimo), il suocomportamento dimostri interesse verso il luogo stesso (il perch´ ), per cui el’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 udi altre. In particolare, posizione, identit`, attivit` e tempo. L’unica a adifferenza tra questo elenco e la definizione fornita da Ryan e al. ` l’utilizzo edel termine “attivit` ” piuttosto che “ambiente”: mentre il termine “ambien- ate” ` un sinonimo di contesto e non aiuta nella sua definizione, l’utilizzo di e“attivit` ” risponde alla fondamentale domanda ‘cosa sta accadendo nella asituazione corrente’. Le categorie fornite da Schilit e al., invece, includonounicamente informazioni riguardo a posizione e indentit`, mentre per ca- aratterizzare una situazione, c’` bisogno anche di informazioni riguardo alle eattivit` svolte e al tempo. La posizione, l’identit`, il tempo e l’attivit` a a acostituiscono dunque le tipologie primarie di contesto, necessarie per ca-ratterizzare la situazione corrente di una particolare entit`: queste tipologie adi contesto non solo rispondono alle domande chi, cosa, dove e quando, mafunzionano anche come indici rispetto ad altre fonti di informazioni con-testuali. Ad esempio, data l’identit` di una persona, possiamo acquisire anumerose altre informazioni collegate, come il numero di telefono, l’indiriz-zo, le email, la data di nascita, la lista degli amici, le relazioni con altrepersone dell’ambiente, ecc... Con la posizione di una persona, possiamo de-terminare quali altri oggetti o persone siano nelle vicinanze e quali azionistiano avvenendo nell’ambiente circostante. Da questi esempi, dovrebbe es-sere evidente che le tipologie primarie relative ad un’entit` possono essere autilizzate come indici per ottenere le tipologie secondarie di contesto perla stessa entit` (es. l’indirizzo email), oppure le tipologie primarie per una adifferente entit` (es. persone nello stesso luogo). a In questa categorizzazione iniziale, troviamo un semplice sistema a duelivelli: le quattro parti primarie del contesto gi` identificate rappresentano ail primo livello. Tutte le rimanenti tipologie di contesto rappresentano ilsecondo livello. Le parti secondarie del contesto condividono una caratteri-stica comune: possono essere indicizzate tramite il contesto primario, perch´ esono attributi dell’entit` tramite il contesto primario. Ad esempio, il nu- amero di telefono di un utente fa parte del contesto secondario e pu` essere oottenuto utilizzando l’identit` dell’utente stesso come indice in uno spazio ainformativo, come una rubrica telefonica. Ci sono alcune situazioni in cui 34
  • 40. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 35sono necessarie svariate informazioni del contesto primario come indice inuno spazio informativo. Le previsioni del tempo, ad esempio, sono un’in-formazione relativa al contesto in una guida turistica outdoor, che utilizzaqueste 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 aricercare altri contesti rilevanti. Le quattro tipologie principali di contestoindicano il tipo di informazioni necessarie per caratterizzare una situazioneed il loro utilizzo come indici fornisce un modo di utilizzo ed organizzazio-ne del contesto stesso. Ora che ` stata fornita una definizione operativa edi 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 principalicaratteristiche.2.3 Mobile context-awarenessCome gi` accennato in precedenza, il campo del context-aware computing arappresenta uno dei filoni di ricerca pi` battuti negli ultimi anni. Soprat- ututto nell’era in cui lo sviluppo tecnologico ha portato alla realizzazione diuna fascia di dispositivi sempre pi` compatti e portatili (denominati mobile udevices), sfruttare il contesto in cui un’applicazione viene lanciata appareuna prerogativa sempre pi` fondamentale. Negli ultimi anni, infatti, l’im- upiego di questi dispositivi ha spostato definitivamente la computazione dalclassico contesto desktop, aprendo infinite possibilit` di utilizzo e nuove ra- amificazioni applicative. Tramite i sensori a disposizione, si pu` raccogliere ouna miriade di informazioni riguardo all’utente ed al contesto attorno a lui,cos` come ` stato definito nella sezione 2.2.3: tracciando i comportamenti ı edel proprio proprietario ed analizzando i dati cos` ottenuti, il dispositivo ınon solo pu` svolgere funzioni utili in relazione al contesto attuale, ma mo- odellare ed anticipare le intenzioni dell’utente. Questo rappresenta realmenteil nuovo livello di context-awareness che si ricerca dalle applicazioni mobileall’avanguardia. 35
  • 41. CAPITOLO 2. UBIQUITOUS COMPUTING E36 CONTEXT-AWARENESS2.3.1 I primi approcci alla context-awarenessLa prima definizione delle applicazioni context-aware fornita da Schilit eTheimer nel 1994 [18] ha ristretto la definizione da “applicazioni sempli-cemente a conoscenza del contesto”, ad “applicazioni che si adattano alcontesto”. Comunque sia, ` universalmente riconosciuto che il primo lavo- ero di ricerca nel campo della context-awareness ` l’Olivetti Active Badge, esviluppato nel 1992. Successivamente, ci sono stati numerosi tentativi didefinire il context-aware computing, di cui di seguito vengono riportati iprincipali. Context-aware ` diventato in qualche modo sinonimo di altri etermini spesso citati nell’informatica: adaptive, reactive, situated, context-sensitive e environment-directed. Le precedenti definizioni di context-awarecomputing rientrano in due macro-categorie: quelle che utilizzano il contestoe quelle che si adattano al contesto. Per primo verr` discusso il caso pi` generale di utilizzo del contesto. a uHull e al. [10] e Pascoe e al. [12] definiscono il context-aware computingcome l’abilit` di dispositivi computazionali di individuare e percepire, in- aterpretare 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] inizianoad introdurre la nozione di “adattamento” definendo la context-awarenesscome il lavoro che avrebbe portato all’automazione di un sistema softwarebasato sulla conoscenza del contesto dell’utente. Salber e al. [15] defini-scono la context-awareness come l’abilit` di fornire la massima flessibilit` a ada parte di un servizio computazionale basato sulla percezione real-time delcontesto. Le seguenti definizioni si riconducono, invece, alla pi` specifica ucategoria “adattamento al contesto”. Molti ricercatori definiscono le ap-plicazioni context-aware come applicazioni che dinamicamente modificanoo adattano il loro comportamento in base al contesto dell’utente o dell’ap-plicazione. Pi` specificamente, Ryan [14] ne parla come applicazioni che umonitorano 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- adirittura pi` restrittiva rispetto alle precedenti in quanto identifica gi` le u amodalit` 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
  • 42. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 37dell’utente, percepito da appositi sensori. Fornisce inoltre una visione ulte-riormente ristretta affermando che queste azioni possono concretizzarsi nelpresentare informazioni all’utente, eseguire un programma coerentementecon il contesto attuale o configurare un apposito layout grafico. Infine,l’ultima definizione analizzata ` quella del ricercatore Fickas e al. [8] che edefiniscono le applicazioni environment-directed (termine praticamente uti-lizzato come sinonimo di context-aware) come applicazioni che monitorano icambiamenti nell’ambiente e adattano il loro comportamento in base a lineeguida predefinite, configurate dall’utente.2.3.2 Definizione operativaCome per quanto riguarda il concetto di “contesto”, riportiamo di seguitola 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- eaware computing. Le definizioni pi` specifiche della categoria “adattamento ual contesto” richiedono che il comportamento di un’applicazione sia modi-ficato per essere considerata context-aware. Quando si prova ad applicarequeste definizioni per discriminare le applicazioni context-aware, si scopreche si adattano difficilmente. Ad esempio, un’applicazione che semplice-mente mostri il contesto dell’ambiente in cui risiede l’utente non modifica ilsuo comportamento, ma ` sicuramente context-aware. Se invece utilizziamo ele definizioni meno generali, queste applicazioni non sarebbero classificatein questo modo. Per questo ` stata scelta una definizione pi` generale, che e upossa descrivere tutte le applicazioni di questa tipologia. Questa definizione, infatti, ` pi` generale di quella fornita da Hull e al. o e uda Pascoe e al.: loro impongono che i sistemi context-aware da loro descrittiindividuino, interpretino e rispondano al contesto. La descrizione operativafornita sopra, invece, necessita unicamente che rispondano al contesto, per-mettendo che l’individuazione e l’interpretazione del contesto sia effettuatada altre entit` computazionali. Inoltre differisce dalle altre definizioni gene- arali fornite nella sezione 2.3.1, in quanto focalizza l’attenzione sull’utente,non limitando la consapevolezza (awareness) all’interfaccia applicativa, non 37
  • 43. CAPITOLO 2. UBIQUITOUS COMPUTING E38 CONTEXT-AWARENESSrichiedendo che l’applicazione svolga servizi automatizzati ed, infine, nonrichiedendo un’acquisizione real-time del contesto.2.3.3 Caratteristiche delle applicazioni context-awareNella sezione 2.2 ` gi` stata introdotta l’importanza di un approccio di- e anamico e non intrusivo nella rilevazione del contesto dell’utente, evitan-do la presenza di contesti predefiniti a cui ricondurre i casi reali: questastaticit`, spesso dovuta alla mancanza di informazioni concettuali disponi- abili, si concretizza spesso nella richiesta esplicita di informazioni all’utente,portando in primis ad una minor utilizzabilit` del sistema. Queste carat- ateristiche rappresentano quindi le linee guida generali durante la progetta-zione di applicazioni context-aware. Per comprendere pi` a fondo il campo udella context-awareness, nelle sezioni successive verranno presentate alcunecaratteristiche comuni a queste tipologie di applicazioni.Categorizzazione di SchilitAll’interno di questo filone di ricerca, sono stati due i principali tentatividi sviluppare una tassonomia simile. Il primo si deve a Schilit e al. [17] ed` costituito da due dimensioni ortogonali: se la computazione ` recuperaree eun’informazione o eseguire un comando o se invece ` eseguito manualmente eo automaticamente. Le applicazioni che recuperano manualmente informa-zioni per l’utente in base al contesto disponibile, sono chiamate applicazionidi selezione prossima. Questa ` una tecnica di interazione dove ` presentata e euna lista di oggetti (printers) o luoghi (offices), in cui gli oggetti rilevantiper l’utente sono enfatizzati o resi pi` facili da scegliere. Invece, le appli- ucazioni che recuperano automaticamente informazioni per l’utente in baseal contesto disponibile, sono classificate come riconfigurazione contestualeautomatica. Questa ` una tecnica di livello o di sistema che crea un legame eautomatico con una risorsa disponibile in base al contesto corrente. Un’al-tra categoria consiste nelle applicazioni che eseguono manualmente comandidell’utente in base al contesto attuale, classificate quindi come applicazio-ni a comando contestuale. Sono in pratica servizi eseguibili resi disponibilitramite il contesto dell’utente o la cui esecuzione ` modificata in base al econtesto dell’utente. Infine, le applicazioni che eseguono automaticamentecomandi per l’utente basandosi sul contesto disponibile, utilizzano azioni 38
  • 44. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 39context-triggered. Quest’ultima tipologia di servizi ` eseguita automatica- emente quando la giusta combinazione del contesto si delinea ed ` basata esull’applicazione di semplici regole “se-quindi”.Categorizzazione di PascoePi` recentemente Pascoe ha proposto anche una tassonomia delle caratte- u `ristiche context-aware. E presente una considerevole sovrapposizione conla tassonomia appena illustrata, ma vi sono comunque differenze cruciali.Pascoe [12] ha sviluppato una tassonomia che ha lo scopo di identificare leprincipali caratteristiche nell’ambito della context-awareness, in contrappo-sizione con la tassonomia presentata in precedenza, che identificava le classidelle applicazioni context-aware. In realt`, le caratteristiche presentate di aseguito possono essere mappate con semplicit` sulle classi di applicazioni adescritte 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
  • 45. CAPITOLO 2. UBIQUITOUS COMPUTING E40 CONTEXT-AWARENESS Sia Pascoe che Schilit elencano l’abilit` di esplorare le risorse rilevanti aper il contesto dell’utente, l’abilit` di eseguire un comando automaticamen- ate in relazione al contesto e l’abilit` di visualizzare informazioni rilevanti aper l’utente. Pascoe sviluppa ulteriormente il concetto legato alla capacit` adi visualizzare informazioni significative, includendo la visualizzazione delcontesto e non solo delle informazioni che necessitano poi di un’ulterioreselezione (es. visualizzare la posizione dell’utente invece che la listadi printers in modo che l’utente possa sceglierne uno). La tassonomiadi Pascoe comprende una categoria non presente in quella di Schilit:l’aumento contestuale, cio` l’abilit` di associare dati digitali al contesto e adell’utente. Infine, la tassonomia di Pascoe non supporta la presentazionedi comandi rilevanti in un determinato contesto (che prende il nome dicomandi contestuali nella tassonomia di Schilit).Categorizzazione di Dey-AbowdLa categorizzazione dei ricercatori Dey e Abowd [1] presentata in segui-to combina idee prese dalle due precedenti tassonomie introducendo treprincipali differenze. Similmente alla tassonomia di Pascoe, ` una lista di ecaratteristiche context-aware che le applicazioni devono supportare. Sonostate identificate tre categorie: • presentazione delle informazioni e dei servizi all’utente • esecuzione automatica di un determinato servizio • etichettatura del contesto per un successivo recupero. La presentazione ` la combinazione dei concetti di selezione prossima ee comandi automatici, proposti da Schilit. A questi ` stata aggiunta la enozione di Pascoe della presentazione del contesto all’utente (come fontedi informazione). L’esecuzione automatica ` la stessa delle azioni context- etriggered di Schilit e dell’adattamento contestuale di Pascoe. L’etichettatura`, invece, un concetto analogo all’aumento contestuale di Pascoe.e Sono state introdotte, per`, due importanti caratteristiche distintive: la odecisione di non differenziare tra informazioni e servizi e la rimozione del-l’esplorazione delle risorse locali come caratteristica. Non ` stata utilizzata e 40
  • 46. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 41la dimensione introdotta da Schilit che contrappone le informazioni ai ser-vizi, come distinzione tra le categorie: nella maggior parte dei casi, infatti,sarebbe stato troppo difficile distinguere tra presentazione di informazioni epresentazione di servizi. Ad esempio, Schilit scrive che una lista di printersordinata per vicinanza ` un esempio del fornire all’utente informazioni. Se equesta lista, per`, sia effettivamente una lista di servizi o una lista di infor- omazioni dipende unicamente da come l’utente attualmente utilizza questeinformazioni. Se l’utente scorre la lista di printers giusto per familiarizzarecon i nomi delle risorse vicine, la sta utilizzando come una lista di informa-zioni. In qualsiasi caso, comunque, se l’utente sceglie un printer dall’elencoper effettuare una stampa, sta utilizzando la lista come un elenco di servizi.Piuttosto che provare ad indovinare le intenzioni dell’utente, ` stato scelto edi trattare in maniera simile informazioni e servizi. Inoltre, si ` scelto, secondo questa interpretazione, di non utilizzare lo esfruttamento di risorse locali o la ricerca di risorse come una caratteristicacontext-aware. Questa operazione ` presente nelle due tassonomie prece- edenti ed ` chiamata riconfigurazione contestuale automatica e rilevazione di erisorse contestuali rispettivamente da Schilit e Pascoe. In questo caso non ` econsiderata una categoria separata, ma piuttosto una parte delle prime duecategorie. La rilevazione di risorse ` l’abilit` di localizzare nuovi servizi in e abase al contesto dell’utente: questa abilit`, quindi, non ` particolarmente a ediversa dal scegliere un servizio in base al contesto. Anche in questo caso,possiamo utilizzare l’esempio dei printers introdotto per Schilit. Quandoun utente entra in un ufficio, la sua posizione cambia e la lista di printersvicine si modifica a sua volta: le stampanti in questa lista possono essereaggiunte, rimosse o riordinate (in base alla prossimit`, ad esempio). Que- asta operazione ` un esempio di esplorazione delle risorse o semplicemente euna presentazione di informazioni e servizi? Piuttosto che considerarla unacategoria separata, ` stato preferito separarla in due categorie esistenti non eesclusive: la presentazione di informazioni e servizi e l’esecuzione automati-ca dei servizi. Quando un’applicazione presenta informazioni all’utente, ca-de in questa prima categoria; similmente, quando automaticamente fornisceun servizio, cade nella seconda. 41
  • 47. CAPITOLO 2. UBIQUITOUS COMPUTING E42 CONTEXT-AWARENESS2.3.4 Applicazione agli smartphoneLa context-awareness ` un ambito di ricerca molto popolare nel campo edell’ubiquitous computing, in cui i ricercatori hanno studiato applicazionisin dai primi anni novanta. Solo successivamente, con lo sviluppo hardwaredei moderni smartphone, sempre pi` spesso dotati di accelerometri, com- upassi digitali e sensori di luminosit`, le possibili applicazioni pratiche sono adiventate molteplici e sempre pi` alla portata di tutti. Una maggiore capa- ucit` computazionale delle nuove CPU permette il lancio di svariati servizi e aapplicazioni contemporaneamente e le ultime GPU sul mercato fornisconointerfacce utente sempre pi` ricche ed intuitive. u Inoltre, gli utenti di queste tecnologie mobile sempre pi` spesso sono uconnessi “always on” alla rete internet, sfruttando le svariate tipologie diconnessione presenti sul proprio dispositivo (dal supporto Wi-Fi alle pi` umoderne reti 3G), sfruttando i vantaggi della velocit` della connessione per al’utilizzo di servizi come l’invio di email, la sincronizzazione tra calendari,social networking ed altre applicazioni online. Questi sensori “virtuali ” of-frono ai dispositivi mobile una lunga serie di fonti informative, come i socialnetwork, le preferenze dell’utente, le playlist musicali, ecc... La fusione diqueste fonti con i tradizionali sensori “fisici ” permette una migliore inferen-za del contesto e, conseguentemente, un range molto pi` ampio di applica- uzioni mobile. Per questi motivi, gli sviluppatori software stanno rivolgendola loro attenzione alle piattaforme mobile per smartphone: la continua cre-scita dei principali App Store, in primis Apple Store e Android Market, edil numero di applicazioni contenute, sempre pi` spesso disponibili in licenza ugratuita, confermano questo trend, destinato a consolidarsi. I principali servizi mobile context-aware, come Google Latitude4 o La-yar5 , si focalizzano principalmente sulla posizione e sull’interazione dell’u-tente con il dispositivo. Nonostante la posizione sia un’area del contestomolto utile, non ` di certo l’unica: pensando al range ed all’eterogeneit` e adelle tipologie di informazioni disponibili, menzionate in precedenza, stannoemergendo applicazioni commerciali mobile che utilizzano varie informazioni 4 Google Latitude ` un servizio web di geolocalizzazione sviluppato da Google. La- etitude permette a un utente dotato di smartphone di essere localizzato e tracciato daaltre persone, in base alla propria configurazione di privacy. Per ulteriori informazioni,http://www.google.it/mobile/latitude/ 5 vedi sezione 2.5.1. 42
  • 48. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 43sul contesto, come Foursquare6 . ` E presente molto materiale di ricerca riguardo le tecnologie abilitantinel campo della context-awareness, come la fusione di sensori e l’inferen-za del contesto, ma non molto ancora sulle applicazioni pratiche di questilavori. Del resto, fattori come la disponibilit` di sensori, la velocit` del- a ala connessione e la potenza di calcolo, pregiudicano il possibilie utilizzo diun’applicazione context-aware, in quanto il servizio risulta difficilmente uti-lizzabile a fronte di fallimenti nel rilevamento o nell’inferenza. Per questomotivo, i nuovi dispositivi mobile e le piattaforme di sviluppo disponibili,aprono ora nuovi scenari di utilizzo e ricerca, rendendo la context-awarenessun campo di ricerca particolarmente attuale.2.3.5 Sicurezza e privacy in ambito mobileAvendo a che fare sempre pi` spesso con dispositivi capaci di carpire info- umazioni sull’utente, come posizione, identit` e attivit` svolte, la sicurezza a anella gestione di queste informazioni assume un’importanza crescente. Inquesto contesto, in cui l’utente si trova ad avere a che fare, in maniera pi` o umeno consapevole, con smart devices che collezionano dati sensibili spessoin maniera trasparente, il potenziale dovuto alla raccolta e ad un suo utilizzoerrato ` un aspetto critico: queste informazioni possono infatti essere utiliz- ezate da malintenzionati o semplicemente da persone spinte da curiosit` peraun’azione di stalking verso l’utente ignaro. Per questi motivi, la necessit` di aprivacy ` ovvia, forse addirittura di pi` della sicurezza o della fiducia verso e uil sistema: senza nessuna informazione riguardo alla gestione della propriaprivacy gli utenti potrebbero infatti rifiutare questa tecnologia. In accordocon la definizione di Alan Westin [20]: La privacy ` la necessit` degli individui, dei gruppi o delle e a istituzioni di determinare quando, come ed a quale scopo le informazioni riguardo se stessi sono comunicate ad altri. In pratica, la privacy di per s´ consiste nel proteggere le informazio- eni personali degli utenti, progettando nuove metodologie per controllare e 6 Foursquare ` un social network creato da Dennis Crowley e Naveen Selvadurai, ba- esato sulla geolocalizzazione disponibile tramite web o applicazioni mobile. Gli uten-ti del servizio eseguono il check-in tramite la versione browser del sito o attraver-so applicazioni su dispositivi che utilizzano il GPS. Per maggiori informazioni, http://www.foursquare.com/. 43
  • 49. CAPITOLO 2. UBIQUITOUS COMPUTING E44 CONTEXT-AWARENESSgestire la privacy. Il concetto di controllo della privacy, in generale, nonriguarda unicamente la definizione di regole per forzarla, ma anche le mo-dalit` in cui la privacy ` gestita e controllata dinamicamente in accordo a econ i cambiamenti nella politica stessa dell’utente o con la mobilit` da un aambiente all’altro. Westin identifica il problema ed elenca alcuni principifondamentali delle corrette pratiche di gestione delle informazioni: 1. Apertura e trasparenza: le attivit` di registrazione delle a informazioni non devono essere mantenute segrete; 2. Partecipazione individuale: l’utente deve avere la possibilit` di a visualizzare i records; 3. Limite di raccolta: la raccolta di informazioni deve essere appropriata all’applicazione che la richiede; 4. Qualit` dei dati: la raccolta dei dati deve essere accurata e rilevante a per l’applicazione; 5. Utilizzo limitato: i dati devono essere utilizzati unicamente per gli scopi specifici dichiarati e solo dalle persone autorizzate; 6. Sicurezza appropriata: devono essere effettuati gli sforzi appropriati per rendere sicuri i dati; 7. Responsabilit`: a chi gestisce e custodisce i dati deve esserne responsabile. Questi principi coprono perfettamente il problema della privacy pre-sentato in precedenza. Le linee guida introdotte presentano l’assunzioneimplicita dell’interazione uno-ad-uno (il sistema che registra l’utente): nelcaso dello smart environment, o comunque quello in cui sono utilizzati pi` udispositivi mobile, i soggetti dell’interazione diventano molteplici, e quindidevono essere gestiti in base a ruoli e regole predefiniti. Questa precisazionenon intacca comunque la validit` dei principi discussi, ma focalizza l’atten- azione sull’importanza che l’utente sia consapevole delle reali interazioni chestanno avvenendo nell’ambiente. 44
  • 50. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 452.4 Alcuni esempi di applicazioniPer poter comprendere al meglio i problemi e gli aspetti del modello affron-tato, di seguito vengono presentate alcune applicazioni reali interessantiche forniscono servizi context-aware. Questa panoramica, oltre all’appro-fondimento dei concetti introdotti, ha l’obiettivo di focalizzare l’attenzionesulla necessit` di raccogliere informazioni inerenti l’ambiente in cui si trova al’utente per sviluppare applicazioni realmente “smart”.2.4.1 ContextPhoneContextPhone ` una piattaforma software sviluppata dal ricercatore Mika e `Raento e al. [13] presso l’Universit` di Helsinki. E costituito da quattro amoduli interconnessi, forniti come un set di librerie C++ e componentisoftware e pu` essere installata su tutti i dispositivi che utilizzano Symbian oOS o la piattaforma Nokia Series 60 Smartphone7 . Lo scopo di questolavoro ` quello di fornire agli sviluppatori un sistema che realizzi alcune einteressanti feature propriamente context-aware: le piattaforme disponibiliattualmente per i dispositivi mobili, infatti, nonostante siano programmabilinon forniscono direttamente queste funzionalit`. aObiettivi principaliDurante lo sviluppo di questo progetto, sono stati seguiti alcuni obiettiviprincipali: 1. fornire il contesto come risorsa dell’interazione sociale, non sono un input per le funzioni di adattamento della macchina; 2. incorporare le applicazioni esistenti, utilizzando le principali funzio- nalit` gi` disponibili per gli smartphone, come ad esempio i servizi di a a messaggistica e chiamata; 3. offrire un’interazione veloce e non invadente, lasciando spesso le funzioni che non necessitano di interazione diretta in background; 4. assicurare robustezza, provvedendo all’implementazione di funzioni di ripristino e salvataggio dei dati; 7 per maggiori informazioni, http://www.series60.com. 45
  • 51. CAPITOLO 2. UBIQUITOUS COMPUTING E46 CONTEXT-AWARENESS 5. lasciare all’utente il controllo dei livelli di applicazione, dalla gestione della batteria alla connettivit` della rete; a 6. enfatizzare la velocit` di risposta, minimizzando la latenza delle a applicazioni; 7. permettere un rapido sviluppo delle applicazioni, fornendo le strutture dati e le primitive necessarie per uno sviluppo iterativo e veloce.Architettura della piattaformaL’architettura di ContextPhone ` costituita da quattro moduli principali, epresentati in figura 2.4. Figura 2.4: Architettura di ContextPhone 46
  • 52. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 47 • Sensori: questo sistema pu` essere utilizzato per rilevare, processare, o memorizzare e trasferire informazioni relative al contesto. Il conte- sto rilevato o dedotto pu` innescare azioni all’interno del telefono o o comunicare con il mondo esterno. I sensori messi a disposizioni dai moderni dispositivi, oltre all’abilit` di monitorare lo stato e l’utilizzo a interno del telefono, di osservare la rete e di utilizzare connessioni wi- reless, forniscono un ambiente contestuale molto ricco. ContextPhone supporta quattro tipologie di sensori: 1. posizione, inclusi GSM, ricevitore GPS, Bluetooth, ecc... 2. interazione utente, incluse le applicazioni attive, lo stato del sistema, i profili di allarme, lo stato della batteria, ecc... 3. comportamento comunicativo, inclusi le chiamate e gli avvisi di chiamata, le registrazioni delle chiamate, gli SMS ricevuti ed inviati, ecc... 4. ambiente fisico, inclusi tutti i dispositivi Bluetooth vicini, marker di riconoscimento ottico, ecc... • Comunicazioni: ContextPhone supporta le comunicazioni sia locali (infrarossi e Bluetooth) che wide-area (GSM e GPRS): allo scopo di utilizzare questi sistemi per lo sviluppo di applicazioni su tale piatta- forma, sono disponibili protocolli implementativi e servizi di pi` alto u livello che si basano sui principali standard di comunicazione. La piat- taforma ContextPhone ` inoltre capace di gestire invio e ricezione di e SMS e MMS, rendendo disponibili questi servizi ai progettisti soft- ware. Per distribuire informazioni e notifiche riguardo la connettivit` a del dispositivo, viene utilizzato il protocollo estensibile di messagging Jabber 8 . • Applicazioni personalizzabili: gli sviluppatori possono utilizza- re il set di applicazioni messe a disposizione da ContextPhone per estendere le potenzialit` della comunicazione person-to-person. Que- a ste applicazioni funzionano molto similmente a quelle built-in nei re- lativi dispositivi, ma danno ai progettisti la possibilit` di integrarne a ed estenderne le funzionalit`. a 8 per ulteriori informazioni, http://www.jabber.org. 47
  • 53. CAPITOLO 2. UBIQUITOUS COMPUTING E48 CONTEXT-AWARENESS • Servizi di sistema: applicazioni non intrusive richiedono la minima interazione con l’utente e funzionano in background senza disturbare le attivit` in corso. La robustezza ` una caratteristica cruciale delle a e applicazioni pervasive su smartphone: molti componenti ed applica- zioni prevedono infatti strategie automatiche di recupero e gestione degli errori.Principali servizi implementatiLa piattaforma di ContextPhone ` stata utilizzata da molti gruppi di ericercatori per sviluppare applicazioni legate al contesto, utilizzando lefeatures messe a disposizione dalla piattaforma, semplicemente prendendole informazioni legate al contesto ed inviando feedback tramite i canali dicomunicazione messi a disposizione. Le seguenti sono le tre applicazioni pi` usignificative basate su ContextPhone e contenute all’interno dello stessopackage. ContextLogger memorizza i dati relativi alla mobilit`. L’obiettivo ` a e quello di fornire ai ricercatori uno strumento robusto ed affidabile che richieda un controllo e un mantenimento minimo, acquisendo dati in maniera non intrusiva. ContextLogger riceve notifiche riguardo al contesto dai sensori e da applicazioni personalizzabili, scrive questi dati in un file locale e pe- riodicamente carica questo file in un server predefinito tramite un background upload. Visto che questa applicazione non richiede l’inte- razione con l’utente, la sua attivit` non ` tipicamente visibile, per cui a e non intrusiva. ContextLogger ` stato utilizzato anche dal Technical Research Centre e of Finland (VTT) per raccogliere dati sui dispositivi Bluetooth nelle vicinanze per modellare i pattern delle interazioni uno-ad-uno in un gruppo di lavoro. Inoltre, il Reality Minding project del Media Lab presso il MIT tramite questa applicazione ha collezionato dati relativi alla vicinanza e alle comunicazioni tra studenti, analizzando le dina- miche sociali e di rete al fine di definire un modello utilizzabile per misurare la solidit` e l’evoluzione delle relazioni sociali tra individui. a 48
  • 54. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 49ContextContacts permette agli utenti di rappresentare e scambiare in- formazioni contestuali. Piuttosto che sviluppare agenti che decidano se l’utente chiamato ` disturbabile (e bloccare la chiamata di conse- e guenza), l’ipotesi di lavoro ` di fornire informazioni relative al suo e attuale contesto. Questi spunti dovrebbero facilitare le decisioni di quando chiamare e quale canale di comunicazione utilizzare. Que- sta applicazione fornisce performance molto simili alla corrispettiva funzione built-in, memorizzando localmente il contesto del chiama- to ed utilizzando il canale di Jabber come notifica delle presenze. ContextContacts ha tre componenti principali: • il presence publisher, che tramite Jabber invia da altri utenti i dati ottenuti dai sensori del dispositivo locale; • il presence listener, che riceve i dati dei sensori dal canale Jabber e li integra nell’interfaccia grafica del programma; • le possibili personalizzazioni dell’applicazione.ContextMedia si basa sull’idea dei locative media, cio` dell’associazione e di una posizione fisica ad ogni media, concetto successivamente svi- luppato come situated media, nei quali viene associata una descrizione della situazione in cui il media stesso ` stato creato. ContextPhone e realizza un’applicazione con questo scopo, fornendo insieme ai file una serie di informazioni contestuali. ContextMedia utilizza svariati sensori per annotare le informazioni, il media sensor per notificare la raccolta e il servizio di upload in back- ground per condividere i media. Gli utenti possono inoltre utilizzare i canali di messaggistica Jabber per notificare altri utenti in real-time della condivisione, permettendo lo sviluppo di differenti pattern di condivisione. Per assicurare che nessun dato venga perso anche nel caso l’upload non vada subito a buon fine, durante il processo Con- textMedia memorizza le infomazioni dell’utente e lo stato dell’upload nella memoria non-volatile del dispositivo. Il media publisher utilizza gli standard del telefono e le caratteristiche built-in per catturare i media, dopo di che appare automaticamente una finestra di upload. ContextMedia ` il risultato della collaborazione del team di Context- e Phone con l’Aware Project presso il Media Lab della University of Art 49
  • 55. CAPITOLO 2. UBIQUITOUS COMPUTING E50 CONTEXT-AWARENESS and Design di Helsinki. Il team finlandese ha scelto ContextMedia per esplorare il campo delle pubblicazioni collettive e dei mobile media.2.4.2 UbiPhoneBasato sull’esperienza delle piattaforme context-aware gi` realizzate, come aContextPhone, iCAM e altri, UbiPhone ` una piattaforma realizzata dai ericercatori Wang, Hwang e Tsai [11] presso la National Chung-Cheng Uni-versity di Taiwan, con l’obiettivo di fornire un servizio di telefonia context-aware incentrato sull’utente, che semplifichi la comunicazione con la personachiamata una volta scelta all’interno della rubrica. Il sistema in manieraautomatica dovrebbe connettersi all’utente chiamato utilizzando la meto-dologia migliore in base alle informazioni contestuali attuali, come la posi-zione di entrambi gli utenti, lo stato corrente, i sistemi telefonici disponibili,i calendari, ecc... Vista la natura dei servizi implementati, la gestione delcontesto ` un aspetto fondamentale: il framework di UbiPhone per la ge- estione di queste informazioni include operazioni come la rappresentazione,il recupero e la deduzione del contesto, in base allo stato dell’arte delletecnologie.Architettura della piattaformaL’architettura di UbiPhone ` mostrata in figura 2.5. I server si dividono in edue principali categorie: i service provider server ed i context managementserver. I primi forniscono i servizi intelligenti rivolti all’utente tramite l’a-iuto di un sistema di inferenza. Gli altri, invece, agiscono principalmentecome un database semantico per la gestione dei dati “grezzi” raccolti dal-l’ambiente. I client includono invece gli smart devices in questione, i sensorie gli altri dispositivi di rete. Tra i server e i client, ` stato progettato un emiddleware come interfaccia per la trasmissione di tutti i messaggi ed i se-gnali. I web services sono stati adottati per l’implementazione di questomiddleware: pi` nello specifico, sia le informazioni contestuali acquisite dal udispositivo dell’utente, sia i messaggi da spedire dal client al server sono in- `capsulati in messaggi SOAP di tipo XML. E stato inoltre utilizzato il JavaWeb Service (JWS) come framework per la generazione dei file contenentila descrizione WSDL, poi pubblicati sul server utilizzando l’Apache TomcatServlet Container. 50
  • 56. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 51 Figura 2.5: Architettura di UbiPhone Gli agenti svolgono le principali funzioni di ricerca del servizio, recu-pero del contesto ed acquisizioni statistiche. Quando ogni agente vienenotificato di certi eventi dal sensore del dispositivo, fornisce uno specifi-co servizio. I call agent e messaging agent aiutano l’utente a connettersial giusto canale di comunicazione disponibile in quel momento. Gli statusagents possono cambiare dinamicamente lo stato dell’utente in base allasua posizione, agenda o stato della rete. Gli schedule agent, location agente network status agent, invece, sono progettati per trasmettere le relativeinformazioni al context management server. Gli statistic agent sviluppanole statistiche riguardo all’utilizzo del dispositivo, basandosi sui record dellechiamate, dai log posizionali, ecc...aggiornando iterativamente le statisticheprecedentemente condotte.Principali servizi implementatiTra tutti i servizi sviluppati su questa piattaforma, i seguenti sono quellimaggiormente rilevanti nell’ottica della context-awareness e dello sviluppodi servizi human-centered. 51
  • 57. CAPITOLO 2. UBIQUITOUS COMPUTING E52 CONTEXT-AWARENESSUbiquitous Call Service, permette di contattare un utente presente in rubrica, unicamente cliccando sul suo contatto. Il call agent sullo smartphone comunicher` quindi con il server fornitore del servizio e a sceglier` quello pi` appropriato per l’utente, utilizzando il protocol- a u lo VOIP piuttosto che lo standard GSM, o suggerendo un messaggio di testo nel caso la persona desiderata non sia disponibile. Inoltre, nel caso il servizio VOIP non sia disponibile per uno dei due uten- ti in questione, l’agente sceglier` dalla rubrica il numero dell’ufficio a piuttosto che quello del cellulare, in base alla posizione dell’utente chiamato. Nel caso in cui l’utente sia occupato, lo strumento migliore per contattarlo sar` suggerito dal message agent. aAnyCall Service fornisce all’utente la possibilit` di chiamare l’utente pi` a u appropriato all’interno di un gruppo (similmente al servizio anycast delle reti IP). Nel caso di un incidente, ad esempio, l’utente necessite- rebbe di chiamare qualcuno della famiglia per avvisare dell’accaduto: in questa situazione di emergenza, ogni persona all’interno della cer- chia familiare potrebbe aiutare l’utente. Questo servizio, selezionan- do il gruppo interessato, effettuer` una chiamata ad un membro del a gruppo disponibile a rispondere al telefono in quel momento. Tra le possibili informazioni disponibili, lo stato ` utilizzato per selezionare e una lista di candidati per essere chiamati. In seguito, si utilizza la po- sizione per decidere quale sia l’utente pi` vicino geograficamente: se u uno o pi` sono alla stessa distanza, allora UbiPhone sceglier` tra i due u a quello con la tariffa telefonica pi` bassa (in generale, discriminando u in base al fornitore del servizio). Una procedura simile ` quindi messa e in atto per decidere quale sia il metodo di comunicazione migliore da adottare, in relazione a quelli disponibili.Emergent-Contact Service aiuta il chiamante a mettersi in contatto con una terza persona, quando l’utente desiderato non ` raggiungibi- e le. In particolare, la funzione definita nell’equazione 2.1 definisce la possibilit` di raggiungere l’utente u tramite il mezzo b al tempo t, in a base alla relazione sociale che intercorre tra i due. Prelation (u, b, t) = (1 − βω ) ∗ Pu (b|t) + βω ∗ ωu,c (2.1) 52
  • 58. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 53 dove βω ` il peso del modello di rete sociale nel calcolare la possibilit`; e a Pu (b|t) rappresenta la preferenza nel raggiungere l’utente u attraverso il contatto b al tempo t. Questa variabile ` predefinita dall’utente u. e Nell’equazione 2.2, invece, ` fornita una funzione che permette di sta- e bilire la possibilit` di raggiungere il chiamato basandosi su uno storico a del contesto posizionale. La possibilit` che u e b siano nello stesso po- a sto (definito come “lo stesso edificio”) ` dato dal numero di volte e in cui sono stati nello stesso luogo al tempo t, durante le ultime W settimane. |locationu (t) = locationb (t)| Plocation (u, b, t) = (2.2) W Infine, la possibilit` di raggiungere u tramite b al tempo t, conside- a rando sia il contesto sociale che posizionale, ` definito dalla seguente e equazione. Pcontact (u, b, t) = αlocation ∗ Plocation (u, b, t) + αrelation ∗ Prelation (u, b, t) (2.3) dove αlocation + αrelation = 1. ` E importante notare che le equazioni presentate in precedenza non seguono strettamente le leggi semantiche della probabilit`, in quanto a sono solamente indicatori di possibilit`. Tramite il server che for- a nisce il servizio viene innanzitutto recuperata la lista b degli utenti disponibili, secondo il context management server, nella rubrica di u. Successivamente verr` analizzata l’agenda di u: se ` presente un re- a e cord, viene analizzata la posizione attuale di u e ricercato il contatto di un utente nella stessa posizione; al contrario, se questa non ` di- e sponibile, verr` prevista in base allo storico dei log posizionali. Le a equazioni precedenti vengono quindi utilizzate per calcolare la possi- bilit` di ogni utente nella lista dei contatti, quindi quello con indice a pi` alto verr` infine contattato. u a 53
  • 59. CAPITOLO 2. UBIQUITOUS COMPUTING E54 CONTEXT-AWARENESS2.5 Ulteriori scenari applicativiL’avvento di nuove tecnologie e sensori sempre pi` all’avanguardia hanno uportato allo sviluppo di applicazioni context-aware avanzate che integra-no virtualmente il mondo reale in cui viviamo con informazioni ed inputvirtuali. Di seguito vengono presentati due dei principali campi applicativi.2.5.1 Realt` aumentata aLa realt` aumentata (o augmented reality) ` un termine che indica una a evisione reale, diretta o indiretta, dell’ambiente fisico in cui alcuni elementirisultano “aumentati” da input sensoriali generati dal sistema, come suoni,video, grafiche o dati GPS. Questo ambito di ricerca ` legato al concetto epi` generale di realt` mediata, in cui una vista della realt` viene modificata u a a(a volte anche diminuita, piuttosto che aumentata) da un computer. Comerisultato, la tecnologia d` la possibilit` di arricchire la percezione dell’utente a aall’interno del sistema. Questo approccio alla realt` ` completamente in a econtrasto con la realt` virtuale e rimpiazza il mondo reale con uno simulato. a L’aumento ` convenzionalmente eseguito in real-time e interno al econtesto degli elementi ambientali, come succede per i punteggi sportiviin TV durante una partita. Con l’aiuto della tecnologia, le informazioniriguardo il mondo reale attorno all’utente diventa interattivo e digitalmentemanipolabile. Le informazioni artificiali riguardo l’ambiente ed i suoioggetti possono essere sovrapposti con il mondo reale. Il termine realt` aaumentata ` stato attribuito a Thomas Caudell, ingegnere della Boing, che ein questo modo si ` riferito a questa tecnologia intorno ai primi anni novanta. e Un valido esempio di questa tecnologia ` l’applicazione Layar 9 , svilup- epata dall’omonima compagnia olandese fondata nel 2009 da Raimo van derKlein, Claire Boonstra e Maarten Lens-FitzGerald. La piattaforma di La-yar permette agli sviluppatori di realizzare i propri livelli (appunto, layer )virtuali, creando esperienze di realt` aumentata sempre differenti. Questo asistema include varie tipologie di esperienze coinvolgenti ed interattive, in-cluse animazioni ed oggetti in 3D. I livelli location-based, inoltre, possonoaiutare gli utenti a trovare i punti di interesse vicini, come caff´, negozi o ealtri edifici commerciali, come anche edifici storici e monumenti. 9 per ulteriori informazioni, http://www.layar.com. 54
  • 60. CAPITOLO 2. UBIQUITOUS COMPUTING ECONTEXT-AWARENESS 552.5.2 Context-aware gamingUn gioco context-aware utilizza informazioni digitali e fisiche riguardo allostato corrente del giocatore per modellare le modalit` di gioco [19]. Simil- amente a quanto gi` visto nell’ambito della realt` aumentata, l’integrazione a adi contesto fisico e digitale introduce una nuova dimensione di gioco, dif-ferente dalle esperienze provate giocando solo nel mondo fisico o in quellodigitale. Per questo motivo, i giochi context-aware sono molto differenti daquello che ci si aspetta da un tradizionale gioco digitale.Gli input contestuali possono essere divisi in quattro categorie: • l’ambiente: include la posizione corrente del giocatore o la presenza di oggetti nell’ambiente, come prodotti etichettati con RFID in un supermarket; • le attivit` fisiche: il movimento del giocatore, sia nella forma di a cambiamento di posizione che nell’eseguire un gesto con il corpo; • i dati del corpo: le informazioni grezze fornite dai nostri corpi, alcu- ne volte controllabili, altre subconscie. Ad esempio, l’attivit` cerebrale a come i livelli di stress, la frequenza di respiro o lo stato emozionale; • il contesto relativo ad altri utenti: alcune esperienze di gioco non sono risolte da singoli individui, ma tramite commenti collettivi, interpretazioni, voti e descrizioni forniti da altri giocatori del giochi o utenti del sistema. Mogi ` un gioco basato sulla posizione, lanciato in Giappone nel 2003, in ecui i giocatori esplorano il mondo fisico che li circonda per raccogliere oggettivirtuali nascosti. Gli utenti si interfacciano con il mondo di Mogi attraversoil software installato sui proprio telefoni cellulari equipaggiati con sensoriGPS: quando si muovono lungo la citt`, il software aggiorna la loro posizione ae mostra la loro vicinanza a token (appunto, simboli o oggetti) virtuali.L’obiettivo del gioco ` radunare pi` token possibili, barattandone alcuni e ucon altri utenti per ottenere i pi` rari ed ampliare la propria collezione. uMogi utilizza la posizione come principale sorgente di contesto: il luogo incui si trova l’utente determina il tipo di esperienza fornita dal gioco. Questatipologia di giochi ` spesso chiamata pervasive games, in quanto estendono el’esperienza di gioco oltre allo schermo e nell’ambito del mondo fisico. 55
  • 61. CAPITOLO 2. UBIQUITOUS COMPUTING E56 CONTEXT-AWARENESS Human Pac-Man, uscito dalla National University of Singapore, prendeed estende l’idea di Mogi di un layer di gioco sul mondo fisico. I giocatoriindossano dei computer portatili ed un display indossato come elmetto: ildisplay analizza il terreno davanti al giocatore e quindi sovrappone elementidel classico gioco Pac-Man sul suo campo visivo. La posizione del giocatoree la direzione dell’elmetto sono i principali input contestuali in questo caso.Quando un utente cammina e guarda in nuove direzioni, il gioco si aggiornadi conseguenza. Esempi pi` diffusi e commerciali sono la Playstation Eye Toy camera o uil Gesture-Recognition Controller per Nintendo Wii. Entrambi i dispositivicostringono i giocatori ad eseguire realmente le azioni che vogliono eseguirenel gioco, in quanto l’attivit` fisica ` l’unico input valido nel gioco, dove non a esono presenti altri controller o joystick. Ad esempio, un gioco di snowboardper EyeToy richiede che l’utente stia davanti alla camera come se si tenessein equilibrio sulla tavola, inclinandosi poi a sinistra e a destra per evitare gliostacoli. Questo accessorio per la Playstation si ` rivelato davvero un suc- ecesso, tanto che le sue capacit` visuali saranno integrate direttamente nella aprossima versione della console; allo stesso modo, anche la Nintendo sta fa-cendo della gesture-recognition una principale caratteristica della prossimaWii. Queste strategie commerciali sono il sintomo di un’importante rivolu-zione nell’home video gaming, suggerendo come, anche in questo campo, lacontext-awareness rappresenti la nuova frontiera di sviluppo. 56
  • 62. Capitolo 3Progettazione di applicazionicontext-aware mobileIl grande sviluppo della tecnologia hardware legata ai dispositivi mobile,ha portato negli ultimi anni a disporre di sistemi computazionalmentemolto avanzati, sia dal punto della memoria che delle risorse messe adisposizione all’utente. Per questo, il gap presente tra i sistemi definitipropriamente desktop e quelli mobile si ` pian piano assottigliato, fino ead essere un particolare trascurabile per i moderni sviluppatori softwaremobile. D’altro canto, questa disponibilit` di risorse ha portato un aaumento sensibile della complessit` delle applicazioni mobile di nuova agenerazione, grazie anche alla disponibilit` di piattaforme computazio- anali avanzate, ormai veri e propri sistemi operativi mobile (vedi sezione 1.2). La vera differenza tra i sistemi desktop e gli odierni sistemi mobile,` racchiusa invece principalmente nell’utilizzo di questi dispositivi daeparte dell’utente: le applicazioni sviluppate per questi sistemi possonoinfatti accedere a numerosissime informazioni relative all’ambiente incui il sistema viene utilizzato, in quanto questa tipologia di dispositiviaccompagna l’utente durante le proprie attivit`. La dinamicit` del contesto a ain cui ` immerso il sistema richiede un comportamento altrettanto dinamico ee reattivo, in continua interazione con tutto quello che lo circonda, oltreche con l’utente stesso. Questi nuovi scenari aprono le porte a numeroseinteressanti sfide dal punto degli sviluppatori, che per realizzare applica-zioni realmente “smart” devono modellare applicazioni che reagiscano con 57
  • 63. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONI58 CONTEXT-AWARE MOBILEil contesto esterno e con i dati sensibili relativi all’utente, adattando illoro comportamento in base ad una serie complessa di valutazioni empiriche. Il contesto ` quindi diventato un concetto chiave per la progettazione di eapplicazioni su smartphone, caratterizzando una categoria di applicazioniin costante aumento. Il diffondersi di queste applicazioni si traduce in pra-tica con l’introduzione di una nuova fascia di problematiche implementativeda tenere in considerazione durante lo sviluppo di tali applicazioni: questecomplessit`, che vanno dalla vastit` e variet` delle informazioni gestite al- a a ala gestione e adattamento ai cambiamenti percepiti dall’ambiente esterno,sono comuni a tutte queste applicazioni e suggeriscono quindi che possanoessere gestite in maniera relativamente simile. Questa considerazione haportato alla ricerca di astrazioni di pi` alto livello che permettessero di si- ustematizzare lo sviluppo di questa fascia di sistemi, fornendo un punto dipartenza efficace che esuli dalla gestione di tutte quelle funzionalit` di pi` a ubasso livello richieste per la gestione del contesto. Le attuali piattaforme per lo sviluppo, nella maggior parte dei casidirettamente i sistemi operativi mobile, forniscono tutte le primitive perutilizzare le risorse, le informazioni ed i sensori di cui ` equipaggiato il edispositivo; quello che per` rende complesso il processo di sviluppo di oquesta tipologia di applicazioni ` il gap presente tra il comportamento edei componenti progettati e gli strumenti messi a disposizione, a livellodi linguaggio e primitive: questa differenza di astrazione esiste e vaconsiderata. L’obiettivo di questo capitolo ` quello di descrivere un approccio alter- enativo che permetta agli sviluppatori di modellare il comportamento delleapplicazioni in modo naturale, fornendo delle primitive di alto livello per ladescrizione dei componenti del sistema e dei loro comportamenti.3.1 Un approccio agent-orientedUna soluzione efficace per colmare il gap concettuale presentato in prece-denza, ` quella di utilizzare l’astrazione di agente. In realt` questa non e a` l’unica soluzione, ma rappresenta comunque un’astrazione di alto livelloeutile per far fronte ad alcune delle caratteristiche principali di queste appli- 58
  • 64. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONICONTEXT-AWARE MOBILE 59cazioni: secondo i sostenitori di questo modello, un sistema che pu` essere osuddiviso logicamente in una serie di componenti interagenti dinamicamente` potenzialmente adatto per l’utilizzo di agenti. Inoltre, le applicazioni cheedevono operare all’interno di ambienti complessi e dinamici sono conside-rate particolarmente adatte, in quanto gli approcci tradizionali non sempreincludono meccanismi per modellare consistentemente la miriade di scenariche questi ambienti presentano. Un semplice esempio di questa complessit` ` dato da un utente mobi- aele con la necessit` di recuperare certe tipologie di informazioni che opera aall’interno di un ambiente: la componente dinamica introdotta accresce ladifficolt` nella fornitura dei servizi e il loro corretto utilizzo. Considerando aquesto semplice scenario possiamo valutare su questo una soluzione basatasugli agenti. Queste classi di problemi sono intrinsecamente adatte ad unapproccio ad agenti: gli agenti sono incorporati nel dispositivo mobile e per-cepiscono costantemente sia l’ambiente che le azioni dell’utente. Inoltre, gliagenti intenzionali possono influenzare l’ambiente attraverso l’attivazione diattuatori. Gli agenti tipicamente mostrano un comportamento collaborati-vo, in cui ognuno fornisce un insieme ristretto di abilit` o responsabilit`, a acome ad esempio l’analisi dell’utente o l’ascolto dell’interfaccia degli even-ti. Questo comportamento collaborativo offre l’adattabilit` di riflettere le adinamiche di questa tipologia di sistemi, come richiesto dai requisiti.3.1.1 Agenti intelligentiIn accordo con la definizione classica, un agente intelligente ` un sistema ecomputazionale capace di agire e percepire in maniera autonoma in undeterminato ambiente. Si suppone che le azioni che compie possanocambiare lo stato dell’ambiente in modo da raggiungere gli obiettivi degliagenti stessi, mentre le percezioni rappresentano un processo tramite ilquale un agente riconosce lo stato dell’ambiente intorno a lui, in modo dapoter adattare il proprio comportamento. La caratteristica principale degli agenti ` la loro autonomia, cio` la ca- e epacit` di agire indipendentemente, incapsulando il controllo all’interno del aproprio stato interno. A parte questo aspetto, le principali propriet` men- azionate sono (i) la reattivit`, (ii) la localit`, (iii) la pro-attivit` e (iv) l’abilit` a a a asociale o coordinazione. 59
  • 65. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONI60 CONTEXT-AWARE MOBILE Quella che viene proposta non ` la semplice scelta di agenti come entit` e acomputazionali che incapsulino un thread di controllo, ma una concezioneforte di agenti secondo il paradigma BDI: le strutture chiave di questomodello sono quindi le credenze, i desideri e le intenzioni (appunto,beliefs, desires e intentions), come astrazioni di base per modellare ilcomportamento degli agenti ispirate dal comportamento umano. Questaarchitettura ` stata inizialmente introdotta nel lavoro relativo al progetto e“Rational Agency” presso lo Stanford Research Institute alla met` degli aanni ottanta. L’origine del modello si deve alla teoria del ragiona-mento pratico umano sviluppato dal filosofo Michael Bratman, che si ` efocalizzato in particolare sul ruolo delle intenzioni nel ragionamento pratico. • i beliefs sono le informazioni che un agente ha riguardo l’ambiente in cui agisce. Queste informazioni possono essere inaccurate o comunque diventare datate; • i desires sono tutti gli stati del sistema che un agente vorrebbe rag- giungere. Avere un desiderio comunque non implica che l’agente agi- sca unicamente per raggiungerlo: questo rappresenta una possibile in- ` fluenza sulle azioni dell’agente. E perfettamente immaginabile, infatti, che un agente abbia desideri di per s´ mutualmente incompatibili tra e loro, per cui si tende a considerarli pi` spesso un’opzione per l’agente u stesso; • le intentions sono gli stati del sistema che un agente ha deciso di cercare di raggiungere. Le intenzioni possono essere obiettivi delegati ad un altro agente o possono essere il risultato della valutazione di varie opzioni: possiamo pensare, ad esempio, ad un agente che valuti le proprie opzioni e scelga una di queste. Per questo, un agente cos` ı definito inizier` la propria computazione con qualche obiettivo di cui a ` incaricato, per poi considerare le opzioni possibili compatibili con e questo obiettivo; le opzioni che sceglier` diventeranno intenzioni che a l’agente si impegner` a perseguire. a L’idea centrale del modello BDI ` che gli agenti governino il proprio ecomportamento sulla base del proprio stato interno, modellato sugli stati 60
  • 66. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONICONTEXT-AWARE MOBILE 61mentali cognitivi. Il particolare modello decisionale sotteso ` chiamato pra- etical reasoning, cio` il processo di ragionamento che ha l’obiettivo di trovare eil set di azioni da eseguire per raggiungere il risultato desiderato. Il ragionamento pratico cognitivo consiste in due attivit` principali: a • la deliberation, in cui l’agente prende una decisione riguardante quale stato del sistema desidera raggiungere. Questa fase del ragionamento produce le intenzioni, cio` quello che un agente desidera ottenere o e desidera fare; • il means-end reasoning, in cui l’agente prende decisioni riguardanti il come raggiungere determinati stati del sistema. Questa fase produ- ce invece il set ordinato di azioni selezionate per ottenere lo scopo desiderato, in pratica il workflow dell’agente. Il Procedural Reasoning System (abbreviato spesso in PRS ), originaria-mente sviluppato presso lo Stanford Research Institute dai ricercatori Mi-chael Georgeff e Amy Lansky, ` stato forse la prima architettura ad agenti ea seguire il paradigma BDI e ha dimostrato in pratica come rappresenti unodegli approcci ad oggi pi` robusti per sviluppare agenti. Nel PRS, un agente unon pianifica tutto dal principio, anzi viene equipaggiato con una libreriadi piani pre-compilati. Questi piani vengono quindi redatti manualmentedal programmatore prima del lancio dell’agente. Le componenti principalidi ogni piano nel PRS sono In the PRS, an agent does no planning from first principles. Instead, itis equipped with a library of pre-compiled plans. These plans are manuallyconstructed, in advance, by the agent programmer. Plans in the PRS eachhave the following components: • un goal : le post-condizioni del piano; • un contesto: le pre-condizioni del piano; • un corpo: la parte descrittiva del piano, cio` il corso delle azioni base e e degli obiettivi da raggiungere. All’avvio un agente PRS disporr` quindi di una serie di piani ed una serie adi beliefs riguardo l’ambiente esterno. Le credenze sono rappresentati nelsistema PRS come fatti Prolog, cio` essenzialmente come formule atomiche e 61
  • 67. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONI62 CONTEXT-AWARE MOBILEin logica di prim’ordine. Inoltre, sempre all’avvio, un agente tipicamentedispone di un obiettivo primario di alto livello: questo obiettivo agisce inmodo simile al metodo main di un programma in Java o C. Quando un agente si avvia, il goal da ottenere viene spostato nello stack,chiamato intention stack : questa pila contiene tutti gli obiettivi ancora daraggiungere. L’agente cerca quindi all’interno della propria libreria i pianiche abbiano come post-condizione il goal in testa alla pila. Di questi, solo al-cuni avranno le relative pre-condizioni soddisfatti, in accordo con i correntibeliefs dell’agente. L’insieme delle opzioni disponibili ` quindi rappresenta- eto da quei piani che raggiungono l’obiettivo e soddisfano le pre-condizioni.Il processo che porta alla scelta tra i possibili piani ` ovviamente la delibera- etion. Il piano scelto viene quindi eseguito quando possibile: questo implicaanche lo spostamento in cima alla pila delle intenzioni dei goal successivi,che spingono l’agente ad effettuare di nuovo questa procedura per trova-re nuovi piani che raggiungerli. Il processo si concretizza con una serie diazioni singole che possono essere direttamente eseguite (come, ad esempio,un’interazione con altri agenti o un calcolo numerico). Se un particolarepiano per raggiungere un obiettivo fallisce, allora l’agente pu` scegliere un oaltro piano dal set di quelli possibili.3.2 Middleware supportL’architettura ad agenti appena descritta rappresenta una facility impor-tante per gli sviluppatori mobile, in quanto permette di creare agenti cheincapsulano al meglio le caratteristiche di reattivit` e pro-attivit` richieste a aalle applicazioni mobile di ultima generazione. Realizzare tali agenti diretta-mente sulle piattaforme mobile di sviluppo, per`, non ` sempre un compito o esemplice: il gap concettuale presente tra le primitive fornite e l’astrazio-ne da realizzare rimane infatti considerevole, necessitando un dispendio dicodice ed energie per la programmazione delle entit` e dei comportamenti adesiderati. Per poter utilizzare quindi il modello BDI durante lo svilup-po di applicazioni context-aware, al fine di valutarne i vantaggi o meno, ` enecessario appoggiarsi su un middleware software che costituisca il livelloconcettuale mancante per la modellazione di un sistema ad agenti, favoren-do cos` una maggiore agilit` durante lo sviluppo ed un utilizzo ottimizzato ı adel codice prodotto. 62
  • 68. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONICONTEXT-AWARE MOBILE 63 La ricerca in questo ambito applicativo ha prodotto numerosi midd-leware ad agenti, ognuno dei quali implementa un diverso modello o sfruttauna determinata tecnologia mobile. Ovviamente, la scelta della piattafor-ma da utilizzare deve essere guidata principalmente dalle caratteristiche delsistema da implementare o dai vincoli imposti dalla tecnologia mobile a di-sposizione, se presenti. Le prime infrastrutture mobile ad agenti, infatti,dovevano poter essere lanciate su dispositivi con limitate risorse, per cuiconsiderazioni legate al consumo o alle prestazioni ottenute erano fonda-mentali per un utilizzo corretto. I dispositivi di ultima generazione, invece,offrono una ricchezza di risorse e capacit` di calcolo comparabili a quelle adei sistemi desktop, per cui l’obiettivo primario non ` quello di scegliere la epiattaforma che ottenga le migliori performance durante l’esecuzione, maquello di poter disporre degli strumenti necessari per applicare il modello diagenti intelligenti allo sviluppo di applicazioni context-aware con il minimosforzo implementativo.3.2.1 Architetture mobile ad agentiL’utilizzo di tecnologie ad agenti su dispositivi mobile ` stata indagata da emolti lavori presenti in letteratura. In generale, ` possibile classificare gli eapprocci secondo le seguenti dimensioni: 1. scopo: ad esempio, piattaforme generiche per il lancio di smart mobile applications oppure soluzioni agent-based per un particolare problema applicativo; 2. tipologia di modello: sono stati presentati vari modelli di sistemi ad agenti, dagli agenti mobili a quelli intelligenti, passando per i FIPA- compliant1 agents. 3. tecnologia mobile: dai dispositivi a bassa capacit` ai pi` moderni a u smartphone. Visto la tipologia del sistema introdotto in questo capitolo, saranno di-scusse unicamente le piattaforme ad agenti “generiche”, per la programma-zione ed il lancio di applicazioni mobile. 1 FIPA, acronimo di Foundation of Intelligent Physical Agents, ` un’organizzazio- ene dell’IEEE Computer Society Standards che promuove la tecnologia ad agenti el’interoperabilit` dei propri standards con altre tecnologie. Ulteriori informazioni su ahttp://www.fipa.org. 63
  • 69. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONI64 CONTEXT-AWARE MOBILEAttualmente molti delle piattaforme disponibili sono semplicemente un por-ting di tecnologie ad agenti gi` esistenti per ambienti desktop, adattate ad aun contesto mobile. Alcune di queste, principalmente quelle pi` orienta- ute all’industria, sono basate su Java, implementano un modello debole adagenti e sono FIPA-compliant (il che significa, in particolare, che adottanocome standard FIPA ACL2 per supportare la comunicazione tra agenti).Per modello ad agenti debole si vuole sottolineare che il modello compu-tazionale e di programmazione adottato non supporta come prima classedi astrazione concetti cardine come le nozioni esplicite di obiettivi, tasks,eventi, percezioni, azioni ed ambiente. In questo caso, gli agenti sono similiad attori che comunicano scambiandosi messaggi, utilizzando per` un lin- oguaggio di comunicazione di alto livello (FIPA ACL, appunto). I principaliesempi di piattaforme di questo tipo sono Micro-FIPA-OS, una versione mi-nimizata di FIPA-OS per dispositivi con scarsa capacit` computazionale, e aLEAP (acronimo di Lightweight and Extensible Agent Platform), una piat-taforma ad agenti FIPA-compliant che estende il Java Agent DEvelopmentframework (pi` spesso chiamato solo JADE ). Recentemente, la piattafor- uma JADE-LEAP ` stata specializzata per il lancio su sistema operativo eAndroid, ma rimane comunque una soluzione incentrata sui problemi deidispositivi mobile con scarsa capacit` computazionale. a Altre piattaforme ad agenti in letteratura affrontano il problema introdu-cendo il concetto di intelligent agent progettati per i principali dispositivimobili, come PDA o smartphones. Un esempio ` dato dall’Agent Factory eMicro Edition (AFME), che per lo sviluppo di agenti intelligenti utilizzaun framework FIPA-compliant general-purpose basato su architettura BDIe che si appoggia all’ambiente di sviluppo Java Micro Edition. 3APL-M ` eun altro esempio simile, realizzando la programmazione degli agenti grazieal linguaggio Artificial Autonomous Agents Programming Language su am-biente Java ME, che fornisce i construtti per implementare la conoscenza,gli obiettivi e le principali regole comportamentali. L’ultima categoria delle soluzioni proposte per la progettazione di si-stemi mobile ad agenti introduce la tecnologia dei mobile agents: questatecnologia ` basata sull’astrazione di agente mobile cpme entit` computa- e azionale capace autonomamente di spostarsi, insieme al proprio codice ed ilproprio stato attuale, da un nodo computazionale all’altro dell’infrastrut- 2 FIPA Agent Communication Language, http://www.fipa.org/repository/aclspecs.html. 64
  • 70. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONICONTEXT-AWARE MOBILE 65tura, rendendo possibile l’aggiornamento degli ambienti distribuiti senzala sospensione del servizio. Fornendo un apposito middleware che suppor-ti la gestione del contesto e della posizione, i mobile agents sono la basedi applicazioni context-aware, supportando l’accesso autonomo, asincronoe locale alle risorse ed essendo particolarmente efficienti nel caso di clienttemporaneamente disconnessi.3.2.2 La scelta di JaCa-AndroidJaCa-Android[16] ` un framework di sviluppo open-source realizzato da ealcuni ricercatori del Dipartimento di Elettronica, Informatica e Sistemisticadell’Universit` di Bologna, con l’obiettivo di fornire un livello di astrazio- ane agent-oriented per la progettazione e programmazione di smart mobileapplications su piattaforma Android. Un’applicazione JaCa-Android vienerealizzata secondo un modello di programmazione, detto appunto JaCa, na-to dall’integrazione sinergica di due tecnologie ad agenti gi` esistenti: Jason ae CArtAgO. Jason ` un interprete open-source che estende il linguaggio AgentSpeak ee fornisce le astrazioni di prima classe per descrivere le azioni ed il com-portamento degli agenti, incapsulando la logica di controllo del compitoda eseguire. CArtAgO (Common ARTifact infrastructure for AGents Openenvironments, invece, ` un’infrastruttura general-purpose che rende possi- ebile lo sviluppo e l’esecuzione di ambienti virtuali per sistemi multi-agente:basato sul meta-modello Agents & Artifacts (A&A), introduce le metaforedi alto livello prese dall’ambiente cooperativo umano, prevedendo l’utilizzodegli artefatti come risorse e strumenti costruiti dinamicamente, utilizzati emanipolati dagli agenti per realizzare le proprie attivit` singole o collettive. a La scelta di utilizzare questa piattaforma ` stata dettata da vari fat- etori, che ne fanno un ottimo candidato per realizzare applicazioni mobilecontext-aware. JaCa-Android, integra in maniera trasparente i modelli ele tecnologie elencate in precedenza con la piattaforma Android, rappre-sentando un’infrastruttura consistente di pi` alto livello per programmare uagenti intelligenti secondo il paradigma BDI, proposto nella sezione 3.1.1come modello utile per la progettazione di tale categoria di applicazioni.Inoltre, date le conoscenze accademiche sviluppate durante il corso di studi,le tecnologie messe in campo non rappresentano un’ostacolo durante l’im-plementazione, in quanto sono state gi` affrontate e studiate in precedenza. a 65
  • 71. CAPITOLO 3. PROGETTAZIONE DI APPLICAZIONI66 CONTEXT-AWARE MOBILEUtilizzando questo framework, realizzato all’interno del dipartimento delDEIS dell’Universit` di Bologna, ` possibile interagire direttamente con a eil team di ricerca durante l’analisi del funzionamento e l’implementazionedel caso di studio, ricevendo importanti feedback legati al deployment inJaCa-Android. 66
  • 72. Capitolo 4La piattaforma JaCa-AndroidQuesto capitolo descrive l’architettura e l’utilizzo della piattaforma JaCa-Android, che fornisce un livello di astrazione agent-oriented per la proget-tazione e la programmazione di smart mobile applications su sistema ope-rativo mobile Android. Da una parte, il modello di programmazione diJaCa-Android permette di organizzare le applicazioni mobile come sistemiad agenti goal-oriented con comportamento reattivo e pro-attivo; dall’altra,questa piattaforma permette un’ottima integrazione con la piattaforma An-droid sottostante, rendendo cos` possibile agli agenti il totale controllo di ıogni funzionalit` disponibile sul dispositivo, incluse le applicazioni Android agi` esistenti. a In questa sezione verranno presentate le caratteristiche principali del fra-mework JaCa-Android e del relativo modello di programmazione, discuten-do poi l’applicazione di queste caratteristiche nell’ottica della progettazionedi applicazioni context-aware.4.1 IntroduzioneIl grande progresso tecnologico dei dispositivi mobili spinge verso lo svilup-po di una nuova generazione di smart mobile applications, con complessicomportamenti computazionali ed interattivi, caratterizzate da differenti li-velli di autonomia e flessibilit`. Questo sviluppo porta a nuove sfide nella aprogettazione di applicazioni mobile, richiedendo nuovi strumenti di pro-grammazione e piattaforme di sviluppo che forniscano il giusto livello diastrazione per fronteggiare questa nuovo livello di complessit`. Da una par- a 67
  • 73. 68 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROIDte, questa complessit` ` comparabile con quella incontrata nelle tradizionali aeapplicazioni desktop: per questo motivo, i linguaggi di programmazione dialto livello e le piattaforme utilizzate in ambiente desktop risultano uti-li anche in un contesto mobile, insieme a middleware che permettano unutilizzo completo delle caratteristiche del dispositivo mobile in questione.Dall’altra parte, invece, lo sviluppo sistematico di smart mobile applica-tion si scontra con la necessit` di caratteristiche che ne rendono difficile la aprogrammazione, anche utilizzando linguaggi di alto livello: queste carat-teristiche, facilmente riscontrabili in molte di queste applicazioni, sono lareattivit`, la pro-attivit` e la flessibilit`. a a a Per questo motivo, un grosso campo di ricerca si occupa di come pro-gettare e programmare queste applicazioni, sviluppando strumenti di pro-grammazione di alto livello e piattaforme che forniscano il giusto livellodi astrazione, aiutino a creare porzioni di codice facilmente riutilizzabile erendano possibile un’integrazione con le piattaforme esistenti.4.2 La piattaforma JaCa-AndroidL’obiettivo della piattaforma JaCa-Android ` quello di lanciare applicazioni ead agenti su sistema operativo mobile Android. L’applicazione ed il model-lo di programmazione adottati sono basati sulla tecnologia ad agenti JaCa,gi` utilizzata in ambiente desktop e qui integrata con un livello specializ- azato nel contesto mobile. Un’applicazione realizzata con l’ausilio di questapiattaforma viene lanciata quindi su un’infrastruttura JaCa runtime, equi-paggiata con un livello che permette l’accesso e il controllo delle risorsemesse a disposizione dal framework Android (vedi figura 4.1). Essendo rea-lizzata in Java, l’infrastruttura di JaCa-Android viene lanciata come unanormale applicazione Android. Un’applicazione ad agenti lanciata su questa piattaforma ` composta eda un insieme dinamico di agenti che pro-attivamente svolgono alcuni com-piti, interagendo in un ambiente comune. Questo ambiente ` organizzato ein termini di uno o pi` workspaces, cio` postazioni logiche che contengono u eentit` computazionali dette artefatti, che a loro volta rappresentano i com- aponenti computazionali di base tramite cui ` strutturato l’ambiente degli eagenti. Seguendo il meta-modello A&A (Agents & Artifacts) introdotto nelcontesto dell’ingegneria software agent-oriented, gli agenti e gli artefatti so- 68
  • 74. CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 69no le astrazioni di primo livello utilizzate per organizzare e programmareun’applicazione (come mostrato in figura 4.2). Figura 4.1: Architettura della piattaforma JaCa-Android Da una parte, gli agenti sono entit` autonome, progettati per eseguire aun determinato compito e caratterizzati da un comportamento pro-attivo ereattivo: per questo rappresentano un’astrazione di primo livello per la rea-lizzazione della parte di controllo dell’applicazione in termini task-oriented ogoal-oriented. Dall’altra, gli artefatti sono entit` passive che rappresentano arisorse e strumenti che gli agenti possono dinamicamente creare, condivi-dere, utilizzare e osservare come supporto alla propria attivit`. Per questo agli artefatti sono tipicamente utilizzati anche per incapsulare tutte quellefunzionalit` legate allo specifico contesto dell’applicazione, rendendole ac- acessibili e controllabili agli agenti: nel caso delle applicazioni mobile questefunzionalit` spaziano dalla gestione e controllo delle risorse del dispositivo a 69
  • 75. 70 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROIDmobile (come i sensori, ad esempio) all’interazione con applicazioni mobileesistenti non ad agenti. Sotto alcuni aspetti, sono simili agli oggetti in OOP,ma presentano sostanziali differenze che saranno pi` chiare in seguito. In- ufine, i workspace (o spazi di lavoro) sono utilizzati per definire la topologiadell’applicazione, che pu` essere organizzata come vari workspace lanciati opossibilmente su nodi distinti dell’applicazione (processi) e distribuiti nellarete. Generalmente, ogni workspace contiene un insieme predefinito di arte-fatti creati all’avvio, fornendo agli agenti le azioni di base per gestire l’interoset di artefatti, utilizzare pi` workspace, stampare messaggi in console e cos` u ıvia. Figura 4.2: Rappresentazione astratta di una applicazione JaCa JaCa-Android ` stato sviluppato con l’obiettivo di di fornire agli svi- eluppatori una piattaforma in grado di garantire un accesso trasparente e lagestione delle funzionalit` di Android grazie agli artefatti e al modello di ainterazione agenti-artefatti. Infatti, il punto chiave della piattaforma ` un eappropriato set di artefatti che incapsulano le principali feature fornite daAndroid, permettendo agli agenti di accedere ed utilizzare le funzionalit` adi cui hanno bisogno astraendo dai dettagli implementativi di basso livello.La piattaforma garantisce un accesso diretto alle funzionalit` pi` comuni a urichieste dalle smart mobile application, fornendo un workspace condivi-so chiamato JaCa-Service (vedi figura 4.1) contenente un set di artefatti 70
  • 76. CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 71general-purpose. Questo workspace, eseguito all’avvio del dispositivo e me-morizzato all’interno di un apposito servizio Android installato con la piat-taforma JaCa-Android, ` condiviso tra tutte le applicazioni JaCa-Android. eGli artefatti in questo workspace possono essere visti come singleton, nelcontesto delle applicazioni object-oriented (cio` ` richiesta una sola istanza eedi ognuno di questi, condivisa tra tutti gli utenti). In dettaglio, gli artefatticontenuti in JaCa-Service sono: • SMSManager / MailManager: gestiscono le funzionalit` legate agli a SMS e alle mail (es. inviare e ricevere un SMS/mail, recuperare SMS/mail memorizzate, ecc...); • GPSManager: gestisce le funzionalit` relative al GPS (es. geolocaliz- a zazione del dispositivo); • AccelerometerSensorManager / GyroscopeSensorManager ...: forniscono informazioni legate ai sensori del dispositivo (es. accelerometro, giroscopio, ecc...); • CallManager: fornisce le funzionalit` per rispondere o rifiutare una a chiamata; • ConnectivityManager: gestisce l’accesso alle differenti tipologie di connettivit` supportate dal dispositivo mobile; a • CalendarManager: gestisce i calendari built-in di Google; • PhoneSettingsManager: provvede alla gestione della vibrazione e della suoneria del dispositivo. La piattaforma include inoltre un insieme di tipologie prede-finite di artefatti (BradcastReceiverArtifact, ActivityArtifact,ContentProviderArtifact, ServiceArtifact) specificatamente realizzatiper costruire componenti compatibili con Android. Per cui i componentiAndroid standard diventano a tutti gli effetti artefatti che gli agenti o glisviluppatori possono utilizzare senza preoccuparsi delle problematiche infra-strutturali relative all’SDK Android. In questo modo ` possibile sfruttare e erealizzare applicazioni mobile completamente integrate con l’SDK Android,possibilmente riutilizzando componenti ed applicazioni sviluppate secondo 71
  • 77. 72 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROIDl’SDK standard. Infatti questi artefatti da un lato permettono agli sviluppa-tori di realizzare, in termini di artefatti, componenti classici Android, quindidirettamente utilizzabili anche da applicazioni standard Android; dall’altro,permettono alle applicazioni JaCa-Android di interagire con ogni compo-nente Android esistente. Questa integrazione ` fondamentale per garantire eagli sviluppatori il riutilizzo della legacy esistente. Oltre all’insieme di artefatti descritto in precedenza, uno sviluppatoreche desidera sviluppare un’applicazione JaCa-Android deve realizzare unset di artefatti specifici per l’applicazione in questione, come ad esempio lerisorse esterne di cui gli agenti necessitano per raggiungere i loro obiettivi.4.3 Il modello di programmazione JaCa- AndroidIl modello di programmazione di JaCa-Android, JaCa, ` attualmente basato esu due differenti tecnologie di programmazione: il linguaggio di programma-zione ad agenti e l’interprete di Jason, che implementa ed esegue gli agenti,ed il framework e l’infrastruttura di CArtAgO per programmare ed eseguirel’ambiente basato sugli artefatti in cui sono situati gli agenti stessi. Da una parte, il modello computazionale ad agenti e l’architettura adot-tata in Jason sono basati sul modello BDI e sul linguaggio astratto Agen-tSpeak. Per questo, gli agenti sono sistemi di pianificazione reattivi: questiagiscono continuamente, reagendo agli eventi con l’esecuzione di piani sta-biliti dal programmatore. I piani sono sequenze di azioni che gli agentiche gli agenti mettono in esecuzione per perseguire i propri obiettivi. Ilcomportamento proattivo degli agenti viene realizzato tramite la nozione diobiettivi (stati desiderati dell’ambiente) che sono anche parte del linguaggionel quale i piani sono scritti. Dall’altra, il modello ad artefatti adottato in CArtAgO segue il meta-modello A&A (Agents & Artifacts), per cui gli artefatti sono entit` passive, ache incapsulano alcune funzionalit` che possono essere svolte dagli agenti aattraverso un’interfaccia di utilizzo. Questa interfaccia ` composta da un einsieme di operazioni e propriet` osservabili. Le prime corrispondono al- ale azioni che l’artefatto rende disponibili agli agenti che interagiscono conquesto tipo di entit` funzionale del sistema; per cui l’intero set di azioni ef- afettuabili dagli gli agenti nel workspace dipende dall’insieme corrente degli 72
  • 78. CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 73artefatti disponibili al suo interno. Le seconde, invece, definiscono lo statoosservabile dell’artefatto, il quale ` rappresentato da un insieme di oggetti einformativi i cui valori (e il loro relativo cambiamento) possono essere per-cepiti dagli agenti. Oltre le propriet` osservabili, l’esecuzione di operazioni apu` generare segnali che sono percepibili dagli agenti come eventi osservabili oche accadono all’interno dell’ambiente.4.3.1 Programmare gli agenti in JasonI costrutti del linguaggio Jason utilizzabili dai programmatori possonoessere separati in tre principali categorie: beliefs, goals e plans (letteral-mente, credenze, obiettivi e piani). Un programma agente ` definito da un einsieme di partenza di beliefs, che rappresentano il suo stato iniziale, daun insieme di goals, che corrispondono ai compiti che il programmatoreha delegato all’agente, e da un insieme di plans che l’agente pu` dinami- ocamente comporre, instanziare ed eseguire per raggiungere i propri obiettivi. Come supporto alla descrizione degli aspetti teorici affrontati, viene pre-sentato di seguito un esempio di codice Jason per la definizione del compor-tamento di un agente di una semplice applicazione JaCa-Android responsa-bile di notificare, con comportamento context-aware, la ricezione di un SMSda una determinata sorgente (agente sms-notifier). I belief in Jason sono rappresentati da fatti in stile Prolog, che sono for-mule atomiche e rappresentano lo stato dell’agente. Questo stato ` formato eda due tipologie di belief : • i belief riguardanti lo stato interno dell’agente. Con riferimento al codice citato, ne sono un esempio sms_received(N), utilizzato dall’agente per tener traccia del numero di SMS gestiti finora, e my_source(5554), che identifica la fonte rilevante di gli SMS per la nostra applicazione; • i belief riguardanti lo stato osservabile degli artefatti monitorati dall’agente. Nell’esempio, gli artefatti osservati dall’agente sono SMSManager e SMSViewer. Il secondo ha una propriet` osservabile a viewer_state che rappresenta lo stato corrente di SMSViewer, comu- nicando se quest’ultimo ` attualmente visualizzato a schermo (in base e al valore displayed o not_displayed). 73
  • 79. 74 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 00 sms_received(0). 01 my_source("5554"). 02 source_relevant(Source) :- my_source(S) & S == Source. 03 04 !manage_sms. 05 06 +!manage_sms 07 <- makeArtifact("smsreceiver", "jaca.android.tools.SMSService", [], IdReceiver); 08 focus(IdReceiver); 09 makeArtifact("notificator", "jaca.android.tools.NotificationService", 10 [], IdNotificator); 11 lookupArtifact("viewer", IdViewer); 12 focus(IdViewer). 13 14 +sms_received(Source, Message) : sms_received(NumSms) & source_relevant(Source) 15 <- -+sms_received(NumSms+1); 16 !notify_sms(Source, Message). 17 18 +!notify_sms(Source, Message) : viewer_state("not_displayed") 19 <- showNotification(Source, Message). 20 21 +!notify_sms(Source, Message) : viewer_state("displayed") 22 <- addSMSToList(Source, Message). Tabella 4.1: Codice sorgente dell’agente sms-notifier. Al momento della progettazione lo sviluppatore potrebbe voler definirela base di conoscenza iniziale dell’agente, specificando alcuni belief inizia-li: successivamente, i belief possono essere aggiunti o rimossi a tempo diesecuzione, in accordo con i cambiamenti di stato dell’agente stesso e degliartefatti che l’agente dinamicamente decide di monitorare. Jason permetteanche di utilizzare nel set di conoscenza iniziale regole in stile Prolog chedanno la possibilit` di produrre nuovi belief basandosi sul set di belief che al’agente gi` possiede. a Come accennato in precedenza, un agente pu` realizzare uno o pi` com- o upiti, i quali possono essere assegnati dinamicamente. Di conseguenza, unprogramma agente pu` esplicitamente definire il compito iniziale o l’insieme odi compiti che dovr` realizzare, all’atto della propria creazione. Nel linguag- agio Jason questi compiti sono chiamati goal e sono rappresentati, allo stessomodo dei belief, da formule atomiche scritte in Prolog precedute da un puntoesclamativo. Questi sono dichiarati dopo l’insieme dei belief. Attualmente,i compiti possono anche essere assegnati a tempo di esecuzione, inviandoall’agente uno specifico tipo di messaggio, chiamato achieve-goal. In seguito, il corpo centrale del programma agente ` formato da un e 74
  • 80. CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 75insieme di piani che l’agente pu` dinamicamente combinare e sfruttare per oeseguire i propri compiti. Questi piani sono descritti da regole del tipoEvent: Context <- Body. Event rappresenta l’evento specifico che innescail piano, facente parte di una delle seguenti categorie: • goal events, i quali sono collegati ai cambiamenti nella base di obiettivi dell’agente. Questi includono: l’assegnazione di un nuovo obiettivo da raggiungere (+!g, dove g ` la rappresentazione letterale del goal) e o il fallimento ottenuto durante l’esecuzione di un piano, che implica quindi il fallimento del goal associato (-!g); • percezioni dell’ambiente, come cambiamenti di belief (aggiunta di be- lief +b o rimozione -b, dove b ne rappresenta la rappresentazione letterale) dovute ai cambiamenti dei valori delle propriet` osserva- a bili degli artefatti monitorati dall’agente o segnali (+s, dove s ` la e rappresentazione letterale del segnale) esplicitamente generati da un artefatto osservato durante un’operazione. Il piano Context ` un’espressione booleana nella base dei belief che eindica le condizioni sotto le quali il piano pu` essere eseguito una volta che o` stato innescato dalla ricezione di un nuovo evento. Infine il piano Bodyespecifica la sequenza di azioni da realizzare una volta che il piano vieneeseguito. Le azioni possono essere divise in due categorie: • azioni interne, che sono legate unicamente allo stato interno dell’a- gente. Esempi di questa categoria sono le azioni per realizzare sotto- obiettivi da realizzare (!g), per gestire l’esecuzione di un piano o per aggiornare lo stato interno di un agente (come aggiungere un belief +b o rimuoverlo -b); • azioni esterne, che sono fornite dall’ambiente esterno in cui l’agente ` e situato. Per questo, come menzionato in precedenza, il set di azioni esterne che un agente Jason pu` realizzare ` determinato dall’insieme o e generale delle operazioni fornite dagli artefatti attualmente disponibi- li nel workspace dove l’agente esegue il proprio lavoro. Queste azio- ni comprendono anche quelle standard fornite un set predefinito di artefatti disponibile in ogni workspace (come, ad esempio, creare o ricercare artefatti, entrare o uscire dal workspace). Per questo motivo il repertorio di azioni degli agenti ` dinamico e pu` essere modificato e o dagli agenti stessi creando o eliminando artefatti. 75
  • 81. 76 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID00 public class SMSViewer extends GUIArtifact {0102 private Viewer mViewer;0304 void init(JaCaActivity activity, Bundle savedInstanceState) {05 super.init(activity, savedInstanceState);06 mViewer = (Viewer) activity;07 defineObsProperty("viewer_state", "not_displayed");08 linkOnStartEventToOp("onStart");09 linkOnStopEventToOp("onStop");10 }11 @OPERATION void addSMSToList(String source, String msg){12 mViewer.append(source, msg);13 signal("new_sms_added",msg);14 }15 @INTERNAL_OPERATION void onStart(){16 ObsProperty obsProp = getObsProperty("viewer_state");17 obsProp.updateValue("displayed");18 }19 @INTERNAL_OPERATION void onStop(){20 ObsProperty obsProp = getObsProperty("viewer_state");21 obsProp.updateValue("not_displayed");22 }23 } Tabella 4.2: Codice sorgente dell’artefatto SMSViewer.4.3.2 Programmare gli artefatti in CArtAgOEssendo CArtAgO un framework che lavora al di sopra della piattaformaJava, la parte funzionale di un’applicazione JaCa-Android ` implementa- eta utilizzando le API di Java, sfruttando le annotazioni del framework peralleggerire la definizione degli artefatti. In CArtAgO, una tipologia di arte-fatto pu` essere definita estendendo la classe base Artifact. Al suo inter- ono, viene utilizzato il metodo init come costruttore principale, definendole operazioni necessarie per recuperare i parametri ed impostare lo statoiniziale dell’artefatto stesso. Riprendendo l’esempio dell’applicazione JaCa-Android SMSViewer,viene presentato di seguito il codice dell’artefatto che permette lavisualizzazione dei messaggi. Come menzionato nella sezione precedente, ogni artefatto fornisce un’in-terfaccia di utilizzo composta da un insieme di operazioni e propriet` os- aservabili. Le operazioni sono processi computazionali che avvengono all’in-terno dell’artefatto e che potenzialmente ne modificano sia lo stato internoche le propriet`, generando eventi osservabili, come ad esempio segnali che a 76
  • 82. CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 77possono essere rilevati dagli agenti che utilizzano l’artefatto stesso; le ope-razioni sono implementate da metodi annotati come @OPERATION. Nell’e-sempio, l’interfaccia di utilizzo ` composta dall’operazione addSMSToList, eutilizzata per aggiungere un nuovo SMS alla GUI, e dalla propriet` osserva- abile viewer_state, che riporta lo stato dell’applicazione, se correntementevisualizzata o meno. L’esecuzione delle operazioni avviene unicamente all’interno dell’artefat-to stesso, indipendentemente dal flusso di esecuzione degli agenti. Questacomputazione ` mutualmente esclusiva, come nei costrutti di tipo monitor, eper cui non possono verificarsi interferenze quando pi` agenti utilizzano in umaniera concorrente l’artefatto. Inoltre, ogni cambiamento ` coerente con elo stato interno, in quando le modifiche alle propriet` dell’artefatto sono arese osservabili unicamente quando e se l’operazione viene completata consuccesso. Al contrario, se un’operazione fallisce, i cambiamenti allo statoosservabile dell’artefatto vengono riportati allo stato precedente. Come ultima considerazione sulle operazioni, dal punto di vista degliagenti, eseguendo un’azione il piano di un agente, inclusa l’azione stessa,viene sospeso fino a quando la corrispondente operazione dell’artefatto non` stata completata: infine l’azione si conclude con esito positivo o negativoein base al risultato dell’operazione dell’artefatto che ` stata chiamata. Nel efrattempo, il ciclo di esecuzione dell’agente pu` procedere, lasciando che ol’agente possa ricevere nuovi eventi oppure selezioni ed esegua altre azioni,in modo da non ostacolare la sua reattivit`. a Le propriet` osservabili sono rappresentate da tuple etichettate e sono adefinite tipicamente durante l’inizializzazione degli artefatti, tramite l’utiliz-zo della primitiva defineObsProperty, specificando il nome della propriet` aed il valore iniziale. All’interno delle operazioni, il valore delle propriet` aosservabili pu` essere visualizzato e modificato dinamicamente mediante odue primitive di base: getObsProperty per ottenere il valore corrente eupdateObsProperty per modificarlo. Oltre alle propriet` osservabili, un artefatto pu` rendere osservabili an- a oche eventi che avvengono durante l’esecuzione delle operazioni. Questo pu` oessere realizzato grazie all’utilizzo di primitive di segnale, specificando iltipo di evento e la lista dei parametri attuali. Nell’artefatto di esempioSMSViewer, l’operazione addSMSToList genera un evento osservabile del ti-po new_sms_added(msg). Gli eventi osservabili verranno quindi percepitida tutti gli agenti che osservano l’artefatto, i quali possono presentare un 77
  • 83. 78 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROIDcomportamento reattivo come nel caso del cambiamento di una propriet` aosservabile. Infine, come principio di composizione, gli artefatti possono essere col-legati tra loro in modo che un artefatto inneschi l’esecuzione di alcune ope-razioni su un artefatto ad esso collegato. La semantica per l’esecuzione dioperazioni collegate ` la stessa di quella dell’esecuzione di operazioni da eparte degli agenti: l’operazione richiesta eseguita dall’artefatto ` sospesa efino a quando la relativa operazione innescata sull’artefatto collegato non `estata completata, qualunque sia il suo esito.4.3.3 Gestione dei workspacesI workspace in CArtAgO sono utilizzati per definire la struttura dell’ap-plicazione, che pu` essere organizzata in molteplici workspace, possibil- omente distribuiti fra differenti nodi computazionali JaCa. Generalmen-te, ogni applicazione CArtAgO fornisce un workspace di default, ma altriworkspace possono comunque essere creati dagli agenti utilizzando l’azionecreateWorkspace. Un agente pu` dinamicamente entrare in un workspace o(tramite l’azione joinWorkspace), per cui lavorare in maniera simultaneasu vari spazi di lavoro ed eventualmente uscirne non appena ha concluso ilproprio lavoro (tramite l’azione duale quitWorkspace).4.4 ConsiderazioniUna volta esauriti gli aspetti architetturali della piattaforma JaCa-Androide del suo modello di programmazione, si ` voluto discutere il suo utilizzo per elo sviluppo di smart mobile applications, valutando questo nuovo approccioin relazione con lo sviluppo classico su sistema operativo Android. Un primo aspetto generale riguarda il livello di astrazione ed il gappresente tra la progettazione e l’implementazione. Adottando il modellodi programmazione di JaCa-Android, un’applicazione Android mobile pu` oessere progettata ed organizzata come un sistema multi-agente, compostoda uno o pi` workspace nei quali gli agenti Jason vengono utilizzati per uincapsulare la logica ed il controllo dei task coinvolti nel flusso di lavo-ro dell’applicazione, mentre gli artefatti sono utilizzati dagli agenti comestrumenti per sfruttare trasparentemente i componenti ed i servizi messi adisposizione dal device o dalla piattaforma Android. Da un punto di vista 78
  • 84. CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID 79concettuale, questo approccio rende possibile il mantenimento dello stes-so livello di astrazione, basato su una visione agent-oriented, sia durantela progettazione dell’applicazione sia durante l’implementazione utilizzandoJason e CArtAgO. La fase di progettazione ` basata sul meta modello A&A, eche permette all’applicazione di: • definire la topologia introducendo uno o pi` workspace, u • scegliere l’insieme di agenti da includere in base alle necessit` a dell’applicazione stessa, • identificare l’insieme degli artefatti da introdurre per facilitare il lavoro degli agenti. Per questo, durante la fase di implementazione il progettista pu` rea- olizzare l’applicazione che ha sviluppato precedentemente utilizzando un setdi astrazioni di prima classe che direttamente si rifanno a quelle utilizzatenella fase di progettazione; gli agenti possono essere implementati in Jason,mentre gli artefatti possono essere realizzati utilizzando il framework CAr-tAgO. In questo modo ` possibile fornire agli sviluppatori una linea guida euniforme da seguire durante il processo di ingegnerizzazione dell’applicazio-ne mobile, senza gap concettuali tra le astrazioni utilizzate nell’analisi e lafase di implementazione successiva. Quindi, dal punto di vista della programmazione, il paradigma ad agen-ti da la possibilit` di affrontare direttamente alcune delle principali sfide amenzionate in precedenza. In particolare: • i comportamenti orientati ai task o alle activity possono essere diret- tamente mappati sugli agenti, possibilmente scegliendo differenti tipo- logie di architetture concorrenti in base alle proprie necessit`, come ad a esempio l’utilizzo di pi` agenti per eseguire concorrentemente i com- u piti o la scelta di un singolo agente per gestire l’esecuzione interleaved di vari compiti; • le interazioni asincrone possono essere gestite specificando propria- mente il comportamento reattivo degli agenti in relazione alla rice- zione di particolari eventi (ad esempio, l’arrivo di nuovi dati da un sensore o la ricezione di una nuova email); 79
  • 85. 80 CAPITOLO 4. LA PIATTAFORMA JACA-ANDROID • possono essere realizzate applicazioni che trasparentemente integrino comportamenti pro-attivi e reattivi, grazie all’architettura del con- trollo ad agenti. Nelle applicazioni Android standard, per rendere un componente consapevole dell’occorrenza di un determinato evento, ` e necessario che questo si registri alle callback appropriate che incap- sulano il codice sorgente che gestisce il relativo evento. Questo porta a varie conseguenza all’inversione del controllo nei programmi ed alla proliferazione del cos` detto “spaghetti code” asincrono. Utilizzan- ı do il modello di programmazione JaCa, invece, questa problematica ` direttamente gestita dall’architettura ad agenti sottesa: gli even- e ti generati dagli artefatti sono tradotti automaticamente in percept che gli agenti Jason possono osservare e quindi utilizzare per scegliere autonomamente, durante il ciclo di esecuzione, le migliori azioni da eseguire per realizzare un determinato task. Il compito della gestione degli eventi pu` essere quindi evitato all’ascoltatore e demandato alla o parte di controllo dell’applicazione, che a questo punto deve essere responsabile della gestione di questi compiti; • la capacit` degli agenti di adattare il loro comportamento sulla base a del contesto corrente pu` effettivamente essere utilizzata per realizzare o applicazioni context-aware e context-sensitive. Per questi motivi e quelli gi` introdotti concettualmente nel capitolo 3, asi ` deciso di utilizzare la piattaforma agent-oriented JaCa-Android per lo esviluppo di un’applicazione context-aware, dimostrando come l’utilizzo diquesto modello di programmazione risulti concettualmente utile per colmareil gap tra la progettazione e l’implementazione dell’applicazione. 80
  • 86. Capitolo 5Un caso di studio:LaggerCalendarNei capitoli precedenti ` stato introdotto l’approccio ad agenti per la mo- edellazione di applicazioni context-aware, discutendo come questo modello diprogrammazione fornisca agli sviluppatori un approccio di alto livello cheriduca il gap concettuale tra la progettazione dei componenti dell’applica-zione stessa e l’effettiva implementazione: i comportamenti e le interazionirichieste ai vari elementi del sistema possono cos` essere facilmente mappati ısugli agenti, adattandone il comportamento sulla base del contesto correntedell’utente. Per dimostrare in pratica come questo approccio risulti utileed innovativo, di seguito verr` presentato lo sviluppo di un’applicazione acontext-aware che esemplifichi i principali aspetti realizzativi, utilizzandocome framework la piattaforma JaCa-Android, introdotta nel capitolo 4.Design goalsIl principale obiettivo di questo capitolo non ` illustrare l’implementazione edi un’applicazione context-aware innovativa dal punto di vista delle risorsemesse in gioco o delle performance ottenute, ma quello di dimostrare comeun approccio ad agenti secondo l’architettura BDI, presentata in dettaglionel capitolo 3, possa fornire agli sviluppatori numerosi vantaggi sia dal puntoconcettuale che da quello implementativo, rispetto al classico sviluppo diapplicazioni su piattaforma Android. 81
  • 87. 82 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR5.1 Descrizione dello scenarioQuesta semplice applicazione context-aware ha l’obiettivo di gestire in mo-do “smart” gli appuntamenti dell’utente, valutando e amministrando perognuno di questi la possibilit` di ritardo. Il sistema ha infatti il compito di acalcolare in anticipo, sulla base della posizione attuale dell’utente e dell’indi-rizzo di destinazione, i tempi di percorrenza stimati per raggiungere il luogodell’appuntamento e la possibilit` che questi non permettano all’utente di arispettare i tempi stabiliti. L’applicazione si basa su un database di eventi inseriti dall’utente, perognuno dei quali deve essere specificata una descrizione, gli orari di inizio e fi-ne, il luogo di ritrovo ed un referente con relativo contatto (email, numero ditelefono, ecc..). Una volta lanciato, il sistema si occupa in maniera autono-ma di controllare a scadenze periodiche la possibilit` di ritardo, calcolando il atempo di percorrenza necessario per raggiungere il luogo dell’appuntamentosuccessivo: in caso le tempistiche stimate permettano comunque all’utentedi arrivare puntuale, l’applicazione si occuper` unicamente di visualizzare aun avviso per notificare il tempo rimanente a disposizione per mettersi inviaggio; altrimenti, previa approvazione dell’utente, provveder` ad inviare ala notifica direttamente al responsabile dell’appuntamento, tramite l’inviodi un messaggio standard (SMS, MMS, email, ecc..) che avverta del ritardoe lo quantifichi in maniera approssimativa. Anche gli appuntamenti succes-sivi potrebbero essere coinvolti in questo procedimento: nel caso in cui unappuntamento venga posticipato di un determinato lasso di tempo, potreb-bero non essere pi` rispettati i vincoli fisici per spostarsi nei vari luoghi in ucui dovranno tenersi i successivi appuntamenti. Per questo motivo, a frontedi una notifica di ritardo (e quindi di posticipazione dell’evento), anche isuccessivi eventi verranno controllati in cascata e, se necessario, notificatidel relativo ritardo. Per poter assicurare il rispetto degli appuntamenti stabiliti, al momentodell’inserimento di un nuovo evento, il sistema dovr` occuparsi di verificare ache l’utente abbia il tempo materiale di spostarsi dal luogo dell’appunta-mento precedente alla destinazione appena inserita. Anche in questo casoviene calcolato il tragitto ed il relativo tempo di percorrenza stimato, quindinel caso in cui il tempo non sia sufficiente nemmeno per il tragitto mini-mo tra i due indirizzi, verr` visualizzato a video un warning che avviser` a al’utente della problematica. 82
  • 88. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 835.1.1 Informazioni contestuali richiesteTra gli aspetti fondamentali da tenere in considerazione durante lo svilup-po di questa tipologia di applicazione, ci sono ovviamente le informazionicontestuali necessarie per il corretto funzionamento. Una volta identifica-te queste informazioni, l’applicazione pu` ottenerle esaminando i dati gi` o apresenti nel dispositivo o tramite i sensori con i quali ` equipaggiato il di- espositivo smartphone. In particolare, LaggerCalendar tratta tre tipologiedi informazioni contestuali: • gli appuntamenti dell’utente: il funzionamento dell’applicazione si basa sulle informazioni relative a data, ora e luogo in cui si terranno gli appuntamenti segnati nell’agenda personale; • i contatti dell’utente: le informazioni per contattare il referente di un appuntamento sono contenute all’interno della rubrica personale; • la posizione attuale dell’utente: questa informazione ` necessaria e per il calcolo del tragitto e del tempo stimato di percorrenza e viene fornita dal sensore GPS di cui deve essere provvisto lo smartphone. Sulla base delle informazioni elencate in precedenza, ` possibile identifi- ecare con una semplice analisi preliminare quali siano le operazioni principaliche dovranno essere eseguite dall’applicazione. Senza scendere in detta-gli implementativi che restringano lo spazio delle soluzioni possibili, pos-siamo affermare che all’interno dell’applicazione dovranno interagire varicomponenti, con l’obiettivo di svolgere i seguenti macro-compiti: • Gestione del calendario: ` necessario che l’applicazione si occupi e della gestione di un database di eventi, con la possibilit` di aggiungerli a o rimuoverli dinamicamente, controllando il rispetto di alcuni vincoli fisici; • Gestione della rubrica: l’applicazione deve poter interagire con la rubrica presente sul dispositivo per recuperare informazioni relative ad una determinata persona scelta dall’utente come responsabile per un evento in programma; 83
  • 89. 84 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR • Calcolo del tempo di percorrenza stimato: l’applicazione deve poter calcolare, fornite le infomazioni riguardo la partenza e la desti- nazione, il tragitto minimo e le tempistiche per percorrerlo. Questa operazione ` sicuramente, sia a livello computazionale che implemen- e tativo, la pi` complessa, in quanto coinvolge una vasta gamma di u risorse, dalle mappe delle strade disponibili all’effettivo algoritmo di calcolo del tragitto minimo. Per ovviare a questa problematica, iden- tificata gi` a questo livello preliminare di analisi, ` possibile appog- a e giarsi a servizi online (come, ad esempio, le Google Directions API 1 ) che forniscono i dati richiesti a fronte di una computazione server-side; • Gestione dell’interfaccia utente: l’applicazione deve infine fornire all’utente un’interfaccia reattiva che permetta la gestione degli eventi in maniera dinamica.5.2 Principali scenari applicativi e casi d’usoDi seguito verranno presentati i principali scenari di utilizzo, in modo damettere in luce i dettagli relativi al funzionamento del sistema. Figura 5.1: Casi d’uso principali 1 le Google Directions API fanno parte dei Google Maps API Web Servi-ces e sono un servizio che calcola le indicazioni stradali tra luoghi utilizzandorichieste HTTP. Per ulteriori informazioni, http://code.google.com/apis/maps/documentation/directions/. 84
  • 90. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 85 In figura 5.1 vengono presentate le operazioni eseguibili dall’utentetramite l’applicazione, a supporto dei principali casi d’uso presentati. Il primo scenario preso in considerazione ` quello relativo all’aggiunta edi un evento. Questa operazione prevede una serie di operazioni accessorie,secondo la semantica del funzionamento descritto nella sezione precedente:oltre alle informazioni relative all’evento da inserire, verr` selezionato un acontatto dalla rubrica gestita dall’applicazione stessa. Inoltre, prima diinserire definitivamente l’evento, viene richiesto il calcolo del tempo di per-correnza tra l’orario di fine dell’appuntamento precedente e quello di iniziodell’evento appena inserito, per verificare i vincoli fisici di spostamento. Il secondo scenario ` quello relativo alla gestione di un appuntamento: equesto in realt` ` un duplice scenario, in quanto le azioni eseguite dell’ap- aeplicazione sono differenti in base all’effettivo ritardo o meno dell’utente.Per ogni appuntamento l’applicazione provvede al calcolo, con un anticipodefinito dall’utente (ad esempio, un’ora prima come valore di default), deltempo di percorrenza dalla posizione attuale al luogo dell’appuntamento:nel caso in cui il ritardo non si ` verificato, ricorda comunque l’appunta- emento all’utente tramite un messaggio video; altrimenti, previa confermadell’utente, notifica il ritardo direttamente al referente dell’appuntamentotramite l’invio di un messaggio (in base ai servizi effettivamente disponibili)e controlla in cascata la possibilit` di ritardo per gli eventi successivi. Nel acaso in cui non si sia configurato il ritardo, questo controllo verr` comunque aripetuto a scadenza periodica dal primo. (a) Aggiunta di un evento (b) Notifica del ritardo Figura 5.2: Dettagli di alcuni scenari 85
  • 91. 86 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR Gi` dall’analisi di questi scenari ` possibile notare come la logica prin- a ecipale di funzionamento dell’applicazione non sia innescata dall’utente, masegua dinamiche legate alle informazioni gestite dal sistema e alle attualiinformazioni relative allo stato dell’utente. Questo comportamento attivo ereattivo segue e conferma le considerazioni fatte nei capitoli 2 e 3.5.3 Architettura dell’applicazioneConclusa una prima fase di analisi del comportamento richiesto all’applica-zione e della sua struttura, ` possibile continuare la progettazione scegliendo einnanzitutto le tecnologie e le piattaforme da utilizzare per l’effettiva im-plementazione. Visto l’obiettivo principale dello sviluppo dell’applicazione,gi` enunciato all’inizio di questo capitolo, si ` deciso di utilizzare la piatta- a eforma JaCa-Android per la progettazione, sfruttando quindi un modelload agenti con architettura BDI ed artefatti (abbreviato in A&A). Le en-tit` di queste due tipologie che compongono il sistema verranno descritte in adettaglio nelle sezioni seguenti. Una visione generale dell’architettura delcomplessiva del sistema e delle entit` che lo costituiscono viene presentata ain figura 5.3.5.3.1 Progettazione degli artefattiGli artefatti modellati all’interno del sistema rappresentano le funzionalit`arese effettivamente disponibili agli agenti. Basandosi sull’analisi precedente-mente affrontata nella sezione 5.1.1, ognuno dei macro-compiti identificati` stato demandato ad uno specifico artefatto, che gestisca la specifica ti-epologia di informazioni e fornisca le funzionalit` richieste dal sistema. In aparticolare, sono state modellate le seguenti entit`: a • CalendarService: gestisce le funzionalit` legate al database degli a eventi caricati; tramite l’operazioni messe a disposizione da questo artefatto ` possibile aggiungere o rimuovere un evento ed ottenere e l’intero calendario; • AddressBookService: gestisce le funzionalit` proprie di una rubri- a ca, fornendo le operazioni necessarie per aggiungere/rimuovere un contatto (addContact/deleteContact) oppure eseguire una ricerca (searchContact); 86
  • 92. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 87 Figura 5.3: Architettura generale dell’applicazione 87
  • 93. 88 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR • DirectionsService: fornisce la principale funzionalit` di calcola- a re il tragitto ed il relativo tempo di percorrenza, date le coordina- te o l’indirizzo del luogo di partenza e quello di arrivo (operazione calculateTravelTime); • TimeService: fornisce le funzionalit` per ottenere la data e l’orario a corrente; • EventManagerArtifact e EventEditorGUI: gestiscono le interfacce grafiche dell’applicazione (rispettivamente, quella relativa alla visua- lizzazione degli eventi gi` inseriti nel calendario e quella per la vi- a sualizzazione o inserimento del singolo appuntamento), effettuando il wrap delle classiche Activity su piattaforma Android. Il sistema, per poter effettuare il calcolo delle tempistiche stimate dipercorrenza, necessita inoltre di conoscere la posizione attuale dell’uten-te, rilevata utilizzando il sensore GPS di cui ` (idealmente) equipaggiato eil dispositivo. Queste informazioni sono ottenute dall’agente tramite l’uti-lizzo di un artefatto messo a disposizione direttamente dalla piattaformaJaCa-Android, il GPSManager: questo artefatto, ` disponibile a startup nel eworkspace condiviso JaCa-Services e fornisce le coordinate di latitudine elongitudine per la geolocalizzazione del dispositivo. Nello stesso workspace condiviso sono presenti gli artefatti chegestiscono le funzionalit` relative alla mail ed agli SMS: trami- ate le operazioni send(String address, String text) degli artefattiSMSManager/MailManager ` possibile gestire l’invio della notifica ai contatti ein caso di ritardo.5.3.2 Progettazione degli agentiLo studio degli scenari di utilizzo dell’applicazione ha identificato quale siail principale comportamento richiesto al sistema: la scelta effettuata permodellare tale comportamento ` la realizzazione di un singolo agente che si eoccupi di utilizzare gli artefatti disponibili. Questa soluzione non pregiu-dica comunque le valutazioni sul modello ad agenti introdotto: la presenzadi un solo agente semplifica aspetti implementativi come la concorrenzao la parallelizzazione della computazione, ma non intacca le caratteristi-che di pro-attivit`, reattivi` ed adattivit` realizzate tramite l’introduzione a a a 88
  • 94. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 89del paradigma BDI. La dinamica dell’applicazione, descritta nella sezione5.1 ` quindi completamente realizzata dal comportamento del singolo agen- ete, che discrimina l’esecuzione dei piani progettati sulla base delle attualiinformazioni contestuali e del database di eventi inserito dall’utente.5.4 Alcuni dettagli implementativiA supporto dell’architettura descritta, vengono forniti alcuni dettagli rela-tivi al codice prodotto, in modo da mostrare quali siano state in praticale tecniche implementative introdotte dall’utilizzo della piattaforma JaCa-Android. All’interno di questa sezione non verr` riportato l’intero codice asorgente dell’applicazione ma solamente alcuni frammenti delle sue parti pi`usignificative.5.4.1 Implementazione degli artefattiIn questa sezione verr` presentata l’implementazione di alcune operazioni asignificative nell’ottica del funzionamento dell’applicazione, per mostrarecome i servizi analizzati nelle sezioni precedenti siano poi effettivamenterealizzati in CArtAgO. Durante questa trattazione ` stato preso in considerazione principalmen- ete l’artefatto CalendarService, che realizza le principali operazioni richie-ste dalla logica dell’applicazione, definite come metodi con l’annotazione@OPERATION (alcuni dettagli di codice sono riportati in tabella 5.1). Il loroutilizzo coinvolge due classi, LaggerEvent e LaggerContact, che incapsula-no le informazioni necessarie per la definizione rispettivamente di un eventoed un contatto nell’applicazione. Il metodo costruttore init, lanciato allostartup del sistema, si occupa della configurazione iniziale del calendario,caricando gli eventi gi` inseriti precedentemente, se presenti. a Durante l’esecuzione dell’applicazione, alla richiesta dell’utente di in-serire un nuovo evento, viene invocata dall’agente l’operazione addEvent,fornendo in input tutte le informazioni relative al nuovo appuntamento: ol-tre all’inserimento nel database, questa operazione si occupa di configurareuna opportuna notifica per il nuovo evento, con l’anticipo definito in fasedi progetto (in questo caso, rappresentato dalla costante ADVANCE_TIME).L’esecuzione asincrona di questa notifica ` realizzata tramite una chiamata e 89
  • 95. 90 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDARall’operazione interna scheduleEventNotification (linee 50-52), che tra-mite la funzione await_time attende il tempo necessario prima di far scat-tare un’opportuna signal contenente le informazioni dell’evento in questio-ne. Questo segnale verr` percepito dall’agente, che innescher` le opportune a aoperazioni per la sua gestione. Analizzando invece il caso in cui, a fronte di una notifica relativa adun determinato evento, il sistema abbia verificato che non si ` configurato eritardo, il sistema deve eseguire una nuova notifica ad un intervallo di tempopredefinito (in questo caso, questo valore ` incorporato nel codice nella ecostante POSTPONEMENT_TIME). Questa operazione, realizzata nel metodopostponeEventNotification, controlla che l’orario della prossima notificanon superi quello di inizio dell’appuntamento, per poi invocare, come nelcaso precedente, l’operazione scheduleEventNotification per configurareuna nuova notifica.00 public class CalendarService extends Artifact {0102 private int id = 0;03 private HashMap<Integer,LaggerEvent> calendar;04 private final static long ADVANCE_TIME = (1000 * 60 * 60);05 private final static long POSTPONEMENT_TIME = (1000 * 60 * 15);0607 public void init() {08 ...09 }1011 @OPERATION void addEvent(String descr, Date startDate, Date endDate, String address, String responsible {12 calendar.put(++id, new LaggerEvent(id, descr, startDate,endDate, address, new LaggerContact(responsible)));13 Date now = new Date();14 long delay = (startDate.getTime() - now.getTime()) - ADVANCE_TIME;15 execInternalOp("scheduleEventNotification", id, delay);16 }1718 @OPERATION void modifyEvent(Integer id, String descr, Date startDate, Date endDate, String address, String responsible){19 LaggerEvent ev = calendar.get(id);20 ev.setAddress(address);21 ev.setStartDate(endDate);22 ev.setEndDate(endDate);23 ev.setResponsible(new LaggerContact(responsible));24 calendar.put(id, new LaggerEvent(id, descr, startDate,endDate, address, new LaggerContact(responsible)));25 ...26 Date now = new Date();27 long delay = (startDate.getTime() - now.getTime()) - ADVANCE_TIME;28 execInternalOp("scheduleEventNotification", id, delay);29 } 90
  • 96. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 913031 @OPERATION void loadCalendar(){32 Iterator<Entry<Integer,LaggerEvent>> i = calendar.entrySet().iterator();33 while(i.hasNext()){34 Map.Entry<Integer,LaggerEvent> me = (Map.Entry<Integer,LaggerEvent>) i.next();35 LaggerEvent e = (LaggerEvent) me.getValue();36 Date now = new Date();37 long delay = (e.getStartDate().getTime() - now.getTime()) - ADVANCE_TIME;38 execInternalOp("scheduleEventNotification", e.getID(), delay);39 }40 }4142 @OPERATION void postponeEventNotification(LaggerEvent event){43 Date now = new Date();44 Date startDate = event.getStartDate();45 if ((now.getTime() + POSTPONEMENT_TIME) - startDate.getTime() <= 0){46 execInternalOp("scheduleEventNotification", id, POSTPONEMENT_TIME);47 }48 }4950 @INTERNAL_OPERATION void scheduleEventNotification(int id, long delay){51 await_time(delay);52 signal("check_schedule_tick", this.get(id));53 }54 } Tabella 5.1: Codice sorgente dell’artefatto CalendarService.5.4.2 Implementazione degli agentiVista la particolare importanza data ai requisiti di dinamicit` e pro-attivit` a arichiesti dalle applicazioni context-aware, ` stata posta particolare attenzio- ene all’implementazione in linguaggio Jason del comportamento dell’agente,sottolineando come i piani definiti in questa sezione definiscano in manieraconsistente il funzionamento del sistema.00 !start.0102 +!start03 <- !init;04 !do_job.05 91
  • 97. 92 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR06 +!init07 <- println("[cal-ag:]Hello World!!.");08 focusWhenAvailable("events-mngr");09 makeArtifact("gps-manager", "...",[] , GPSID);10 focus(GPSID);11 makeArtifact("sms-manager", "...",[], SmsID);12 focus(SmsID);13 makeArtifact("call-manager", "...",[] , CallID);14 focus(CallID);15 makeArtifact("addressbook", "...",[] , AddressBookID);16 focus(AddressBookID);17 makeArtifact("directions", "...",[] , DirectionsID);18 focus(DirectionsID);19 makeArtifact("calendar", "...",[] , CalendarID);20 focus(CalendarID);21 println("[cal-ag:]Artifacts created and focussed").2223 +!do_job : true24 <- startMonitoring;25 println("[cal-ag:]Successfully started monitoring GPS").2627 +add_new_event_menu_click28 <- println("[cal-ag:]Menu click perceived by the agent");29 startExplicitActivity("jaca.laggercalendar.EventEditorActivity");30 focusWhenAvailable("event-editor-gui");31 println("[cal-ag:]focusWhenAvailable done");32 lookupArtifact("event-editor-gui", EditorID);33 println("[cal-ag:]Event editor artiact created and focussed").3435 +new_event_btn_click(EvDescr, StartDate, EndDate, Address, Responsible)36 <- println("[cal-ag:]new_event_btn_click received");37 addEvent(EvDescr, StartDate, EndDate, Address, Responsible);38 startExplicitActivity("jaca.laggercalendar.EventListActivity").3940 +modify_event_btn_click(EvID, EvDescr, StartDate, EndDate, Address, Responsible)41 <- println("[cal-ag:]modify_event_btn_click");42 modifyEvent(EvID, EvDescr, StartDate, EndDate, Address, Responsible);43 startExplicitActivity("jaca.laggercalendar.EventListActivity").4445 +check_schedule_tick(EventInfo)46 <- ?latitude(Lat);47 ?longitude(Long);48 println("[cal-ag:]Latitude and longitude retrieved");49 calculateTravelTime(Lat, Long, EventInfo, EstTime);50 +estTime(EstTime);51 println("[cal-ag:]Estimated time calculated", EstTime);52 !notify_event_approaching.5354 +!notify_event_approaching55 <- !check_on_time(EventInfo, EstTime);56 showEventReminder(EventInfo);57 postponeEventNotification(EventInfo).5859 -!notify_event_approaching : estTime(EstTime)60 <- println("[cal-ag:]FAILURE HANDLED", EstTime);61 showDelayManagementWindow(EstTime); 92
  • 98. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 9362 println("[cal-ag:]Delay selection window shown").6364 +!check_on_time(EventInfo, EstTime, Res)65 <- ...6667 +approved_delay(Delay)68 <- !postpone_apps(Delay);69 .concat("I’m sorry, I’m ",Delay," minutes late for our appointment.", Msg);70 !notify_delays(Msg).7172 +!postpone_apps(Delay)73 <- ...7475 +!notify_delays(Message)76 <- ...7778 +!send_notification(Contact, Message) : wifi_status(on)79 <- sendMail(Contact, Message).8081 +!send_notification(Contact, Message) : wifi_status(off)82 <- sendSMS(Contact, Message).8384 +latitude(Lat) : longitude(Long) & time(Time) & busy(Lat,Long,Time)85 <- +busy;86 setRingtone_volume(0);87 setVibration(on).8889 +longitude(Long) : latitude(Lat) & time(Time) & busy(Lat,Long,Time)90 <- +busy;91 setRingtone_volume(0);92 setVibration(on).9394 +latitude(Lat) : longitude(Long) & time(Time) & not_busy(Lat,Long,Time)95 <- -busy;96 setRingtone_volume(100);97 setVibration(on).9899 +longitude(Long) : latitude(Lat) & time(Time) & not_busy(Lat,Long,Time)100 <- -busy;101 setRingtone_volume(100);102 setVibration(off).103104 +incoming_call(Contact) : busy105 <- dropCall;106 !send_notification(Contact, "Sorry, I’m currently busy.").107108 +new_sms(Contact) : busy109 <- sendSMS(Contact, "Sorry, I’m currently busy."). Tabella 5.2: Codice sorgente del LaggerCalendar agent. 93
  • 99. 94 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR Il comportamento dell’agente, una volta conclusa la fase di inizializ-zazione (linee 00-21), segue una serie di piani reattivi. Il primo e prin-cipale, check_schedule_tick (linee 45-52), viene avviato in seguito al-la generazione del relativo segnale check_schedule_tick da parte del-l’artefatto quando l’evento sta per iniziare. In dettaglio, questo piano ` eutilizzato per effettuare il controllo della posizione corrente e confrontar-lo con l’indirizzo di destinazione: a tal fine viene utilizzata l’operazionecalculateTravelTime realizzata dall’artefatto DirectionsService. Unavolta ottenuto il tempo stimato di percorrenza, registrato in un appositobelief chiamato estTime, viene aggiunto il sub-goal relativo alla notifica diun evento (notify_event_approaching). Il relativo piano messo in esecu-zione, verifica la presenza di ritardo (gestito dal sub-goal check_on_time)e, nel caso in cui l’utente non ne abbia accumulato, chiama le opportunefunzioni per visualizzare un reminder dell’appuntamento e posticipare lanotifica, come previsto dalla logica dell’applicazione. In caso l’utente sia in ritardo, invece, il piano check_on_timefallisce, come del resto l’intero piano notify_event_approaching:a questo punto, l’agente esegue il relativo piano di recupero(-!notify_event_approaching, linee 59-62), che consente all’utente dispecificare un nuovo orario di inizio per l’evento corrente. Nel caso in cuil’utente acconsenta a spostare la data di inizio dell’evento corrente, il relati-vo ritardo accumulato sar` notificato all’agente dall’apposito GUIArtifact atramite una signal approved_delay che innescher` l’esecuzione del piano arelativo riportato alle linee 67-70: l’agente, tramite due appositi sub-goal,posticiper` in cascata gli altri appuntamenti, se necessario, ed effettuar` le a aopportune notifiche di ritardo. Infine, una volta arrivato ad un appuntamento, in maniera dinamicasulla base delle percezioni dei latitudine e longitudine dal GPSManager edel tempo attuale fornito dall’artefatto TimeService, l’agente si occupa didisattivare la suoneria ed impostare la vibrazione del dispositivo, gestendoun apposito belief chiamato busy. Durante lo svolgersi dell’appuntamen-to, non sono previsti contatti in entrata, notificando ad ognuno di questil’indisponibilit` dell’utente, tramite l’apposito piano send_notification a(linee 78-82). Da notare il fatto che le modalit` di comunicazione variano ain base al contesto dell’utente: la presenza o meno del collegamento Wi-Fidisponibile discrimina il fatto che questa avvenga rispettivamente via mailo via SMS. 94
  • 100. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 955.5 Scenari reali di funzionamentoUna volta conclusa la fase di realizzazione dell’applicazione, sono stati ese-guiti alcuni test su scenari reali per testare la correttezza della logica im-plementata. I semplici scenari presentati di seguito esemplificano un paiodi contesti interessanti legati al comportamento dell’applicazione. Si pre-suppone che l’utente inserisca nell’applicazione due appuntamenti durantela giornata corrente: • un meeting in ApiCe, presso la Facolt` di Ingegneria, che si svolge a a Cesena dalle 14.00 alle 15.00; • una lezione presso la Facolt` di Ingegneria di Bologna dalle 16.30 alle a 18.00. A fronte dell’inserimento del secondo evento (visualizzato nello screen-shot in figura 5.4(b)), l’applicazione verifica il rispetto dei vincoli fisici dispostamento calcolando il tempo di percorrenza tra i due indirizzi: questatempistica, che ora per semplicit` stimiamo essere circa 1 ora, permette ail rispetto di tutti gli orari. Gli eventi finora inseriti sono visualizzati inun’apposita schermata contenente l’intero database degli appuntamenti(figura 5.4(a)). Stabilito che le notifiche inizino ad essere generate con un anticipo un’orae ad intervalli di 15 minuti, alle 13.00 l’applicazione verificher` la posizione acorrente e le tempistiche necessarie per raggiungere la Facolt` di Ingegneria adi Cesena. Il comportamento del sistema viene discriminato in base allaposizione corrente dell’utente. Nel primo caso, assumiamo che l’utente si trovi attualmente fuori An-cona e che quindi il tempo di percorrenza stimato per raggiungere il primoappuntamento sia di 1 ora e 40 minuti. Il sistema allora visualizzer` una anotifica del ritardo accumulato, lasciando che l’utente proponga un nuovoorario di arrivo (screenshot in figura 5.5). Il nuovo orario stabilito verr` anotificato automaticamente al responsabile tramite SMS o email, ma spo-ster` comunque in avanti l’appuntamento corrente di 40 minuti, rendendo anecessario il controllo di eventuali conflitti con gli eventi successivi: in que-sto caso, i 50 minuti rimanenti per lo spostamento non risultano sufficienti,per cui l’evento verr` spostato di 10 minuti ed il ritardo verr` notificato al a aresponsabile incaricato. 95
  • 101. 96 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR (a) Lista degli eventi (b) Inserimento di un nuovo evento Figura 5.4: Alcune schermate relative agli eventi in LaggerCalendar. 96
  • 102. CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR 97 Figura 5.5: Schermata di notifica di un ritardo 97
  • 103. 98 CAPITOLO 5. UN CASO DI STUDIO: LAGGERCALENDAR Anche nel secondo caso, in cui l’utente si trova indicativamente fuo-ri Bologna, il tempo di percorrenza del tragitto (circa 1 ora e 15 minuti)non permette l’arrivo puntuale all’appuntamento in ApiCe. La gestionedel ritardo per il primo evento avviene in maniera del tutto analoga allaprecedente, spostando l’appuntamento e notificando il ritardo. Il controlloin cascata sugli eventi successivi, invece, non produce inconsistenze: la di-stanza tra i due meeting, diminuita a 1 ora e 15 minuti, risulta comunquesufficiente per lo spostamento. Una volta giunto all’appuntamento in Api-Ce, l’applicazione provveder` a disattivare la suoneria dello smartphone e aad attivare la vibrazione, rispondendo ad eventuali chiamate in entrata oSMS con un messaggio standard che avvisa che l’utente non ` attualmente edisponibile.5.6 Considerazioni conclusiveL’obiettivo primario dello sviluppo dell’applicazione LaggerCalendar ` sta- eto quello di esemplificare le caratteristiche delle applicazioni context-aware,affrontate agilmente tramite l’introduzione dell’ astrazione di agente intel-ligente supportata dalla piattaforma JaCa-Android. Per questo motivo, leperformance dell’applicazione non sono state considerate un’aspetto prima-rio durante lo sviluppo. Il testing del corretto funzionamento dell’appli-cazione ` stato comunque effettuato partendo dal caso reale modellato in esezione 5.5, utilizzando uno smarphone Samsum Galaxy Ace: processore a800MHz, 256 MB di RAM, Android versione 2.2.1 Froyo. Nonostante non siano stati effettuati test statistici sulle performance, `ecomunque possibile affermare che la reattivit` e la fluidit` dell’applicazione a asono state mantenute durante il normale funzionamento, senza presentareritardi nella risposta della GUI o nel caricamento delle informazioni. Afronte dell’implementazione di nuove e pi` ricche funzionalit` di LaggerCa- u alendar che arricchiscano l’interazione e l’esperienza dell’utente, queste con-siderazioni legate alle performance, meno considerate in questa trattazione,possono essere valutate e riconsiderate, fornendo come supporto accuratitest statistici che ne permettano una comprensione pi` completa. u 98
  • 104. ConclusioniLa progettazione e lo sviluppo delle moderne smart mobile application coin-volgono sempre pi` spesso il contesto in cui avviene la compuzione: questo ucomporta la gestione di una consistente mole di dati ed una percezione di-namica dei cambiamenti che avvengono nell’ambiente, per poter adattareil comportamento del sistema durante l’esecuzione. Uno degli obiettivi diquesta tesi ` innanzitutto l’analisi di quali siano le problematiche introdotte edalla gestione di questo nuovo aspetto e quali siano effettivamente le infor-mazioni coinvolte nel processo. Basandosi su quanto presente in letteratura,sono state proposte varie interpretazioni del contesto, al fine di mettere inluce gli aspetti chiave di questa emergente categoria di applicazioni: si ` eevidenziato che caratteristiche come reattivit`, percettivit` e adattamento a asono comuni a tutti questi sistemi e, quindi, affrontati sistematicamentedurante la progettazione. Sulla base di queste valutazioni ` stato possibile quindi notare come gli estrumenti forniti dalle attuali piattaforme di sviluppo, pur sufficienti pergestire tutte le risorse e le funzionalit` del dispositivo, non offrono per` a oil giusto supporto per affrontare la progettazione degli aspetti precedente-mente individuati. L’utilizzo di una programmazione ad agenti minimizzail gap concettuale tra il comportamento richiesto al sistema e le primitivemesse a disposizione, suggerendo che un approccio pi` ad alto livello possa uridurre queste complessit` e sistematizzare la progettazione di tale catego- aria di applicazioni. A questo scopo ` stata proposto un approccio ad agenti eintelligenti secondo il paradigma BDI, facendo notare come l’astrazione diagente ben si adatti alla modellazione delle caratteristiche richieste. Lo sco-po primario di questa tesi ` stato quindi quello di affrontare lo sviluppo di etale categoria di sistemi, proponendo l’utilizzo di un approccio ad agenti co-me possibile soluzione per tracciare uno sviluppo sistematico di applicazionidipendenti dal contesto. 99
  • 105. 100 CAPITOLO 5. CONCLUSIONI Per poter proseguire nell’implementazione concreta di un’applicazionecontext-aware su cui testare le ipotesi formulate, si ` scelto di utilizzare il emiddleware software JaCa-Android, che permette la modellazione di appli-cazioni mobile su piattaforma Android in termini di agenti goal-oriented perintegrare comportamenti computazionali reattivi e pro-attivi all’interno diambienti basati su artefatti, permettendo quindi l’utilizzo delle funzionalit`ae dei servizi resi disponibili dal dispositivo stesso. Per indagare effettivamente lo sviluppo di applicazioni mobile utilizzan-do una tecnologia agent-based, tale piattaforma ` stata effettivamente uti- elizzata nella progettazione ed implementazione di una semplice applicazionecontext-aware, LaggerCalendar. Il sistema realizzato ha l’obiettivo di esem-plificare la trattazione dell’intera categoria di applicazioni mobile dipendentidal contesto, mostrando come le caratteristiche identificate possano essereriscontrate anche in questa applicazione di esempio: ` stato dimostrato co- eme le dinamiche reattive ed adattive richieste al sistema in una prima fasedi analisi, siano poi state realizzate agilmente durante l’implementazionetramite la progettazione di agenti intelligenti. Per motivi di tempo, ` stata posta particolare attenzione solo su quelli eche sono gli aspetti base dello sviluppo di applicazioni mobile context-aware,tralasciando aspetti implementativi legati invece all’utilizzo dell’applicazio-ne stessa. Futuri sviluppi di questo lavoro possono riguardare due aspettiprincipali: il primo riguarda la realizzazione di nuove funzionalit` legate aalla logica del sistema, implementando nuovi servizi accessori e miglioran-do le interfacce grafiche, per arricchire l’interazione con l’utente; il secondoaspetto, invece, riguarda lo sfruttamento di servizi web forniti da terzi, perfavorirne la diffusione e l’integrazione con altre applicazioni gi` installate asulle stesso dispositivo. 100
  • 106. Appendice AAcronimiACL Agent Communication Language.API Application Programming Interface.BDI Belifs, desires and Intentions.CArtAgO Common ARTifact infrastructure for AGents Open environments.FIPA Foundation of Intelligent Physical Agents.GUI Graphic User Interface.HCI Human-computer interaction.IDE Integrated Development Environment.JADE Java Agent DEvelopment framework.JVM Java Virtual Machine.LEAP Lightweight and Extensible Agent Platform.OOP Object Oriented Programming.OS Operating System.PDA Personal Digital Assistant. 101
  • 107. 102 APPENDICE A. ACRONIMIPRS Procedural Reasoning System.SDK Software Development Kit. 102
  • 108. Bibliografia[1] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith, and P. Steggles. Towards a better understanding of context and context- awareness. In Proceedings of the 1st international symposium on Han- dheld and Ubiquitous Computing, HUC ’99, pages 304–307, London, UK, 1999. Springer-Verlag.[2] Apple. Ios developer library. http://developer.apple.com/ library/ios/, 2011.[3] P. J. Brown. Triggering information by context. Personal Technologies, 2(1):1–9, September 1998.[4] A. K. Dey. Context-aware computing: The cyberdesk project. In AAAI 1998 Spring Symposium on Intelligent Environments, pages 51– 54, Palo Alto, 1998. AAAI Press.[5] A. K. Dey. Understanding and using context. Personal Ubiquitous Comput., 5:4–7, January 2001.[6] A. K. Dey, G. D. Abowd, and A. Wood. Cyberdesk: a framework for providing self-integrating context-aware services. Knowledge-Based Systems, 11(1):3–13, September 1998.[7] P. Dourish. What we talk about when we talk about context. Personal Ubiquitous Comput., 8:19–30, February 2004.[8] S. Fickas, G. Kortuem, and Z. Segall. Software organization for dynamic and adaptable wearable systems. In ISWC, pages 56–64, 1997.[9] Google. Android developers. http://developer.android.com/ guide/, 2011. 103
  • 109. 104 BIBLIOGRAFIA[10] R. Hull, P. Neaves, and J. Bedford-Roberts. Towards situated computing. In ISWC, pages 146–153, 1997.[11] R.-H. Hwang, S.-Y. Tsai, and C.-Y. Wang. Ubiphone: Human-centered ubiquitous phone system. IEEE Pervasive Computing, 8:40–47, April 2009.[12] M. J. Pascoe. Adding generic contextual capabilities to wearable com- puters. In Proceedings of the 2nd IEEE International Symposium on Wearable Computers, ISWC ’98, pages 92–99, Washington, DC, USA, 1998. IEEE Computer Society.[13] M. Raento, A. Oulasvirta, R. Petit, and H. Toivonen. Contextphone: A prototyping platform for context-aware mobile applications. IEEE Pervasive Computing, 4:51–59, April 2005.[14] N. Ryan, J. Pascoe, and D. Morse. Enhanced reality fieldwork: the context-aware archaeological assistant. In V. Gaffney, M. van Leu- sen, and S. Exxon, editors, Computer Applications and Quantitative Methods in Archaeology (CAA 97), Oxford, 1997.[15] D. Salber, A. K. Dey, and G. D. Abowd. Ubiquitous computing: Defining an hci research - agenda for an emerging interaction pa- radigm. Technical report, Georgia Tech GVU Technical Report GIT-GVU-98-01, 1998.[16] A. Santi, M. Guidi, and A. Ricci. Jaca-android: An agent-based plat- form for building smart mobile applications. In In Proceedings of Lan- guages, Methodologies and Development tools for multi-agent systems (LADS-2010), 2010.[17] B. Schilit, N. Adams, and R. Want. Context-aware computing applica- tions. In Proceedings of the 1994 First Workshop on Mobile Computing Systems and Applications, pages 85–90, Washington, DC, USA, 1994. IEEE Computer Society.[18] B. N. Schilit and M. M. Theimer. Disseminating active map in- formation to mobile hosts. IEEE Network, pages 22–32, September 1994. 104
  • 110. BIBLIOGRAFIA 105[19] J. Tester. All the world is a game: The future of context aware gaming. Technology Horizons Program, 2006.[20] A. Westin. Privacy and freedom. Atheneum, New York, 1970.[21] Windows. Architecture guide for windows phone os 7.0, 2010.[22] Windows. Oem and mo application development guide for windows phone os 7.0, 2010. 105
  • 111. 106 BIBLIOGRAFIA 106
  • 112. Elenco delle figure 1.1 Principali tipologie di smart devices . . . . . . . . . . . . . . 7 1.2 Schermata e logo di Apple iOS . . . . . . . . . . . . . . . . . 9 1.3 Architettura di iOS . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Schermata e logo di Google Android . . . . . . . . . . . . . 13 1.5 Architettura di Android . . . . . . . . . . . . . . . . . . . . 16 1.6 Esecuzione di un’applicazione Android . . . . . . . . . . . . 17 1.7 Schermata e logo di Windows Phone . . . . . . . . . . . . . 18 1.8 Architettura di Windows Phone . . . . . . . . . . . . . . . . 19 2.1 Aspetti principali dell’ubiquitous computing . . . . . . . . . 25 2.2 Ere della computer science secondo Weiser . . . . . . . . . . 27 2.3 Trend di sviluppo dell’ubiquitous computing . . . . . . . . . 27 2.4 Architettura di ContextPhone . . . . . . . . . . . . . . . . . 46 2.5 Architettura di UbiPhone . . . . . . . . . . . . . . . . . . . 51 4.1 Architettura della piattaforma JaCa-Android . . . . . . . . . 69 4.2 Rappresentazione astratta di una applicazione JaCa . . . . . 70 5.1 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . 84 5.2 Dettagli di alcuni scenari . . . . . . . . . . . . . . . . . . . . 85 5.3 Architettura generale dell’applicazione . . . . . . . . . . . . 87 5.4 Alcune schermate relative agli eventi in LaggerCalendar. . . . 96 5.5 Schermata di notifica di un ritardo . . . . . . . . . . . . . . 97 107
  • 113. 108 ELENCO DELLE FIGURE 108
  • 114. Elenco delle tabelle 4.1 Codice sorgente dell’agente sms-notifier. . . . . . . . . . . . . 74 4.2 Codice sorgente dell’artefatto SMSViewer. . . . . . . . . . . . 76 5.1 Codice sorgente dell’artefatto CalendarService. . . . . . . . . 91 5.2 Codice sorgente del LaggerCalendar agent. . . . . . . . . . . . 93 109
  • 115. 110 ELENCO DELLE TABELLE 110
  • 116. RingraziamentiOrmai giunto alla conclusione di questo lungo percorso universitario, vorreiringraziare tutte le persone che mi sono state vicino, ognuna a proprio modo,e che mi hanno aiutato a diventare la persona che sono. In primo luogo, un grazie di cuore alla mia famiglia, che mi ha so-stenuto costantemente, senza cedimenti o dubbi riguardo le strade che hodeciso di intraprendere finora. Per quanto sia sembrato scontato, ho laconsapevolezza che senza il vostro aiuto non sarei arrivato dove sono. Un ringraziamento particolare va anche ai miei compagni di corso, concui ho condiviso le soddisfazioni e superato le difficolt` che in questi anni aabbiamo affrontato insieme, rendendo questo duro percorso uno stupendoviaggio insieme. Grazie a tutti gli amici veri che ho al di fuori dell’universit`, aperch´ mi hanno aiutato a staccare dai libri quando ne avevo bisogno. e Un grazie va alla persona che mi ` sempre stata vicino e che, anche nei emomenti in cui non c’` stata fisicamente, ` rimasta comunque un pensiero e efisso nella mia testa. Concludo ricordando le quattro persone che condividono con me l’altramia grande passione, la musica. Grazie. 111