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
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
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
Notas del editor
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,
