Corso di Laurea Magistrale in Informatica
Umanistica
R
ELAZIONE
Un ambiente per la creazione di regole di
personalizzazione basato su blocchi visuali e
sistema di raccomandazione
Candidato:
Andrea Mattioli
Relatore:
Dott. Fabio Paternò
Abstract
Negli ultimi anni il numero di dispositivi che fanno parte della rete Internet of Things ha registrato una crescita costante. Uno dei modi per sfruttare questo incremento di dispositivi connessi a vantaggio degli utilizzatori è quello di permettere la personalizzazione dell’ambiente abitativo tramite una piattaforma per la creazione di regole trigger-action. L’aumento del numero e delle funzionalità dei dispositivi fa sì che si amplino anche il numero e la tipologia di utilizzatori. Essi possono essere persone esperte e appassionate di queste tecnologie, che vogliono usare una piattaforma di personalizzazione per rendere la propria abitazione più confortevole e su misura per loro. Possono però essere principianti o persone che usano questi sistemi per migliorare la qualità della vita di un familiare, oppure che li utilizzano come strumento di supporto al proprio lavoro, come nel campo dell’assistenza agli anziani. Questo lavoro propone un’interfaccia per la creazione di regole trigger-action nel contesto della domotica. L’interfaccia ha come obiettivo rendere le persone non esperte in grado di comporre regole in modo autonomo ed efficace. Per permettere questo è stato utilizzato il paradigma della programmazione visuale basata su blocchi. Per fornire ulteriore supporto all’utente è stato sviluppato un sistema di raccomandazione specifico per questo contesto.
Indice
Abstract 1
1 Contesto 4
1.1 Motivazioni 4
1.2 End User Development 5
1.3 Linguaggi di programmazione visuale 7
1.4 Linguaggi basati su blocchi 9
1.5 Programmazione trigger-action 10
1.6 Recommender systems 13
2 Stato dell’arte 19
2.1 Introduzione 19
2.2 Supporto nella creazione della regola e suggerimenti 19
2.3 Uso di blocchi e puzzle 22
2.4 Debug delle regole 24
2.5 Rappresentazione del contesto 29
2.6 Individuazione degli obiettivi di ricerca 31
3 Progettazione 33
3.1 Bug nei sistemi trigger-action 33
3.2 Scelte di programmazione 35
3.2.1 Scelta del contesto e del linguaggio visivo 35
3.2.2 Altre possibilità 38
3.2.3 Definizione dei concetti e design 39
3.2.4 Requisiti 44
3.4 Librerie e tecnologie 45
3.4.1 Blockly 45
3.4.2 Front-end e back-end 49
4 Implementazione 52
4.1 Editore di regole basato su blocchi 52
4.2 Architettura di riferimento 54
4.3 Realizzazione dei blocchi 55
4.4 Controlli e suggerimenti 60 4.4.1 Controlli 60 4.4.2 Suggeritore di trigger 61 4.4.3 Suggeritore di azioni 64 4.4.4 Suggeritore di regole 68 4.5 Esempio di uso 70 5 Test utente 73
5.1 Impostazione del test 74
5.2 Report dello svolgimento dei task 75
5.3 Report del questionario 76
5.4 Valutazioni qualitative 80
6 Conclusioni e sviluppi futuri 84
Bibliografia 85
Appendice A: task utente 89
Appendice B: valutazione 89
Appendice C: tempi ed errori nei task 94
1 Contesto
1.1 Motivazioni
Questo progetto nasce successivamente all’esperienza di tirocinio svolto presso il laboratorio Human Interaction in Information Systems (HIIS) presso il CNR di Pisa. Durante il tirocinio è stato portato un contributo al refactoring del codice e alla modifica dell’interfaccia della piattaforma trigger-action esistente, utilizzata per il progetto europeo PETAL (PErsonalizable assisTive Ambient monitoring and Lighting) . Scopo del progetto è fornire1 una piattaforma in grado di aumentare l’autonomia delle persone anziane, e di fornire loro assistenza durante lo svolgimento delle attività quotidiane.
Gli utenti possono comporre e modificare regole di personalizzazione interagendo con una pagina principale. Essa mostra la gerarchia del contesto (insieme di dispositivi collegati in quella installazione) tramite una struttura ad albero navigabile, da cui è possibile scegliere i trigger (sensori, i cui cambiamenti vengono monitorati per far attivare le regole) e le azioni (tramite attuatori che provocano cambiamenti nell’ambiente) da utilizzare nella regola. Dopo la scelta viene mostrata una finestra modale per la definizione delle caratteristiche di quell’elemento. Sono presenti degli elementi di supporto all’utente: una “rule map” che mostra lo stato della regola in costruzione e la traduzione in linguaggio naturale della regola. Lo scopo dell’interfaccia è quello di fornire uno strumento per la personalizzazione dell’ambiente a coloro che si occupano degli anziani.
Durante il periodo di tirocinio è emersa la volontà di trovare una rappresentazione visuale delle regole alternativa a quella usata nel progetto, adeguata a questo tipo di interfaccia. Questa diversa rappresentazione deve risultare di più semplice utilizzo per gli utenti (nel senso di chi dovrà creare le regole) e in grado di limitare le possibili ambiguità. Allo stesso tempo essa deve permettere loro una maggiore libertà espressiva nella composizione delle regole. Ciò si traduce nella progettazione e sviluppo di una nuova interfaccia, che si adatti ad essere usata da persone con poca o senza esperienza di programmazione, non necessariamente nell’ambito dell’assistenza agli anziani.
1 "PETAL – PErsonalizable assisTive Ambient monitoring and ...." http://www.aal-petal.eu/.
Un fattore guida per questo progetto è stato il cercare un modo di ridurre gli errori nella creazione delle regole. Dagli studi emerge come non ci sia una congruenza nel modo in cui gli utenti interpretino le regole create [12] e come questo sia collegato alla presenza di errori nelle regole [3]. Gli errori possono essere di diverso tipo: alcuni possono essere individuati durante la creazione della regola (e quindi limitati tramite feedback all’utente in questa fase), altri durante l’esecuzione (nel caso ad esempio di azioni contraddittorie), mentre per altri non c’è una soluzione automatica [3]. Per limitare gli errori nelle regole trigger-action sono già state applicate diverse strategie come uso di feedback [4], implementazione di debugger e simulatori [14, 6], introduzione del concetto di priorità [14, 20].
Una strategia non molto sfruttata è invece quella di applicare tecniche usate generalmente nei recommender systems a questo diverso campo di utilizzo, sia per quanto riguarda il suggerire regole rilevanti per l’utente [17], sia il fornire supporto durante la creazione di una regola. Per poter fornire supporto nella creazione è necessario ripensare l’approccio, in quanto il ragionamento alla base cambia da “se l’utente ha già comprato questo, quale altro oggetto demo mostrare per massimizzare la probabilità di acquisto?” a “l’utente sta usando questo tipo di trigger: cosa posso suggerire per completare la regola senza introdurre errori?”. Successivamente all’interfaccia è stato quindi progettato e sviluppato un sistema per fornire suggerimenti durante la creazione della regola.
1.2 End User Development
Gli editor di regole trigger-action sono uno delle rappresentazioni del paradigma End-User Development (EUD), un modo di guardare alla progettazione e allo sviluppo software per fare si che non sia solo facile da usare, ma facile da sviluppare [18]. Ciò significa che questo 2 paradigma “...should be understood as a set of methods, techniques, and tools that allow users who are acting as non-professional software developers of a specic application environment at some point to create, modify or extend an IT artefact [18]”. Questa metodologia è particolarmente attuale poiché ci troviamo in una situazione nella quale l’informatica in tutte le sue forme sta entrando nella vita quotidiana di una quantità sempre maggiore della popolazione mondiale ma, allo stesso tempo, è costituita in prevalenza da software sviluppati seguendo la divisione in creazione a design time e uso a run time [18].
2 "End-User Development: An Emerging Paradigm | SpringerLink."
Questa divisione, perfettamente logica e sensata relativamente al contesto in cui i software erano usati prevalentemente da esperti in domini specifici, diventa troppo netta se rapportata alla pervasività dell’informatica (e in particolare dei dispositivi Internet of Things(IoT)) nella vita quotidiana nel contesto attuale, nonostante l’evoluzione delle metodologie di sviluppo software siano sempre più orientate verso cicli brevi di rilascio . 3
Infatti questa pervasività porta alla nascita di diverse esigenze, specifiche anche da persona a persona (ma variabili anche ad esempio a seconda del dispositivo, del momento sociale, del contesto, o dopo che la stessa persona è diventata più esperta nell’uso di un tool). Questa natura differenziata fa si che sia difficile riuscire ad individuare correttamente tutti i requisiti di un’applicazione a tempo di design [18]. L’End User Development è un paradigma che ha lo scopo di mitigare questo problema, permettendo a utenti (o a esperti di dominio) di ri-disegnare le applicazioni durante l’uso, tramite la modifica di una parte dell’applicazione o la creazione di estensioni. Per poter realizzare un approccio di questo tipo (meta-design) gli strumenti devono essere progettati in modo da supportare le modifiche apportate durante l’uso.
Questa possibilità deve confrontarsi con lo sforzo cognitivo che necessariamente viene aggiunto a carico dell’utente come conseguenza dell’aumento delle possibilità che ha a disposizione. Uno dei temi portanti dell’EUD è il rapporto tra espressività e complessità del linguaggio. In genere i linguaggi testuali sono più complessi, in quanto aggiungono la necessità di imparare da capo un nuovo lessico e una nuova sintassi . Lo sforzo aggiuntivo 4 per l’utente sarà comunque presente, qualunque tipo di linguaggio venga usato: gli strumenti di EUD devono fornire motivazioni valide affinché l’utente voglia imparare ad usarli.
Negli anni precedenti i ricercatori hanno testato e valutato diversi metodi e tecniche per l’EUD: programmazione per esempi, programmazione visuale, uso di linguaggio naturale. Non c'è un modello concettuale in grado di far combaciare perfettamente la semantica dell'utilizzatore e quella dei linguaggi: ci sarà sempre uno scambio tra espressività del linguaggio e vicinanza della mappatura mentale [6].
3 "How to drive shorter development release cycles | InfoWorld." 10 gen. 2019,
https://www.infoworld.com/article/3331919/how-to-drive-shorter-development-release-cycles. html. Ultimo accesso: 1 nov. 2019.
4 "Meta-Design: A Manifesto for End-User Development."
http://l3d.cs.colorado.edu/~gerhard/papers/CACM-meta-design.pdf. Ultimo accesso: 1 nov. 2019.
L’applicazione più popolare di EUD è il foglio di calcolo . La metodologia EUD si può 5 realizzare con diverse tecniche, ognuna con i propri campi di applicazione principali. Una è il programming-by-example (fare apprendere un comportamento al computer tramite dimostrazione con esempi concreti), utilizzato nella programmazione dei robot, ma anche quando in una normale applicazione desktop c’è bisogno di ripetere una lunga sequenza di azioni (registrazione di macro).
Sempre nel campo della programmazione di robot, è possibile usare altre metodologie di EUD. E’ molto diffusa la programmazione visuale basata su blocchi, ma sono anche usate tecniche basate sul linguaggio naturale. Quest’ultima metodologia è stata testata ad esempio nella programmazione di robot sociali dedicati a particolari terapie. In questi casi i comportamenti dei robot dovranno essere specificati sul momento, a seconda dei casi, da personale sanitario . 6
Il linguaggio naturale è usato anche nei sistemi trigger-action come metodo per dare supporto e feedback nella creazione della regola, o nei linguaggi a blocchi per affiancare le icone, in quanto anche se queste ultime possono essere più intuitive e facili da leggere, difficilmente possono veicolare concetti complessi [16].
1.3 Linguaggi di programmazione visuale
I linguaggi di programmazione visuale sono linguaggi che permettono la creazione di programmi tramite la manipolazione di elementi grafici, invece che tramite la costruzione di testi. Questi linguaggi presentano una serie di elementi grafici come blocchi o icone che ne rappresentano il vocabolario. Essi sono componibili secondo la la “grammatica spaziale” delle possibili interazioni degli elementi tra loro per esprimere i concetti desiderati.
I linguaggi visuali sono particolarmente orientati verso chi si avvicina alla programmazione, e vengono loro incontro sotto tre aspetti: come le primitive del linguaggio possono mettersi insieme per costruire programmi ben formati (livello sintattico, supportato tramite uso di
5 "The role of spreadsheet knowledge in user-developed ...."
https://www.sciencedirect.com/science/article/pii/S016792360400003X. Ultimo accesso: 1 nov. 2019.
6 "Design and evaluation of an end-user friendly tool for robot ...."
primitive che riassumono concetti più ampi rispetto al singolo carattere), fornire spiegazioni riguardo le primitive che si stanno usando (livello semantico), poter impostare uno stato specifico del programma per poterne visualizzare l’esito (livello pragmatico) . 7
L’aspetto pragmatico emerge, ad esempio, nella possibilità di effettuare debug visuale del programma che si sta scrivendo, oppure nella programmazione di robot, sia in ambito educativo che lavorativo. Da studi8 9 emerge l’importanza di avere una rappresentazione dello stato del programma (a che punto si trovi nel flusso di esecuzione) e la possibilità di simulare elementi del sistema. La simulazione serve per provare quali sono gli effetti sul robot del cambio di valore di un sensore, o per vedere l’esito di una lista di comandi di movimento.
Questo aspetto non è solamente legato alla didattica e alla robotica. Nei contesti della domotica e dell’IoT è importante per gli utenti capire perché un programma si stia comportando in un certo modo in modo più immediato rispetto ad usare log, breakpoint e debugger, e una rappresentazione visuale può essere usata per questo scopo.
I linguaggi di programmazione visuale, relativamente all’uso nell’End-User Development, rientrano generalmente in tre categorie: riempimento di form (oppure wizard), a blocchi, a flusso [4].
I primi si realizzano tramite la compilazione di form o menù come le finestre modali (elementi grafici subordinati rispetto alla finestra principale che le si sovrappongono e rimangono in primo piano fino al termine della sequenza di operazioni che l’utente deve compiere). Questa categoria supporta l’utente usando delle procedure guidate passo passo che limitano le scelte disponibili nel momento [4] (come nel celebre “Installation wizard” dei sistemi Microsoft).
L’approccio a blocchi è molto usato per introdurre bambini e ragazzi alla programmazione, spesso tramite progetti di robotica. Si realizza trascinando in un’area di lavoro delle strutture di diversa forma, grandezza e colore. Questo approccio, in particolare affiancato alla
7 "Visual programming language - Wikipedia."
https://en.wikipedia.org/wiki/Visual_programming_language. Ultimo accesso: 3 nov. 2019.
8 "Design and evaluation of an end-user friendly tool for robot ...."
https://ieeexplore.ieee.org/document/7745109. Ultimo accesso: 1 nov. 2019.
9 "Evaluating CoBlox: A Comparative Study of Robotics ...." 20 apr. 2018,
metafora del puzzle, è percepito come creativo e meno restrittivo rispetto a quello a riempimento di forme, e in grado di diminuire la curva di apprendimento e motivare gli utenti ad esplorare il tool [4].
L’approccio a flusso eccelle invece nel mostrare la struttura dei processi, anche molto elaborati. E’ un tipo di rappresentazione più vicina al mondo dell’informatica e dell’ingegneria. Anche se riesce a portare espressività nella rappresentazione di situazioni complesse [4], ha spesso bisogno per raggiungere questo scopo di aumentare la complessità dell’interfaccia e delle relazioni che essa mostra, rischiando di diventare confusa.
1.4 Linguaggi basati su blocchi
La programmazione basata su blocchi non è una novità recente: ad esempio, l’ambiente LogoBlocks è usato dalla metà degli anni 90. Nell’ultimo decennio si è assistito però ad un fioritura di progetti intorno a questa modalità, da giochi a percorsi scolastici, sulla scia del successo di ambienti (Scratch ) e iniziative (Hour of Code ). Questo tipo di10 11 programmazione è oggi entrata a far parte della didattica dell’informatica [2].
La programmazione basata su blocchi si appoggia alla metafora del puzzle a livello di costrutto base (primitiva), che serve a dare un’idea visuale di come dovrà essere usato quel pezzo e a limitare gli errori di sintassi, affiancata alla metodologia drag-and-drop. I costrutti tra cui scegliere sono presenti in una toolbox, nella quale le tipologia di blocco sono organizzate per concetto e con altri supporti visuali come l’uso del colore.
La possibilità di vedere prima ciò che è possibile fare aiuta gli utenti inesperti, che così non devono imparare prima un grande numero di costrutti sintattici. Scratch è il linguaggio di questo tipo che ha avuto più successo [23]. Esso mira a permettere a persone con poca o nessuna esperienza di creare programmi sofisticati (low threshold-high ceiling), cercando allo stesso tempo di sviluppare una comunità di programmatori di tutti i livelli intorno alla piattaforma tramite la possibilità di condivisione dei progetti.
Anche se mirato principalmente a bambini e ragazzi, questo tipo di programmazione è stata usato efficacemente per introdurre principianti adulti alla programmazione di robot
10 "Scratch - Imagine, Program, Share." https://scratch.mit.edu/. Ultimo accesso: 4 nov. 2019. 11 "Hour of Code." https://hourofcode.com/it. Ultimo accesso: 4 nov. 2019.
industriali, risultando più adatto per questo delle interfacce di programmazione robot esistenti [24]. Questo fa pensare ad ulteriori possibili campi di applicazione per questo tipo di interazione. Le questioni aperte riguardano quanto di ciò che viene appreso tramite questi linguaggi siano applicabili successivamente in un linguaggio di programmazione testuale, e come questi linguaggi siano percepiti da chi li usa, in quanto possono non risultare “vera programmazione” [23] nonostante le possibilità espressive.
La programmazione tramite blocchi rende possibile realizzare applicazioni di vario tipo. Nella guida di Blockly sono descritti vari paradigmi da usare per le applicazioni: l’uso di un 12 unico blocco fissato nell’area di lavoro, con la possibilità di inserire all’interno di esso blocchi figlio o modificare i suoi campi, è usabile per definire file di configurazioni. Un “normale” flusso di blocchi si traduce in programmi sequenziali, e le istruzioni saranno poi eseguite in ordine. Una serie di più blocchi iniziali è usabile per definire un programma che dovrà essere eseguito in parallelo (un approccio simile è stato usato nella modalità a blocchi di Reason ). Ogni blocco iniziale sarà associato a un interprete JavaScript, oppure13 assemblato in un programma Python che fa uso di threading. Sempre diversi blocchi contenitore possono essere utilizzati per creare applicazioni guidate da eventi, insieme ad un blocco che serve da gestore.
1.5 Programmazione trigger-action
La programmazione trigger-action (TAP) è un approccio popolare per la definizione di comportamenti personalizzati nell’ambito smart home. Le regole Trigger-Action (chiamate anche, nello stesso campo di applicazione, regole Event-Condition-Action) sono una rappresentazione concettualmente simile ad una istruzione condizionale. Permettono di specificare che tipo di cambiamento all’interno dell’ambiente vogliamo fare avvenire (specificato nella parte “action” della regola) al verificarsi di quello che abbiamo definito nella parte “if” della regola (ovvero uno o più avvenimenti, denominati “trigger”).
Le regole Trigger-Action vengono descritte tramite appositi editor e utilizzate in contesti dove siano presenti sensori ed attuatori IoT (può essere una casa, un ufficio, un negozio, un
12"Custom Blocks: Block Paradigms | Blockly | Google Developers."
https://developers.google.com/blockly/guides/create-custom-blocks/block-paradigms. Ultimo accesso: 1 nov. 2019.
13 "Learn Blocks in Reason | LearnReason."
museo, una struttura di ricovero), servizi Web (utilizzando come trigger i cambiamenti che avvengono in altri servizi come Gmail o Twitter) o una combinazione di essi, permettendo all’utilizzatore finale di ottenere un comportamento personalizzato dal proprio ambiente.
La programmazione di un ambiente di smart home non significa creare una serie di regole svincolate dalle altre, ma organizzare queste regole in un ambiente coerente, introducendo dei concetti come la priorità tra regole, per venire incontro alle necessità di chi vi abita. Per progettare un ambiente smart si usano delle piattaforme dedicate di home automation che agiscono da bridge per i vari dispositivi e servizi (come openHAB o SmartThings), o tramite servizi online come If This Then That (IFTTT) o Zapier.
IFTTT è un servizio Web gratuito che utilizza un meccanismo di richieste temporizzate alle API cui l’utente si sottoscrive per la parte “if this” delle regole che sta costruendo (applets) per ascoltare eventuali cambiamenti di stato, e nel caso un trigger si attivi si connette alla API del servizio per attivare l’azione corrispondente. Zapier è considerabile come un traduttore tra api e fornisce flussi di lavoro per poter automatizzare l’uso di congiunto di14 applicazioni web.
IFTTT permette di creare regole semplici utili per connettere servizi che espongono API e come Zapier permette di personalizzare il comportamento congiunto di applicazioni Web e dispositivi. La personalizzazione avviene tramite procedure guidate (wizard). L’immediatezza di questi sistemi ha il lato negativo di non esporre gli utenti a tutte le informazioni che possono essere necessarie a specificare in modo corretto il tipo di comportamento che essi vogliono descrivere.
In questo tipo di applicazioni si può avere un’ampia selezione di trigger e di azioni, che possono differire dal punto di vista temporale. In [12] è stata sistematizzata la struttura temporale di trigger e azioni, suddividendo i trigger in eventi, segnali istantanei inviati in uno specifico punto nel tempo, e stati, condizioni booleane valide in lungo periodo di tempo, definibili anche condizioni. La distinzione per le azioni è di tipo immediato (come ad esempio inviare un messaggio), prolungato (come una frase pronunciata da un robot sociale, o un’azione compiuta da una smart coffee maker) o sostenuto (cambiamento di uno stato, come accensione di una luce o apertura di una finestra).
In IFTTT sono possibili tutti i tipi di azione, ma non è stata fatta una distinzione tra
esse. Ciò può essere problematico in particolare per le azioni sostenute, in quanto riportarle al loro stato originario richiede una regola separata mentre, quando queste azioni sono accoppiate a trigger di tipo state, gli utenti possono aspettarsi che ciò avvenga automaticamente [12]. Ciò avviene in regole del tipo “se sto dormendo spegni lo stereo”: alcune persone possono aspettarsi che lo stereo si accenda di nuovo, automaticamente, al risveglio, mentre altre no.
In [3] è stato esaminato come gli utenti si rapportino con la possibilità di creare regole che vadano oltre lo specificare una regola composta da un trigger e una azione. Infatti, anche se da studi precedenti risulta come anche usando solo regole semplici sia possibile coprire una buona percentuale di possibili comportamenti desiderati [12], esistono diversi programmi che permettono una maggiore libertà espressiva. E’ quindi necessaria una sistematizzazione riguardo come gli utenti interpretino queste regole più complesse e che possibili problemi possono emergere nella costruzione delle regole. I ricercatori hanno delineato tre paradigmi temporali (ovvero che relazioni siano permesse tra i diversi tipi di trigger) che delineano come vengono generalmente espresse le regole nei sistemi trigger-action [3]:
● Evento-evento: una combinazione di due eventi tramite operatore “and” viene intuitivamente vista come valida per fare attivare una regola. È impossibile che due eventi avvengano nello stesso identico istante: il paradigma evento-evento quindi dovrà usare una finestra temporale (“se l’utente entra nella camera da letto e il sole tramonterà entro 2 ore”). Quindi quando avviene un evento il sistema deve o guardare indietro agli altri eventi avvenuti in una finestra temporale, oppure guardare se l’altro evento avverrà entro il tempo stabilito (se è qualcosa di definibile, come appunto l’ora del tramontare del sole), o ancora introdurre un concetto di sequenzialità di eventi.
● Evento-stato: richiede che ogni trigger contenga un evento in congiunzione con un qualunque numero di stati. Quando avviene un evento, viene controllato se gli stati sono attivi. Il problema di questo paradigma è che molti utenti non colgono la differenza tra eventi e stati. Nonostante questo problema, questo paradigma è usato sia in applicazioni commerciali (Stringify, SmartRules) che accademiche [2, 15].
● Stato-stato: visto che stati multipli possono essere veri allo stesso tempo, regole che riguardano le stesse azioni (come controllare le luci) devono includere
un sistema di priorità per risolvere i conflitti. Le regole stato-stato potrebbero introdurre ulteriori complicazioni: in una ipotetica regola “se sono affamato, allora ordina una pizza”: finchè rimani nello stato “affamato” continuerà ad attivarsi il trigger, e quindi continuerai a ordinare pizze.
Gli stessi ricercatori hanno evidenziato come ogni paradigma debba avere a che fare con i propri bug specifici: una regola nel paradigma evento-stato si comporterà diversamente a seconda se i due trigger nella regola siano usati rispettivamente come evento e condizione, o viceversa. Questo evidenzia una difficoltà nelle persone di distinguere tra eventi e condizioni, anche nei paradigmi dove è presente solo un tipo di essi: spesso le persone pensano solo in un modo o nell'altro [3]. Per questo è importante definire una semantica non ambigua per i trigger.
Questa necessità riguarda anche le azioni, in quanto anche esse possono avere diversa durata, e ciò può portare ambiguità. Dobbiamo quindi pensare a come verranno interpretate queste regole, ad esempio se un’azione immediata o continuativa (come ordinare una pizza) verrà ripetuta o no finché la condizione è valida, o se un’azione sostenuta (come accendere una luce) riporterà o meno il dispositivo allo stato iniziale quando la condizione non sarà più valida.
1.6 Recommender systems
Lo studio dei recommender systems (RS) emerge come area di ricerca autonoma verso la metà degli anni 90 [19]. Essi hanno come obiettivo trovare quanto sia probabile che un utente apprezzi un determinato oggetto. Da un lato questo serve per mostrare un oggetto che sia interessante per l’utente, dall’altro per ridurre il problema del sovraccarico di informazioni [19] (un esempio comune, scegliere quale film vedere stasera da un elenco molto ampio).
Bisogna trovare un bilanciamento tra accuratezza della raccomandazione e fattore di scoperta: non è molto utile proporre un oggetto già comprato o un film che corrisponde perfettamente ai gusti dello spettatore, dato che con ogni probabilità corrisponderà ad un film già visto. Possono basarsi su diversi meccanismi, a seconda del tipo di somiglianza che
sfruttano per generare i suggerimenti. Tradizionalmente i recommender systems riguardano due dimensioni, utenti (con le valutazioni effettuate) e oggetti da suggerire, ma in dei casi può essere utile prendere in considerazione più dimensioni . 15
Una tipologia di recommender systems è basata sull’idea che se due utenti hanno condiviso gusti simili in passato, allora ciò avverrà anche in futuro: ad esempio, se due persone hanno una forte sovrapposizione nello storico recente degli acquisti, e una delle due acquista un oggetto che l’altra non ha mai visto, il sistema mostrerà questo oggetto all’altra persona [19].
Questa metodologia, molto usata data la sua efficacia [1], si chiama collaborative filtering. Nella forma base non prende in considerazione le caratteristiche dell’oggetto, ma può anche essere basato sulla similarità tra oggetti invece che tra utenti [13]. Due modi comuni per realizzarlo sono user-based e item-based. Il metodo user-based cerca gli altri utenti con lo stesso pattern di valutazioni, e usa i migliori vicini per calcolare quale sarà la valutazione dell’utente su un oggetto non visto. Il metodo item-based calcola prima la similarità tra gli oggetti (tramite similarità del coseno tra le valutazioni o funzioni di correlazione). Successivamente mostra nuovi oggetti all’utente scegliendo tra quelli valutati bene da persone con gusti simili. Questo metodo è stato inventato e usato da Amazon nel 1998 . 16
Gli algoritmi di collaborative filtering possono essere distinti in model-based e memory-based. I primi allenano un modello da un database di valutazioni. e usano questo modello per effettuare la predizione della valutazione che darà un utente a un oggetto che non ha visto. I secondi costruiscono una matrice di valutazioni utenti-oggetti e usano funzioni di similarità per generare le raccomandazioni per l’utente tramite l’identificazione di un numero K di migliori vicini [1].
Un modello è quello basato su fattorizzazione di matrice. Una realizzazione popolare di questo modello è quella di Simon Funk per la competizione di Netflix . Si applica partendo 17 da una matrice di valutazione utenti - oggetti, tipicamente molto sparsa: lo scopo è predire i valori mancanti. L’idea è che i voti dati dagli utenti ai film siano basati su una serie di parametri non immediatamente visibili. Il voto è considerato prodotto del vettore dei 15 "Context-Aware Recommender Systems for Learning: A Survey ...." 24 apr. 2012,
https://ieeexplore.ieee.org/document/6189308. Ultimo accesso: 1 nov. 2019.
16 "Item-item collaborative filtering - Wikipedia."
https://en.wikipedia.org/wiki/Item-item_collaborative_filtering. Ultimo accesso: 1 nov. 2019.
17 "Singular Value Decomposition vs. Matrix Factoring in Recommender ...." 21 giu. 2019,
https://www.freecodecamp.org/forum/t/singular-value-decomposition-vs-matrix-factoring-in-re commender-systems/287959. Ultimo accesso: 1 nov. 2019.
parametri di quel film per il peso che da l’utente ad ogni parametro. Tramite gradient descent è possibile, partendo dalle valutazioni conosciute, trovare il numero di parametri che ottimizzi il peso dato ad essi dagli utenti. In questo modo otteniamo una nuova matrice contenente le ricostruzioni approssimate dei voti degli utenti per i film visti. Da questa matrice è possibile ottenere le valutazioni mancanti tramite prodotto di feature vector del film per i pesi dell’utente.
Ci sono una serie di domande specifiche riguardo il collaborative filtering, ad esempio come fare a misurare la similarità tra utenti (alcune metriche comuni sono la similarità del coseno, l’indice di correlazione di Pearson o l’indice di Jaccard, mentre il quali caratteristiche usare per misurare la similarità è relativo al caso in questione) e come il sistema debba comportarsi con oggetti non ancora acquistati o con solo pochi voti (cold start problem) [13].
La necessità di risolvere problemi relativi alla selezione di oggetti può avvenire in campi diversi, come nell’information retrieval, dove l’attenzione è posta sul discriminare quale documento sia più rilevante rispetto ad un altro. In questo devono essere prese in esame le caratteristiche dei documenti: una metodologia appropriata è effettuare raccomandazioni basate sul contenuto (Content Based) [13]. Servono metodi per costruire e sfruttare la descrizione degli oggetti, per assegnare un peso alle diverse caratteristiche. Può anche essere usato un approccio simile per strutturare una descrizione degli utenti.
Le domande tipiche relative a questi sistemi riguardano come determinare quale oggetto possa combaciare con gli interessi dell’utente, e come diminuire l’annotazione manuale delle descrizioni degli oggetti. Un punto a favore di questo sistema è il non richiedere molti utenti per poter effettuare predizioni significative, e che i nuovi oggetti possono essere suggeriti immediatamente. Un punto negativo è che le predizioni possono essere poco varie e non avere nessun carattere di “scoperta” [13].
Un metodo molto usato per stabilire l’importanza di un termine rispetto ad un documento è la funzione tf-idf (term frequency - inverse document frequency ). Term frequency è la misura di quanto sia importante il termine di ricerca nel documento, identificata tramite conteggio. Inverse document frequency è un metodo per penalizzare le parole troppo frequenti, impedendo che ad esempio i risultati di una ricerca siano sbilanciati verso documenti che presentano molte volte termini comuni nel linguaggio.
Un altro utilizzo di tf-idf è quello del Content Association, applicabile ad esempio ad una situazione nella quale abbiamo diversi giochi, e vogliamo suggerire ad ogni giocatore un nuovo gioco al termine della partita attuale. E’ possibile costruire uno storico per ogni gioco, partendo dalla lista di partite effettuate dai giocatori. In questo modo è possibile costruire per ogni gioco una tabella di compresenze di un gioco con ognuno degli altri nello storico dei giocatori. Usando tf-idf, è possibile da questa stabilire quale potrà essere un buon gioco candidato ad essere suggerito come prossimo, limitando il peso dei quelli estremamente popolari . 18
Quelli presentati sono i due metodi più comuni per effettuare raccomandazioni. Un diverso dominio di applicazione può richiedere un approccio diverso. Nell’elettronica di consumo la maggior parte dei (molti) compratori effettua solo acquisti saltuari, quindi lo storico è poco affidabile per la generazione di suggerimenti [13]. In questi casi è possibile sfruttare, se presenti, informazioni strutturate riguardo l’oggetto. I Constraint-based RS si basano sia su queste informazioni che sulla possibilità di utilizzare vincoli che definiscono quello che sarà il contesto di uso dell’utente. I vincoli possono essere ottenuti chiedendo all’utente quali sono le caratteristiche che ritiene più importanti per quello specifico oggetto, e gli oggetti filtrati di conseguenza [13].
L’aspetto dell’interazione con l’utente è fondamentale per questo tipo di RS, molto più che ad esempio nel collaborative filtering, dove ad essere preso in considerazione era solo il voto dato all’oggetto, o una dicotomia acquisto/non acquisto. Le domande tipiche di questo approccio sono che informazioni utilizzare per costruire la knowledge base, come prendiamo in considerazione le eventuali informazioni storiche, come le integriamo con quelle relative alle preferenze esplicite [13].
Un altro dominio è quello della didattica. In questo caso la necessità di raccomandazioni è data dalla grande variabilità delle possibili condizioni che rendono un suggerimento adatto alla persona. I bisogni di ogni apprendente sono specifici riguardo la sua preparazione, il momento della giornata, il luogo, il tempo a disposizione, il livello di attenzione. E’ difficile esprimere questi concetti tramite keywords. Un sistema di raccomandazioni per questo dominio dovrà descrivere il contesto come un aggregato delle varie categorie che descrivono
18 "Developing personalised recommender systems at the BBC." 1 ago. 2019,
https://medium.com/bbc-design-engineering/developing-personalised-recommender-systems -at-the-bbc-e26c5e0c4216. Ultimo accesso: 1 nov. 2019.
il setting nel quale la raccomandazione sarà consegnata . Se l’apprendente si trova in un bar, 19 il rumore e le possibili interruzioni sono elementi da considerare: una raccomandazione contestuale sarà il suggerire un questionario sulle conoscenze, semplice e continuabile in un secondo momento. Altre raccomandazioni contestuali sono il suggerire persone (descritte ad esempio usando il dizionario Friend of a Friend ) vicine che stanno lavorando su argomenti 20 simili, o suggerire materiale adatto al luogo (es. tragitto in treno).
A seconda del dominio e delle informazioni disponibili è possibile combinare più approcci per ottenere risultati migliori. Se ci sono informazioni riguardo le valutazioni degli acquisti degli utenti, insieme a informazioni dettagliate riguardo gli oggetti, è possibile costruire un sistema ibrido basato su un filtro collaborativo e su tecniche content-based, oppure integrare questi sistemi con algoritmi di community discovery.
Un altro aspetto da prendere in considerazione è quello della scoperta: mostrare solo gli oggetti migliori e più popolari, anche se probabilmente buoni suggerimenti, non serve a molto: l’oggetto sarebbe acquistato lo stesso, inoltre mostrarlo non aiuta a far sentire all’utente che il sistema abbia davvero capito i suoi gusti, e fa infine perdere tutta quella “long tail” di buone raccomandazioni che possono davvero interessare l’utente. Per questo un aspetto da tenere in considerazione riguarda l’ordine di presentazione dei risultati, per mantenere acceso l’interesse e il senso di esplorazione e non “perdere il focus” dopo i primi risultati.
I sistemi di raccomandazione hanno anche un possibile ruolo nei sistemi trigger-action. Generalmente in questo tipo di programmi l’attenzione è posta maggiormente sul design dell’ambiente di creazione delle regole, e meno su come suggerire regole coerenti con il comportamento dell’utente e il contesto [17]. I possibili utilizzi di queste tecniche per i suggerimenti in questo contesto sono stati esaminati in uno studio recente 21
I sistemi trigger-action generano un massiccio flusso di dati da sensori, riguardanti i comportamenti degli utenti e le condizioni ambientali. C’è la possibilità di poter usare tecniche di machine learning su questi dati per scoprire e suggerire personalizzazioni
19 "Context-Aware Recommender Systems for Learning: A Survey ...." 24 apr. 2012,
https://ieeexplore.ieee.org/document/6189308. Ultimo accesso: 1 nov. 2019.
20 "The FOAF Project." http://www.foaf-project.org/. Ultimo accesso: 1 nov. 2019. 21 "Towards Intelligent Personalization of IoT Platforms - CEUR ...."
appropriate [17]. Un’altra possibilità riguarda l’utilizzo dei dati riguardanti le regole, come i trigger e le azioni usati o il numero e gli orari delle attivazioni delle regole.
Per quanto riguarda il primo caso, uno scopo è quello di identificare in quale situazione contestuale avvenga in prevalenza l’attivazione di una regola. E’ un approccio utile quando il numero di trigger e azioni è limitato, poiché per per poter inferire le preferenze dell’utente riguardo una possibile personalizzazione è necessario conoscere un grande numero di fattori: relativamente a una luce è necessario avere informazioni su orario, posizione dell’utente, meteo [17]. Inoltre c’è il problema comune a questo tipo di approcci riguardo la difficoltà di inferire dai dati quelle che possono essere le abitudini e i desideri dell’utente.
Per quanto riguarda l’uso dei dati delle regole, sono possibili approcci basati sul Collaborative Filtering o su Content based. Un’implementazione dell’approccio collaborativo potrebbe stabilire una similarità tra gli utenti basandosi sull’attivazione delle regole e le loro caratteristiche, e suggerire altre regole di conseguenza. L’approccio basato sul content potrebbe generare suggerimenti tramite generalizzazione di parti di regole esistenti (“se l’utente entra in bagno allora accendi la luce” è generalizzabile per altre stanze) o tramite raffinamento (aggiunta di vincoli riguardo l’attivazione di una regola). E’ possibile un approccio basato su comportamenti e preferenze dell’utente [11] che generi suggerimenti basandosi sulle zone preferite della casa per determinate azioni, o su orario e formato preferito per ricevere i promemoria [17].
2 Stato dell’arte
2.1 Introduzione
In questa sezione si è fornisce una panoramica sui risultati raggiunti nel campo delle applicazioni trigger-action, guardando ad esse concentrandosi su alcuni aspetti, ovvero: metodi per effettuare suggerimenti e fornire supporto nella creazione delle regole, uso di metafora del puzzle e di programmazione visuale a blocchi, debugging di regole, rappresentazione del contesto di uso. Sono presentate alcune applicazioni che, anche se non rivolte verso l’uso di ambienti di programmazione basati su blocchi nelle applicazioni trigger-action, risultano particolarmente significative e applicate a contesti concettualmente paragonabili.
2.2 Supporto nella creazione della regola e suggerimenti
Un progetto mirato all’individuazione di un paradigma per supportare gli utenti non tecnici nella composizione di servizi Web è EFESTO-5W [9]. L’idea è quella di concentrare la ricerca non tanto sugli aspetti tecnologici degli smart objects, ma sul come amplificare i benefici sociali e pratici per gli utilizzatori finali [9].
Il design di questo progetto è stato guidato dal paradigma delle “5 W” giornalistiche (Who did it? What happened? When did it take place? Where did it take place? Why did it happen?). La creazione effettiva della regola avviene secondo una procedura wizard, che partendo dalla definizione di un evento tramite scelta del “which” (quale servizio monitorare) e del “what” (cosa deve succedere) prosegue con la specificazione (opzionale) dei “when” e “where” relativi a quell’evento. E’ possibile aggiungere altri eventi, stabilendo in che relazione essi devono porsi tra loro (se devono accadere entrambi, espresso tramite la frase “Match ALL of the following condition”, o se basta che ne accada uno, espresso con “Match AT LEAST ONE of the following condition), e infine l’azione collegata a questi eventi.
Inoltre è stato studiato come poter collegare trigger con operatori logici, combinazioni, annidamenti e raggruppamenti (permettono di aggiungere un nuovo trigger o un blocco di
trigger). La strutturazione delle regole viene incontro ai modelli mentali degli utenti seguendo due possibili costrutti di normalizzazione: la disjunctive normal form e la conjunctive normal form. La disjunctive normal form è la teoria che propone come più semplici da concettualizzare statements logici composti da disgiunzioni di congiunzioni (un OR di AND). La conjunctive normal form modella gli statements logici come congiunzione di disgiunzioni. Sono due modi di raggruppare o destrutturare operatori logici, traducibili l'una nell'altra tramite equivalenze logiche come la legge di De Morgan [9]
In questo modo, i ricercatori hanno esteso un’applicazione di trigger-action, aumentando l’espressività senza contraddire gli elementi necessari a migliorare le performance e la soddisfazione di utilizzatori finali non tecnici [9].
Un altro progetto rilevante per quanto riguarda i suggerimenti all’utente è CharIoT. E’ un’interfaccia di end-user programming per la piattaforma GIoTTO . Le funzionalità di 22 CharIoT sono connettersi al middleware di GIoTTO per comunicare con sensori ed attuatori e permettere di creare sensori virtuali programmabili. Essi servono per definire un livello di astrazione sopra il livello di dati grezzi (che permette ad esempio di definire cosa significa “caldo” per ogni stanza) e creare regole in stile IFTTT relative a questi dati [22].
Inoltre include un sistema per effettuare raccomandazioni, basato su due diversi metodi. Il primo si basa sull’individuazione dei vicini più simili in base alla similarità dei valori dei sensori, usando un approccio content-based. Sono costruiti dei profili dei sensori, contenenti fuzzy sets (distribuzioni di valori prodotti dai sensori in un intervallo di tempo stabilito) di valori. Questa similarità dà una indicazione di quanto siano simili due ambienti: le similarità sono combinate e usare per creare il ranking di regole [22].
Il secondo metodo usato è l’individuazione della similarità nelle installazioni, usando un metodo di collaborative filtering item-to-item. Nuove regole sono mostrate basandosi sulle altre regole che l’utente ha creato, basandosi sugli utenti che hanno creato regole simili [22].
RecRules [5] propone un approccio per fornire raccomandazioni nel contesto dei sistemi trigger-action. Lo scopo è alleggerire il carico mentale degli utenti nello scegliere trigger e azioni da un insieme ampio di possibilità. Anche prendendo come riferimento IFTTT, che permette di creare regole con solo un trigger e una azione, le possibili combinazioni di essi possono rendere complicata l’esperienza dell’utente [5].
Per superare questo problema i ricercatori hanno sviluppato un sistema di raccomandazione misto basato su content filtering (informazioni semantiche modellate su OWL) e collaborative filtering (preferenze dell’utente in formato grafo). Queste informazioni sono usate per allenare un algoritmo learning-to-rank (applicazione del machine learning alla costruzione di modelli di ranking a partire da un set di dati di training su cui è specificato un qualche tipo di punteggio o di giudizio numerico come “rilevante” e “non rilevante” ) per 23 suggerire i migliori N risultati.
Lo scopo di questo suggeritore è astrarre dal tipo di dispositivo per fornire suggerimenti basati sulla funzionalità, mirando quindi al comportamento che si vuole ottenere [5]. Arricchendo le regole di un layer di semantica permette di far emergere dei collegamenti tra regole non immediatamente visibili (ad esempio una lampada e una tapparella, anche se diversi dal punto di vista tecnologico, condividono la funzionalità di regolare l’illuminazione di una stanza [5]).
Il modello di riferimento è quello dei Linked Open Data: l’intero dataset LOD può essere visto come un grande knowledge graph decentralizzato, i cui nodi corrispondono ad entità RDF, e gli archi etichettati alle proprietà che li connettono. Questo grafo può essere ulteriormente arricchito inserendo come archi tra utenti e regole i feedback impliciti ed espliciti sulle regole [5].
Il sistema in due fasi, creazione del knowledge graph e learning. La creazione del knowledge graph si basa sulle regole presenti e sulla history dell’utente. Per effettuare le mappature necessarie ad arricchire questi elementi di informazioni semantiche è utilizzata l’istanziazione dell’ontologia EUPont per IFTTT [5]. Un sistema di reasoning semantico (programma in grado di inferire conseguenze logiche da un set di facts o assiomi asseriti ) 24 permette di analizzare trigger e azioni di ogni regola e collegare le classi OWL ad essi relativi. A questo grafo vengono infine aggiunte le informazioni collaborative, che permettono di distinguere se una regola è o no rilevante in base a quanto è stata apprezzata dagli utenti, e viene filtrato utilizzando le informazioni contestuali relative all’utente.
23 "Learning to rank - Wikipedia." https://en.wikipedia.org/wiki/Learning_to_rank. Ultimo
accesso: 1 nov. 2019.
24"Semantic reasoner - Wikipedia." https://en.wikipedia.org/wiki/Semantic_reasoner. Ultimo accesso: 1 nov. 2019.
Nella fase successiva vengono estratte dal grafo diversi percorsi costruiti secondo diverse possibili caratteristiche che uniscono utenti a regole, ovvero collaborative, tecnologiche o di funzionalità. Questi percorsi sono usati per allenare il modello di learning to rank, il cui scopo è apprendere una funzione in grado di ordinare nuovi oggetti in base alla loro rilevanza [5]. Dai test effettuati dai ricercatori emerge che la raccomandazione basata sulla funzionalità è più accurata, e che costruire recommender systems basati su questa caratteristica sia efficace [5].
In [25] è stato realizzato un sistema (AutoTap) per tradurre le regole trigger-action in proprietà LTL (linear temporal logic). L’idea alla base è l’evitare i possibili conflitti e cattive interpretazioni che avvengono se le regole vengono create e specificate come “entità singole”. Una regola del tipo “se inizia a piovere chiudi le finestre” può non funzionare perchè può esserci conflitto con un altro trigger che fa aprire la finestra, oppure essa può essere aperta manualmente da un altra persona nell’ambiente. Gli utenti possono esprimere, oltre alle regole, le proprietà del sistema che devono essere sempre soddisfatte, quindi che "finestre aperte" e "sta piovendo" non possono accadere insieme [25].
La base consiste in una mappatura delle proprietà, da input di tipo “questo stato e questo stato devono apparire sempre insieme” o “questo evento non può mai avvenire in concomitanza con questo stato” a formule LTL. Il sistema controlla che le regole create siano valide rispetto alle proprietà del sistema, trova quale parte di regola ne impedisce la validazione, e modifica una regola non valida per renderla invece accettabile rispetto alla proprietà definite.
Ciò avviene costruendo un sistema di transizioni per un insieme di dispositivi di regole trigger-action. Questo sistema viene trasformato in un automa di Büchi che accetta tutto ciò che è permesso, unito successivamente ad un altro automa rappresentante tutto ciò che viola le esecuzioni possibili ottenuto dalle formule LTL definite [25].
2.3 Uso di blocchi e puzzle
In [24] è stata testata l’interfaccia a blocchi sviluppata (CoBlox, basata su Blockly) nel contesto dei robot industriali. Lo scopo era valutare se una interfaccia basata su blocchi fosse più adatta per la modellazione di task complessi rispetto ad altri ambienti di programmazione usati nell’industria. Gli ambienti rispetto cui è stato testato sono Flex Pendant (dispositivo
hardware che permette di creare e modificare programmi e di dare direttamente posizioni di input al robot tramite un joystick) e Polyscope (utilizza di navigazione guidata, realizzato tramite un sistema ad albero).
Emerge dallo studio che gli utenti percepiscono l’interfaccia a blocchi più facile e soddisfacente da usare rispetto alle altre [24]. Gli utenti riescono a modellare i task in maniera più veloce, anche se non cambiano qualità e il tipo di errori commessi. Un altro aspetto interessante è la possibilità di definire funzioni predefinite che servono da template per azioni comuni [24]. Nel programma è possibile definire varie procedure “pick and place”, operazione comune nei robot industriali, tramite la composizione di vari movimenti all’interno di un blocco contenitore e inserendo poi un blocco riferimento a questa funzione nel flusso principale del programma.
In [2] è stata sviluppata un’applicazione (Smart Block) basata un linguaggio visuale basato su blocchi adatto ad essere usato da persone non esperte di programmazione per creare regole di personalizzazione per la piattaforma IoT SmartThings. La descrizione delle regole dal punto di vista formale si appoggia a IoTa calculus, un linguaggio specifico per il dominio basato sul paradigma ECA. Questo linguaggio permette di definire i concetti di tempo, stati, aggregazione di dispositivi . Gli autori hanno scelto la sintassi ECA perché, anche se perde 25 di espressività nei confronti di un linguaggio di programmazione generico, essa può esprimere la maggior parte delle regole creabili con le applicazioni comuni di home automation [2].
La realizzazione del linguaggio visuale a blocchi segue quella del paradigma ECA: il blocco regola presenta una sezione per event, una per condition e una per action, nelle quali è possibile inserire i blocchi corrispondenti. E’ possibile esprimere regole che non presentano una condizione. Inoltre più blocchi regola possono essere uniti a formare una applicazione.
Un progetto rilevante per quanto riguarda l’uso della metafora del puzzle è il framework Puzzle [7]. E’ un ambiente di sviluppo visuale orientato verso persone senza esperienza di programmazione, per fornire un modo di creare applicazioni mobile utilizzando lo smartphone [7].
25 "Iota: A Calculus for Internet of Things Automation - Manu ...."
E’ un approccio ad alto livello (non basato quindi sulla traduzione di costrutti di programmazione in un altra forma) che mira a creare un linguaggio visuale in grado di diminuire la curva di apprendimento e la barriera tra sviluppo ed uso [7]. Inoltre è possibile l’interazione con oggetti dotati di sensori e attuatori presenti nell’ambiente. La possibilità di sviluppare applicazioni direttamente da mobile permette di scollegare questa attivita da una situazione definita (seduti davanti a pc), integrandola nelle attività quotidiane. Questo è stato prefigurato nel modello Ubiquitous computing . 26
L’applicazione è pensata per l’uso su un dispositivo touch dallo schermo relativamente ridotto. L’interazione avviene tramite touch per selezionare oggetti, drag per spostarli e slide per mostrare le parti non visibili dell’area di lavoro [7].
Il linguaggio visuale è basato sulla metafora del puzzle: essa da indizi visuali immediati riguardo il come e dove un comando potrà essere usato [ 23].Un altro indizio visivo è dato dalla sequenza in cui i pezzi del puzzle si connettono (da destra a sinistra) che da un senso di flusso di informazioni. Esso viene evidenziato da forme circolari poste a sinistra e a destra del pezzo di puzzle, che rendono esplicito che un pezzo riceva un input o dia un output.
Input e output sono anche resi più evidenti da un sistema di colori che ha lo scopo di fare risaltare quali tipi di pezzo possono essere connessi: sarebbe stato infatti problematico usare forme diverse per i diversi connettori [7].
Per mostrare i diversi pezzi disponibile è usato un carosello con informazioni testuali aggiunte. I menù vengono mostrati o nascosti tramite uno slider, per risparmiare spazio. Sempre per permettere di visualizzare un appropriato numero di scelte rispetto allo spazio disponibile è usato un raggruppamento dei pezzi in categorie, e dei menù pop-up per effettuare ulteriori operazioni [7].
2.4 Debug delle regole
In [15] la programmazione trigger-action è stata estesa da un ambiente abitativo ad un edificio commerciale dotato di sensori ed attuatori (smart building) con potenzialmente molti occupanti. Il problema in questo caso consiste nella gestione dell’edificio, poiché essa è
26 "Ubiquitous computing - Wikipedia." https://it.wikipedia.org/wiki/Ubiquitous_computing.
spesso automatizzata e centralizzata. Ciò non permette personalizzazioni [15]: serve un modo per gli utenti di interagire con le policies definite.
Questo framework permette di specificare regole in linguaggio pseudo-naturale che possono agire a livello di singola stanza o di gruppo. Le regole create sono suddivise in categorie in base a su che dispositivo agiranno. Visti i molti utenti c’è la possibilità che le regole siano in conflitto, ovvero siano attivate contemporaneamente e cerchino di attuare azioni che non possono essere soddisfatte nello stesso momento [15].
Per identificare i conflitti tra regole i ricercatori hanno trascritto le regole e le hanno analizzate con il solver SMT Z3. Prima di aggiungere una regola, essa è verificata su un insieme di regole già attive nella stanza. Se dei trigger che possono essere attivi nello stesso momento usano azioni che non possono essere attive allo stesso momento viene segnalato un conflitto [15].
Il tool ITAD (Interactive Trigger-Action Debugging) propone diverse funzionalità (simulazione, spiegazione interattiva, identificazione e risoluzione di conflitti [14]) per fornire supporto all’utente nella TAP. Il supporto è relativo a situazioni come più regole in conflitto, o una regola che non si comporta nel modo desiderato. Ciò viene fatto introducendo il concetto di Whyline nella TAP [14].
Il concetto di Whyline proviene dal paradigma Interrogative Debugging, il cui scopo è diminuire i tempi necessari all’individuazione di un problema durante il debug. E’ stato ideato da Amy Jensen Ko e da lei realizzato come27 plugin per l’ambiente Alice. Il plugin permetteva di mettere in pausa l’esecuzione del programma in Alice per scegliere uno degli output disponibili al momento, e di visualizzare graficamente per l’output scelto la catena di eventi che lo aveva portato nello stato attuale. La Whyline era espressa tramite una rappresentazione grafica dei passi di programmazione necessari a raggiungere il risultato desiderato [14].
Il tool ITAD può simulare un insieme di parametri per testare se una regola si attiverà o no in un determinato contesto. Inoltre rende possibile chiedere in modo interattivo le domande
27 "(PDF) Debugging by asking questions about program output."
https://www.researchgate.net/publication/221554394_Debugging_by_asking_questions_abo ut_program_output. Ultimo accesso: 1 nov. 2019.
“perché?” e “perché no?”, riguardo alle ragioni per cui una regola si sia o meno attivata nel contesto fornito [14].
Dal punto di vista dell’interfaccia il simulatore mostra da un lato una struttura gerarchica che permette di creare un’istanza di contesto con specificati i valori che vogliamo usare nella prova, e dall’altro la lista di regole che vogliamo testare sul simulatore: l’esito dell’attivazione della regola è mostrato cambiando il colore di sfondo nella lista di regole.
Come risultato della simulazione vengono inoltre aggiunti dei bottoni nel pannello della regola: “edit” per modificare la regola, e “why” o “why not” (per le regole non attivate). Questi ultimi servono rispettivamente a evidenziare gli elementi del contesto che hanno concorso all’attivazione della regola, e a evidenziare nel caso della non attivazione quali elementi sono risultati positivi al test con il contesto e quali no, mostrandoli sia nella regola che nella rappresentazione del contesto simulato.
La funzionalità “conflict” serve ad identificare per una regola attiva con quali altre regole può entrare in conflitto (ovvero andare ad agire tramite azioni sullo stesso dispositivo o categoria: accendere e spegnere quella luce oppure tutte le luci), sotto quali condizioni esso può avvenire e quali azioni vadano in conflitto. L’uso di colori e di descrizioni in linguaggio naturale permettono di individuare quando una regola non venga attivata per errata impostazione di evento o condizione rispetto al contesto [14].
My IoT Puzzle è uno strumento per comporre ed effettuare debug di regole if-then basato sulla metafora del puzzle. Il tool mira a trovare un linguaggio di debug comprensibile dall’utilizzatore. Le domande di ricerca usate per guidare l’analisi sono state: di che tipo di informazioni (ad esempio feedback e spiegazioni) ha bisogno l'utente per effettuare debug? Qual è il linguaggio visuale più adatto per effettuare il debug? [4]
Generalmente un utilizzatore inesperto non avrà coscienza di come effettuare del debug organizzato, quindi proverà a risolvere i problemi cambiando cose continuamente finché non riesce a far funzionare il programma (debugging into existence) [4]. Basandosi sul paradigma Interrogative Debugging lo strumento è in grado di stabilire il perché una certa regola non funzioni, e di dare feedback all’utente tramite spiegazioni testuali durante la creazione della regola.
Per capire che informazioni dare, i ricercatori si sono basati sulle domande tipiche che si pone un programmatore durante il debug (perché sta facendo questo? Perché non sta facendo questo?). I tipi di problemi nelle regole presi in esame sono:
● loop: più regole si attivano continuamente in maniera alternata, impedendo il raggiungimento di uno stato stabile del sistema;
● ridondanza: più regole attivate condividono funzionalità replicate;
● inconsistenza: regole attivate allo stesso tempo che cercano di far attivare azioni contrastanti.
Gli autori hanno individuato il linguaggio visuale a blocchi, in particolare che utilizzi la metafora del puzzle, come più adatto per lo sviluppo di regole IF-THEN, in quanto meno restrittivo a più creativo rispetto ad un approccio basato sul riempimento di form. Anche l’approccio data-flow è stato giudicato utile, ma data la sua natura orientata verso processi complessi, più adatto a mostrare le interazioni tra regole.
La composizione avviene avvalendosi delle metafore di blocchi e puzzle. Per evitare approcci troppo complessi sono stati usati solo due tipi di blocco, uno per trigger e uno per azioni. Durante la fase di composizione della regola i pezzi già usati in altre regole sono resi come danneggiati, per avvisare di eventuali possibili ridondanze o inconsistenze con altre regole. Se il sistema avverte uno di questi problemi, avvisa anche l’utente tramite un feedback (rosso) con informazioni su come poter risolverlo. Ulteriori informazioni sono date nell’area di risoluzione problemi, che contiene una spiegazione testuale del problema una rappresentazione di tipo data-flow, tramite linguaggio petri-net: in questo modo si dà una descrizione esplicita del perché sta avvenendo il problema, seguendo il paradigma Interrogative Debug.
Il progetto AppsGate riguarda la realizzazione di un sistema EUD per la personalizzazione di un ambiente smart home, mirato al massimo controllo da parte dell’utente, senza che le sue scelte vengano limitate o “indirizzate” dall’utilizzo di Intelligenza Artificiale (AI). L’AI potrebbe mostrare solo i servizi giudicati più pertinenti, decidendo dopo aver effettuato data mining sulle routine giornaliere dell’utente [6].
Lo strumento fornisce due visualizzazioni per permettere di monitorare lo stato dell’abitazione, una basata su timeline (sia in tempo reale che tramite snapshot di momenti passati) e una su un grafo delle dipendenze che permette di individuare eventuali comandi in conflitto.
Nella progettazione i ricercatori si sono ispirati al framework delle dimensioni cognitive (approccio per misurare l’usabilità di artefatti di informazioni come i programmi, o da usare come euristica per guidare il design ) per effettuare scelte di design riguardo il grado di 28 astrazione (in questo caso regole raggruppabili in programmi) e la vicinanza del mapping (quanto corrisponde la notazione scelta al dominio del problema: è stato scelto un linguaggio pseudo-naturale, unito ad un editor guidato da una smart keyboard che fornisce le opzioni possibili nel momento attuale).
Sono state inoltre usate notazioni secondarie per rendere visibili informazioni non esplicite, migliorando il cognitive fit, per tracciare l'esecuzione del programma ed effettuare debug, utile in questo caso perchè i linguaggi basati su regole tendono a oscurare l'ordine delle azioni: vengono usate frecce per indicare che il programma è in attesa.
Nella fase di debug, ispirata al paradigma Interrogative Debugging, vengono usati cerchi rossi per denotare conflitti o per dispositivi non disponibili, arancio per entità non più disponibili, numeri per tracciare l'esecuzione. Il sistema non può rispondere direttamente alle domande, ma c'è possibilità di esplorare manualmente le snapshot passate della situazione della casa.
Le difficoltà incontrate dai ricercatori hanno riguardato la mancanza di un sistema operativo standard de facto e aperto, orientato alla gestione di una smart home, per permettere una infrastruttura che gestisca il flusso dinamico di device e servizi in tempo reale. C’è bisogno di usare un middleware open source, come Open HAB. Inoltre è difficile per persone senza esperienza di programmazione esprimere condizioni complesse e distinguere le diverse temporalità delle azioni (sono state usate frasi diverse per queste distinzioni). I lati positivi individuati in questo sistema sono la convenienza dell’installazione e la grande possibilità di personalizzazione.
28 "Cognitive dimensions of notations - Wikipedia."
https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations. Ultimo accesso: 1 nov. 2019.
2.5 Rappresentazione del contesto
Nella realizzazione dell’applicazione Context-Dependent Authoring Tool i ricercatori hanno studiato un modo di utilizzare il contesto d’uso per permettere di sviluppare applicazioni dotate di interfaccia cross-device tramite il paradigma trigger-action [11].
Applicazioni di questo tipo possono essere usate in diversi domini:
● nello smart retail per fornire supporto ai clienti, basandosi ad esempio sulla prossimità;
● in musei e durante le visite alle città per fornire informazioni e giochi in relazione al contesto;
● in applicazioni di apprendimento per adattare il contenuto e il modo di presentazione ai dispositivi presenti, persone vicine, stato personale. [11].
I ricercatori hanno definito quattro dimensioni rilevanti alla struttura del contesto: utente (task, preferenze, stato emotivo), dispositivo (possibilità di interazione, connettività, supporto multimediale), ambiente (rumore, luce, temperatura), relazioni sociali (amicizia, gruppi) [11]. Le informazioni del contesto sono usate sia per creare la classificazione dei trigger, sia per permettere durante l’uso la distribuzione dinamica dell’interfaccia tra i dispositivi disponibili nell’ambiente in cui si trova l’utente. Un’applicazione per l’ambito museale può essere progettata per passare da un dispositivo a mano a un pannello quando viene attivato il trigger di prossimità [11].
I ricercatori hanno aggiunto un livello di astrazione per fornire già pronte delle regole rilevanti in un contesto, in modo da permettere all’utilizzatore di usare la regola solo inserendo i valori relativi al suo caso. Nel caso di uno smart retail, le strutture di regola predefinita potrebbero riguardare quando il cliente è vicino a qualcosa, quando si sta muovendo, quando sta entrando o uscendo. Scegliendo e completando un trigger relativo a uno dei casi, sono mostrate le azioni significative relativamente a quella regola.
CCBL (Cascading Context Based Language) è un linguaggio di EUD dedicato agli ambienti smart home sviluppato per risolvere alcuni problemi relativi alla programmazione Event-Condition-Action (ECA), proponendo un linguaggio basato su una rappresentazione diversa rispetto a quelle comunemente usate in questo ambito.
I ricercatori hanno definito il contesto come una gerarchia di situazioni di crescente specificità. Un contesto può riferirsi a quando l’utente è a casa, un altro (più specifico e con priorità maggiore) a quando si trova a casa e sta usando il telefono. I contesti sono di due tipi: evento (non hanno associata una nozione temporale, sono concettualmente simili agli eventi nella programmazione trigger-action) e stato, che sono invece associati ad una durata.
I contesti di tipo stato costituiscono la base della struttura usata nel progetto, e sono costituiti da 3 parti:
● un’espressione booleana e, opzionali, un evento start e o un evento end: ad esempio, l’espressione “l’utente è al telefono” può essere associata ad un evento start “l’utente entra in casa”. Il contesto dura finchè l’espressione è vera, o finchè non si verifica l’evento end;
● un insieme di azioni da effettuare quando il contesto è attivo;
● una lista di sotto-contesti (sia di tipo stato che evento) che fanno parte del contesto stato in esame, che possono quindi attivarsi solo se il contesto genitore è attivo. Ad esempio il contesto “utente è a telefono” si applica solo durante il contesto “utente è in casa”.
Il contesto radice rappresenta lo stato “naturale” della casa. Per evitare inconsistenze, solo un contesto alla volta ha possibilità di modificare lo stato di un dispositivo: quindi, se ad esempio siamo nel contesto stato “utente è al telefono”, e esso va ad agire sul volume dello stereo, esso non viene modificato anche se si verifica un evento che andrebbe ad alterare il suo stato. E’ presente il concetto di priorità, assegnata in base all’indice di profondità del contesto (più specifico, maggiore priorità) con un meccanismo ispirato ai fogli di stile.
Lo scopo di questo sistema è di dare feedback specifici agli utenti riguardo alla “chiusura” dei contesti, e secondo il test condotto dai ricercatori, con questo metodo gli utenti realizzano
