v2 Presentazione Lelli
6 Jun 2016•0 j'aime•93 vues
Télécharger pour lire hors ligne
Signaler
Matteo LelliSuivre
Contenu connexe
En vedette
Reactive Sputtering Deposition PresentationDisheng Zheng
Foguete Escola joao de lima sala de tecnologias
Contabilidad 10AJuan Gómez
Advertising budgetAnjali Das V.M
Lasoldadura mayerlin canadgffdf34
Slide titolo revisore.4Cittalia
Similaire à v2 Presentazione Lelli
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...Mattia De Bernardi
Progettazione e sviluppo di un software applicativo su un single board computerAlessandro Mascherin
Generazione automatica diagrammi di rete con template pptxGiacomoZorzin
Supsi dti abstract_informatica_2012L Dr
Android - Programmazione AvanzataStefano Sanna
Angular js o React? Spunti e idee per la scelta di un frameworkGiovanni Buffa
v2 Presentazione Lelli
- 1. Design and Implementation of a Cloud-based Middleware for Persuasive Android Applications Candidato: Matteo Lelli Relatore: Chiar.mo Prof. Ing. Paolo Bellavista Correlatori: Prof. Abdelsalam Helal, Prof. Ing. Antonio Corradi 1
- 2. Captology • Deriva dall’acronimo di “Computers As Persuasive Technologies” • Si occupa dello studio dei computer utilizzati come tecnologie di persuasione 2
- 3. Assenza di teorie e di middleware In letteratura vi era una mancanza di: •Modelli teorici che potessero aiutare gli sviluppatori software a comprendere ed utilizzare al meglio le conoscenze inerenti lo studio della captology •Middleware che potessero facilitare lo sviluppo di applicazioni su dispositivi Android 3
- 4. Action- based Behavior Model Sviluppato all’University of Florida, ABM è un modello per applicazioni persuasive che può essere facilmente compreso ed utilizzato da informatici e da sviluppatori 4
- 5. Situation- based Assess Tree Struttura utilizzata per effettuare la valutazione della persuasione (Assess Step di ABM), in cui ogni nodo foglia corrisponde ad un comportamento da monitorare 5
- 6. Cicero Middleware • Middleware per dispositivi Android • Basato su ABM • Riduce ABM, adattandolo al mondo Android • Sensing che sfrutta le potenzialità di Google Play Services • Assessment delle modifiche dei comportamenti basata su Situation-based Assess Tree 6
- 7. Criticità di Cicero • Mono-sensing: può essere monitorato un solo comportamento per ogni applicazione • Mono-device: Cicero può essere eseguito su un solo dispositivo, perdendo l’opportunità di utilizzare più dispositvi posseduti dall’utente (ad esempio Smartwatch) • Integrazione con esperto del dominio: l’esperto è coinvolto solo minimamente nella persuasione e non può controllare o modificare l’applicazione • Espressività e uniformità dell’implementazione di SAT: albero non omogeneo e con lacune espressive 7
- 8. Struttura di Sensing Nuova architettura che permette il sensing contemporaneo di più comportamenti: ogni Sentience Object all’interno del Sentience Pool ha il compito di gestire un comportamento Sentience Manager Sentience Manager Service Sentience Manager Receiver Sentience Pool Sentience Objects Location Scan Motion Scan Completeness Scan Request to sense a behavior Google Play Services API or low-level API 8
- 9. Architettura Cloud- based Nuova architettura basata sulla centralizzazione del SAT in una piattaforma cloud (Google App Engine), che offre ai dispositivi delle API remote (Google Endpoints), mentre il sensing rimane distribuito Cyber Manager SAT APIs Domain Expert 9
- 10. Comunicazione con Smartwatch • Gli Smartwatch Android non sono tipicamente in grado di comunicare direttamente con la piattaforma cloud • È richiesto un protocollo di comunicazione che sfrutti lo Smartphone collegato allo Smartwatch come ponte verso il cloud • Il sensing è analogo a quello degli altri dispositivi; è necessario modificare solamente la comunicazione con la piattaforma cloud 10
- 11. Smartwatch- to-Cloud Communicatio n Protocol Protocollo di comunicazione fra smartwatch e cloud che si sviluppa in 7 passaggi, più un ottavo per la terminazione Handheld Smartwatch 1 SAT 2 3 4 5 6 7 8 11
- 12. Integrazione dell’esperto del dominio Grazie alla nuova architettura e ad un’apposita applicazione, l’esperto del dominio può: •Creare nuovi comportamenti da analizzare (aggiunta nodi SAT) •Modificare i valori di riferimento dei comportamenti preesistenti (ad esempio i minuti di camminata giornaliera) •Visualizzare la situazione corrente •Visualizzare un grafico con il dettaglio della storia dell’utente 12
- 13. Potenziamenti di SAT • Struttura gerarchica dei nodi che consente l’utilizzo di funzione ricorsive ed una migliore manipolazione degli stessi • Introduzione di un ID creato a runtime al momento dell’inserimento del nodo all’interno dell’albero • Aggiunta di due campi facoltativi all’interno dei nodi foglia allo scopo di specificare informazioni aggiuntive riguardo al contesto o alle azioni di sensing del dispositivo, modificabili successivamente alla creazione del nodo (ad esempio, la posizione della palestra preferita da un utente può avvenire in un secondo momento) 13
- 14. Test delle performance Per analizzare le performance della nuova versione di Cicero, ho svolto diversi test utilizzando i dispositivi fisici e gli emulatori riportati nella figura a lato Router GAE Development Server Android Watch Emulator Users’ smartwatch application Desktop PC USB connection Smartphone DEMA Users’ application LAN connection IEEE 802.11n connection 14
- 15. Risultati test App per Smartphone Grafico dell’utilizzo della CPU nell’applicazione per Smartphone Utilizzo CPU (%) Tempo Trascorso (s) 15
- 16. Risultati test App per Smartphone Utilizzo Memoria (MB) Tempo Trascorso (s) Grafico dell’utilizzo della memoria nell’applicazione per Smartphone 16
- 17. Risultati test App per Smartphone Traffico di rete (KB/s) Tempo Trascorso (s) Grafico del traffico di rete nell’applicazione per Smartphone 17
- 18. Risultati test App per Smartwatch Utilizzo CPU (%) Tempo Trascorso (s) Grafico dell’utilizzo della CPU nell’applicazione per Smartwatch 18
- 19. Risultati test App per Smartwatch Utilizzo Memoria (MB) Tempo Trascorso (s) Grafico dell’utilizzo della memoria nell’applicazione per Smartwatch 19
- 20. Conclusioni La nuova versione di Cicero è quindi: •In grado di effettuare il sensing di più comportamenti contemporaneamente e su più dispositivi fisici distinti, compresi Smartwatch •Organizzata in una nuova struttura orientata al cloud, offrendo un servizio di assess as-a-service •Impostata verso una maggiore integrazione dell’esperto del dominio, il quale ha il pieno controllo del SAT Possibili sviluppi futuri possono essere: •Gestione degli accessi e della sicurezza dei dati sensibili degli utenti conservati nel cloud •Applicazione web che consenta all’esperto del dominio di interagire con il SAT attraverso un browser web 20
Notes de l'éditeur
- Buongiorno. Sono Lelli Matteo e presenterò la mia tesi dal titolo “Design and Implementation of a cloud-based middleware for persuasive android applications”, svolta al Pervasive Lab dell’University of Florida
- La mia tesi rientra nell’area di ricerca della Captology, cioè lo studio dei computer utilizzati come tecnologie di persuasione. Anche se i computer e le tecnologie informatiche non sono nate con lo scopo di persuadere, negli anni stanno sempre più assumendo ruoli da persuasori una volta affidati ad esseri umani, come ad esempio insegnanti, personal trainer, venditori.
- In letteratura vi era però una mancanza di middleware sia teorici che pratici che potessero aiutare gli sviluppatori software a sviluppare applicazioni persuasive, cioè applicazioni in grado di cambiare i comportamenti degli utenti, sfruttando al meglio le conoscenze della captology.
- Per colmare questa lacuna, il gruppo di ricerca guidato dal Prof. Helal dell’Universit of Florida ha sviluppato in passato diversi modelli che potessreo rappresentare gli sforzi di persuasione, producendo anche diverse pubblicazioni. Fra questi il più importante è l’Action-based Behavior Model (ABM), un modello per applicazioni persuasive che può essere facilemnte compreso ed utilizzato da informatici e sviluppatori. In particolare, come illustrato nello schema in figura, l’utente è guidato attraverso diversi passaggi. Ad esempio, supponiamo di dover convincere una persona con problemi di diabete a condurre una vita più sana. Dopo una prima fase di profilazione, si rende consapevole l’utente della propria condizione o patologia (fase di aware), lo si interroga su alcuni informazioni come ad esempio la posizione della propria palestra preferita (fase di plan), lo si istruisce su come ad esempio sia più opportuno camminare o correre (fase di learn), lo si notifica nel momento e nel luogo più opportuno (fase di recall), lo si monitora durante l’attività (act) e si effettua una valutazione di quanto l’applicazione sia stata persuasiva (fase di assess). A questo punto si può assegnare ricompense all’utente (reward) o ritornare ad una fase precedente in cui sono emerse lacune di persuasione.
- All’interno della fase di valutazione, uno strumento fondamentale è il Situation-based assess tree (SAT). Esso è una struttura utilizzata per effettuare la valutazione della persuasione, in cui ogni nodo foglia corrisponde ad un comportamento positivo o negativo da monitorare. Inoltre, utilizzando una serie di operatori, si è in grado di valutare l’effetto della persuasione in ogni singolo nodo. Ad esempio, osservando il valore del nodo Aware, si è in grado di capire quanto l’utente sia stato reso consapevole della propria condizione.
- Un altro interessante prodotto del lavoro di ricerca condotto all’University of Florida è stata una prima versione di un middleware chiamato Cicero. Cicero è un middleware per dispositivi Android basato su ABM e SAT per quanto riguarda la fase di valutazione della persuasione. Per quanto riguarda invece il sensing, Cicero sfrutta le potenzialità di Google Play Services. In particolare, sfrutta diversi servizi, tra cui tra cui vale la pena citare quelli in grado di restituire la posizione approssimata dell’utente o il modo in cui si sta muovendo (ad esempio camminando, correndo, in bicicletta, su un veicolo)
- Questa prima versione di Cicero presentava però diverse criticità. In particolare, Cicero era strutturato in modo da consentire il monitoraggio di un solo comportamento per volta, rendendolo inservibile in ogni contesto reale. Poteva essere eseguito su un solo dispositivo, perdendo l’opportunità di sfruttare più dispositivi posseduti dallo stesso utente, come ad esempio smartwatch. Inoltre, l’esperto del dominio (cioè un dottore, psicologo, fisioterapista) non era completamente coinvolto. Infatti, esso poteva condividere link ad articoli o video con l’utente, ma non monitorare o modificare il SAT a runtime. Infine, il SAT presentava una mancanza di espressività ed omogeneità. Affronterò in dettaglio questo punto in seguito. Il mio lavoro di tesi, oltre ad individuare queste criticità, è consistito nel proporre e nell’implementare diversi modelli ed architetture per cercare di risolverle.
- Una prima struttura introdotta è quella di sensing. Essa è basata su il concetto di Sentience Objects, contenuti all’interno di un pool chiamato Sentience Pool. Ogni Sentience Object ha un proprio ciclo di vita, rendendo possibile il monitoraggio contemporaneo di più comportamenti. In particolare, gli aggiornamenti che giungono dai Google Play Services vengono gestiti separatamente da ogni oggetto, rendendo possibile il sensing contemporaneo.
- Un altro cambiamento apportato a Cicero è stata la nuova architettura basata sul cloud. Come mostrato in figura, ho accentrato tutta la parte di Cicero preposta alla valutazione della persuasione su di una piattaforma cloud Google App Engine ed in particolare il SAT. Inoltre, attraverso Google Endpoints ho esposto delle API remote per consentire la comunicazione tra i dispositivi dell’utente e il SAT. Con questa nuova architettura, è possibile gestire il sensing contemporaneo su più dispositivi distribuiti anche eterogenei poiché è presente un solo SAT per utente conservato sul cloud. Un particolare tipo di dispositivi sono gli Smartwatch. Tipicamente essi sono collegati allo smartphone attraverso Bluetooth e sono equipaggiati con Android Wear.
- In questa tipica configurazione, gli smartwatch non sono in grado di comunicare direttamente con il cloud. Si è quindi reso necessario un nuovo protocollo di comunicazione che sfrutti lo smartphone collegato come ponte verso il cloud. Il sensing tuttavia rimane analogo a quello degli altri dispositivi, infatti l’unica modifica riguarda la comunicazione tra smartwatch e cloud.
- Questo nuovo protocollo, chiamato Smartwatch-to-cloud communication protocol, consta di 7 passaggi fondamentali, più un ottavo necessario per la terminazione. In particolare, nel primo passaggio, lo smarphone richiede al SAT remoto quali comportamenti devono essere monitorati dalla smartwatch. Essi vengono restituiti sotto forma di oggetti serializzati nel punto 2. La lista viene poi inviata allo smartwatch attraverso un messaggio bluetooth nel punto 3. A questo punto lo smartwatch inizia a monitorare i comportamenti. Quando si rileva una determinata situazione collegata ad un comportamento, viene generato un evento che viene inviato allo smartphone (punto 5) Lo smarphone per prima cosa propaga l’evento localmente in quanto potrebbero esserci comportamenti in attesa localmente. Invia poi l’evento al cloud al punto 7. Infine, attraverso un ultimo messaggio è possibile terminare il sensing sullo smartwatch.
- Grazie ad una nuova applicazione sviluppata per l’esperto del dominio, quest’ultimo è ora in grado di: Creare nuovi comportamenti da monitorare, quindi aggiungere nodi foglia al SAT remoto Modificare i valori di riferimento dei nodi preesistenti, cambiando ad esempio i minuti che devono essere camminati in un giorno da 20 a 30 a runtime. Visualizzare la situazione corrente O un grafico della storia dell’utente
- Ho anche potenziato il SAT, creando una nuova struttura omogenea attraverso una gerarchia di classi. In questo modo è possibile utilizzare funzioni ricorsive per implementare gli operatori dell’albero. Ho anche introdotto un identificatore unico creato a runtime nel momento in cui viene il nuovo nodo viene inserito all’interno dell’albero. Infine ho aggiunto due campi facoltativi all’interno dei nodi foglia per aggiungere informazioni di contesto necessarie al monitoraggio del comportamento. Come ad esempio la posizione della palestra preferita dell’utente è necessaria a Cicero perché deve essere confrontata con la posizione attuale per capire se l’utente si trova in palestra.
- Ho poi condotto diversi test sulle performance del middleware utilizzando la configurazione riportata in figura. In particolare, su un PC desktop ho un emulatore di Android Wear con installata l’applicazione per smartwatch. Ho poi un server di sviluppo Google App Engine con tutta la parte cloud. Su uno smartphone collegato attraverso usb ho invece installato l’applicazione utente per smartphone e quella per l’esperto del dominio.
- I risultati sono stati più che soddisfacenti. Infatti, per quanto riguarda làapplicazione per smartphone sia i livelli di utilizzo di CPU, che di memoria, batteria e il traffico di rete sono risultati estremamente bassi. In particolare, la CPU a runtime raggiunge picchi sotto l’1%.
- La memoria utilizzata è compresa tra 6 e 7 MB
- E il traffico di rete, dopo un primo picco per il download dei comportamenti, presenta picchi isolati trascurabili.
- Analogamente per lo smartwatch, la CPU presenta solo alcuni picchi,
- Mentre la memoria è compresa tra 1 e 2 MB
- Concludendo, la nuova versione di Cicero è quindi in grado di effettuare il sensing contemporaneo di più comportamenti contemporaneamente e su più dispositivi,