Politecnico di MilanoScuola di Ingegneria Industriale e dell’Informazione

Corso di Laurea Magistrale in Ingegneria InformaticaDipartimento di Elettronica, Informazione e Bioingegneria

Progettazione di mashup per dispositivi mobili: un metodobasato sulla modellazione del contesto

Relatore: Prof.ssa Letizia TANCACorrelatori: Prof.ssa Maristella MATERA

Prof. Vittorio ZACCARIA

Tesi di laurea di:Valerio CASSANI Matr. 817014Stefano GIANELLI Matr. 817398

Anno Accademico 2014–2015

Too often we forget that genius, too, depends upon the data within its reach, thateven Archimedes could not have devised Edison’s inventions

Ernest Dimnet

Sommario

Data la sovrabbondanza di dati e servizi disponibili online è spesso difficile trova-re informazioni e applicazioni adatte al contesto corrente. Questa situazione è accen-tuata se la ricerca di dati è eseguita su dispositivi mobili, dove le risorse (memoria,capacità computazionale, piano dati modesto) sono limitate.

Date queste premesse questa tesi mira alla definizione di metodologie e strumentiper la progettazione e sviluppo di Context-Aware Mobile mashUpS (CAMUS). Leapplicazioni CAMUS recuperano e integrano i dati dinamicamente da risorse online(interrogate tramite web API) e si occupano di ritagliare le informazioni acquisitein base alla situazione nella quale si trova l’utente. Offrono numerosi vantaggi graziealla capacità di identificare fonti pertinenti, selezionate in base alla loro adeguatezzarispetto alle esigenze dell’utente, i cui dati sono integrati e forniti sotto forma dimobile app.

Questo paradigma permette di superare i limiti delle applicazioni preconfezio-nate e mette a disposizione applicazioni flessibili e personalizzate la cui strutturae contenuti possono variare in fase di esecuzione in base alla situazione d’uso. Unesempio di beneficio è l’integrazione dei contenuti principali con servizi di suppor-to, come le mappe, le informazioni sul meteo o il trasporto pubblico, che possonomigliorare l’esperienza d’uso.

Questa tesi presenta una metodologia di progettazione e una piattaforma per lacreazione di applicazioni CAMUS. L’approccio i) utilizza la modellazione del conte-sto come strumento principale per individuare le risorse più adatte per soddisfare ibisogni dell’utente e ii) individua in fase di esecuzione come ritagliare i dati e le fun-zioni recuperate dalle risorse selezionate. L’astrazione fornita dal contesto, infatti,viene utilizzata per generare modelli che definiscono come i dati recuperati andrannointegrati e visualizzati. Questi modelli definiscono le regole di esecuzione dinamicadelle mobile app. La tesi inoltre descrive un prototipo che fa uso delle tecnologieweb e mobile più recenti per supportare la modellazione delle applicazioni CAMUS,la generazione automatica del codice e l’esecuzione delle applicazioni finali.

Abstract

Given the plethora of data and services today available online, it is often diffi-cult to find on-the-fly the information or the applications that are appropriate tothe current context of use. This is even more accentuated in the mobile scenario,where device resources (memory, computational power, transmission budget) arestill limited.

Given this evidence, this thesis focuses on the definition of methods and toolsfor the design and development of Context-Aware Mobile mashUpS (CAMUS). CA-MUS apps dynamically collect and integrate data from documental, social and Webresources (accessed by means of Web APIs) and adapt the integrated contents tothe users’ situational needs. They can offer multiple advantages thanks to their in-trinsic capability of identifying pertinent data sources, selected on the basis of theiradequateness with respect to the current users’ needs, and pervasively presentingthem to the final user in the form of integrated visualizations deployed as mobileapps.

This application paradigm overcomes the limits posed by pre-packaged apps andoffers to users flexible and personalized applications whose structure and contentmay even emerge at runtime based on the actual user needs and situation of use.An example of benefit is the integration with support services, such as maps, weatherforecast or public transport information, to provide a better user experience.

This thesis presents a design method and an accompanying platform for thedevelopment of CAMUS app. The approach is characterized by the role given tocontext as a first-class modelling dimension used to support i) the identification ofthe most adequate resources that can satisfy the users’ situational needs and ii)the consequent tailoring at runtime of the provided data and functions. Context-based abstractions are exploited to generate models specifying how data returnedby selected services have to be merged and visualized by means of integrated views.These models then drive the flexible execution of the final mobile app on targetmobile devices. A prototype of the supporting platform, making use of novel andadvanced web and mobile technologies, is also illustrated.

Indice

1 Introduzione 11.1 Caso di studio: il turismo . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Preliminari 92.1 Concetti Preliminari . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Context-Awareness . . . . . . . . . . . . . . . . . . . . . . . . 92.1.1.1 Context Dimension Tree . . . . . . . . . . . . . . . 11

2.1.2 Mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2.1 Classificazione dei mashup . . . . . . . . . . . . . . 162.1.2.2 Mobile Mashup . . . . . . . . . . . . . . . . . . . . . 172.1.2.3 Funzionamento generale . . . . . . . . . . . . . . . . 18

2.1.3 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.3.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.3.2 REST . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.1 Tecnologie utilizzate per il backend . . . . . . . . . . . . . . . 322.3.1.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1.3 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.1.4 GraphQL . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.2 Tecnologie utilizzate per la mobile app . . . . . . . . . . . . . 362.3.2.1 React . . . . . . . . . . . . . . . . . . . . . . . . . . 382.3.2.2 React Native . . . . . . . . . . . . . . . . . . . . . . 382.3.2.3 Flux . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 Metodologia CAMUS 433.1 Organizzazione del framework . . . . . . . . . . . . . . . . . . . . . . 433.2 Obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3 Integrazione del contesto con i mashup . . . . . . . . . . . . . . . . . 49

i

Indice

3.4 Utilizzo dei servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.5 Modello del contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.6 Creazione dell’ecosistema dei servizi . . . . . . . . . . . . . . . . . . 513.7 Associazione dei servizi al contesto . . . . . . . . . . . . . . . . . . . 543.8 Albero di contesto su misura per gli utenti . . . . . . . . . . . . . . . 573.9 Selezione delle operazioni in base al contesto . . . . . . . . . . . . . . 593.10 Integrazione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.11 Mashup Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 Progettazione di alto livello 734.1 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.1.2 Mobile app . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1.2.1 Pagine dell’applicazione . . . . . . . . . . . . . . . . 764.1.2.2 Helpers . . . . . . . . . . . . . . . . . . . . . . . . . 784.1.2.3 Actions e Stores . . . . . . . . . . . . . . . . . . . . 78

4.2 Scenario d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.3 Flusso di esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 Progettazione di dettaglio e implementazione del backend 875.1 Descrittore dell’albero di contesto . . . . . . . . . . . . . . . . . . . . 87

5.1.1 Radice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.1.2 Nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.1.3 Parametri dei nodi . . . . . . . . . . . . . . . . . . . . . . . . 89

5.2 Descrittore dei servizi . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.1 Descrizione generale del servizio . . . . . . . . . . . . . . . . 905.2.2 Descrittore delle operazioni . . . . . . . . . . . . . . . . . . . 915.2.3 Parametri delle operazioni . . . . . . . . . . . . . . . . . . . . 925.2.4 Formato della risposta . . . . . . . . . . . . . . . . . . . . . . 945.2.5 Paginazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.3 Schema del database . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.4 Componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.4.1 Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.4.2 Context Manager . . . . . . . . . . . . . . . . . . . . . . . . . 1025.4.3 Primary Service Selection . . . . . . . . . . . . . . . . . . . . 1035.4.4 Query Handler . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.4.5 Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.4.6 Response Aggregator . . . . . . . . . . . . . . . . . . . . . . . 1055.4.7 Support Service Selection . . . . . . . . . . . . . . . . . . . . 1055.4.8 Session Helper . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.4.9 Query Composer . . . . . . . . . . . . . . . . . . . . . . . . . 107

ii

Indice

5.5 Endpoint GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.5.1 Execute Query . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.5.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.5.3 Get Personal Data . . . . . . . . . . . . . . . . . . . . . . . . 111

5.6 File di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6 Progettazione di dettaglio e implementazione della mobile app 1176.1 Gestione dello stato . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.1.1 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.1.2 Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.2 Struttura dello schema di mashup . . . . . . . . . . . . . . . . . . . . 1216.3 Rendering delle view . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.3.1 Rendering a partire dal contesto . . . . . . . . . . . . . . . . 1236.3.2 Rendering dei risultati . . . . . . . . . . . . . . . . . . . . . . 1246.3.3 Gestione degli stili . . . . . . . . . . . . . . . . . . . . . . . . 125

6.4 Query GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.4.1 Login Query . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.4.2 Data Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.4.3 Gestione paginazione . . . . . . . . . . . . . . . . . . . . . . . 129

6.5 Servizi di supporto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

7 Valutazione delle prestazioni 1337.1 Sistema di test e modello di simulazione . . . . . . . . . . . . . . . . 1337.2 Tempo di risposta a una singola richiesta . . . . . . . . . . . . . . . 1357.3 Tempo di risposta per richieste multiple . . . . . . . . . . . . . . . . 1387.4 Tempo di risposta con condizioni di rete diverse . . . . . . . . . . . . 139

8 Conclusioni e sviluppi futuri 1438.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Bibliografia 151

A Descrittori 153

B Esempi di codice 157

iii

Indice

iv

Elenco delle figure

1.1 Traffico generato per tipologia di dispositivo . . . . . . . . . . . . . . 11.2 Traffico generato per segmento . . . . . . . . . . . . . . . . . . . . . 21.3 Traffico generato per categoria . . . . . . . . . . . . . . . . . . . . . 3

2.1 Context Dimension Tree . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Grammatica del Context Dimension Tree . . . . . . . . . . . . . . . 132.3 Esempio di contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Configuration-based mapping . . . . . . . . . . . . . . . . . . . . . . 142.5 Value-based mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Potholes Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Esempio di merge e union . . . . . . . . . . . . . . . . . . . . . . . . 202.8 Esempio Swagger Editor . . . . . . . . . . . . . . . . . . . . . . . . . 242.9 Esempio API risultante Swagger . . . . . . . . . . . . . . . . . . . . 252.10 Composizione visuale in Appery.io . . . . . . . . . . . . . . . . . . . 272.11 Karma Service Integration . . . . . . . . . . . . . . . . . . . . . . . . 292.12 Peudom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.13 CADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.14 Flusso di sviluppo React Native . . . . . . . . . . . . . . . . . . . . . 392.15 Flusso dati unidirezionale Flux . . . . . . . . . . . . . . . . . . . . . 40

3.1 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 463.2 Associazione dei servizi al CDT . . . . . . . . . . . . . . . . . . . . . 563.3 Esempio di contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4 Esempio gerarchia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.5 Esempio di assegnazione del punteggio per le operazioni primarie . . 623.6 Esempio di selezione delle operazioni di supporto . . . . . . . . . . . 643.7 Tempi di esecuzione algoritmo di ricerca duplicati . . . . . . . . . . . 673.8 Prestazioni dell’algoritmo di ricerca dei duplicati . . . . . . . . . . . 693.9 Web App di Visual Mapping . . . . . . . . . . . . . . . . . . . . . . 703.10 Schema delle views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.1 Architettura del backend . . . . . . . . . . . . . . . . . . . . . . . . . 74

v

Elenco delle figure

4.2 Architettura dell’applicazione mobile . . . . . . . . . . . . . . . . . . 764.3 Schema delle pagine . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.4 Pagina di autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . 794.5 Schermata principale . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.6 Selezione del contesto . . . . . . . . . . . . . . . . . . . . . . . . . . 804.7 Risultati ricevuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.8 Dettagli oggetto selezionato nella view DetailsPage . . . . . . . . . . 804.9 Flusso dei dati dell’app Flux . . . . . . . . . . . . . . . . . . . . . . 814.10 Flusso di una nuova richiesta . . . . . . . . . . . . . . . . . . . . . . 824.11 Flusso di creazione del CDT decorato . . . . . . . . . . . . . . . . . 834.12 Flusso di richiesta dei risultati primari . . . . . . . . . . . . . . . . . 84

5.1 Diagramma ER del database . . . . . . . . . . . . . . . . . . . . . . 975.2 Schema logico del database . . . . . . . . . . . . . . . . . . . . . . . 985.3 Diagramma delle classi del backend . . . . . . . . . . . . . . . . . . . 995.4 Diagramma dello schema GraphQL . . . . . . . . . . . . . . . . . . . 109

6.1 Schermata dei dettagli . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.1 Sistema a coda singola . . . . . . . . . . . . . . . . . . . . . . . . . . 1347.2 Analisi del Service Time con differenti configurazioni . . . . . . . . . 1367.3 Distribuzione del Service Time . . . . . . . . . . . . . . . . . . . . . 1377.4 Analisi del tempo di esecuzione dei componenti . . . . . . . . . . . . 1387.5 Analisi del Response Time con differenti configurazioni . . . . . . . . 1397.6 Analisi dei tempi di risposta con reti diverse . . . . . . . . . . . . . . 141

vi

Elenco delle tabelle

3.1 Sintesi architetture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2 Confusion Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.1 Caratteristiche della macchina di test . . . . . . . . . . . . . . . . . . 1357.2 Analisi velocità delle connessioni . . . . . . . . . . . . . . . . . . . . 140

vii

Elenco delle tabelle

viii

Elenco degli algoritmi

3.1 Algoritmo di ricerca dei nodi figlio . . . . . . . . . . . . . . . . . . . 603.2 Algoritmo di rimozione dei duplicati . . . . . . . . . . . . . . . . . . 665.1 Algoritmo di composizione degli indirizzi . . . . . . . . . . . . . . . . 108

ix

Elenco degli algoritmi

x

Elenco dei listati

2.1 Esempio query GraphQL . . . . . . . . . . . . . . . . . . . . . . . . 352.2 Esempio di risposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3 Esempio connessione GraphQL . . . . . . . . . . . . . . . . . . . . . 362.4 Esempio di risposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1 Esempio di nodo del CDT . . . . . . . . . . . . . . . . . . . . . . . . 895.2 Esempio di parametro associato a un nodo . . . . . . . . . . . . . . . 905.3 Esempio di servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4 Esempio di operazione . . . . . . . . . . . . . . . . . . . . . . . . . . 925.5 Esempio di parametro di un’operazione . . . . . . . . . . . . . . . . 945.6 Esempio di formato di risposta . . . . . . . . . . . . . . . . . . . . . 955.7 Esempio di descrittore della paginazione . . . . . . . . . . . . . . . . 966.1 Esempio Data Store Mashup . . . . . . . . . . . . . . . . . . . . . . 1206.2 Esempio Schema Mashup . . . . . . . . . . . . . . . . . . . . . . . . 1226.3 Esempio Foglio di Stile . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.4 Esempio di servizi di supporto con intent . . . . . . . . . . . . . . . 131A.1 Descrittore dell’albero di contesto . . . . . . . . . . . . . . . . . . . . 153A.2 Schema dei Mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . 154A.3 File di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.4 Descrittore dei servizi . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.5 Schema delle operazioni . . . . . . . . . . . . . . . . . . . . . . . . . 156B.1 Esempio richiesta login . . . . . . . . . . . . . . . . . . . . . . . . . . 157B.2 Esempio richiesta executeQuery . . . . . . . . . . . . . . . . . . . . . 158B.3 Esempio risposta executeQuery . . . . . . . . . . . . . . . . . . . . . 159B.4 Esempio richiesta getPersonalData . . . . . . . . . . . . . . . . . . . 160

xi

Elenco dei listati

xii

Capitolo 1

Introduzione

Negli ultimi anni abbiamo assistito a un’enorme diffusione di Internet e soprat-tutto di una varietà di dispositivi mediante i quali è possibile accedervi: mentreagli albori esistevano solamente PC desktop, con i quali poter visitare pagine Webper lo più statiche, al giorno d’oggi sono disponibili dispositivi come smartphonee tablet che ci permettono di rimanere sempre connessi. Grazie al fatto di essereestremamente portatili e semplici da utilizzare, tali dispositivi sono ormai diventatioggetti indispensabili nella vita quotidiana, tanto che oramai la quantità di trafficogenerata da smartphone e tablet supera nettamente quella generata dai PC (Figura1.1). L’incremento della velocità delle connessioni e il progresso tecnologico ha fattosì che sia possibile consultare qualsiasi tipo di informazione su Internet, dal semplicetesto fino a immagini e video.

0

5

10

15

20

25

2015 2016 2017 2018 2019 2020Anno

Dat

i tra

sfer

iti [E

B/m

ese]

Tipologia

M2M

PC

Smartphone

Tablet

Traffico generato per tipologia di dispositivo

Figura 1.1: Traffico generato per tipologia di dispositivo (Fonte: Cisco, 2016)

1

1. Introduzione

Si è persa anche la tradizione che sia un gestore a pubblicare contenuti, in quantoormai sono direttamente gli utenti a produrre la maggior parte delle informazionidisponibili (Figura 1.2). Questo fenomeno è stato accentuato con la creazione deisocial network, che permettono di creare collegamenti tra le persone e dove è possibilecondividere qualunque cosa che ognuno trova interessante. Gli utenti vengono cosìcoinvolti nella creazione di contenuti di varia natura, anche di tipo multimedialegrazie alla dotazione di fotocamere ad alta risoluzione nei dispositivi.

50

100

2014 2015 2016 2017 2018 2019Anno

Dat

i tra

sfer

iti [E

B/m

ese]

Segmento

Business

Consumer

Traffico generato per segmento

Figura 1.2: Traffico generato per segmento (Fonte: Cisco, 2016)

Come si può notare in Figura 1.3 il traffico video e audio è in costante aumento.In particolare il traffico di video sovrasta tutti gli altri, anche a causa della maggiordimensioni di questi contenuti. Questo fenomeno è incentivato dalla diffusione diservizi che permettono lo streaming dei contenuti multimediali come YouTube1 oNetflix2.

Internet è quindi diventato una fonte immensa di informazioni, che sono desti-nate ad aumentare. Questo trend è inoltre accentuato dall’avvento dei dispositiviconnessi, cioè l’Internet of Things, come è possibile osservare in Figura 1.1 nella ti-pologia “M2M” (Machine to Machine). L’idea è che qualsiasi dispositivo può essereconnesso a Internet per generare informazioni, in particolare tutti quelli provvisti disensori che possono fornire dati sullo stato dell’ambiente nel quale si trovano.

Uno dei principali problemi che chiunque lavori coi dati vuole cercare di risolvereè ridurre l’information noise, migliorando la precisione delle informazioni da mo-

1YouTube: https://www.youtube.com2Netflix: https://www.netflix.com

2

0

5

10

15

20

2015 2016 2017 2018 2019 2020Anno

Dat

i tra

sfer

iti [E

B/m

ese]

Tipologia

Audio streaming

File sharing

Video

Web, data e VOIP

Traffico generato per categoria

Figura 1.3: Traffico generato per categoria (fonte: Cisco, 2016)

strare, in maniera che meglio si adattino ai requisiti che caratterizzano le situazionid’uso.

È frequente che le informazioni non vengano acquisite unicamente da una base didati bensì provengano da più fonti, anche di tipologie diverse tra loro (es.: relazionali,XML, ec..). Basti pensare alla moltitudine di servizi presenti nel Web.

Questo aumento della quantità e dell’eterogeneità delle informazioni, se nonpropriamente controllato, può provocare un ammasso di dati che genera soltantoconfusione piuttosto che fornire elementi utili, riducendo i benefici che invece si po-trebbero ricavare da tutte queste informazioni. Tuttavia, distinguere le informazionirilevanti da quelle che non lo sono è un compito tutt’altro che semplice: alcune infor-mazioni potrebbero essere trattate in maniera differente, anche per lo stesso utenteche in diverse situazioni ha bisogno di informazioni differenti.

Si parla dunque di sistemi Context-Aware, che si occupano cioè dell’acquisizionedel contesto (per esempio tramite l’utilizzo di determinati sensori), l’astrazione eil riconoscimento del contesto (per esempio per associare un determinato stimoloal contesto) e il comportamento adatto alla situazione riconosciuta (per esempiol’esecuzione di un’azione innescata dal contesto) [1]. L’utilizzo del contesto permettela realizzazione di applicazioni flessibili e personalizzate.

Una volta acquisite le informazioni nasce tuttavia l’esigenza di definire regolesu come mostrarle all’utente finale. Con la diffusione di dispositivi mobili semprepiù sofisticati si è resa maggiormente necessaria un’esperienza utente semplice chelo guidi durante le sue attività.

3

1. Introduzione

Per questo motivo ha assunto un ruolo di grande importanza l’esperienza d’usodell’utente (User Experience). Infatti se un’applicazione non è ben strutturata enon è fruibile in modo semplice dall’utente, il numero di utenti che la utilizzerannocalerà sempre di più. Secondo Gary Illyes di Google “circa il 61% degli utentiche incontrano problemi con siti e app su smartphone ne abbandonano l’utilizzovolontariamente”3. Per evitare questo problema è necessario prestare un’attenzionesempre maggiore a come viene progettato tutto il flusso di navigazione e a fornirei dati necessari per poter sfruttare al meglio l’applicazione. L’aggiunta di elementicomprensibili in modo intuitivo come mappe e foto porta l’utente a utilizzare altrearee della mente, come quella della memoria fotografica. In questo modo l’utentepuò facilmente acquisire conoscenza, utilizzando diversi dati e diverse tipologie divisualizzazione.

È proprio per cercare nuovi strumenti in grado di migliorare l’esperienza dell’u-tente nell’esplorazione delle informazioni che nasce il progetto CAMUS. CAMUS(Context-Aware Mobile mashUpS) si propone come un framework per permetterela realizzazione di mobile app che si adattino sia alle preferenze dell’utente sia allasituazione nella quale si trova. L’idea è che l’utilizzo di modelli per definire il contestoe per schematizzare la composizione dell’interfaccia grafica possa portare enormibenefici nell’interazione tra utente e applicazione. Questo paradigma permette larealizzazione di applicazioni flessibili e personalizzate dove la struttura e i contenutipossono variare in fase di esecuzione in base alle esigenze dell’utente e alla situazionenella quale si trova. Inoltre si vuole sfruttare la multimedialità messa a disposizionedei recenti dispositivi mobili per coinvolgere maggiormente l’utente e semplificare lesue attività.

Dalla sigla è possibile intuire le due anime principali che sono alla base delprogetto: i mashup e il contesto.

Per la tematica dei mashup viene preso in considerazione l’aspetto di acquisire leinformazioni da più fonti di diverso tipo. CAMUS prevede un sistema flessibile chepermette di acquisire e integrare in modo “leggero” informazioni da diverse risor-se, andando così ad aumentare la completezza delle informazioni fornite all’utente.Poichè, come detto in precedenza, bisogna fare attenzione all’utilizzo di grosse quan-tità di dati, in quanto se non opportunamente trattate e filtrate possono generaresolamente confusione e risultare così poco fruibili dall’utente, nasce l’intuizione diutilizzare la modellazione del contesto come metodo per selezionare i servizi chepossono fornire i dati più rilevanti per l’utente. Il modello del contesto mette a di-sposizione lo stato in cui si trova l’utente, le condizioni dell’ambiente che lo circondae i suoi interessi personali. Queste preziose informazioni possono essere uno stru-mento determinante per mettere ordine tra i dati e fornire così solo le informazioni

3Search Engine Land Interview to Gary Illyes of Google: http://searchengineland.com/google-may-add-mobile-user-experience-ranking-algorithm-205382

4

che sono interessanti.Nella tesi si andrà quindi ad affrontare la modellazione della situazione nella qua-

le si trova l’utente. È un’attività molto delicata, in quanto esistono una moltitudinedi parametri che possono definire una particolare situazione (contesto). È necessariofare una scelta di quali siano gli indicatori più idonei e quali invece possano esserescartati. L’obiettivo è fornire un modello che permetta di definire in maniera ade-guata e semplice il contesto, in modo da agevolare l’utente rispettando i principi diUser Experience precedentemente citati.

Certamente il problema principale riguarda l’organizzazione fisica delle informa-zioni. Visto che le applicazioni CAMUS non sono limitate a uno specifico contesto,è necessario prevedere un meccanismo che permetta di adattare la presentazione dicategorie diverse di informazioni. Come è facilmente intuibile, mostrare un elencodi film è ben diverso da mostrare un elenco di ristoranti. Un primo punto da sno-dare è quindi relativo alla creazione di uno schema flessibile per la presentazionedei dati che permetta di descrivere come organizzare e rapportare tra loro questeinformazioni sul dispositivo.

Questo schema deve inoltre essere anche in grado di raccogliere informazionidi contorno che permettano di migliorare l’esplorazione di quelle principali. Peresempio, se si sta cercando un ristorante può essere d’aiuto avere a disposizione unagalleria di foto del locale con i piatti che offre, una mappa che indichi dove si trovail ristorante o alcune informazioni sul meteo, per decidere se prenotare all’esterno oall’interno. Invece se si sta cercando un film può essere sicuramente d’aiuto avere untrailer da vedere per avere un’idea del film, oppure l’elenco dei cinema che l’hannoin programmazione.

Le operazioni di modellazione descritte sopra non sono alla portata degli uten-ti, soprattutto per quanto riguarda la modellazione del contesto o la composizionedell’interfaccia grafica. Inoltre, quando il contesto deve descrivere diverse realtà,l’insieme delle scelte possibili assume anche dimensioni notevoli; avere troppe scel-te a disposizione rende vani gli sforzi per cercare di mettere ordine nei dati, inquanto verrebbe solamente spostato il problema a un altro livello. L’utente nonconosce a fondo la struttura dei dati e non è in grado quindi di integrarli al meglioe fornire un’interfaccia completa dei servizi ausiliari. Sfruttando la letteratura suimashup, che propone metodi di sviluppo adatti all’utente finale con poche conoscen-ze tecniche, in accordo con le discipline dell’End-User Development [2] si è deciso diintrodurre la figura dell’esperto di settore. L’esperto di settore è colui che conosce afondo l’ambito di utilizzo di una CAMUS app e questa sua conoscenza può guidarela creazione dell’app finale e il supporto dell’utente nelle proprie scelte. Uno deisuoi compiti sarà quello di definire, con l’aiuto della conoscenza dell’utente finale unprofilo, in base alle sue esigenze, in modo che dalla rappresentazione del contestopossano essere eliminate le informazioni non necessarie. Inoltre avrà un ruolo di

5

1. Introduzione

designer occupandosi di comporre delle interfacce funzionali sia per la situazione siaper l’utente. In questo modo è possibile avere una varietà di composizioni adatteai diversi ambiti di utilizzo, alle preferenze dell’utente e ad altri fattori, come lageo-referenziazione.

All’esperto di settore vengono delegati compiti che riguardano maggiormentel’ambito nel quale viene utilizzata l’applicazione. Per questo motivo non è necessa-rio che sia una figura con particolari competenze informatiche. Nel framework sonoperò previste delle fasi iniziali più tecniche, che garantiscono il corretto funziona-mento della piattaforma. Queste attività, relative alle configurazioni del sistema,necessitano di competenze soprattutto per quanto riguarda il funzionamento deiservizi. Per questo motivo è necessaria la figura dell’amministratore. I suoi com-piti sono quelli di creare lo schema globale del contesto, che verrà utilizzato dagliesperti di settore per creare gli schemi personalizzati, e la descrizione dei serviziche il sistema può utilizzare per recuperare le informazioni. L’amministratore puòanche dedicarsi all’introduzione nel sistema di nuovi schemi di visualizzazione deidati utilizzabili nella fase di creazione dell’app finale.

1.1 Caso di studio: il turismo

In questa sezione introduciamo un caso di studio, che sarà utilizzato nei capitoliseguenti per esemplificare i concetti e le tecniche che saranno illustrate.

CAMUS ha come obiettivo quello di essere universale, cioè utilizzabile in ambitianche molto diversi tra loro. Come caso di studio è stato dunque necessario pensarea un ambito che consentisse di sfruttare al meglio le capacità di adattarsi alle variesituazioni nelle quali si può trovare l’utilizzatore dell’app.

È stato scelto quindi il settore turistico proprio per via della sua dinamicità.In particolare si è preso in considerazione il caso di un’agenzia di viaggi che deveproporre ai propri clienti dei pacchetti di viaggio.

L’ambito turistico calza a pennello per gli intenti di CAMUS; un viaggio inco-mincia dalla sua pianificazione: prima di partire il turista si informa sulla destina-zione, su quali hotel sono disponibili, con quali mezzi di trasporto è più convenienteraggiungere la destinazione. In questo frangente, CAMUS si propone come “sug-geritore” di esperienze di viaggio: permette all’utente di non concentrarsi sul dovevuole andare ma sul cosa vuole fare. All’utente viene data la possibilità di sceglierel’esperienza di viaggio che vuole intraprendere, per proporgli così i pacchetti checorrispondono alle sue scelte.

Le potenzialità di CAMUS non terminano una volta che il viaggiatore sceglie lasua meta: il sistema permetterà di configurare l’app che gli servirà durante il viaggioper informarsi sulle attività da svolgere, le escursioni disponibili, i ristoranti neiquali cenare, ecc. Per esempio, se un utente vuole provare un ristorante tipico della

6

1.1. Caso di studio: il turismo

zona, gli basterà aprire l’app CAMUS e selezionare che è interessato nella ricerca deiristoranti che propongono dei menù tipici del luogo. Gli verrà quindi mostrato unelenco dei ristoranti che si trovano nei suoi paraggi che rispettano i criteri di ricercadefiniti. Inoltre gli verranno fornite indicazioni su come raggiungere il ristorante,sfruttando, se specificato nella richiesta, i mezzi pubblici presenti nella destinazionescelta. Un analogo comportamento sarà a disposizione per la ricerca di attività comele visite di musei o intrattenimento serale.

Le due figure principali in questo caso di studio sono quindi: l’agente di viaggioe il turista. L’agente ha il compito di organizzare tutto il viaggio, gestire le preno-tazioni, gli spostamenti principali e i soggiorni per il viaggiatore, mentre il turistaè colui che fisicamente compie il viaggio, che può essere quindi considerato comel’utente finale.

All’agente vengono quindi demandati i compiti di personalizzazione dell’app:questa fase avviene quando il cliente si presenta nell’agenzia di viaggio. A que-st’ultimo vengono prima di tutto fatte alcune domande per conoscere il suo profiloe i suoi gusti, in modo da adattare le scelte che gli verranno mostrate dall’app. Inquesto modo è possibile evitare che al cliente vengano proposte troppe scelte chenon siano di suo interesse. Inoltre vengono fissate alcune opzioni che tendono a noncambiare nel corso del viaggio; per esempio, se l’utente viaggia con un animale do-mestico, questa scelta sarà considerata durante tutto il viaggio, e l’utente non dovràspecificarla per ogni nuova ricerca di informazioni.

L’ulteriore compito che può svolgere l’agente è quello di personalizzare l’aspettografico dell’app qualora ritenga che sia necessario. Con CAMUS vengono propostialcuni template predefiniti per ogni categoria di informazioni e viene lasciata liberascelta all’agente se utilizzarli così come sono o modificarli. Per esempio può decidereche alcuni elementi del template siano rimossi o aggiungerne tra quelli disponibiliall’interno dell’applicazione, a seconda della disponibilità dei termini presenti nellacategoria di informazioni, oppure può modificare lo stile dell’elemento grafico.

Come si può notare da questo breve esempio, l’utilizzo di CAMUS in un’agenziaviaggi permette di fornire un servizio più coinvolgente ai propri clienti. La realiz-zazione di app personalizzate permette al turista di effettuare scelte migliori e diproprio interesse. Inoltre estende la capacità dell’agenzia di fornire un’assistenzaal proprio cliente anche durante il viaggio: si può affermare che un’app CAMUSassume il ruolo di assistente di viaggio e guida il turista durante tutte le fasi dellasua esperienza di viaggio.

7

1. Introduzione

1.2 Struttura della tesi

Viene ora fornita una panoramica sulla struttura di questa tesi:

• Nel Capitolo 2, dopo aver introdotto i modelli che saranno utilizzati nel restodella tesi, si discute la letteratura sull’argomento e le tecnologie impiegate perlo sviluppo del prototipo

• Nel Capitolo 3 si entra nei dettagli del progetto CAMUS andando a fornire uncontesto più ampio di quello appena descritto e mettendo in risalto gli obiettiviche si vogliono raggiungere. In seguito saranno analizzate nel dettaglio lelogiche alla base del framework

• Nel Capitolo 4 viene introdotta l’architettura della piattaforma. Verrà inoltrefornito uno schema del flusso di esecuzione delle attività ed esposto un casod’uso reale per chiarire meglio la sequenza delle attività

• Nei Capitoli 5 e 6 viene analizzata nel dettaglio l’implementazione rispetti-vamente lato backend e mobile app. Si analizzano i componenti che forma-no il sistema e le scelte tecnologiche che hanno portato alla realizzazione delprototipo

• Nel Capitolo 7 si analizzano le prestazioni della soluzione implementata, simu-lando alcuni casi d’uso simili alle condizioni di regime della piattaforma

• Nel Capitolo 8 si discuteranno le conclusioni del lavoro relative al progetto ealcuni spunti per futuri miglioramenti al framework

8

Capitolo 2

Preliminari

In questo capitolo vengono esposti i concetti alla base del progetto CAMUS,per fornire al lettore un quadro generale delle tematiche che verranno affrontate neisuccessivi capitoli. Vengono inizialmente introdotti i concetti preliminari che sononecessari per la comprensione delle tematiche affrontate nella tesi. In particolare sivogliono introdurre i concetti relativi alla Context-Awareness e ai Mashup, in quantocomponenti fondamentali del framework. Successivamente verranno presentate eanalizzate le soluzioni che sono già disponibili in letteratura per risolvere problemisimili a CAMUS. Infine il capitolo fornirà una panoramica sulle principali tecnologiee i framework che sono stati adoperati per lo sviluppo della piattaforma. Sono stateutilizzate sia tecnologie più consolidate sia tecnologie di più recente introduzione.Questa sezione si soffermerà maggiormente sulla descrizione di queste ultime, inquanto meno conosciute data la loro gioventù.

2.1 Concetti Preliminari

Questa sezione fornisce al lettore una panoramica delle nozioni e dei modelliche verranno utilizzati nello svolgimento della tesi. Viene inizialmente discusso ilconcetto di Context-Awareness e viene introdotto il modello del contesto che è statoselezionato per CAMUS. In seguito verrà definito cosa si intende per Mashup e levarie tipologie disponibili, soffermandosi in particolare su quella che copre il mondomobile. Infine verrà fornita una descrizione del funzionamento dei servizi web esaranno analizzate le tipologie REST e SOAP, in quante le più diffuse

2.1.1 Context-Awareness

Il concetto di dipendenza dal contesto viene citato in diverse aree di ricerca, comela filosofia, la psicologia e l’informatica. Il contesto gioca spesso un ruolo importantenel definire un comportamento o l’interpretazione dell’ambiente; dei cambiamentinel contesto possono cambiare la percezione del momento che si sta vivendo. La

9

2. Preliminari

parola “contesto” deriva dal verbo latino contexere, che significa intrecciare. Vienedefinito come “il complesso delle circostanze e delle situazioni nelle quali un fatto oun fenomeno si verificano”1.

In informatica il concetto di contesto è riferito all’idea che i computer possanoavere una percezione dell’ambiente e che riescano dunque a modificare il loro compor-tamento in base alla situazione. I dispositivi devono dunque acquisire informazionirelative all’ambiente in cui operano e tramite determinate regole, che possono esseresia staticamente fissate che dinamicamente dedotte tramite algoritmi di intelligenzaartificiale, devono reagire di conseguenza, utilizzando la strategia più idonea allasituazione corrente. Il termine Context-Awareness è stato introdotto per la primavolta in ambito informatico a opera di Schilit [3] [4].

Agli albori il contesto veniva inteso solamente come la posizione nella quale sitrova l’utente, come discusso da Dey in [5]; negli ultimi anni invece si è iniziatoa pensare al contesto non solo come uno stato, bensì come un processo più vastoche coinvolge diversi aspetti relativi all’utente. Sono stati dunque ideati modelli dicontesto sofisticati e generali, in modo che possano adattarsi a diverse situazionid’utilizzo [6] [7].

In particolare il contesto viene utilizzato per realizzare applicazioni che sianoin grado di a) adattare l’interfaccia grafica, b) filtrare l’insieme dei dati che sonorealmente rilevanti, c) migliorare la precisione dei dati raccolti, d) scoprire servizi,e) predire alcune scelte dell’utente o f) realizzare ambienti intelligenti.

Per esempio, un’app mobile fornita ai visitatori di un museo di storia natura-le può sfruttare il contesto per a) adattare la struttura e l’aspetto dell’interfacciagrafica in base alle caratteristiche del visitatore, sia esso una persona con problemidi vista oppure un bambino; b) mostrare informazioni diverse in base agli interessidel visitatore (es.: geologia, paleontologia, ecc.) oppure in base alla stanza in cuisi trova; c) imparare dalle precedenti scelte effettuate dall’utente quali potrannoessere le informazioni di maggiore gradimento; d) proporre al visitatore determinatiservizi, come l’acquisto dei biglietti per una mostra temporanea o la prenotazione diun posto nello spettacolo sui dinosauri che sta per incominciare nella sala adiacente;e) conoscere la posizione del visitatore in base ai sensori che monitorano l’ambiente;f) fornire dei contenuti attivi al visitatore su cosa accade in un particolare ambiente.

Per il progetto CAMUS sono state identificate le seguenti caratteristiche che unmodello di contesto deve essere in grado di soddisfare.

• Deve permettere di rappresentare informazioni predefinite e parametriche, doveper predefinite si intendono le caratteristiche del contesto che vengono speci-ficate a priori, mentre le caratteristiche parametriche corrispondono ai datiche devono essere specificati dall’utente in quanto non è possibile (e conve-

1Dizionario Garzanti: http://www.garzantilinguistica.it/ricerca/?q=contesto

10

2.1. Concetti Preliminari

niente) enumerarli. Un esempio di informazione predefinita è descritta dalla“Tipologia di Viaggio”, che può assumere i valori “Avventuroso”, “Rilassan-te”, “Lavoro”, ecc.; un esempio di informazione parametrica è la località, cheè caratterizzata dalle innumerevoli posizioni in cui si può trovare l’utente

• Deve consentire una rappresentazione gerarchica delle informazioni sul conte-sto. Per esempio, Mezzi di trasporto pubblici si può specializzare in bus, treno,car sharing

• Deve essere facilmente personalizzabile e adattabile a diversi ambiti di utilizzo.Per esempio, deve essere in grado di descrivere i contesti che può assumereun’app per la gestione dei viaggi o del personale, come per esempio il ruoloche ricopre un dipendente e, nel caso in cui sia necessario recarsi da un cliente,i dati relativi ai clienti nella zona in cui si trova

• Deve prestarsi a una rappresentazione visuale semplice e chiara, in modo chesia utilizzabile anche da persone non esperte di informatica

Tra i diversi modelli a disposizione, si è ritenuto che il Context Dimension Tree(CDT) [8] sia il modello che rispetti maggiormente le richieste precedentementeelencate. Nella seguente sezione verrà quindi presentato nel dettaglio questo modello,che sfrutta una struttura ad albero per descrivere la situazione nel quale si troval’utente.

2.1.1.1 Context Dimension Tree

In questa sezione viene presentato nel dettaglio il Context Dimension Tree, inquanto è il modello di rappresentazione del contesto che è stato selezionato perl’utilizzo nel progetto CAMUS. Nel Context Dimension Tree il contesto viene rap-presentato come un albero T = <N,E, r>, che descrive i possibili contesti nei qualici si può trovare in una data situazione. È formato da una radice r, un insieme dinodi N, che vengono partizionati nei sottoinsiemi dei nodi dimensione ND, coloratidi nero, e nei nodi concetto NC , colorati di bianco, che rappresentano i possibilivalori che possono assumere le dimensioni, e dall’insieme dei collegamenti tra i nodiE. La radice r è un nodo concetto, in quanto rappresenta il contesto più generalepossibile, che corrisponde dunque all’intero dataset.

Le dimensioni che sono dirette discendenti della radice vengono chiamate dimen-sioni principali, perché definiscono le differenti caratteristiche dell’utente e del con-testo nel quale agiscono. Nell’esempio in Figura 2.1, relativo al caso di un’agenziaimmobiliare, le dimensioni principali sono il ruolo dell’utente, l’interest topic, lasituazione, il tempo e il luogo in cui si trova. Inoltre, ogni valore può essere ulterior-mente specializzato tramite sottodimensioni, che a loro volta formano un sottoalbe-

11

2. Preliminari

Figura 2.1: Context Dimension Tree

ro. Per esempio, l’interest topic “estate” può essere analizzato in base al prezzo, allacategoria, alla tipologia di proprietà e al numero di camere.

Ogni nodo del CDT è caratterizzato dalla sua tipologia, che può essere dimen-sione o concetto, e dalla sua etichetta; può essere identificato univocamente tramitel’unico percorso che lo collega fino alla radice. Senza perdita di generalità, vieneadottata l’ipotesi che ogni etichetta sia unica in un albero, quindi ogni nodo puòessere identificato semplicemente dalla sua etichetta. I collegamenti tra i vari nodinon vengono invece etichettati.

L’alternanza tra nodi dimensione e concetto fa sì che vengano create delle ge-nerazioni, ognuna delle quali sarà formata da nodi dello stesso colore, e ogni coloreverrà alternato man mano che si prosegue discendendo nell’albero: dunque ogni nododimensione può avere come figli solo nodi di tipo concetto e viceversa.

È inoltre possibile associare uno o più parametri ai nodi concetto e ai nodi dimen-sione che sono foglie dell’albero. Ogni parametro permette di raffinare ulteriormentela selezione dei dati e selezionare un sottoinsieme del dataset particolare. Per esem-pio, il parametro “val” associato alla dimensione n_bedrooms permette di filtrare leproprietà in base al numero di stanze.

Per ogni nodo dimensione è possibile selezionare al massimo un nodo concettotra i suoi figli oppure, se non possiede alcun nodo figlio, deve essere selezionatoobbligatoriamente uno e un solo parametro. L’utilizzo dei parametri aumenta ilpotere espressivo del modello, in quanto lo rende più semplice per l’utilizzo da partedel designer. Si è resa necessaria l’introduzione dei parametri in quanto non tutti iconcetti espressi da una dimensione possono essere enumerati.

Ora che è stato definito il modello è necessario spiegare come viene rappresentatouno specifico contesto. Dato un Context Dimension Tree T = <N,E, r>, un contestoè definito dalla grammatica in Figura 2.2 con assioma context.

12

2.1. Concetti Preliminari

C =

<context>← <context_element> | <context_element> ∧<context>

<context_element>← dim_name : <value_item> | dim_name (<parameter>)

<value_item>← value | value (<parameters>)

<parameters>← <parameters> ∧<parameter> | <parameter>

<parameter>← param_name : param_value

Figura 2.2: Grammatica del Context Dimension Tree

Un contesto è formato dalla congiunzione tra uno o più elementi del contesto.Ogni elemento del contesto è formato dal nome della dimensione seguita da uno deivalori scelto tra i nodi che sono suoi figli diretti, oppure dal valore che assume l’unicoparametro a essa associato, nel caso in cui la dimensione è una foglia dell’albero.Ogni valore può essere a sua volta raffinato aggiungendo il/i parametro/i a essoassociati.

Non è necessario selezionare per forza tutte le dimensioni presenti nell’albero:non selezionare alcun valore relativo a una dimensione equivale a essere indifferentirispetto quella particolare situazione. Ogni dimensione che non viene selezionatanon influirà nel processo di acquisizione e di ritaglio dei dati in base al contesto.

C = role : manager ($manager_id : ‘‘2”) ∧interest_topic : agency ($a_id : ‘‘5”)∧situation : in_office

Figura 2.3: Esempio di contesto

In Figura 2.3 viene mostrato un esempio che rappresenta il contesto in cui ilmanager con identificativo “2” è interessato alle proprietà gestite dall’agenzia conidentificativo “5” e si trova nel suo ufficio.

Infine, dopo aver discusso del modello e di come vengono rappresentati i varicontesti, resta da definire come è possibile acquisire i dati che sono pertinenti a undeterminato contesto. Come evidenziato in [9], esistono due strategie principali perdefinire le associazioni tra i contesti e la porzione di dati rilevanti per i vari contesti,chiamate configuration-based mapping e value-based mapping.

La strategia configuration-based mapping prevede che il designer definisca perogni contesto possibile la relativa porzione del dataset da mostrare. Questa opera-zione può essere effettuata definendo delle viste nel linguaggio specifico del databaseadottato. In Figura 2.4 viene mostrato un esempio per il contesto nel quale unmanager è interessato alle informazioni relative le sue agenzie. In questo caso ildesigner specifica delle viste in linguaggio SQL relative al contesto specifico, met-

13

2. Preliminari

Figura 2.4: Configuration-based mapping (Fonte: “And what can context do fordata?” [9], 2009)

tendo in evidenza i dati del personale che lavora nelle agenzie gestite dal manager,i contratti di affitto e vendita e infine le informazioni relative alle proprietà.

Questa strategia ha il vantaggio di generare delle viste molto precise rispetto alcontesto che vogliono rappresentare, ma ha l’enorme svantaggio che deve essere ripe-tuta per ognuno dei possibili contesti che, com’è facilmente intuibile, possono esserein quantità molto elevata. Inoltre, se in futuro dovesse essere aggiunta un’ulterioredimensione, sarebbe necessario modificare le varie associazioni per includere la nuovadimensione.

La strategia value-based mapping permette di superare i limiti evidenziati per lastrategia precedente. Questa strategia prevede che il designer definisca le viste par-ziali relative a un particolare elemento del contesto, indipendentemente dagli altri.Quindi, una volta selezionato un contesto, un algoritmo si occuperà di combinareassieme le varie viste parziali definite dai singoli elementi per formare la vista globaleadatta allo specifico contesto. La Figura 2.5 mostra come il contesto dell’esempioprecedente viene mappato tramite questa strategia. Le linee tratteggiate mostranole viste parziali che vengono associate ai vari elementi del contesto, mentre nel ri-quadro in basso viene mostrata la vista globale generata dalla combinazione delleviste parziali. L’algoritmo di composizione delle view parziali è basato sull’utilizzodi diverse policy e operatori di composizione, tra i quali i più utilizzati sono dou-ble union, double intersection e double difference [10], operatori basati sull’algebrarelazionale.

14

2.1. Concetti Preliminari

Figura 2.5: Value-based mapping (Fonte: “And what can context do for data?” [9],2009)

2.1.2 Mashup

In questa sezione vengono introdotti i mashup, la seconda anima del sistemaCAMUS, e il loro ruolo nell’applicazione finale. La parola mashup, che significaletteralmente miscuglio o combinazione, è un termine che può essere adottato in di-versi ambiti. Per esempio, in campo musicale, indicano due o più brani le cui tracceaudio vengono tagliate e sovrapposte creando un nuovo brano. Un altro esempio èl’ambito dei contenuti video, dove due o più filmati sono montati in sequenza perottenere un video dal significato diverso da quelli originali. In informatica questotermine assume un significato simile, perché i mashup sono applicazioni che utiliz-zano contenuti e funzioni provenienti da due o più sorgenti [11]. Inizialmente lacomposizione era limitata all’utilizzo per la realizzazione rapida di siti web con con-tenuti di elevata dinamicità, vista la possibilità di integrare varie informazioni inmodo molto intuitivo.

Molto diffuse in questa prima fase sono state le applicazioni che offrivano integra-zione con mappe geografiche, come HousingMaps 2, che combinava le informazionitra Google Maps, per quanto riguarda le mappe, e Craiglist, un portale che ospitaannunci di diversa tipologia (es.: lavoro, incontri, ecc.).

2Housing Maps: http://www.housingmaps.com

15

2. Preliminari

Figura 2.6: Potholes Service

L’esempio in Figura 2.6 mostra un simpatico esempio di mashup che posizionanella mappa le buche stradali segnalate dagli utenti presenti a Montreal in Cana-da, fornendo anche la possibilità di calcolare un itinerario per evitarle o almenoincontrarne il meno possibile3.

Con lo sviluppo dei social network e delle piattaforme di condivisione di contenu-ti multimediali, i mashup hanno assunto grande importanza perché è stato possibilecreare nuove applicazioni utilizzando i metadati associati ai contenuti, arricchendodi informazioni il contenuto originale. La diffusione dei mashup è presente anche indomini più critici, soprattutto per la facilità di creazione e la possibilità di essereutilizzati anche da utenti non esperti in ambito IT, di cui un esempio possono esseregli enterprise mashups. La crescita esponenziale della quantità di informazioni pre-sente nel web, con i Big Data e il moltiplicarsi dei Web Service, ha portato i mashupa elemento fondamentale nella creazione delle applicazioni, per via della possibilitàdi filtrare i dati necessari all’utente finale e quindi rendere la visione di una partesignificativa della moltitudine di informazioni provenienti dai servizi.

2.1.2.1 Classificazione dei mashup

I mashup possono essere distinti in diverse tipologie, a prescindere dalla piat-taforma sulla quale vengono utilizzati. In questo caso, la classificazione è basata

3Articolo con altri esempi: http://www.pcworld.com/article/252243/top_10_cool_and_useful_google_maps_mashups.html

16

2.1. Concetti Preliminari

soprattutto alla metodologia con la quale vengono integrate le diverse risorse checompongono i mashup. Vengono definite tre macro famiglie:

1. Consumer Mashups Sono i mashup che combinano elementi visuali e dati dadiverse fonti. Un ottimo esempio può essere considerato Housing Maps citatonella Sezione 2.1.2, dove vengono integrati i dati provenienti da Craigslist emostrati sulla mappa creata sfruttando le API di Google Maps

2. Data Mashups Sono mashup che combinano più risorse di dati in una singolaapplicazione. Questa tipologia di mashup viene invece sfruttata per realizzaremolte applicazioni, anche in settori di utilizzo diversi tra loro. Nell’ambito deiviaggi, un esempio viene fornito da Kayak4, che è un sito di ricerca dei viaggiche acquisisce dati da oltre 100 siti diversi. Inoltre non vende direttamentei contenuti ai fornitori, ma si propone come un portale attraverso il quale iclienti possono essere dirottati verso le agenzie viaggi per completare la pro-cedura di acquisto o specificare alcune esigenze particolari. Un altro ambitocompletamente differente riguarda Facile.it5, che permette di confrontare di-verse offerte per quanto riguarda diversi settori (es.: assicurazioni, mutui, lineetelefoniche, ecc.), permettendo di visualizzarli in unico portale e valutare laproposta migliore per le esigenze dell’utente

3. Business Mashups I business mashups sono utili per quanto riguarda l’inte-grazione di servizi business, permettendo di sviluppare più facilmente serviziintegrati e, di conseguenza, semplificare l’utilizzo all’utente attraverso inter-facce web. Differiscono dai consumer mashup a livello di integrazione con isistemi business, perché sono necessarie funzionalità aggiuntive, riguardantisicurezza, controllo di accesso, governance e complessità degli editor utilizza-ti. Un’altra differenza è data dall’utilizzo crescente di business mashups neimodelli Software as a Service (SaaS), dove un produttore sviluppa e gestisceun’applicazione web che mette a disposizione dei propri clienti via internet,come servizio cloud.

2.1.2.2 Mobile Mashup

In questi ultimi anni si è avuto un incremento esponenziale del numero di disposi-tivi mobili, al punto che il loro numero ha superato quello dei personal computer [12].Come spiegato nel Global Internet Report di Internet Society6, lo sviluppo di nuoveapplicazioni e sistemi operativi di facile utilizzo, oltre all’incremento della velocità

4Kayak: http://www.kayak.com5Facile.it: http://www.facile.it6Global Internet Report 2015: http://www.internetsociety.org/globalinternetreport/

assets/download/IS_web.pdf

17

2. Preliminari

delle reti mobili (3G e 4G), ha portato a una diffusione capillare dei dispositivi mo-bili, oltre alla possibilità di integrare nuovi aspetti finora non utilizzabili facilmentetramite i PC. Un chiaro esempio è dato dalla possibilità di poter sfruttare la po-sizione corrente del dispositivo, oppure gli altoparlanti o l’accelerometro. Questamaggiore integrazione con le esigenze dell’utente ha dato una spinta nella ricerca dicome i mashup possano trarre vantaggio da queste nuove opportunità.

I mobile mashups sono l’applicazione dei mashup web ai mobile devices, pensaticome applicazioni native che integrano dati provenienti da servizi differenti [13].Spesso i mashup di questo tipo sono costruiti utilizzando un’applicazione di VisualMapping, dove in modo intuitivo è possibile associare i servizi ai diversi campi davisualizzare nello schermo del device. In CAMUS è stata adottata la metodologiadescritta in [2], che pone al centro l’interfaccia utente per integrare i dati: durantela creazione delle view dell’applicazione è possibile vedere in modo immediato ilrisultato del Visual Mapping. In questo approccio si sono volute seguire le lineedettate dalla filosofia Model-Driven Engineering (MDE) [14], che permettono digeneralizzare la creazione degli schemi dell’applicazione, e delegare l’interpretazionedi tali schemi nelle differenti piattaforme. Così è possibile creare applicazioni crossplatform, che, pur basandosi su uno schema comune, possono essere istanziate sudiversi sistemi operativi.

2.1.2.3 Funzionamento generale

Generalmente le piattaforme di sviluppo dei mashup prevedono due differentipartecipanti, spesso separati fisicamente:

1. Content Providers Questi sono i fornitori dei contenuti che verranno uti-lizzati nell’applicazione di mashup, spesso dei più disparati generi e tipi. Lerisorse dalle quali è possibile ottenere contenuti sono:

• API (Application Programming Interface) Vengono fornite da alcuni pro-vider di contenuti (es. Google, Facebook, Twitter, Amazon). Una APIpermette di creare un mashup basato sul web fornendo un punto di ac-cesso a una funzionalità o a un contenuto (es.: Google Maps). Le APIpossono essere di due tipi:

(a) Proprietarie Richiedono la stipulazione di un contratto di licenza checomprende spesso il pagamento di una quota per poter usufruire delservizio

(b) Free Non richiedono il pagamento di nessuna licenza; tuttavia, inalcuni casi, possono esserci limitazioni nel numero di chiamate chel’applicazione finale può fare verso il provider

18

2.1. Concetti Preliminari

• Information Feed Gli Information Feed sono informazioni strutturatesecondo specifiche prestabilite, spesso utilizzate per distribuire notizie intempo reale. Un esempio sono i news feed in formato RSS utilizzati dalleagenzie di stampa come Reuters7 o Ansa8 per inviare le notizie alle altretestate giornalistiche

• Documenti HTML, XML/JSON I formati HTML, XML e JSONsono standard per il trasferimento di dati attraverso Internet. Dopo averlianalizzati, gli utenti possono creare dei mashup a partire dai dati generatidai siti web. Questo tipo di operazione è detta scraping e, a differenzadi API e Information Feed, richiede una conoscenza approfondita deilinguaggi di programmazione. Va aggiunto che a ogni variazione nelloschema dei dati nel sito web originale, il codice scritto per lo scrapingpuò non essere più valido

2. Web Mashup Il Web Mashup è l’applicazione finale resa disponibile onli-ne. Questa viene spesso generata utilizzando codice di tipo client-side, cioèeseguito sul client, (es.: JavaScript), con tecnologie di caricamento dei datidinamiche come Ajax, che permette di evitare di ricaricare l’intera pagina seuna parte di essa subisce delle modifiche. Non è tuttavia escluso l’utilizzo dicodice server-side

Non è detto che le informazioni grezze ottenute direttamente dai servizi esternisiano già pronte per essere visualizzate nel mashup finale. Esse necessitano di tra-sformazioni per poter migliorare e integrare i diversi dati ricevuti. Come espostoin [15] queste operazioni possono essere definite mediante template visuali, i qualioffrono una rappresentazione dei dati come saranno mostrati nell’applicazione fina-le. Nel caso di applicazioni sui contenuti si hanno generalmente due schermate: unamostra tutti i risultati provenienti dai diversi servizi, l’altra invece mostra i dettaglidell’elemento selezionato (Figura 2.7). Le operazioni sui dati da svolgere sono due:

1. Union L’operazione di union ha lo scopo di definire l’unione di tutti gli ele-menti che provengono dai diversi servizi, cercando di evitare ridondanze equindi di fondere le istanze che si riferiscono a una stessa entità

2. Merge L’operazione di merge permette di mostrare tutti i dettagli di unaistanza selezionata nelle viste di unione. In questo modo i dati, provenientida più servizi ma relativi all’entità selezionata, vengono mostrati nella stessaschermata. Questa operazione è eseguita durante la composizione del mashup,associando gli attributi forniti dai vari servizi a campi visuali di un template

7Reuters: http://it.reuters.com/8Ansa: http://www.ansa.it/

19

2. Preliminari

Figura 2.7: Esempio di merge e union (Fonte: “MobiMash: una piattaforma per losviluppo di mobile mashup” [15], 2011)

2.1.3 Web Services

Secondo la definizione formale fornita dal Consorzio W3C9 “un Web Service èun sistema software creato allo scopo di permettere la comunicazione tra macchineattraverso una rete. È composto da un’interfaccia di programmazione, descritta inun linguaggio interpretabile dalle macchine (WSDL in particolare). [...]” [16]. Inquesta definizione viene citato l’utilizzo del protocollo SOAP: in realtà, qualche annopiù tardi, la definizione è stata estesa [17], includendo nell’elenco:

• REST Web Services, il cui obiettivo principale è la manipolazione di risorseutilizzando operazioni che non necessitano di mantenere uno stato

• Servizi Web Arbitrari, dove è possibile esporre a piacimento un insieme dioperazioni

Il motivo principale che ha spinto verso questa scelta è da ricercare nella defini-zione stessa di web service: l’obiettivo principale è quello di permettere lo scambiodi informazioni tra macchine, favorendo l’interoperabilità tra sistemi e linguaggi diprogrammazione differenti. La maggior parte dei servizi utilizza il protocollo HTTPcome livello di trasporto: questa scelta ha l’enorme vantaggio di poter sfruttarelo stesso protocollo già utilizzato per le comunicazioni via internet, così da ridurrei costi di gestione necessari per la messa in opera di un diverso protocollo. Nelcorso del tempo sono nate diverse tipologie di servizi: alcuni, come SOAP, for-niscono una struttura standardizzata da seguire per l’implementazione dei servizi

9Consorzio W3C: https://www.w3.org/

20

2.1. Concetti Preliminari

compatibili mentre altri, come REST, forniscono delle linee guida sulla metodologiada seguire per l’implementazione del servizio, ma non sono dipendenti da nessu-na tecnologia in particolare. La creazione di servizi che adempiono a uno specificocompito ha favorito un ulteriore aspetto: la composizione. È possibile creare deiservizi che ne sfruttano contemporaneamente diversi al fine di realizzare un processopiù complesso [18]. Recentemente questo concetto è stato ulteriormente esteso conla realizzazione dei mashup [19] che permettono di combinare assieme informazioniprovenienti da diverse fonti dinamicamente, in modo da fornire un’esperienza utentemigliore.

Di seguito vengono analizzate alcune tra le tecnologie e paradigmi più utilizzatiper la creazione di servizi, tra cui SOAP e REST.

2.1.3.1 SOAP

È l’acronimo di Simple Object Access Protocol e fornisce un framework per loscambio di messaggi. Utilizza come formato di risposta XML e nella maggior partedei casi si appoggia al protocollo HTTP come livello di trasporto. Vengono scambiatedelle buste, che contengono le informazioni su come interrogare il servizio e come sonorappresentate le risposte. L’architettura SOAP si distingue per tre caratteristicheprincipali:

1. Estensibilità Le funzionalità di base possono essere ampliate attraverso l’u-tilizzo di estensioni

2. Neutralità Non dipende da nessun protocollo di comunicazione in particolare.Quello più utilizzato è HTTP, ma esistono delle implementazioni per SMTP,TCP, UDP o JMS per citarne alcuni

3. Indipendenza Può essere utilizzato da diversi linguaggi di programmazione

In seguito, SOAP è stato utilizzato come base per altre tecnologie legate ai webservices, come il Web Services Description Language (WSDL), che è un linguaggio didescrizione delle funzionalità fornite dal servizio, e l’Universal Description Discoveryand Integration (UDDI), che è un registro dove è possibile ricercare i servizi.

2.1.3.2 REST

È l’acronimo di REpresentational State Transfer ed è uno stile architetturale chedefinisce determinati vincoli di comportamento per componenti, connettori e datiche compongono un sistema distribuito ipermediale. REST è prima di tutto un para-digma: non vengono infatti menzionati nè i dettagli relativi all’implementazione deicomponenti nè i protocolli da utilizzare proprio per concentrarsi sul ruolo dei com-ponenti, sulle loro interazioni e come interpretare le informazioni. Il termine REpre-sentational State Transfer è stato utilizzato per la prima volta nella tesi di dottorato

21

2. Preliminari

di Roy Fielding [20]. REST viene largamente utilizzato per descrivere i servizi web,in modo tale da non generare contraddizioni durante l’implementazione. I sistemiche rispettano i principi REST vengono chiamati RESTful. Nella maggior parte deicasi, i sistemi RESTful comunicano attraverso i verbi standard del protocollo HTTP(GET, POST, PUT, DELETE, ecc.). Utilizza le web resources come interfaccia percomunicare con i sistemi esterni, identificate tramite un Uniform Resource Identifier(URI). L’applicazione delle linee guida definite dall’architettura permette di ottenerei seguenti vantaggi: performance, scalabilità, semplicità, manutenibilità, visibilità,portabilità e affidabilità.

I vincoli definiti dall’architettura sono:

• Client-server C’è una separazione delle attività che devono essere eseguite sulclient e sul server. Per esempio, i client non devono occuparsi della memoriz-zazione dei dati, che rimane interna al server, in modo da favorire la portabilitàdel codice del client. Il server invece non deve preoccuparsi dell’interfaccia edello stato dell’utente, in modo da rendere l’implementazione del server piùsemplice e scalabile. Il client e il server possono essere sostituiti e sviluppatiseparatamente a patto che le interfacce tra di loro rimangono immutate

• Stateless Lo stato non deve essere assolutamente salvato sul server. Ognirichieste che proviene dal client deve contenere tutte le informazioni necessariealla sua esecuzione. Sarà compito del client mantenere memorizzato lo statocorrente. Lo stato della sessione può però essere trasferito dal server verso unulteriore servizio di memorizzazione, per esempio un database, per un periododi tempo limitato. Al client viene affidato il compito di decidere quando èpronto a passare a un nuovo stato

• Cacheable Sia il client sia il server possono effettuare caching delle risposte.Le risposte utilizzano appositi parametri per definire se possono essere salvatein cache o meno, in modo da limitare le situazioni nelle quali il client utilizzainformazioni non corrette o non più valide. Implementare un ottimo sistemadi cache permette di ridurre il numero di interazioni tra il client e il server,migliorando la scalabilità e le performance del sistema

• Layered system Un client non può specificare se è connesso direttamenteal server di più basso livello oppure a un server intermediario. L’utilizzo diserver intermediari permette di migliorare la scalabilità del sistema, tramiteload balancer e cache distribuite. Possono inoltre fornire ulteriori misure disicurezza

• Uniform interface L’utilizzo delle uniform interface permette di semplifi-care e disaccoppiare i vari componenti dell’architettura, rendendo possibile lo

22

2.1. Concetti Preliminari

sviluppo indipendente delle varie parti del sistema. I quattro vincoli riguardole uniform interface sono:

1. Identificazione delle risorse Le singole risorse vengono identificatenella richiesta tramite, per esempio, un URI. Le risorse sono concettual-mente separate dalle rappresentazioni che vengono inviate al client. Peresempio, un server può inviare dati acquisiti dal database sotto forma difile HTML, XML o JSON, che sono diversi dalla rappresentazione internadel server

2. Manipolazione delle risorse tramite le rappresentazioni Ogni rap-presentazione di una risorsa che viene inviata al client deve conteneretutte le informazioni che permettano la modifica o l’eliminazione dellarisorsa

3. Messaggi autoesplicativi Ogni messaggio deve contenere informazionisu come trattare l’informazioni che porta con sè, tramite per esempio imedia type

4. Sfruttamento dell’hypermedia (HATEOAS) I client possono effet-tuare delle azioni che vengono dinamicamente messe a disposizione dalserver tramite hypermedia (es.: link). A eccezione dello stato iniziale, ilclient conosce le attività che possono essere eseguite a partire da una datarappresentazione solamente tra quelle che espone

Applicando i principi REST alle API dei servizi web si ottengono quelle chevengono definite RESTful API. Le RESTful API che sfruttano il protocollo HTTPsono definite tramite le seguenti caratteristiche:

• Possiedono un URI di base

• Definiscono un media type, che indica il formato della risposta, che nelleimplementazioni più comuni è JSON

• Utilizzano i verbi standard del protocollo HTTP (es.: OPTIONS, GET, PUT,POST e DELETE)

• Mettono a disposizione dei link come referenza per passare alle risorse correlate

• Utilizzano dei link come referenza dello stato

Solitamente a una URI viene associata una funzione diversa in base al verbo conla quale viene chiamata, in modo da distinguere l’operazione che si vuole eseguiresull’elemento o collezione. Per esempio, eseguire una “GET” su di un’elementopermette di recuperarne le informazioni mentre eseguire una “PUT” crea un nuovoelemento.

23

2. Preliminari

2.2 Stato dell’arte

In questa sezione vengono presentati alcuni strumenti già esistenti per quantoriguarda l’utilizzo dei mashup, quindi con l’integrazione e la fruizione dei servizi, ealcuni esempi di applicazioni che si adattano al contesto dell’utente.

Swagger

Swagger 10 è uno dei servizi più famosi per la definizione di interfacce REST peri servizi. Lo scopo di Swagger è di definire un’interfaccia standard e indipendentedal linguaggio utilizzato per le diverse API al fine di permettere la scoperta e la com-prensione delle risorse di un servizio, senza accedere ai suoi parametri tecnici (es.:codice sorgente, documentazione o ispezione del traffico di rete). Una volta definiti iservizi via Swagger, un consumatore può interagire con il servizio remoto implemen-tando una minima parte di logica. Swagger è quindi, tecnicamente parlando, unaspecifica formale supportata da un grande ecosistema di strumenti aggiuntivi, checomprende interfacce utente frontend, librerie di codice a basso livello e soluzionicommerciali per gestire le API. Per poter descrivere la propria API con Swagger cisono diversi approcci disponibili:

Figura 2.8: Esempio Swagger Editor

• Top-down L’approccio top-down considera per prima la definizione del servi-zio che si vuole avere come output e successivamente genera l’applicazione. Perla prima operazione lo strumento fornito è lo Swagger Editor (Figura 2.8), chepermette la definizione del nuovo servizio, mentre per la seconda operazionelo strumento utilizzato è Swagger Codegen

10Swagger: http://swagger.io

24

2.2. Stato dell’arte

• Bottom-up Nel caso in cui si ha una già API REST esistente e si vuolecreare una nuova definizione si usa un approccio bottom-up. È possibile crearela definizione manualmente utilizzando lo Swagger Editor oppure, nel caso siutilizzi uno dei framework supportati (es.: JAX-RS, Node.js, ecc.), è possibilegenerare in modo automatico la definizione Swagger

Nel caso in cui si utilizzi una API e se ne voglia integrare un’altra che già pos-siede una definizione Swagger, si può utilizzare la versione online della Swagger UIper esplorarla e successivamente lo Swagger Codegen per generare la libreria clientdesiderata.

Figura 2.9: Esempio API risultante Swagger

Nell’esempio in Figura 2.9 è presente una descrizione del servizio che è possibilegenerare con Swagger. In questo caso si tratta di un interfaccia di tipo REST conle operazioni CRUD, spiegate nel dettaglio in 2.1.3 e gli endpoint che è possibileinvocare.

25

2. Preliminari

Appery.io

Appery.io è uno strumento basato sul cloud che offre la possibilità di velocizzarelo sviluppo di applicazioni mobile e responsive. Ha due funzionalità principali: lacostruzione di applicazioni mobile in maniera rapida e l’offerta di un servizio diMobile Backend as a Service (MBaaS). Con il servizio di App Builder, è possibilecreare applicazioni per dispositivi mobili che possono girare sui sistemi operativi piùdiffusi come iOS, Android e Windows Phone, a partire da un unica implementazionelogica. È possibile creare applicazioni di due tipi:

1. Hybrid Apps Creare applicazioni ibride che utilizzano API comuni e indi-pendenti dal sistema operativo, che girano in modo coerente su iOS, Androide Windows Phone, integrando il supporto per i framework più diffusi comeApache Cordova (precedentemente conosciuto come PhoneGap), Ionic e jQue-ry Mobile. In questo modo è possibile fornire all’applicazione le potenzialitàdelle applicazioni completamente native, senza la necessità di imparare diversilinguaggi nativi. Si possono sfruttare inoltre tutti i plug-in disponibili per ivari framework, per implementare funzionalità più avanzate rispetto a quellefornite dal framework stesso

2. Responsive Web Apps Con il supporto a Bootstrap, il framework UI per leinterfacce di tipo responsive, è possibile creare applicazioni web che adattanola modalità con la quale vengono visualizzate in base al tipo di dispositivo ealla dimensione dello schermo

Per poter creare le applicazioni si utilizzano paradigmi di Visual Development inmodo da permettere la creazione rapida e intuitiva di nuove applicazioni, semplice-mente usando drag & drop. È possibile sfruttare diversi template messi a disposizioneda Appery.io per avere una base di partenza per alcune applicazioni comuni. Altri-menti, se si vuole ottenere maggiore flessibilità si può creare uno schema da zero.Viene anche fornita la possibilità di acquisire dati da servizi esterni, che possonoessere associati utilizzando l’editor di Visual Data Mapping, anche scrivendo fram-menti di codice personalizzati per garantire la massima adattabilità alle esigenzedell’utente. Le principali fasi che coinvolgono la realizzazione di un’applicazionesono:

• Development La costruzione delle applicazioni è svolta in modo modulare,con componenti riutilizzabili in maniera veloce e semplice, come in Figura2.10. Possono essere già presenti oppure creati ex-novo. Il tipo di strutturadati utilizzato, invece, è di tipo model-based, in particolare è usato il patternMVC (Model View Controller). Anche per quanto riguarda lo storage dei datila soluzione scelta per l’interazione dell’utente è di tipo visuale, tramite laStorage API, che permette di gestire le variabili in modo semplice

26

2.2. Stato dell’arte

Figura 2.10: Composizione visuale in Appery.io

• Deployment Successivamente alla fase di sviluppo, in Appery.io è presenteanche una parte per poter esportare la propria applicazione per le diversepiattaforme. In particolare, il metodo più veloce per poter diffondere l’appappena creata è l’utilizzo di un QR code. È sufficiente inviare questo codice perpermettere di scaricare l’applicazione sul dispositivo. Oltre a questo metodoè possibile esportare l’applicazione come sorgenti HTML5/CSS oppure comeprogetti per gli IDE di sviluppo native come Android Studio, XCode o VisualStudio

• Testing È considerato anche l’aspetto del testing, sia per quanto riguardaHTML5 sia per le app native. Nel primo caso è possibile eseguire testingistantaneamente nel browser o direttamente sul telefono, mentre nel secondocaso è supportato anche l’offline testing, cioè è possibile fare test di unità e diintegrazione senza installare l’app sul dispositivo

• Administration La parte amministrativa è la parte che si riferisce al MobileBackend as a Service (MBaaS) e permette di gestire tutta la parte di logicae storage sul cloud. Per quanto riguarda questo aspetto è presente in Appe-

27

2. Preliminari

ry.io una console di controllo, con la quale è possibile inviare notifiche push,controllare i certificati e le API key necessarie all’app, condividere lo sviluppocon altri utenti, gestire i ruoli del team di sviluppo e controllare i rilasci delleversioni dell’applicazione

Karma

Karma11 è uno strumento di integrazione dati sviluppato dalla University ofSouthern California, che permette agli utenti di creare rapidamente e facilmenteuna nuova rappresentazione dei dati da diverse fonti, come database, web API edocumenti di diversa natura (XML, JSON, KML, ecc.). Gli utenti possono integra-re le informazioni modellandole tramite un’ontologia di loro scelta. Questa attivitàviene svolta interamente tramite un’interfaccia grafica, in modo da semplificare ilprocesso. Dopo questa operazione è possibile interagire con il sistema per correg-gere il modello generato in modo automatico ed è possibile trasformare i dati pernormalizzarli. Una volta che il modello è completo, gli utenti possono pubblicare inuovi dati come RDF o salvarli su un database. Oltre a queste funzionalità, altrecaratteristiche di Karma sono le seguenti:

• Ease of use L’utente, utilizzando tecniche di programmazione per esempi ealgoritmi di ottimizzazione (es.: Steiner tree), perfeziona il modello generato inmodo automatico utilizzando un interfaccia grafica che maschera la complessitàdelle regole di mapping usate

• Semantic Models Karma permette agli utenti di combinare diverse ontologieper permettere loro di mappare i loro dati a vocabolari standard

• Scalable Processing Anche la scalabilità è un elemento importante in Kar-ma; infatti gli utenti lavorano con un sottoinsieme dei loro dati, permettendodi creare un’interfaccia utente dove essi definiscono il modello di integrazionedei dati. Dopo questo passaggio, il sistema usa questi modelli in modalitàbatch per integrare una quantità maggiore di dati

• Data Transformation Viene offerta un’interfaccia di programmazione peresempi che permette all’utente di definire le operazioni di trasformazione deidati per poter restituire un unico formato comune

Karma è stato applicato con dati di diversa natura, spaziando dai musei ai datidi tipo bioinformatico. Nel caso dei dati di reperti dei musei, utilizzando questo toolsi sono convertiti oltre 40000 reperti appartenenti alle collezioni dei musei seguendol’Europeana Data Model12, un modello di classificazione per le collezioni artistiche.

11Karma: http://usc-isi-i2.github.io/karma/12Europeana Data Model: http://pro.europeana.eu/page/edm-documentation

28

2.2. Stato dell’arte

Figura 2.11: Karma Service Integration

A partire dai dati provenienti da diverse tabelle di un database SQL Server è statopossibile creare un nuovo dataset omogeneo secondo un nuovo modello dati.

Peudom

PEUDOM [2] è un progetto di ricerca sui mashup nato all’interno del dipartimen-to di Elettronica, Informazione e Bioingegneria (DEIB) del Politecnico di Milano.Si tratta di una piattaforma per la creazione di mashup interamente visuale checonsente all’utente finale di sviluppare la propria applicazione su misura. La piat-taforma guida l’utente nella scelta dei componenti e nelle definizioni delle relazioni,permettendo alcune operazioni e negandone altre secondo determinate regole di com-patibilità definite a priori. L’elemento peculiare di questa piattaforma è l’utilizzodi paradigmi di composizione visuale per definire la l’integrazione dei componentia livello di presentazione. Questi paradigmi agiscono direttamente sull’interfacciautente del mashup, in una sorta di programmazione in tempo reale nella quale irisultati della composizione sono visibili appena definiti. Esistono due tipologie dicomponenti:

1. Wrapped UI Components Questi sono i widget già predisposti da svilup-patori esperti, che specificano la logica dei i wrapper per l’accesso ai serviziWeb e alle API

2. VI Components VI Components significa Visual Integration based Compo-nents e si tratta di componenti creati direttamente dall’utente, manipolandoi result set estratti da uno o più data component e utilizzando i diversi UItemplate a disposizione

29

2. Preliminari

Alla fine del processo di definizione dei componenti, questi vengono sincronizzatitra loro attraverso regole di sincronizzazione, che ne determinano il comportamentodel mashup finale.

Figura 2.12: Peudom

Nell’esempio in Figura 2.12 viene illustrata una Dashboard dove è possibile crearei mashup specificando le fonti dalle quali acquisirli in modo da mostrarli nella stessapagina. In questo caso si considerano dati di film ed è stato selezionato il film diStar Wars Parte IV. Associati ai dati sul film estratti da IMDb è stato scelto dimostrare altri dati correlati al film provenienti da Wikipedia, Flickr e YouTube.

CADD

CADD [21] è un tool sviluppato all’interno del progetto Context-ADDICT delPolitecnico di Milano (DEIB), il cui scopo è la definizione di un framework che sup-porta l’integrazione di nuove informazioni basate sul contesto sui dispositivi mobilidegli utenti. In particolare CADD è lo strumento che permette di progettare i conte-sti. In questo sistema è stato usato come modello di contesto il Context DimensionTree (CDT), usato anche in CAMUS. Una volta stabilito il modello di contesto,vengono creati i contesti dal designer, il quale viene guidato nell’associazione deicontenuti con la porzione di dati presente sul dispositivo mobile dell’utente finale.Come risultato, il sistema genera le query necessarie a selezionare i dati rilevantiper ogni contesto, in questo caso tramite espressioni XQuery13 usate per potare i

13XQuery: https://www.w3.org/TR/xquery/

30

2.2. Stato dell’arte

dati XML da inviare ai dispositivi mobili. Il Context-ADDICT Server supporta laselezione dei dati online e l’invio dei risultati all’applicazione mobile.

Figura 2.13: CADD (Fonte: “CADD: a tool for context modeling and data tailoring”[21], 2007)

I componenti di CADD , come si può osservare in Figura 2.13, sono i seguenti:

• Context Space Designer Assistant Il designer viene supportato nella mo-difica del CDT usando una procedura guidata. In questo modo può aggiungere,modificare ed eliminare i nodi dell’albero di contesto in modo semplice

• Valid Contexts Generation Una volta terminata la fase di design, questocomponente genera automaticamente tutti i contesti validi, come combinazionedei valori dimensione

• Data Tailoring Assistant Il designer associa ogni contesto con la porzionecorrispondente di dati disponibili. Questa associazione è svolta utilizzando unoschema globale di tipo ER. Basandosi sull’interazione con una rappresentazionegrafica dello schema, il tool è in grado di generare una o più espressioni XQueryin modo da costruire le view corrispondenti ai dati

ADaPT

Anche ADaPT [22] (Automatic Data Personalization and Tailoring) è un pro-getto sviluppato all’interno del DEIB, al Politecnico di Milano, che propone unframework per personalizzare l’accesso ai dati a partire dal contesto nel quale sitrova l’utente.

Dopo una fase di apprendimento delle abitudini dell’utente, l’applicazione è ingrado di fornire le informazioni corrette quando si ripresenta lo stesso. L’architetturapresentata è formata da due componenti: il client e il server. Il client è implemen-tato in Android e utilizza il database interno SQLite e le connessioni con il servermediante TCP. Questo permette di utilizzare l’applicazione anche in condizioni diassenza di rete, perché i dati rilevanti vengono salvati anche nel database locale.La visualizzazione dei dati utilizzata è di tipo master-detail, dove nella schermataprincipale è presentata la lista degli argomenti. Quando uno di essi è selezionatol’utente può esplorare i dati o cercare un elemento specifico con un filtro di ricerca

31

2. Preliminari

per poi visualizzare i dati ricevuti nella pagina dei risultati. Una volta ottenuti,l’utente può visualizzare i dettagli dell’elemento desiderato in una nuova pagina.

2.3 Tecnologie utilizzate

Questa sezione vuole introdurre le tecnologie e i framework che hanno assistito losviluppo della piattaforma. La sezione comincia con la descrizione delle tecnologieutilizzate per il backend di CAMUS per poi passare a quelle relative all’applicazionemobile.

2.3.1 Tecnologie utilizzate per il backend

In questa sezione si vuole fornire una panoramica sulle tecnologie che sono stateutilizzate per lo sviluppo del backend. Verrà analizzato il framework Node.js, conil quale è stata sviluppata la logica del backend. In seguito saranno descritti i duesistemi di gestione di database utilizzati: MongoDB, per la persistenza dei dati, eRedis, per la gestione della cache.

2.3.1.1 Node.js

La logica del sistema è stata realizzata a partire da Node.js14, un frameworkper lo sviluppo di applicazioni web basato sul linguaggio Javascript15. Node.js èbasato sul motore Javascript V8 di Google, realizzato con l’obiettivo principale digarantire ottime performance di esecuzione. Il framework permette la creazione diweb server tramite l’ausilio di diversi moduli che gestiscono le funzionalità di base,come il file system, le operazioni di rete, la crittografia, ecc. È compatibile con isistemi operativi più diffusi e possono essere utilizzati tutti i linguaggi che una voltacompilati producono codice Javascript, come CoffeScript o TypeScript. Per certiversi Node.js può essere considerato molto simile a PHP come ambito di utilizzo, laprincipale differenza è che le funzioni in Node.js non sono bloccanti, quindi è possibileeseguire attività in parallelo e utilizzare callback o promise per gestire il flusso diesecuzione, nel caso in cui le singole funzioni abbiano successo o meno. Questascelta di utilizzare un’architettura di tipo event-driven permette la realizzazione diweb server estremamente scalabili senza utilizzare più thread. Node.js infatti lavorasolo su un singolo core, tranne nel caso in cui vengano avviate più istanze separate.Il parallelismo gestito tramite eventi permette di simulare un sistema multithread,riducendo però in maniera significativa la complessità di sviluppo.

14Node.js: https://nodejs.org/en/15Javascript Documentation: https://developer.mozilla.org/en/docs/Web/JavaScript

32

2.3. Tecnologie utilizzate

2.3.1.2 MongoDB

Per la gestione del database è stato scelto di utilizzare MongoDB16. MongoDBfa parte della categoria NoSQL, in quanto abbandona lo schema relazionale classicobasato su tabelle in favore di uno basato sui documenti. Ogni documento ha unastruttura simile a un file JSON, che in MongoDB viene nominato BSON. A differen-za dei database relazionali, ove uno schema viene definito a priori, in MongoDB vienepreferito uno schema dinamico, cioè che varia in base alle esigenze dello sviluppato-re. Questa caratteristica permette di sviluppare in maniera più semplice e rapida leapplicazioni e di integrare facilmente determinate tipologie di dato. La struttura adocumento prevede però un approccio differente nella fase di modellazione, in quan-to applicare uno schema adatto a un sistema relazionale in MongoDB porterebbe adiverse inefficienze. Per esempio, chi è abituato a un database relazionale deve essereconsapevole che in MongoDB non esiste l’operatore di JOIN, bensì viene fornita lapossibilità di salvare dei sotto-documenti all’interno di un documento. Per esempio,se si vuole memorizzare un libro che ha più autori è possibile salvare l’elenco degliautori, insieme a eventuali altri suoi dati, all’interno del documento contenente leinformazioni del libro17. Un’altra caratteristica di MongoDB è la flessibilità nellacomposizione delle query: possono essere specificate sui campi, su un range di valorio tramite espressioni regolari. Sono sempre ammesse proiezioni degli attributi chesi vogliono visualizzare nei risultati. Sempre per l’interrogazione dei dati si possonoutilizzare funzioni MapReduce e di Aggregazione. In particolare quest’ultima per-mette di ottenere un risultato simile all’operatore GROUP BY dei database SQL,ma fornisce inoltre la flessibilità di concatenare più operazioni per formare una pi-peline. Mette a disposizione anche il comando $lookup per effettuare un’unione tradocumenti diversi, al fine di simulare un’operazione di JOIN. MongoDB permettedi definire degli indici sui campi che vengono utilizzati di frequente nelle query pervelocizzarne l’esecuzione. Una caratteristica che rende MongoDB estremamente sca-labile è la possibilità di eseguire multiple istanze su macchine diverse, permettendo alsistema di scalare orizzontalmente. Sarà compito di MongoDB gestire le chiamate eselezionare il nodo dove effettuare la richiesta, tramite un sistema di load-balancing.Questa caratteristica viene agevolata dalla struttura del file system utilizzato daMongoDB, chiamato Grid File System, che gestisce la divisione dei documenti indiversi “pezzi”. Oltre al load-balancing, che viene utilizzato per migliorare le presta-zioni, è possibile anche utilizzare altre macchine come repliche, in modo da garantirela sicurezza dei dati nel caso di guasti.

Il fatto che MongoDB memorizzi i file in un formato dalla struttura molto si-mile a un JSON agevola l’integrazione con Node.js, che a sua volta utilizza oggetti

16MongoDB: https://www.mongodb.org/17Questo è solo un esempio indicativo, non è una soluzione ottima in quanto un autore può

pubblicare più di un libro e utilizzando questo schema si otterrebbe duplicazione delle informazioni.

33

2. Preliminari

semplicemente convertibili in formato JSON.

2.3.1.3 Redis

Oltre a un sistema di gestione di basi di dati che garantisse la persistenza deidati più importanti, si è resa necessaria l’adozione di un altro sistema per effettuarecaching delle risposte ricevute dai servizi e per memorizzare informazioni relativealle sessioni degli utenti. La scelta in questo caso è ricaduta su Redis18. Redissupporta la gestione di un database interamente memorizzato in memoria centrale,quindi estremamente rapido nell’evadere le richieste, basato su di una struttura ditipo chiave-valore. Queste caratteristiche, insieme al fatto che quanto viene salvatoun dato è possibile impostare un intervallo di tempo, scaduto il quale l’elementoviene eliminato, lo hanno reso il candidato perfetto per svolgere questo compito.

2.3.1.4 GraphQL

GraphQL19 è, come suggeriscono le ultime due lettere del nome, un query lan-guage, creato come supporto alla realizzazione di applicazioni client, che mette adisposizione una sintassi intuitiva e flessibile e un sistema che permette al clientdi specificare i requisiti e le interazioni sui dati [23]. Rispetto all’approccio REST,GraphQL permette di effettuare richieste più efficienti sui dati ed evita la duplica-zione della logica lato server che può verificarsi nel caso di endpoint personalizzati.Una delle principali differenze rispetto a REST riguarda la possibilità di lasciare alclient la scelta dei dati da ricevere. Questa modifica nasce dall’idea che è il clienta conoscere nel dettaglio quali dati servono per comporre la view e quindi gli vienedelegata la responsabilità di richiedere solo quelli essenziali all’interno della query.

Alla base di GraphQL ci sono i seguenti principi:

• Gerarchico Una buona parte dei prodotti sviluppati implica la creazione emanipolazione di view gerarchiche. Per mantenere coerenza con la strutturadelle applicazioni, le query GraphQL sono esse stesse strutturate gerarchica-mente. La query viene organizzata esattamente come i dati che deve restituire.È un metodo naturale per permettere ai client di descrivere i vincoli sui dati

• Basato sul prodotto GraphQL è stato creato tenendo ben presenti i requisitidelle view e del come gli sviluppatori di frontend li esplicitano

• Tipizzato Ogni server GraphQL definisce il proprio schema specifico perl’applicazione in uso. Le query vengono eseguite a partire dal contesto definitoda questo schema. Inoltre vengono effettuati dei controlli al fine di verificareche la query sia sintatticamente corretta e valida prima di essere eseguita

18Redis: http://redis.io/19GraphQL: http://graphql.org/

34

2.3. Tecnologie utilizzate

• Query definite dal client Negli schemi viene inoltre definito il formato dellarisposta, compresa la tipologia di ogni dato. Sarà compito del client specificareesattamente quali sono le informazioni che gli interessano. Rispetto ad altriapprocci, dove è il server a decidere quali dati restituire ai client, in GraphQLinvece vengono restituiti solamente i dati che vengono richiesti

• Introspettivo Qualsiasi schema GraphQL può essere interrogato tramite que-ry. In questo modo è possibile conoscere la struttura globale dello schema, cosìcome le query che sono permesse e quali dati possono essere richiesti. Questeintrospezioni vengono utilizzate da vari tool per avere una visione completadello schema che viene esposto dal server

Listato 2.1 Esempio query GraphQL

user (id: 2) namesurname

Listato 2.2 Esempio di risposta

"user": "name": "Mario","surname": "Rossi"

Nel Listato 2.1 viene riportato un semplice esempio di query scritta tramiteGraphQL. Con questa query si vogliono acquisire i dati relativi all’utente con iden-tificativo “2”, e in particolare si è interessati a ricevere il suo nome e cognome.Nel Listato 2.2 viene invece mostrato un esempio di risposta che viene ricevuta dalserver.

GraphQL fornisce inoltre un’altra funzionalità estremamente utile: le connes-sioni. Una connessione permette a un oggetto di definire i legami che ha con altrioggetti, anche di tipo diverso dal proprio. In questo modo è possibile richiederedirettamente le informazioni riguardo ad altri oggetti tramite un’unica query; que-sta caratteristica non è presente nei sistemi REST e permette di ottenere un nettomiglioramento delle prestazioni. Infatti nei sistemi REST, per richiedere le rap-presentazioni correlate sono necessarie n query, dove n è il numero di risorse darichiedere. Con GraphQL invece è sufficiente una sola richiesta, nella quale vienespecificato che si è interessati anche alle altre risorse. Inoltre, GraphQL mette adisposizione per ogni connessione la paginazione dei risultati, ossia la possibilità dirichiedere un determinato numero di elementi a ogni richiesta. A ogni oggetto vie-ne automaticamente associato un cursore che lo identifica univocamente: in questomodo è possibile chiedere ulteriori elementi in una seconda query, specificando ilcursore dell’oggetto dal quale si desidera partire.

Nel Listato 2.3 viene mostrata una query più complessa della precedente. La con-nessione viene definita da “friendConnection”, che viene utilizzata per recuperare gli

35

2. Preliminari

Listato 2.3 Esempio connessione GraphQL

user (id: 4802170) idnameisViewerFriendprofilePicture (size: 50)

uriwidthheight

friendConnection (first: 2)

totalCountfriends:

idname

Listato 2.4 Esempio di risposta

"user": "id": 4802170,"name": "Lee Byron","isViewerFriend": true,"profilePicture":

"uri": "cdn://pic/4802170/50","width": 50,"height": 50

,"friendConnection":

"totalCount": 13,"friends": [

"id": 305249,"name": "Stephen Schwink"

,

"id": 3108935,"name": "Nathaniel Roman"

]

amici dell’utente corrente. Si vuole far notare che gli oggetti che vengono restituitinel campo “friends” sono dello stesso tipo dell’utente richiesto in origine: questo vuoldire che è possibile produrre un numero di livelli gerarchici potenzialmente infinito.Se, all’interno di un utente amico, si specifica di nuovo la connessione “friendCon-nection”, verranno restituiti anche gli amici di quello specifico utente. Altro puntointeressante, come citato in precedenza, delle connessioni riguarda la possibilità dirichiedere solo un sottoinsieme dei risultati: nell’esempio vengono richiesti solamentei primi due amici dell’utente. Come si può notare nel Listato 2.4, vengono restituitisolamente i primi due amici, nonostante il campo “totalCount” indichi che l’utenteha in totale 13 amici. Tramite ulteriori query possono essere richiesti gli altri amicidell’utente.

2.3.2 Tecnologie utilizzate per la mobile app

Al momento di scegliere come implementare l’applicazione mobile per CAMUSsono state considerate due opzioni: la creazione di un’applicazione nativa inizial-

36

2.3. Tecnologie utilizzate

mente solo per Android, per poi estendere la compatibilità su iOS, oppure l’utilizzodi strumenti cross-platform, funzionanti su più di un sistema operativo mobile. Que-sta esigenza è nata dal fatto che il mercato delle applicazioni per smartphone stacrescendo in maniera esponenziale e le competenze richieste agli sviluppatori per svi-luppare applicazioni native sono molto variegate. Per esempio per quanto riguardalo sviluppo iOS è necessario conoscere i linguaggi di programmazione Objective-Ce Swift, mentre per Android ci si basa su Java e per Windows Phone è necessarioutilizzare C#, senza dimenticare altri sistemi operativi meno diffusi o emergenti(Tizen, Ubuntu Touch, ecc.). La tipologia di strumenti che permettono di sviluppa-re un’applicazione scrivendo una sola volta il codice ed eseguirla su diversi sistemioperativi mobili è detta cross-platform Gli strumenti di sviluppo cross-platform so-litamente si basano sul principio di “write once run everywhere”, cioè il codice vienescritto una volta sola per creare applicazioni per diverse piattaforme, permettendoquindi di limitare le competenze richieste ai programmatori. È possibile identificaredue famiglie di strumenti per la programmazione multi piattaforma:

1. Rendering tramite componenti nativi In questa famiglia il renderingdell’applicazione viene fatto utilizzando le API grafiche native del sistema ope-rativo di destinazione. Al fine di ottenere ciò è necessario implementare unatraduzione in codice nativo a partire dal linguaggio utilizzato per programma-re. Ad esempio in Xamarin si sviluppa utilizzando C# per programmare sia inAndroid che in iOS ed è possibile effettuare Linking con le librerie di sistemadei due sistemi operativi e fornire una migliore esperienza d’uso per l’utente.Anche per quanto riguarda altri strumenti come React Native o Native Script20

che utilizzano JavaScript viene riproposto lo stesso principio compositivo

2. Rendering tramite WebView In questo caso la costruzione della maggiorparte dell’applicazione è svolta utilizzando una Web View, cioè viene mostratauna pagina web all’interno di un contenitore nativo. In questo caso è pos-sibile programmare l’applicazione come se fosse una pagina web, implemen-tandola allo stesso modo di un sito web per browser. Nonostante si tratti diun’implementazione non molto legata alla logica nativa, è possibile in alcunicasi permettere un’interazione dell’applicazione con i sensori del dispositivo.Questo modello offre un’infinità di possibilità implementative a livello graficoe una elevata capacità di adattamento a diversi dispositivi, tuttavia le presta-zioni possono risentire del fatto che si stia interagendo con una pagina web enon con un’applicazione nativa

Per la creazione di CAMUS si è scelto di utilizzare anche lato frontend deglistrumenti che siano implementabili in maniera semplice e dove la suddivisione in

20Native Script: https://www.nativescript.org/

37

2. Preliminari

moduli singoli riutilizzabili assuma un ruolo di primo piano. Per questo motivosi è scelto di utilizzare degli strumenti tecnologici che sono all’avanguardia nellosvolgere questo compito, come React e la sua derivazione per la programmazionemobile React Native. Successivamente è introdotta la parte logica dell’applicazionecon il funzionamento architetturale dell’aggiornamento dati, con il paradigma Flux.

2.3.2.1 React

React21 nasce come libreria open-source rilasciata nel 2013 da Facebook, che per-mette di ottimizzare le visualizzazioni delle pagine HTML, utilizzando componentiche ne racchiudono altri specificati come HTML tag personalizzati. Essa provie-ne da XHP22, che è un framework HTML per il linguaggio PHP creato sempre inFacebook per gestire tutta la logica del social network. L’impiego di React è statoinizialmente nel newsfeed di Facebook nel 2011 e più tardi nel sito web di Instagram.Le principali funzionalità in React sono le seguenti:

• Virtual DOM React crea una propria struttura dati in memoria, che calcolale differenze risultanti e aggiorna il DOM HTML risultante nella pagina inmodo efficiente. In questo modo il programmatore può scrivere codice come sel’intera pagina fosse ricaricata ogni volta, mentre è il motore React a stabilirequali siano i componenti che è necessario sostituire e quali no

• JSX I componenti React utilizzano JSX23, un linguaggio basato su JavaScriptche introduce la tipizzazione delle variabili e un sistema di classi ben definitocome in Java. Inoltre apporta ottimizzazioni a livello di compilazione permet-tendo all’applicazione di essere più veloce rispetto a normale codice JavaScript.È comunque possibile scrivere la propria applicazione utilizzando JavaScript,con un metodo che permette la conversione in codice JSX

• One-way data flow Le proprietà, un set di valori immutabili, sono passatial componente figlio all’interno del suo tag HTML. Il componente figlio nonpuò modificare direttamente nessuna proprietà che gli è stata passata, ma puòpassare funzioni che possono modificare il valore. L’unidirezionalità del flussodati viene specificata nell’architettura Flux, che verrà spiegata nella Sezione2.3.2.3

2.3.2.2 React Native

React Native24 è una libreria open-source rilasciata nel 2015 sempre da Facebook,e si propone come implementazione del framework React per quanto riguarda le

21React:https://facebook.github.io/react/22XHP: http://facebook.github.io/xhp-lib/23JSX: https://jsx.github.io/24React Native: https://facebook.github.io/react-native/

38

2.3. Tecnologie utilizzate

applicazioni mobili. Le principali differenze con React sono dovute alla difficoltàmaggiore di sviluppare un framework per le applicazioni mobili. Quando si sviluppasul web, semplicemente si salvano i file modificati e si ricarica la pagina, cosa che nonè possibile fare con le applicazioni mobili, perché è necessaria una nuova compilazioneper vedere i cambiamenti apportati. Per risolvere questo problema, in React Nativeci si basa sull’utilizzo di un server locale in Node.js che permette il caricamento dellemodifiche dell’applicazione sul dispositivo senza ricompilare l’applicazione (Figura2.14) Questo server, il quale ha la funzione di packager, invia un bundle contentetutti i file JavaScript necessari per far funzionare l’applicazione. Questo funziona finoa quando le modifiche sono relative esclusivamente alla parte di codice JavaScript,mentre per quanto riguarda le modifiche a livello di codice nativo è sempre necessariauna nuova compilazione. Per esempio, quando è stato il momento di installare alcunelibrerie grafiche collegate ad elementi nativi è stato necessario apportare modificheanche ai file di configurazione dei progetti Android e iOS, dato che diventavanonecessari anche file aggiuntivi alla compilazione.

JavaScript Code Packager

iOS

Android

*.android.js + *.js

*.ios.js + *.js

Figura 2.14: Flusso di sviluppo React Native

Con React Native è possibile migliorare l’esperienza d’uso sulle piattaforme mo-bili rispetto al web. Come primo aspetto si può accedere ai componenti specificidell’interfaccia utente, come le mappe, i picker e gli switch, anche se tuttavia possonoessere modificati nella loro implementazione.

2.3.2.3 Flux

Flux25 è un pattern architetturale creato da Facebook per gestire il flusso dei datiall’interno dell’applicazione. È complementare alla gestione delle view di React, in

25Flux: https://facebook.github.io/flux/

39

2. Preliminari

cui i componenti sfruttano un flusso di dati unidirezionale, come espresso in Figura2.15.

Action Dispatcher ViewStore

Action

Figura 2.15: Flusso dati unidirezionale Flux

Si tratta fondamentalmente di una modifica del pattern MVC (Model View Con-troller), al quale vengono effettuate alcune modifiche. Le applicazioni Flux, come sivede nella medesima figura, hanno quattro tipologie di componenti principali:

1. Dispatcher Il Dispatcher è l’hub centrale che controlla tutto il flusso dei datidell’applicazione. È essenzialmente un registro di callback agli Store e possiedeun meccanismo semplice per distribuire le Action verso gli Store. Man manoche l’applicazione cresce di dimensioni, il Dispatcher assume un’importanzasempre maggiore, perché può essere sfruttato per gestire le dipendenze tra gliStore invocando le callback registrate in un ordine specifico, talvolta ancheattendendo la conclusione dell’aggiornamento degli altri Store

2. Store Gli Store contengono lo stato dell’applicazione e la logica, e il loro ruoloè molto simile al modello nel pattern MVC, ma in Flux hanno il compito dimodellare lo stato per un particolare dominio all’interno dell’applicazione

3. View L’implementazione delle view proposta da React si sposa perfettamentecon quella necessaria per Flux. Si tratta di un misto tra la view e il controllerin MVC, perché permette al codice di ricevere i dati dagli store e passare questidati direttamente ai discendenti per creare ogni singola sezione della pagina.Quando riceve un evento dagli store, richiede i nuovi dati attraverso i getterdagli store, per poi aggiornare il proprio stato interno e renderizzarlo a cascatautilizzando tutti i sottocomponenti

4. Action Con il termine Action si intende il payload di dati che viene mandatoal metodo esposto dal dispatcher, il quale come espresso nella sua spiegazione,poi si occupa di inviare i dati agli store

40

2.3. Tecnologie utilizzate

Nell’applicazione è stato scelto di utilizzare Alt.js26, una libreria diversa daquella originale di Flux creata da Facebook, che, pur mantenendo un’architetturafunzionale simile, presenta alcune semplificazioni:

• Non è necessario implementare il Dispatcher, componente che viene fornito conla libreria. È necessario fornire soltanto le Actions e gli Stores

• Le Action sono molto simili a quelle di Flux. Nel metodo che le definisce ildato ritornato alla fine viene automaticamente inviato al Dispatcher di Alt

• Negli Store è necessario mappare l’operazione che controlla il corretto aggior-namento dei dati con le Actions corrispondenti

• Il posizionamento delle operazioni preliminari come il controllo sui dati o delletrasformazioni sui dati è indifferente se sia posta nelle Actions o negli Stores epossono essere svolte prima o dopo l’operazione di dispatch di Alt

26Alt.JS: http://alt.js.org/

41

2. Preliminari

42

Capitolo 3

Metodologia CAMUS

Questo capitolo fornisce una panoramica sulle caratteristiche e le metodologieadottate per il progetto CAMUS. Vengono inizialmente messe in evidenza le fonda-menta sopra alle quali è stato sviluppato il framework per poi andare ad analizzaregli approcci utilizzati per il design e la creazione delle applicazioni CAMUS. L’utenteviene messo al centro della progettazione [24], tenendo conto delle sue esigenze diutilizzo e cercando di mascherare la complessità delle operazioni. Per questo motivovengono seguite le linee guida relative alla Visual Programming dei mashup [25].

Nelle sezioni seguenti verrà mostrata l’organizzazione del progetto e verrannoillustrati gli obiettivi che si vogliono prendere in considerazione e per i quali verràproposta una soluzione. Successivamente verrà analizzato l’approccio seguito perintegrare i precedenti lavori sul contesto e sui mashup, al fine di sfruttarne i rispettivivantaggi. Si passerà poi alle motivazioni che hanno spinto all’utilizzo dei servizicome fonte di acquisizione dati. In seguito saranno analizzate le tecniche operativeutilizzate, come l’estensione del modello del contesto, la creazione dell’ecosistema deiservizi che possono essere interrogati, l’associazione dei servizi al contesto e le relativeprocedure di selezione, l’algoritmo di integrazione dei dati e, per finire, l’approccioper la definizione degli schemi di mashup.

3.1 Organizzazione del framework

CAMUS è l’acronimo di Context-Aware Mobile mashUpS e, come si può intuiredal nome, il principale obiettivo del progetto è quello di proporre un framework perla realizzazione di mashup per dispositivi mobili che sfruttino il contesto nel quale sitrova l’utente al fine di proporre informazioni di interesse e pertinenti alla situazioned’uso.

Il progetto CAMUS vuole proporsi come una soluzione user-friendly al proble-ma del sovraccarico cognitivo, o information overload, cioè la difficoltà che unapersona ha nel comprendere un problema e nel prendere una decisione quando ha

43

3. Metodologia CAMUS

a disposizione un’eccessiva quantità di informazioni. In particolare sfrutta due fi-loni di ricerca che a loro volta propongono una metodologia per attenuare questoproblema, utilizzando approcci differenti. Questi due ambiti sono relativi agli studisul contesto e sui mashup. Viene utilizzato il contesto per raccogliere informazionisull’utente e sull’ambiente nel quale si trova, al fine di selezionare i servizi più ido-nei alla situazione e filtrare le informazioni che sono di maggior interesse. Oltre aquesto aspetto, si vuole sfruttare la dinamicità di presentazione che caratterizza imashup per adattare la modalità nella quale queste informazioni vengono mostratee la flessibilità di integrazione dei dati provenienti da diverse fonti.

In particolare il concetto dei mashup è applicato al mondo dei dispositivi mobili:il risultato finale consiste in un’app per smartphone o tablet che adatta la propriastruttura e i dati mostrati in base a regole di interrogazione dei dati e visualizzazionedelle view definite a priori. Questa caratteristica permette di ottenere un’estremaflessibilità, in quanto non è necessario rilasciare versioni diverse se i servizi interrogatisono diversi. Viene lasciata massima libertà di variare l’interfaccia grafica in modoche si adatti a diverse situazioni di utilizzo.

I fattori che hanno guidato la scelta dell’architettura più idonea riguardano qua-le componente del sistema avrà il compito di interrogare i servizi per acquisire leinformazioni da mostrare all’utente e l’integrazione dei dati. Per quanto riguar-da l’interrogazione dei servizi sono state valutate due possibilità diametralmenteopposte:

• Client centric In questa tipologia tutte le richieste verso i servizi esterni ven-gono eseguite sul dispositivo, che si occuperà inoltre di integrare le informazioniricevute e contattare i servizi di supporto

• Server centric In questa tipologia di architettura tutto il carico computa-zionale viene gestito dal server. Quando viene effettuata una richiesta, saràquindi il server a occuparsi di contattare i servizi necessari a recuperare i da-ti, integrare le informazioni ricevute e contattare i servizi di supporto definitinello schema di mashup per arricchire il precedente dataset

Nel caso Client centric il vantaggio è dato principalmente dal fatto che ogni di-spositivo esegue le query e le operazioni di merge e, data la non indifferente potenzadi calcolo dei moderni processori montati negli smartphone di ultima generazione,la complessità computazionale non introduce problemi. Purtroppo in questo modonon è possibile fare caching tra diversi utenti. Per esempio, se due utenti eseguonola medesima ricerca di ristoranti a Milano in zona Duomo verso Google Places oTripAdvisor, partiranno due query uguali per ogni servizio e, aumentando il numerodi utenti, la quantità di richieste aumenta considerevolmente, portando alla satura-zione le API key con un numero limitato di richieste (es.: le API di Google). Inoltre

44

3.1. Organizzazione del framework

Tabella 3.1: Sintesi architetture

Architettura PROs CONs

Client Centric • Poco carico computazio-nale sul server

• Utilizzo migliore dei datidai servizi di supporto

• No caching tra diversiutenti e ”consumo” APIkeys

• Consumo di batteria edati

• No sincronizzazione deidescrittori dei servizi

Server Centric • Caching dei risultati tradiversi utenti

• No limiti computazionalie energetici

• Migliore gestione dei de-scrittori

• Unico endpoint per tuttele richieste dai client

• Unico collo di bottiglianel sistema

• Dati inutilizzati dai ser-vizi di supporto

il fatto di eseguire query verso i servizi esterni comporta un aumento del consumoenergetico del device, non solo per la quantità di dati che le interfacce di rete devonogestire, ma anche per la necessità di eseguire le operazioni sui dati di Merge e Union,definite nella Sezione 2.1.2.3. Esiste anche un problema legato alla descrizione deiservizi: la mobile app deve conoscere le regole per interrogare un servizio. Vistoche queste definizioni vengono create e modificate dal server si rende necessario unmeccanismo di aggiornamento su tutte le applicazioni.

Il caso Server centric permette di ottenere dei miglioramenti ai problemi sopracitati. In particolare è possibile fare caching dei risultati a livello multiutente, cioè searrivano due query uguali con un breve intervallo l’una dall’altra, il server effettueràuna singola richiesta verso il servizio esterno e i dati della seconda richiesta verrannorecuperati dalla cache. In particolare, il caching permette di ridurre il problema delnumero limitato di richieste che possono essere effettuate tramite una particolareAPI key. Un altro aspetto che viene risolto è il fatto che naturalmente un serverpuò elaborare in maniera più efficiente i dati. Il dispositivo mobile non ha più il caricocomputazionale del caso Client centric, ma sfrutta la potenza di calcolo del server,che permette di ricevere i dati già elaborati con Merge e Union. Anche i descrittori

45

3. Metodologia CAMUS

Figura 3.1: Architettura del sistema

dei servizi non hanno più il problema di essere distribuiti in ogni singolo device inseguito a un aggiornamento: una volta che uno di essi viene modificato sul server, ègià pronto e funzionante per tutte le richieste verso quel servizio. Uno degli svantaggiprincipali di questa architettura è di avere un unico collo di bottiglia per tutto ilsistema, che sarebbe ovviamente il server. Si dovrà dimensionare correttamente lacapacità computazionali del sistema per permettere l’evasione rapida delle richiesteanche in situazioni di elevato carico, cioè quando diversi utenti effettuano nello stessoistante un vasto numero di richieste. Inoltre si presenta un problema che riguardal’interrogazione dei servizi di supporto: questo compito dovrebbe essere ripetutodal server per ogni elemento appartenente alla risposta che deve essere inviata alclient. Molte richieste potrebbero essere invece evitate, in quanto le informazionimesse a disposizione dai servizi di supporto hanno validità nella pagina di dettagliodi ogni elemento: non è detto che l’utente selezioni tutti gli elementi di un rispostama generalmente ne visualizza una porzione ristretta [26]. Nel lavoro precedente[27] si era scelto di utilizzare un’architettura di tipo ibrido, dove però il caricodi complessità era collocato principalmente nell’applicazione mobile. I dati sonosintetizzati nella Tabella 3.1.

In questa versione, è stato scelto sempre un sistema di tipo ibrido, ma spostan-do l’elaborazione del contesto, l’esecuzione delle richieste verso i servizi esterni el’integrazione dei dati lato server, come si può osservare in Figura 3.1. All’applica-zione mobile vengono invece delegati i compiti di rendering dell’interfaccia graficatramite gli schemi di mashup e l’interrogazione dei servizi di supporto per acquisirele informazioni utili ad arricchire i dati forniti dal server. Questa tecnica ha il van-taggio di ottimizzare il numero di richieste che vengono effettuate verso i servizi di

46

3.1. Organizzazione del framework

supporto, limitandone il numero a quelle strettamente necessarie, che corrispondonoal numero di elementi che l’utente decide di visualizzare nel dettaglio.

Di seguito vengono elencati i tre componenti principali del sistema CAMUS:

1. Server Il server è il componente col quale si interfaccia l’amministratore disistema e dal quale è possibile avere una visione sulla complessità del sistemasenza astrazioni. L’amministratore ha i compiti di registrare i nuovi servizi edi configurare i termini per la trasformazione dei risultati ricevuti dai servizi.Inoltre definisce l’albero di contesto globale, che verrà utilizzato come base perla creazione di quelli personalizzati per gli utenti, e di associare le operazioniai vari nodi che compongono l’albero

2. Web App Le web app sono collegate all’esperto di settore che compone l’appli-cazione mobile. Questo attore non è necessariamente un esperto di informaticae della tecnologia utilizzata, quindi ha bisogno di un livello di astrazione mag-giore rispetto all’amministratore. Sono disponibili due funzionalità di base:una permette di creare dei CDT personalizzati per gli utenti e di modificarele associazioni dei servizi, mentre l’altra permette di creare i mashup per lepagine dell’applicazione, collegando i termini con i componenti che verrannopoi renderizzati in fase di esecuzione

3. Mobile App La mobile app è l’interfaccia dell’utente finale con il sistema. Es-sa ha il compito di renderizzare i mashup definiti dall’esperto e di permettereall’utente di specificare il proprio contesto per richiedere al server i risulta-ti inerenti a esso. Oltre alle informazioni richieste all’utente vengono inoltresfruttati i sensori messi a disposizione dal dispositivo (es.: coordinate geografi-che, orario, ecc.) per migliorare la precisione del contesto, in modo trasparenteall’utente. Una volta che l’utente finale ha effettuato l’accesso, vengono ca-ricati gli schemi di mashup e l’albero di contesto specifico dell’utente. L’appsi occuperà di renderizzare gli schemi ricevuti generando dinamicamente delleschermate che verranno utilizzate dall’utente per effettuare tutte le opera-zioni che desidera. I risultati vengono mostrati seguendo il pattern master-detail [28]: in prima istanza viene generato un elenco (master) dei risultatiottenuti, mostrando poche informazioni riguardo il singolo elemento; successi-vamente l’utente può selezionare uno o più elementi della lista per visualizzarei dettagli (detail) dell’elemento. In questa fase entrano in gioco i servizi di sup-porto: una volta che l’utente decide di visualizzare i dettagli di un elemento,l’app si occupa, in base allo schema di mashup corrente, di interrogare i servizidi supporto necessari per arricchire le informazioni che ha precedentementericevuto

47

3. Metodologia CAMUS

3.2 Obiettivi del progetto

L’obiettivo principale del progetto CAMUS è definire la metodologia con la qualeè possibile creare app sfruttando i mashup e il contesto, al fine di mostrare all’utentele informazioni che sono più pertinenti alla situazione in cui si trova.

Per la creazione del framework sono state rispettate le seguenti linee guida:

• Creazione visuale Questo punto è relativo alla modalità di realizzazione delleapp. Si vuole ideare un sistema che permetta la composizione dell’interfacciagrafica interamente in modo visuale, senza la necessità di scrivere codice

• Contestualità Si vuole sfruttare il contesto dell’utente per comprendere qualisiano le sue esigenze e mostrargli così le informazioni maggiormente pertinen-ti alla situazione. In questo modo è possibile utilizzare anche diverse fontiper acquisire dati più precisi e variegati, che verranno filtrati adeguatamen-te in modo da mostrare le informazioni più rilevanti e nascondere quelle cheporterebbero solamente a una maggior confusione

• Semplicità Ogni operazione deve essere facile, in modo che anche personenon pratiche di informatica possano creare delle app CAMUS. Qualsiasi at-tività di creazione e modifica viene dunque effettuata tramite un’interfacciagrafica, in modo da aiutare l’utente nella composizione dell’applicazione. Inol-tre sono stati scelti dei modelli concettuali semplici, di facile comprensione masufficientemente potenti da creare schemi di una certa complessità

• Automazione Si vuole far ripetere all’utente il minor numero di azioni pos-sibile; in quest’ottica vengono sfruttati i sensori disponibili sui dispositivi peracquisire in maniera automatica determinate informazioni, sgravando l’utenteda questo compito

• Uniformità dell’accesso ai dati Il framework non prevede l’interfacciamentocon un database per il recupero delle informazioni, bensì i dati vengono acqui-siti tramite l’utilizzo dei servizi. Questa soluzione rende più flessibile l’accessoai dati, in quanto viene fornita un’interfaccia comune per servizi sia interni,cioè gestiti direttamente dal creatore dell’app, sia esterni, cioè mantenuti daterzi. Inoltre apre la strada all’utilizzo dei servizi di supporto, che fornisconodati complementari per arricchire le informazioni primarie

• Personalizzazione Una delle principali caratteristiche del framework è lapossibilità di modificare l’aspetto dell’app in modo intuitivo. Viene dunqueagevolata la personalizzazione dell’interfaccia grafica non solo in base alla si-tuazione di utilizzo ma anche tenendo conto del profilo dell’utente. Ogni uti-lizzatore dell’app può così avere una visualizzazione delle informazioni adatta

48

3.3. Integrazione del contesto con i mashup

alle sue esigenze, cosicché si possa concentrare esclusivamente sulla fruizionedei contenuti. Verrà dunque preferito uno schema flessibile che permetta la ge-nerazione dinamica delle schermate da mostrare all’utente e soprattutto verràprivilegiato un metodo semplice e visuale per la creazione di questi schemi

• Universalità CAMUS deve essere utilizzabile in domini applicativi diversi.Si vuole realizzare un modello che sia valido e in grado di essere applicatoin contesti anche molto diversi tra loro. Per questo motivo il framework nonviene costruito con elementi specifici di un determinato settore, proprio perevitare perdite di generalità

3.3 Integrazione del contesto con i mashup

Come evidenziato nella Sezione 3.1, il progetto CAMUS consiste nell’unione dellericerche effettuate nell’ambito della context-awareness e dei mashup. Il frameworkmira all’integrazione tra questi due filoni di ricerca, in modo da catturare le poten-zialità di entrambi. I mashup permettono di utilizzare diverse fonti per acquisireuna maggior quantità di informazioni e ottenere dei dati che sono complementari,finalizzati all’arricchimento delle descrizioni degli elementi. Inoltre mettono a di-sposizione una logica di creazione dinamica delle interfacce grafiche: permettono disfruttare la conoscenza acquisita dalle diverse fonti per visualizzare i dati che sonodi maggior interesse. Il problema nasce quando si ha a che fare con una quantitàenorme di informazioni. È sì un bene avere a disposizione una moltitudine di dati,ma esiste il rischio concreto che questa mole di dati generi unicamente confusionee renda difficoltoso il lavoro di ricerca delle informazioni che sono di reale interes-se. Proprio per mitigare questo problema viene introdotto l’utilizzo del contesto.Quest’ultimo permette di filtrare le informazioni che sono rilevanti in una partico-lare situazione. Vengono dunque nascosti o messi in secondo piano tutti i dati chenon sono di alcun interesse per la situazione corrente, permettendo così all’utentedi concentrarsi unicamente su un sottoinsieme dei risultati più attinenti al contestonel quale si trova.

Rispetto al paradigma di composizione presentato nella Sezione 2.1.2.2, in CA-MUS vengono separate la attività di acquisizione dati e creazione dell’interfacciagrafica. Questo disaccoppiamento permette di modificare l’aspetto delle app in mo-do molto flessibile, in quanto non è necessaria a priori la conoscenza della fonteesatta dalla quale proverranno le informazioni. Viene così fornita un’estrema libertàal designer nella scelta di come comporre l’interfaccia grafica, in modo che possa con-centrarsi solo su questo aspetto e non si debba preoccupare di come i dati venganointegrati tra loro.

49

3. Metodologia CAMUS

Un’altra parte del framework viene dunque dedicata all’integrazione dei dati.È in questa attività che entra in gioco il contesto. Grazie alle informazioni sullasituazione nella quale si trova l’utente, è possibile selezionare quali sono i serviziche forniscono i migliori risultati e, una volta acquisiti i dati, possono fornire leinformazioni necessarie per assegnare un punteggio ai vari elementi, in modo daportare in primo piano quelli più rilevanti. Quest’attività viene divisa in tre partiprincipali:

1. Selezione dei servizi Vengono selezionati, grazie alle informazioni di conte-sto, i servizi che sono più idonei per la situazione corrente

2. Acquisizione dei dati Vengono interrogati i servizi scelti per acquisire i dati

3. Integrazione delle informazioni I dati ricevuti dai vari servizi vengono in-tegrati in modo da formare un unico dataset. Quest’operazione prevede trefasi: i) trasformazione delle risposte in una rappresentazione comune; ii) fu-sione degli elementi duplicati; iii) assegnamento di un punteggio agli elementi,tenendo conto delle informazioni fornite dal contesto

3.4 Utilizzo dei servizi

Uno dei punti chiave del framework, seguendo la filosofia dei mashup, è di nonessere limitati a una singola fonte per l’acquisizione dei dati, bensì si vuole esse-re in grado di recuperare le informazioni da diverse sorgenti. In questo modo èpossibile ottenere diversi vantaggi, come l’acquisizione di una maggiore quantità dirisultati, ottenere informazioni più complete, ecc. Presenta però anche degli svan-taggi: avere molti dati a disposizione può essere dispersivo ed esiste il rischio diottenere entità ridondanti. Per fornire un’elevata flessibilità, il framework prevede ildisaccoppiamento della logica di accesso ai dati: per l’acquisizione delle informazioniviene fornita un’unica interfaccia, rappresentata dai servizi. Questo metodo permet-te di avere una descrizione unica sul come recuperare i dati, indipendentemente dalfornitore che li mette a disposizione. L’utilizzo dei servizi porta i seguenti vantaggi:

• Varietà L’utilizzo di un’interfaccia generica per l’accesso ai dati favoriscel’acquisizione di informazioni da fonti diverse. In questo modo è possibileottenere dei dataset più ampi

• Integrabilità Ogni servizio restituisce i dati secondo una propria rappresenta-zione. Avere un unico metodo di accesso ai dati permette anche di descriverecome queste informazioni devono essere trattate una volta ricevute. Que-sto passaggio permette di uniformare le rappresentazioni fornite in ingresso,in modo tale che siano trasformate in una forma più idonea per le futureelaborazioni

50

3.5. Modello del contesto

• Completezza Acquisendo informazioni da diverse fonti è possibile otteneredegli elementi duplicati. Questa caratteristica potrebbe sembrare un difettomentre in realtà fornisce una risorsa molto importante: la possibilità di otte-nere degli elementi più completi. Diverse fonti possono essere utilizzate peracquisire informazioni di tipologia diversa, in modo da generare un elementodescritto in maniera più precisa e che colga maggiori aspetti

Questa scelta permette inoltre di dividere l’acquisizione dei dati in due passaggi:i) acquisizione delle informazioni principali; ii) acquisizione di dati che vanno adarricchire le informazioni principali.

In particolare verrà utilizzato uno schema che permette di descrivere come acce-dere alle risorse messe a disposizione da un servizio e come interpretare le rispostericevute. Questo formalismo possiede il vantaggio di essere utilizzabile per entrambele casistiche presentate.

3.5 Modello del contesto

Il progetto CAMUS usa il Context Dimension Tree come modello per la rappre-sentazione del contesto. In questa sezione si vogliono mettere in evidenza le modifi-che rese necessarie per adattare il modello alle esigenze del progetto. In particolare,oltre alla classificazione dei nodi originale del CDT, viene aggiunta un’ulteriore di-visione in base al ruolo che un nodo può assumere durante la fase di selezione deiservizi:

• Nodo filtro È la tipologia predefinita. I nodi di tipo filtro permettono, comesi può dedurre dal nome, di filtrare i servizi che sono idonei all’utilizzo in undeterminato contesto

• Nodo ranking Questa tipologia viene assegnata ad alcuni nodi specifici, comequello relativo alla località, che assumono una maggiore importanza durantela selezione dei servizi, in quanto permettono di scegliere dei servizi che hannoun maggior impatto nel contesto specifico. Per esempio un nodo relativo allalocalità permette di dare maggiore rilevanza ai servizi che sono più attinenti alluogo e che quindi forniscono delle informazioni più accurate

3.6 Creazione dell’ecosistema dei servizi

I servizi rappresentano un punto cardine del sistema, in quanto mettono a di-sposizione le risorse che verranno mostrate all’utente. Si è deciso di suddividerli indue categorie ben distinte, in base alla loro funzionalità:

51

3. Metodologia CAMUS

1. Primari Sono i servizi che vengono interrogati in prima istanza per acquisire leinformazioni di interesse per il contesto nel quale si trova l’utente. Per esempio,se si effettua la ricerca di un ristorante, le informazioni principali saranno ilnome del ristorante, l’indirizzo e il numero di telefono. TripAdvisor1 e Zomato2

sono due esempi di servizi primari

2. Supporto Sono i servizi che vengono utilizzati per arricchire le informazio-ni acquisite tramite i servizi primari. Possono mettere a disposizione datiaggiuntivi, contenuti multimediali (es.: foto e video) oppure possono fornireun’integrazione con altre app presenti sul dispositivo. Alcuni esempi di servizidi supporto sono quindi in grado di fornire informazioni sul meteo, la map-pa del luogo o le indicazioni dei mezzi di trasporto per raggiungere il posto.Invece l’apertura del dialer telefonico quando viene selezionato il numero ditelefono o l’utilizzo dell’app di navigazione preferita quando si sceglie un indi-rizzo rappresentano degli esempi di integrazione con altre app, che assumonopur sempre il ruolo di servizi di supporto anche se disponibili in locale suldispositivo dell’utente

Per quanto queste categorie rappresentino una divisione molto precisa dei servi-zi, non vengono considerate come rigide. Come già evidenziato in [27], ogni servizioespone una o più operazioni e non è detto che tutte rientrino nella medesima ca-tegoria. Può capitare che un servizio metta a disposizione un’operazione che vieneconsiderata primaria e un’altra che invece fornisce informazioni di supporto. Si èdeciso quindi di non effettuare una categorizzazione a livello di servizio, bensì perogni operazione, in modo da garantire una maggiore flessibilità.

Per coerenza, d’ora in avanti verrà utilizzata la nomenclatura operazione prima-ria per riferirsi alle operazioni che forniscono le informazioni principali e operazionedi supporto per le operazioni che arricchiscono le informazioni primarie.

Per l’acquisizione dei dati è importante che il server sappia come interrogare iservizi e come interpretare le risposte. Si è deciso dunque di creare una repositorycomposta dai descrittori dei servizi, che contengono le informazioni necessarie per lagestione di tutti i servizi che possono essere utilizzati dal sistema. Ogni descrittoreè composto da una prima parte relativa alle informazioni del servizio (es.: nome,categoria, url base, ecc.) e da una parte costituita dall’elenco delle operazioni cheespone. La specifica delle operazioni fornisce le seguenti informazioni che permettonodi effettuare le richieste:

• Elenco dei parametri Per interrogare l’operazione di un servizio è necessariocomporre una query con i dati che si vogliono richiedere. Queste informazio-ni sono dipendenti dalla specifica implementazione del servizio e variano tra

1TripAdvisor: https://www.tripadvisor.it/2Zomato: https://www.zomato.com/it

52

3.6. Creazione dell’ecosistema dei servizi

diversi servizi. Nel descrittore vengono dunque elencati i parametri necessariper la composizione della query e dove andare a recuperare i relativi valori.L’acquisizione dei valori può avvenire secondo tre differenti modalità:

1. Default Il valore viene impostato direttamente nel descrittore (es.: l’APIkey per l’autenticazione)

2. Mapping CDT Viene definita l’associazione con uno o più nodi del CDT eil valore viene recuperato in base alla selezione effettuata dall’utente (es.:le coordinate geografiche). Questi valori possono essere eventualmentetrasformati da quelli simbolici del contesto a un’altra rappresentazioneadatta per effettuare la query (es.: al valore “Restaurant” del contestoviene associata la tipologia “food”)

3. Mapping Term Questa modalità viene utilizzata esclusivamente per i ser-vizi di supporto e fornisce un placeholder nelle query che verrà rimpiazzatoa runtime con il valore reale acquisito dalla risposta o dal dispositivo. Peresempio, se vogliamo ottenere l’indicazione del tempo necessario per rag-giungere in bus il ristorante “Vietnamonamour” dalla posizione corrente,l’url da interrogare assumerà la forma http://www.example.com/maps/api/directions/json?origin=45.4789205,9.2343392&destination=45.4815105,9.220423&transit_mode=bus, dove in ori-gin vengono inserite le coordinate di dove si trova l’utente mentre in de-stination vengono aggiunte le coordinate del ristorante da raggiungere.Quindi al parametro origin vengono associati i termini “device_latitude”e “device_longitude”, che corrispondono alle coordinate del dispositivo,mentre al parametro destination vengono associati i termini “latitude”e “longitude”, che verranno recuperate a runtime dalla descrizione delristorante. L’URL che riceverà il dispositivo sarà simile alla seguente:http://www.example.com/maps/api/directions/json?origin=device_latitude, device_longitude&destination=latitude,longitude&transit_mode=bus

• Schema della risposta Per ottenere omogeneità tra le risposte ottenute daidiversi servizi, i dati ricevuti devono essere trasformati secondo uno schemacomprensibile dalla mobile app. Per effettuare questa trasformazione vengonoin aiuto i termini (es.: titolo, indirizzo, descrizione, ecc.), che rappresentanole classi semantiche di appartenenza degli attributi. L’elenco dei termini di-sponibili viene mantenuto in una repository come per i descrittori dei servizi.Queste annotazioni hanno una duplice utilità: in primo luogo, definendo il si-gnificato di ogni attributo, semplificano l’integrazione dei dati provenienti dadiversi servizi, in secondo luogo semplificano la creazione dei mashup, comeverrà approfonditamente trattato nella Sezione 3.11, in quanto permettono di

53

3. Metodologia CAMUS

ragionare su categorie astratte rispetto a dati reali forniti dai vari servizi eagevolano la riusabilità degli schemi in diversi contesti

• Gestione della paginazione I dati che vengono restituiti a seguito di unaquery possono essere molteplici. Per semplificare la gestione delle risposte, iservizi implementano delle politiche di paginazione, dove vengono specificatiil numero di risultati che si vogliono ottenere in una pagina e un numero cheindica la pagina che è stata richiesta [29]. Questa sezione serve appositamen-te per indicare quali sono i parametri che vengono utilizzati dal servizio perrichiamare le diverse pagine che compongono i risultati

3.7 Associazione dei servizi al contesto

Una volta che i servizi sono stati aggiunti alla repository è necessario specificarele associazioni che permettono la selezione dei servizi in base al contesto nel qualesi trova l’utente.

Nel modello originale del CDT, presentato nella Sezione 2.1.1.1, il processo diselezione dei dati rilevanti per un determinato contesto avveniva tramite la defi-nizione di viste, che venivano create in linguaggio SQL e associate ai nodi valore.Come evidenziato anche nella precedente ricerca [27], questa metodologia non è piùapplicabile principalmente per due motivi:

1. Si vuole rendere il funzionamento del sistema il più semplice possibile affin-ché possa essere utilizzato da persone che non hanno profonde conoscenze diinformatica, la scrittura di query in SQL non è alla portata di chiunque

2. Non avendo a disposizione direttamente i dati, bensì i servizi da invocare peracquisirli, la selezione tramite viste non è la più idonea a essere utilizzata

Il nostro approccio prevede di mappare ai vari nodi dell’albero del contestol’elenco delle operazioni definite nel descrittore dei servizi. In questo modo vienedefinita una strategia sì semplice ma allo stesso tempo funzionale, in quanto per-mette di definire con una buona libertà i contesti nei quali ha senso di richiamareun’operazione.

Le operazioni vengono mappate unicamente sui nodi di tipo valore, perché sonoquelli che definiscono un contesto specifico. Non vengono invece imposti vincoli sullivello dei nodi verso i quali effettuare le associazioni. Generalmente le operazionivengono mappate nei nodi foglia ma, se un’operazione è valida per più di un contesto,può essere aggiunta in un nodo valore che ha uno o più figli. Per poter essereselezionata, un’operazione deve essere mappata in almeno un nodo. Non viene inveceimposto nessun limite superiore, in quanto un’operazione può appartenere a tantinodi quanti sono i contesti nei quali è corretto che venga richiamata. Un’operazione

54

3.7. Associazione dei servizi al contesto

non può essere aggiunta più volte all’interno di un nodo, in quanto è sufficiente chevenga mappata una sola volta affinché l’operazione venga presa in considerazionedurante la fase di selezione.

Questo metodo è utile nella maggior parte dei casi per coprire le situazioni piùcomuni. In alcuni casi però è necessario prevedere dei meccanismi di selezione piùcomplessi. Un esempio è dato dalle coordinate geografiche: quando si ha a che farecon un servizio locale è bene che venga associato in modo che il servizio sia messo inrisalto in quella zona, per due motivi in particolare: i) all’esterno di quest’area nonprodurrebbe risultati; ii) deve essere messo in risalto se l’utente si trova nel suo raggiod’azione, in quanto può fornire delle informazioni più accurate riguardo la zona.CAMUS prevede questo caso e in particolare è possibile mappare un’operazione auna specifica latitudine e longitudine, che rappresentano solitamente il centro dellacittà. Il sistema utilizza queste informazioni per definire una circonferenza, concentro dato dalle coordinate, e utilizza un raggio preimpostato al fine di selezionaretutti i servizi che rientrano nell’area definita.

Questo è solo un esempio di associazione particolare e potrebbero esisterne diulteriori: il sistema è stato progetto in modo che sia estendibile tramite funzio-ni sviluppate ad-hoc che possano gestire questi casi particolari. Ulteriori dettaglisull’implementazione verranno analizzati nella Sezione 5.4.

Esistono delle distinzioni in base alla tipologia di operazione, se primaria o disupporto, in quanto cambia l’algoritmo di selezione.

Per quanto riguarda le operazioni primarie, quando vengono associate a un de-terminato contesto viene definito anche un indice di priorità: questo valore è unnumero intero, a partire da 1 e crescente all’interno del singolo nodo, che definiscel’importanza che il servizio assume in quel determinato contesto e verrà utilizzatonella fase di selezione dei servizi illustrata nella Sezione 3.9. Ha senso utilizzarequesto indicatore ha senso di essere utilizzato esclusivamente nei nodi valore, inquanto contengono una raccolta generica di servizi, mentre per i nodi attributo nonè necessario, poiché l’ordinamento all’interno di una categoria di attributi non èsempre univoca. Se si prende per esempio un elenco di servizi mappati su una cittàtramite le sue coordinate geografiche, si può considerare come indice di priorità lalontananza rispetto all’utente, che può essere calcolata solamente a runtime e puòvariare spesso.

Una menzione particolare viene riservata alla dimensione Interest Topic. Comeprecedentemente esposto nella Sezione 3.5, il modello del contesto deve essere ingrado di adattarsi a diversi ambiti di utilizzo. Gli Interest Topic fungono proprio dadescrittori delle situazioni principali nelle quali l’utente può trovarsi. Un contestospecifico può essere molto complesso: gli Interest Topic hanno il vantaggio di per-mettere la definizione di una categoria di riferimento, sulla quale poi specializzarela ricerca secondo le altre caratteristiche del contesto attive. Alcuni esempi di Inte-

55

3. Metodologia CAMUS

rest Topic sono i “Ristoranti”, gli “Hotel”, i “Musei”, ecc. Al fine di far rispettarequesta classificazione è stato introdotto il vincolo che ogni operazione primaria de-ve obbligatoriamente essere aggiunta ad almeno un Interest Topic. Viceversa nonviene imposto un vincolo sul numero di Interest Topic differenti ai quali può esseremappata un’operazione, in quanto può essere valida per ambiti differenti.

Per le operazioni di supporto non è sempre necessario che siano mappate coni nodi del CDT. Alcuni operazioni di supporto possono essere richiamate in modostatico quando non necessitano del contesto per essere scelte (es.: i servizi genericicome Wikipedia3 o Flickr4). Per altre operazioni, come per esempio quelle relativeai mezzi di trasporto, è invece necessario basarsi sul contesto per selezionare la piùidonea alla situazione. Per esempio, se un utente specifica che non dispone di un’autoe che si trova a Milano, allora il sistema proporrà i mezzi di trasporto pubblicipresenti nella città, insieme all’elenco di altre tipologie di trasporto come i taxi oil car sharing. In questo caso è dunque necessario, come nel caso delle operazioniprimarie, mappare le operazioni con i nodi del CDT. Il processo è dunque similea quello delle operazioni primarie, con la differenza che non bisogna specificare lapriorità dei servizi.

Figura 3.2: Associazione dei servizi al CDT

In Figura 3.2 viene mostrato un esempio di associazione. Viene rappresentatoun contesto nel quale è possibile richiedere informazioni su ristoranti, cinema, teatrie musei. Sotto a ogni Interest Topic vengono evidenziate, nei blocchi tratteggiati,le operazioni che sono state mappate allo specifico nodo. Si può notare come a ognioperazione venga assegnato un numero, che corrisponde alla priorità che ha nellacategoria.

Per i ristoranti viene data anche la possibilità di scegliere la tipologia di cucinache si preferisce. Con questi valori non vengono effettuate associazioni: infatti questeselezioni verranno utilizzate come parametro per i servizi.

3Wikipedia: https://en.wikipedia.org/wiki/Main_Page4Flickr: https://www.flickr.com/

56

3.8. Albero di contesto su misura per gli utenti

Un’altra dimensione importante è la Località, che definisce il punto nel qualesi trova l’utente. Per rappresentare un posto vengono utilizzate le sue coordinate,che sono memorizzate nel parametro CityCoord, il quale a sua volta viene specia-lizzato nei campi Latitudine e Longitudine. In questo caso la mappatura dei serviziavviene definendo le coordinante del centro della città desiderata. Per semplificarel’immagine, è stato utilizzato il valore “Milan”, per associare l’operazioni di ricercadei teatri per Milano. In realtà andrebbero utilizzate le coordinate del centro città,che sono (45.46427, 9.18951).

Infine, con le dimensioni Trasporto e Tipologia Trasporto vengono definite leassociazioni con le operazioni di supporto. La principale differenza con il caso delleoperazioni primarie è che non viene definito nessun valore di priorità.

3.8 Albero di contesto su misura per gli utenti

Il modello del CDT definito nella Sezione 3.7 viene chiamato CDT Universale,in quanto fornisce la rappresentazione del contesto più completo del quale il sistemadispone. Questo CDT deve descrivere tutti i possibili contesti che si vogliono gestire;possono coesistere diversi ambiti in parallelo, con le relative dimensioni che vannoa specializzare il dominio generale. Com’è facilmente intuibile, questo schema puòdiventare di enormi dimensioni, quindi inutilizzabile per via della moltitudine diselezioni possibili. Inoltre emerge il problema dei contesti non validi, cioè queicontesti che non possono esistere nella realtà. Per esempio, scegliere come InterestTopic la ricerca di “Ristoranti” e selezionare di voler fare un viaggio “Rilassante”non è un contesto valido, in quanto la dimensione “Tipologia di Viaggio” ha sensoche sia attiva solo quando viene selezionato come Interest Topic quello relativo aiviaggi. Queste due problematiche vanno in senso contrario con i principi di usabilitàe semplicità che sono stati presi come linee guida per il progetto.

Una prima soluzione consiste nell’introdurre l’elenco delle dimensioni che è con-sentito accoppiare con un Interest Topic. In questo modo, nella fase di scelta delledimensioni che si vogliono attivare, l’interfaccia grafica può essere aggiornata in se-guito a ogni selezione, mostrando solamente le dimensioni che è possibile sceglieresenza generare conflitti. In questo modo si risolverebbero entrambi i problemi sopracitati, in quanto l’elenco delle dimensioni consentite permette di ridurre il numerototale di contesti generabili e impedisce la selezione di dimensioni che porterebberoa effettuare delle selezioni erronee.

Per quanto questa soluzione sia tecnicamente valida, rimane aperta un’ulteriorequestione: all’utente potrebbero venire proposte comunque una serie di opzioni chenon sono di suo interesse. Per esempio, un utente deve pianificare un viaggio e nonpossiede animali e nel CDT viene definita una dimensione “Con Animali Domestici”,per specificare che bisogna cercare strutture che ammettano l’accesso anche agli

57

3. Metodologia CAMUS

animali. In questa situazione verrebbe ogni volta proposta la selezione del possessoanimali all’utente, scelta che dovrebbe essere sempre omessa in quanto non utilenella descrizione del contesto di quello specifico utente.

È proprio per risolvere questa ulteriore problematica, relativa più al profilo spe-cifico di ogni utente, che si è pensato di far entrare in gioco la figura dell’espertodi settore: l’esperto è la persona alla quale si deve rivolgere l’utente per ottenereuna personalizzazione dell’app. Come verrà descritto nella Sezione 3.11, l’espertodi settore è anche colui che ha il compito di adattare l’aspetto della mobile app,andando a modificare lo schema di mashup. Si è deciso dunque che si tratta dellafigura più indicata anche per adattare il contesto al profilo specifico di ogni utente.Nasce quindi l’idea di creare dei CDT specifici per gli utenti, che mostrano solamen-te le dimensioni che sono di loro interesse. Questi CDT vengono definiti come CDTsu misura o Tailored CDT. In pratica, all’esperto di settore viene dato il compitodi eliminare le dimensioni che non sono utili all’utente e che creerebbero solamenteconfusione. Questi alberi di contesto vengono creati a partire dallo schema globale emodificati dall’esperto di settore appositamente per uno specifico utente. Oltre allapossibilità di eliminare le dimensioni del contesto non necessarie, viene data anchela libertà di effettuare ulteriori modifiche per migliorare l’esperienza dell’utente:

• Viene data la possibilità di impostare dei valori predefiniti. Questa caratteri-stica è sempre correlata con il profilo dell’utente e da un certo punto di vista èun problema simile a quello esposto in precedenza riguardo le dimensioni noninteressanti. In questo caso però, invece che rimuovere totalmente un ramodell’albero, viene assegnato un valore che rimane sempre valido. Questa ca-ratteristica è molto importante, ed è utile che coesista insieme alla possibilitàdi rimuovere le dimensioni non interessanti. Si prenda per esempio un utenteche non dispone di un proprio mezzo di trasporto: in questo caso non si puòrimuovere completamente la dimensione che riguarda i Trasporti, in quantoall’utente può sempre interessare come muoversi con i mezzi pubblici. È in-vece più conveniente fissare il valore “Trasporto Pubblico” per segnalare chel’utente utilizzerà sempre i mezzi di trasporto pubblici per raggiungere i luoghidi suo interesse, in modo che l’app generata permetta soltanto di sceglierne latipologia, e non scegliere il trasporto con mezzi propri

• È possibile inoltre modificare le associazioni delle operazioni con i nodi delCDT, comprese, solo per le operazioni primarie, le priorità che assumonoall’interno di ogni nodo. Questa funzionalità tende a sfruttare in manierapiù marcata le conoscenze dell’esperto di settore per migliorare la qualità deirisultati ottenuti dal sistema. Può essere utilizzata per diversi scopi, comefavorire l’uso di determinati servizi rispetto ad altri o sostituirne alcuni che inuna certa località non sono disponibili o non forniscono dei buoni risultati.

58

3.9. Selezione delle operazioni in base al contesto

3.9 Selezione delle operazioni in base al contesto

Nelle precedenti sezioni è stato spiegato come è possibile aggiungere nuovi servizinel sistema, come vengono associati al contesto e infine come è possibile personaliz-zare il contesto in base alle preferenze dei singoli utenti.

Resta da definire il metodo col quale a runtime questi servizi vengono selezionati.Questa fase è una tra le più importanti all’interno di CAMUS, in quanto la selezionedei servizi da utilizzare impatta in maniera preponderante sulla qualità e rilevanzadei dati che verranno mostrati all’utente. È necessario quindi definire un algoritmoche tenga conto della situazione nella quale si trova l’utente e, a partire da questa,selezioni le operazioni più idonee a soddisfare la richiesta.

Si ricorda che un contesto è formato dalla congiunzione tra uno o più elementidel contesto, che a loro volta sono formati dalla dimensione di riferimento e dalvalore o parametri che essa assume. In Figura 3.3 viene mostrato un esempio dicontesto in cui si vogliono cercare i ristoranti con cucina a base di pesce nei dintornidi Lambrate.

C = InterestTopic : Restaurant ∧RestaurantType : SeaFood ∧Transport : PublicTransport ∧Location (Latitude : ‘‘45.478897” ∧ Longitude : ‘‘9.2342429”)

Figura 3.3: Esempio di contesto

Un contesto può essere dunque visto come un elenco di coppie <dimensione,valore>, che rappresentano i nodi selezionati dall’utente. La ricerca delle associazioniche hanno validità nelle singole coppie avviene tramite una ricerca chiave-valore,dove la chiave è l’etichetta della dimensione mentre il valore è il valore specificoassunto dalla dimensione, tra le associazioni definite nell’albero di contesto.

Questo metodo non è sempre utilizzabile: come già introdotto nella Sezione 3.7esistono alcune associazioni particolari che necessitano di apposite funzioni per esserericercate. L’elenco generato da queste funzioni viene integrato con quello prodottodalla ricerca tramite <dimensione, valore>.

Una menzione particolare va fatta al caso dei nodi contesto che hanno dei figli.Visto che la maggior parte delle associazioni viene definita sui nodi foglia, selezionareun nodo che non sia foglia porterebbe a non trovare nessuna associazione. Lo pseu-docodice utilizzato per la selezione dei nodi figlio viene presentato nell’Algoritmo3.1. L’idea è che se un utente seleziona un nodo a un livello superiore significa che èindifferente rispetto alle sue specializzazioni, che dunque devono essere a loro voltaconsiderate.

59

3. Metodologia CAMUS

Algoritmo 3.1 Algoritmo di ricerca dei nodi figlioRequire:

cdt ▷ The decorated CDTnodes ▷ The list of active nodes

Ensure:childList ▷ List of child nodes found

nodeV alues← nodes.map(′value′) ▷ Acquire list of values selectedfor all item in cdt.context do

intersection← intersect(item.parents, nodeV alues)if !isEmpty(interesection) then

for all value in item.values dochildList.push(

name : item.name,value : value

)end for

end ifend forreturn childList

Ogni nodo ha associato l’elenco di nodi dai quali discende, a partire dalla radice.Viene controllato nell’albero del contesto se esistono dei nodi che hanno nel loroelenco dei parenti uno dei nodi che sono stati scelti dall’utente. Ogni nodo chesoddisfa questa regola viene a sua volta selezionato.

Figura 3.4: Esempio gerarchia

In Figura 3.4 viene mostrato un esempio di albero. Nel caso in cui l’utente scel-ga un qualsiasi nodo foglia la selezione avviene come nei casi esposti. Invece peril contesto C = MezziTrasporto : TrasportoPubblico deve essere trattato separa-tamente, in quanto il valore Trasporto Pubblico possiede un nodo figlio. In questocaso la selezione del valore Trasporto Pubblico significa che per l’utente è indifferen-

60

3.9. Selezione delle operazioni in base al contesto

te prendere una tipologia di mezzo piuttosto che un’altra. Il problema che emergeriguarda le associazioni con le operazioni: come si può notare nell’esempio, le ope-razioni vengono associate solamente ai nodi foglia. Quindi il contesto precedenteporterebbe alla selezione di nessuna operazione. Per risolvere questo problema vienedefinito che, quando viene selezionato un nodo che ha dei figli, tutti i suoi discendentivengono automaticamente selezionati. In definitiva, il precedente contesto diventaC ′ = MezziTrasporto : TrasportoPubblico ∧ Tipologia : Bus ∧ Tipologia : Taxi.

Come già evidenziato nella Sezione 3.7, le associazioni vengono effettuate seguen-do due approcci differenti in base alla tipologia dell’operazione, primaria oppure disupporto. Il motivo principale risiede nel fatto che queste tipologie di operazionehanno scopi differenti e necessitano dunque di due approcci di selezione appositi. Diseguito vengono analizzati entrambi i metodi utilizzati in CAMUS, concentrandosisu di una tipologia di operazione alla volta. Si parte dal presupposto che sia giàstata eseguita la ricerca delle associazioni esposta in precedenza.

Operazioni primarie

Come esposto nella Sezione 3.7, ogni operazione viene associata a uno o piùnodi dell’albero di contesto e a ognuna di queste associazioni viene assegnato unvalore che rappresenta la priorità che l’operazione assume all’interno del nodo. Ilprimo passo per la selezione delle operazioni è l’assegnazione di un punteggio a ognioperazione che ha una o più corrispondenze all’interno dell’albero di contesto.

La ricerca delle associazioni fornisce come risultato un elenco delle operazioni chesono adatte all’utilizzo nello specifico contesto, assieme al relativo valore di priorità,per ogni associazione trovata. È necessario introdurre un ulteriore parametro cheinfluisce nella formula per l’assegnamento del punteggio alle operazioni: il peso deinodi. Come definito nella Sezione 3.5, vengono introdotte tre nuove tipologie di nodo:filtro, ranking e interestTopic. Le associazioni trovate tramite funzioni personalizzatevengono sempre intese come nodi di tipo ranking. Il peso di un nodo viene assegnatoin base alla tipologia del nodo, rispettando il vincolo:

wFILTRO < wRANKING < wINTEREST_TOPIC ∀ n ∈ CDT

In pratica a ogni nodo filtro deve essere assegnato un peso strettamente minorerispetto a un nodo ranking, che a sua volta deve essere inferiore al nodo relativol’Interest Topic. Quest’ultima tipologia viene utilizzata esclusivamente per il nodoche rappresenta l’Interest Topic. La sua introduzione è stata necessaria per dare unpunteggio base alle operazioni che hanno senso di essere selezionate: se non fossepresente, potrebbero essere scelte alcune operazioni appartenenti a Interest Topic

61

3. Metodologia CAMUS

differenti. Il punteggio R di ogni operazione o viene calcolato tramite la funzione:

Ro =∑

i∈SA(o)

wi

pi(3.1)

dove SA(o) rappresenta l’insieme dei nodi associati all’operazione o, wi e pi rap-presentano rispettivamente il peso e il valore di priorità dell i-esimo nodo. Una voltacalcolati i punteggi, l’elenco delle operazioni viene riordinato in modo decrescente evengono selezionati le top-N operazioni. In Figura 3.5 viene definito un contesto diesempio con le associazioni delle operazioni primarie ai vari nodi dell’albero.

Figura 3.5: Esempio di assegnazione del punteggio per le operazioni primarie

Al nodo “Interest Topic” viene assegnata la sua tipologia particolare, il nodo“Momento Giornata” è di tipo filtro mentre il nodo “Località” è di tipo ranking(come evidenziato dalla diversa forma utilizzata). I nodi foglia di colore grigio sonoquelli selezionati, che corrispondono al contesto C = InterestTopic : Ristoranti ∧Localita : Milano ∧ MomentoGiornata : Cena. Dalla fase di ricerca vengonoselezionate le operazioni dei servizi TripAdvisor, Zomato, Y elp. Considerandocome pesi dei nodi wFILTER = 1, wRANKING = 4 ewINTEREST_TOPIC = 6, viene calcolato il punteggio per ogni operazione:

RTripAdvisor =5

1+

1

1= 6

RZomato =5

2+

4

1=

13

2= 6, 5

RY elp =5

3+

1

2=

13

6≈ 2, 16

Riordinando la lista si ottiene Zomato, TripAdvisor, Y elp e scegliendo i top-2risultati si ottiene la selezione finale Zomato, TripAdvisor.

62

3.9. Selezione delle operazioni in base al contesto

Operazioni di supporto

A differenza delle operazioni primarie, per quelle di supporto non viene definitoun valore di priorità. Quindi la precedente funzione per il calcolo del punteggionon è applicabile. È stata inoltre considerata un’ulteriore problematica per la qualela precedente funzione non è utilizzabile. Per esempio, si consideri un servizio disupporto che fornisce indicazioni sui mezzi di trasporto pubblici. Molti di questiservizi hanno validità locale, infatti ogni città ha il proprio gestore per il serviziodi trasporto pubblico (es. ATM5 per Milano e ATAC6 per Roma). Quindi, nellafase di calcolo del punteggio, anche questi servizi verrebbero considerati e in alcunesituazioni erroneamente selezionati come risultato finale. Si è optato per un metododi selezione più rigido rispetto al caso delle operazioni primarie. In questo caso laricerca delle associazioni produce un elenco di operazioni senza altri dati annessi. Diquesta lista viene successivamente effettuato il conteggio del numero di associazionitotali per ogni operazione. A ogni operazione viene inoltre conservato il numerominimo di associazioni che devono essere rispettate. Vengono selezionate solamentele operazioni che rispettano le seguenti regole:

1. le operazioni hanno un conteggio pari al numero minimo di associazioni e ilvalore del conteggio è pari al valore massimo trovato tra tutte le associazioni

2. se il primo filtro non ha prodotto risultati, vengono selezionate le operazioniche hanno un conteggio superiore al numero minimo di associazioni, restituitein ordine decrescente secondo il valore del conteggio

In questo modo vengono definite due regole, la prima più restrittiva mentre laseconda, che viene applicata solamente nel caso la prima non produca risultati,permette di avere libertà maggiore.

La prima regola permette di ottenere risultati che rispettano esattamente il nu-mero minimo di associazioni imposto. Preferire le operazioni con il valore più altodel conteggio permette la selezione delle operazioni che sono maggiormente conformial contesto corrente.

Nel caso questa ricerca non sia soddisfatta entra in gioco la seconda regola. Inquesto caso viene semplicemente imposto che il valore del conteggio sia maggiorerispetto al numero minimo di associazioni. L’elenco delle operazioni viene ordinatoin modo decrescente sempre in base al valore del conteggio, per mettere in risalto,come nel caso precedente, le operazioni più attinenti al contesto.

L’introduzione di questa seconda regola nasce dall’esigenza dettata dal fatto cheun’operazione può essere associata a più di un nodo dell’albero. Questa affermazioneviene chiarita meglio dal seguente esempio. Si ipotizzi che un’operazione sia associata

5ATM: www.atm.it6ATAC: www.atac.it

63

3. Metodologia CAMUS

a due nodi, entrambi figli dello stesso padre, e questo nodo padre discenda da unaltro nodo. A questa operazione verrà dunque assegnato un numero minimo diassociazioni pari a uno, perché è sufficiente che uno dei due nodi sia selezionatoaffinché l’operazione possa essere scelta. Tuttavia l’utente può selezionare ancheil nodo dal quale il padre discende e anche in questo caso l’operazione può essereselezionata. Questa selezione porterebbe invece a un conteggio pari a due e quindi laprima regola scarterebbe l’operazione in quanto non ha il valore del conteggio pari alnumero minimo di associazioni. Il secondo vincolo permette di gestire correttamenteanche questa evenienza.

In Figura 3.6 viene mostrato un contesto di esempio con le associazioni delleoperazioni di supporto ai vari nodi dell’albero.

Figura 3.6: Esempio di selezione delle operazioni di supporto

I nodi attivi sono evidenziati in grigio ed equivalgono al contesto C = Tipologia

Mezzo : Bus ∧ Localita : Milano. Per le operazioni ATM e ATAC vengono defi-nite due associazioni, mentre per le operazioni FS7 e Baltour8 viene effettuata unasingola associazione. La fase di ricerca restituisce le operazioni ATM con conteggiopari a due e le operazioni ATAC e Baltour entrambe con conteggio pari a uno. Leoperazioni che hanno un valore del conteggio pari al numero minimo di associazionisono ATM e Baltour. Alla fine verrà selezionata solamente l’operazione relativa alservizio ATM, in quanto possiede il valore massimo del conteggio. Come si può nota-re, quest’ultimo filtro permette di selezionare le operazioni che hanno una maggiorerilevanza per il contesto corrente, escludendo le operazioni che forniscono risultatimeno precisi.

3.10 Integrazione dei dati

Una volta selezionati i servizi che più si adattano al contesto dell’utente, il passosuccessivo è interrogarli per acquisire le risposte. Dopo che sono state ricevute leinformazioni si presenta un nuovo problema: ogni servizio ha il proprio formato di

7Ferrovie dello Stato: http://www.trenitalia.com/8Tour operator di bus su tutta Italia: www.baltour.it

64

3.10. Integrazione dei dati

risposta. È necessario dunque fare sì che tutte le risposte vengano trasformate inuna rappresentazione comune tale che sia utilizzabile dalla mobile app. Al fine dieffettuare questa trasformazione vengono utilizzati una serie di termini semantici:questi termini permettono di identificare univocamente una risorsa all’interno del-le varie rappresentazioni ricevute, associando a ogni attributo il rispettivo valoresemantico. Come precedentemente introdotto nella Sezione 3.6, le associazioni tragli elementi di una risposta e il termine di riferimento viene definito nel descrittoredel servizio. In seguito alla trasformazione viene creato un set di risposte unificato,composto da tutti i dati ricevuti dai servizi.

Un ulteriore problema che si è dovuto affrontare riguarda gli elementi duplicati:può accadere che due o più servizi restituiscano dati relativi a una stessa entità.Questi dati duplicati devono essere fusi assieme a formare una singola istanza. Iltermine “fondere” viene usato di proposito, in quanto anche gli elementi duplica-ti possono essere utilizzati per arricchire le informazioni ottenute. Si prenda peresempio due servizi che restituiscono il medesimo ristorante: il primo fornisce infor-mazioni sul nome del ristorante, l’indirizzo e il numero di telefono mentre il secondomette a disposizione sempre il nome, l’indirizzo, l’url del sito web e l’indirizzo email.Come si può notare non è conveniente semplicemente ignorare uno dei due risultatiin quanto si perderebbero alcuni informazioni che possono essere rilevanti. La pro-cedura che viene adottata in questi casi è quella appunto di fondere i due elementi.Resta da definire come comportarsi nel caso dei dati in comune tra gli elementi.Nell’esempio precedente si tratta del nome del ristorante e del suo indirizzo. Inquesta situazione entra in gioco il punteggio del servizio calcolato come descrittonella Sezione 3.9. Vengono mantenute solamente le informazioni in comune fornitedal servizio col punteggio più elevato. Questa scelta ha una semplice spiegazione: siipotizza che il servizio col punteggio migliore fornisca i dati più affidabili rispetto aun altro servizio con un punteggio inferiore.

L’altro punto importante nella ricerca degli elementi duplicati riguarda il nume-ro di confronti da eseguire. Infatti, per effettuare un’analisi approfondita sarebbenecessario analizzare tutte le possibili coppie di elementi, un algoritmo con com-plessità temporale O(n2). Tuttavia alcuni confronti potrebbero essere evitati. Peresempio, se due ristoranti hanno un nome completamente diverso, è ovvio che nonpossono essere duplicati.

Come mostrato dallo pseudocodice dell’Algoritmo 3.2, per evitare i confrontiinutili il dataset viene diviso in vari “bucket”. All’interno di questi bucket vengonoinseriti gli elementi che hanno una certa somiglianza tra loro. Questa tecnica vienechiamata blocking [30] e permette di migliorare l’efficienza dell’algoritmo, in quantosi occupa di separare l’intero dataset in porzioni ridotte in base alla somiglianzadegli elementi che ne fanno parte. Per assegnare ogni elemento a uno specificobucket viene utilizzato l’algoritmo denominato “Soundex” [31]. Questo algoritmo

65

3. Metodologia CAMUS

Algoritmo 3.2 Algoritmo di rimozione dei duplicatiRequire:

response ▷ The list of items receivedEnsure:

output ▷ The results list without duplicates

for all item in responses doclass_key ← Soundex(item.title)buckets.add(class_key, item)

end forfor all items in buckets do

len← items.lengthif len > 1 then

i← 0while i < len do

j ← i+ 1while j < len do

sim_value← calculateObjectSimilarity(items[i], items[j])if sim_value > threshold then

if items[i].rank ≥ items[j].rank thenitems[i]← mergeItems(items[i], items[j])items.remove(j)

elseitems[j]← mergeItems(items[j], items[i])items.remove(i)

end iflen← len− 1

elsej ← j + 1

end ifend whileoutput.push(items[i])i← i+ 1

end whileelse

output.push(items[0])end if

end forreturn output

66

3.10. Integrazione dei dati

genera un codice per ogni elemento in base alla pronuncia fonetica. Questo codiceviene utilizzato come chiave per l’assegnazione dell’elemento a uno specifico bucket.Per effettuare questa operazione viene utilizzato per il confronto esclusivamente ilcampo “titolo” dell’elemento.

Una volta che i bucket sono stati creati, è necessario effettuare una comparazionepiù approfondita all’interno dei singoli gruppi, in quanto l’appartenenza allo stessogruppo indica che esiste una certa affinità tra gli elementi ma non garantisce che sianoduplicati. Vengono dunque effettuate delle comparazioni tra ogni coppia di elementiappartenenti allo stesso bucket. Questa comparazione produce come risultato unvalore di similarità. Se questo valore è superiore a una soglia predefinita, alloragli elementi sono duplicati. Per calcolare l’indice di somiglianza viene utilizzato ilcoefficiente di Dice [32]. In questo caso vengono presi in considerazione tutti i campiche sono in comune tra gli elementi in analisi. Ogni volta che due elementi risultanocome duplicati vengono fusi tramite la tecnica descritta precedentemente.

Analizzando la struttura di questo algoritmo risulta che nel caso pessimo la com-plessità temporale resta sempre pari a O(n2), in quanto se tutti gli elementi hannoil medesimo codice fonetico verrebbero aggiunti in un singolo bucket, costringendo aeseguire tutti i confronti. Questa situazione è un caso limite: si assume infatti chegli elementi vengano distribuiti in modo uniforme all’interno dei bucket. In generei bucket saranno composti al massimo da un numero di elementi pari al numero diservizi interrogati. Infatti generalmente gli elementi duplicati appartengono a ser-vizi diversi. Questo valore può variare leggermente in alcuni casi particolari. Può

500

1000

1500

100 200 300Element number

Tim

e [m

s] Algorithm

New

Old

Time analysis

Figura 3.7: Tempi di esecuzione algoritmo di ricerca duplicati

67

3. Metodologia CAMUS

capitare per esempio che elementi distinti tra loro possano essere aggiunti allo stessobucket a causa della loro pronuncia fonetica simile. Nel caso medio si ottiene chequesto algoritmo abbia una complessità Ω(nm2), dove n rappresenta il numero dielementi e m la lunghezza massima di un bucket, con m ≪ n. In Figura 3.7 vieneconfrontata la versione “base” dell’algoritmo, in cui venivano effettuati i controllicoppia a coppia per tutti gli elementi, e quella “nuova”, con le ottimizzazioni attive.È stato utilizzato un dataset composto dall’elenco dei ristoranti di Milano provenien-te da quattro diversi servizi e con un elevato numero di elementi simili (81%). Comesi può notare il nuovo algoritmo ha un incremento lineare dei tempi di esecuzioneall’aumentare del numero di elementi, come ci si poteva aspettare.

Si è andati a effettuare anche un’analisi sulle prestazioni dell’algoritmo. A partireda un dataset composto da 100 ristoranti, acquisito da 4 differenti servizi e compostoper l’81% da elementi duplicati, si è verificato quali di questi elementi vengonocorrettamente etichettati come duplicati. Per valutare la bontà dell’algoritmo sonostati utilizzati i seguenti indicatori:

• Precision Rappresenta il rapporto tra i documenti pertinenti recuperati etutti i documenti recuperati

• Recall Rappresenta il rapporto fra il numero di documenti rilevanti recuperatie il numero di tutti i documenti rilevanti disponibili nella collezione considerata

Queste due misure permettono di fornire un’indicazione su come si comportal’algoritmo. Per calcolarle vengono utilizzate le seguenti formule:

Precision =TP

TP + FPRecall =

TP

TP + FN

Dove TP significa “True Positive”, FP sta per “False Positive” e FN per “FalseNegative”. In Tabella 3.2 viene chiarito il significato di questi parametri.

Tabella 3.2: Confusion Matrix

Predetto Positivo Predetto NegativoCondizione Positiva True Positive False NegativeCondizione Negativa False Positive True Negative

Per il caso in analisi i True Positive sono gli elementi correttamente identificaticome duplicati, i False Positive sono gli elementi che sono stati identificati comeduplicati ma non lo sono e False Negative sono gli elementi duplicati che non sonostati rilevati. L’unico parametro configurabile dell’algoritmo è il threshold, cioè lasoglia minima del valore di similitudine affinché due elementi vengano identificaticome duplicati. In Figura 3.8 vengono mostrati i risultati ottenuti.

68

3.11. Mashup Design

0.2

0.4

0.6

0.8

1.0

0.50.60.70.80.9Threshold

Val

ue

Measure

Precision

Recall

Precision / Recall

Figura 3.8: Prestazioni dell’algoritmo di ricerca dei duplicati

Alti valori del threshold permettono di avere una precision del 100%, il che si-gnifica che non sono presenti falsi positivi. Il contro è avere un valore di recallmolto basso: in pratica molti elementi duplicati non vengono identificati. Calibrareil valore di threshold è un compito delicato: bisogna cercare di bilanciare l’esigenzadi trovare il maggior numero di duplicati possibili con quella di non sbagliare lerilevazioni con elementi che sono estranei.

3.11 Mashup Design

Un altro aspetto fondamentale del sistema è legato all’utilizzo dei mashup percostruire le view dell’applicazione mobile e per associare a ogni singolo elemento delleviste il termine che caratterizza i dati da richiedere al server. Questo compito vienesvolto dall’esperto di settore per mezzo della web app di Visual Mapping (Figura3.9), la quale genera uno schema che definisce come e quali informazioni vengonomostrate all’utente.

È stato scelto di adottare due tipologie di schemi fondamentali, uno per la listadei risultati (UNION) e uno per i dettagli dell’elemento selezionato (MERGE), per-ché fondamentalmente sono queste due le pagine dell’applicazione che necessitanodi istanziare con i dati gli elementi visuali dei template. Gli schemi generati possonoessere ulteriormente differenziati per due motivi principali:

1. Il primo di essi è la tipologia dei dati, che nel nostro caso viene differenzia-ta usando il parametro dell’Interest Topic. Per esempio se viene selezionato

69

3. Metodologia CAMUS

Back Osteria Alla Grande

Osteria Alla Grande

Via delle Forze Armate 405, Milano

Drop the component here

[ Drop term here ]

Dropped Pin101 1/2 S Union St, Alexandria, VA 2...

SUPPORT COMPONENTSPRIMARY DATA

Title

Address

Phone Number

Description

Website

Menu

Mail

[ Drop address here ]

[ Drop telephone here ]

Food & Drink

Drop the images here

1

2

Figura 3.9: Web App di Visual Mapping

“Food and Drink” può essere necessario visualizzare dati diversi rispetto a“Museum”. Anche se ci sono attributi in comune, come Titolo, Indirizzo, Nu-mero di telefono, ci possono essere parametri peculiari, come il tipo di cucinaper il primo caso o il tipo di museo per il secondo caso. Questi dati possonoessere visualizzati quindi in maniera differente e si è scelto, oltre a una diffe-renziazione a livello di termini, anche di lasciare libertà di scelta per quantoriguarda il design del mashup

2. Il secondo aspetto è la possibilità di differenziare i dati da mostrare a livellodi utente, dato che non a tutti possono interessare le stesse informazioni op-pure può essere preferibile mostrare i dati e le view in maniera differente instili grafici e componenti. Infatti, una volta generato, lo schema dei mashupviene associato allo specifico utente, in modo da essere disponibile su richiestadella mobile app dopo che è stato effettuato l’accesso. Nella web app l’espertoseleziona l’utente per il quale deve generare l’applicazione e, in aggiunta allemodifiche al CDT evidenziate nella Sezione 3.8, carica gli schemi predefinitiche verranno utilizzati come base per lo schema personalizzato per l’utente.In questo modo ogni utente dell’applicazione può avere i propri mashup perso-nalizzati. Oltre alla definizione dei termini nei mashup, è possibile aggiungerele proprietà stilistiche la presentazione dei dati nelle view relative al singoloschema, se diverse da quelle definite globalmente

Lo schema delle view che è stato adottato è raffigurato nella Figura 3.10. A ogni

70

3.11. Mashup Design

Page

Type

Content

Style

0..1

1

1..m

Topic1..n

1

0..1

1

1

Figura 3.10: Schema delle views

pagina definita vengono associati uno o più valori di “Interest Topic”, perché puòessere che uno schema venga utilizzato in più ambiti. Ogni pagina può avere più diun contenuto al quale è associato opzionalmente uno stile e la tipologia del conte-nuto, che servirà all’app per visualizzare i dati. Per esempio se il designer desideramostrare il titolo nei dettagli con una dimensione maggiore di quella di default econ un colore rosso, può impostare questi parametri nel campo “Styles”. Nella fasedi elaborazione dinamica delle view sarà l’applicazione ad applicare questo stile sepresente, sostituendo quello di default. Per quanto riguarda la tipologia del dato“titolo” in questo caso è necessario specificare che è di tipo “Text”. Per compo-nenti più complessi come una mappa è sufficiente fornire come tipologia “Map” ecome contenuti i parametri di latitudine e longitudine per ottenere la visualizzazionedesiderata.

Per personalizzare uno schema, al designer spettano i seguenti passaggi:

• Associazione dei termini L’associazione dei termini agli elementi visualiviene effettuata mediante drag & drop. I singoli termini, che corrispondono a“categorie semantiche” di dati, sono collegati allo specifico elemento della view.I termini possono essere acquisiti da una repository mantenuta sul server o dauna knowledge base9, che permette di associare un significato a ogni terminein modo da agevolare l’interoperabilità dei dati. Il designer può scegliere seutilizzarli tutti o solo una parte nella creazione dello schema, in modo che aruntime l’applicazione possa richiedere solamente i dati necessari alla popola-zione della view. Nella Figura 3.9 viene mostrata la sequenza di operazioni chedeve compiere il designer e che vengono elencate di seguito:

1. Selezione dell’elemento visuale da inserire (es.: text field, mappa, galleriafoto, ecc.) nella view dell’app e modifica dello stile a seconda delle opzionidisponibili

9Schema.org: http://schema.org/

71

3. Metodologia CAMUS

2. Associazione del termine tra l’elenco di tutti quelli disponibili

Per esempio, per mostrare il titolo di un’istanza, l’esperto deve selezionarel’elemento che permette di mostrare del testo, trascinarlo all’interno dellaschermata virtuale e associarvi il campo titolo dai termini sulla sinistra dellaweb app. A questo punto è possibile modificare alcuni elementi di stile tramiteCSS che, definiti sullo schema, sovrascrivono eventuali stili presenti in quellopredefinito

• Associazione dei servizi di supporto Come spiegato nella Sezione 3.6, iservizi di supporto hanno la funzione di arricchire le informazioni che sonofornite dai servizi primari. La loro integrazione nei mashup può essere fattaprincipalmente in due modi:

1. La prima possibilità è di associare a un termine una app già installata suldevice. Si consideri il caso d’uso del turismo e un servizio di ristorantiche restituisce un numero di telefono: questo dato può essere collegato aldialer del dispositivo per effettuare direttamente una chiamata o all’appdi gestione degli SMS. Oppure l’indirizzo email può essere associato allafunzione “Crea Email” dell’app predefinita di gestione della posta elettro-nica. Un altro esempio può essere quello di associare il browser di sistemaal sito ufficiale o alle pagine Facebook del ristorante

2. La seconda possibilità riguarda invece l’utilizzo di un modulo che mostridirettamente i risultati dei servizi di supporto all’interno dell’app. Inquesto modo è possibile mostrare nuovi dati relativi a un singolo elementoproveniente dai servizi primari. È possibile per esempio associare unamappa per visualizzare una posizione geografica oppure una segnalazioneche indica la distanza o i tempi di percorrenza, oppure, citando semprel’esempio dei locali, i mezzi pubblici, car sharing o taxi che si possonoutilizzare per raggiungere il ristorante

72

Capitolo 4

Progettazione di alto livello

Questo capitolo viene dedicato allo studio della progettazione relativa al proto-tipo implementato. Si andrà a definire l’architettura scelta sia per il backend sia perla mobile app, descrivendone le funzionalità e le scelte che hanno portato alla suarealizzazione. In seguito il capitolo fornirà uno scenario relativo ad un caso d’usoreale, in modo da chiarire l’utilizzo dell’applicazione. Infine verranno approfonditele attività eseguite dalla mobile app e le interazioni con il backend, analizzando tuttii passaggi che vengono svolti.

4.1 Architettura del sistema

Al fine di validare la fattibilità della metodologia descritta nel capitolo prece-dente, è stato sviluppato il prototipo di una piattaforma che supporta la selezione el’interrogazione context-aware dei servizi, e la creazione dinamica di un’mobile appin grado di presentare i risultati. Questa sezione illustra l’organizzazione dei modulidel backend e di quelli dell’mobile app, evidenziando anche le interazioni necessariea soddisfare le richieste che l’utente formula tramite l’app.

4.1.1 Backend

In questa sezione si vuole analizzare nel dettaglio l’architettura messa a puntoper il backend di CAMUS, specificando le motivazioni che hanno portato alla suarealizzazione, e la descrizione delle tecnologie che hanno permesso lo sviluppo dellasoluzione.

L’architettura di CAMUS viene descritta schematicamente in Figura 4.1. Comesi può notare è stata privilegiata la modularità dei vari componenti che formanoil sistema, in modo che il compito di ognuno fosse ben circoscritto. Inoltre tutti icomponenti mostrati sono stateless, cioè non mantengono informazioni sullo stato diuna sessione. Questa scelta architetturale permette di poter avviare diverse istan-ze del backend di CAMUS per poter soddisfare le molteplici richieste degli utenti.

73

4. Progettazione di alto livello

GraphQL

Context Manager

Response Aggregator

Query Handler

Primary Service Selection

Support Service Selection

Bridge

REST Custom

Service Description

Service Association

Response Parser

Local and remote services

Query Response

CAMUS ServerCDT

Repository

Session Helper

Execution Helper

Figura 4.1: Architettura del backend

Questa scelta permette di selezionare quale nodo sia il miglior candidato per gestireuna richiesta in coda in base a politiche che non riguardano lo stato della sessione(es.: disponibilità del nodo, basso carico sul sistema, ecc.).

Il componente che coordina tutti gli altri è l’Execution Helper. Il suo compito èquello di inizializzare tutti gli altri componenti e organizzare le chiamate secondo ilflusso della richiesta (che verrà analizzato nel dettaglio nella Sezione 4.3).

Il Context Manager è il componente che si occupa di ricevere il contesto inviatodalla mobile app e trasformarlo in una versione “decorata”, eseguendo un’unionetra le informazioni ricevute dal client e quelle del descrittore completo del CDT.In questo modo viene agevolata l’esecuzione dei componenti successivi, in quanto leinformazioni necessarie all’elaborazione sono già state catalogate e definite in modocorretto.

L’attività del Primary Service Selection è di andare a recuperare le associazionitra l’albero di contesto e le operazioni dei servizi primari. È inoltre suo compitogestire le associazioni personalizzate, come quella relativa alla ricerca tramite località.In seguito assegna un punteggio a ogni operazione identificata ed emette in uscita leprime N operazioni con valutazione più elevata.

Un compito simile viene svolto dal Support Service Selection per le operazionidi supporto. Sebbene lo scopo del componente sia lo stesso, l’algoritmo di selezioneè differente: in questo caso viene effettuato un conteggio del numero di associazioni

74

4.1. Architettura del sistema

trovate e successivamente si verifica che soddisfi il minimo numero di associazionidefinito per ogni operazione. Infine, una volta che le operazioni idonee sono stateselezionate, vengono composti gli indirizzi, che possono essere relativi a servizi weboppure degli intent verso applicazioni installate sul dispositivo dell’utente. Al clientsarà richiesto solamente di interrogare il servizio o aprire l’applicazione specificata.

Il Query Handler ha il compito di gestire le chiamate verso i servizi primari.Acquisisce l’elenco di operazioni scelte dal Primary Service Selection e ne recupe-ra i descrittori, contenenti le informazioni per poterli interrogare. Successivamenteorganizza le chiamate ai servizi attraverso l’uso di bridge specifici, scelti in base alprotocollo di comunicazione adottato dal servizio. Una volta ricevute le risposte, sioccupa di interfacciarsi con il Response Parser per trasformarle nella rappresenta-zione interna, che utilizza dei termini semantici per associare il rispettivo significatoai vari attributi che compongono la risposta.

Il Response Aggregator riceve l’elenco dei risultati dal Query Handler e si occupadi andare ad analizzarli per trovare e fondere assieme le entità duplicate e assegnaun punteggio a ogni elemento in base alla rilevanza con i dati del contesto (es.:vicinanza del luogo rispetto alla posizione dell’utente, ecc.). Questa attività rendepossibile l’ordinamento dei dati in base a criteri di idoneità rispetto alla situazionedell’utente.

Il Session Helper si occupa di gestire le richieste verso pagine successive allaprima, in quanto questa attività richiede una fase di preparazione aggiuntiva. Ilcomponente analizza lo stato della richiesta e smista i dati quando sono disponibilialtrimenti effettua nuove richieste verso i servizi per acquisire ulteriori informazioni.

Per quanto riguarda l’esposizione dei metodi che possono essere richiamati dalclient si è deciso di non utilizzare un approccio basato sull’esposizione di endpointREST bensì di sperimentare GraphQL.

In questa sezione si è voluta dare una visione d’insieme sui compiti che spettanoai vari componenti. Un’analisi più approfondita delle attività di ognuno di essi verràsvolta nella Sezione 5.4.

4.1.2 Mobile app

In questa sezione è presentata l’architettura dell’applicazione mobile CAMUS,spiegando in modo rapido le diverse tipologie di moduli che la compongono. Si èvoluta seguire principalmente un’architettura simile alle applicazioni web per quantoriguarda il controllo della navigazione e della visualizzazione e per quanto riguardala logica seguire le linee guida di Alt.js. Guardando lo schema presente in Figura4.2 è possibile distinguere diverse tipologie di moduli: le pagine dell’applicazione,gli helpers e i componenti che gestiscono lo stato (Actions e Stores).

75

4. Progettazione di alto livello

Context Selection Page

View Builder

Result Page

Details Page

Main Page

Login Page

Login Router

Secondary Router

Connection Manager

React Native components

Alt.js

StoresActions

Figura 4.2: Architettura dell’applicazione mobile

4.1.2.1 Pagine dell’applicazione

Essendo il progetto basato su JavaScript, per poter controllare le diverse pagi-ne dell’applicazione è necessario utilizzare un router. Si è scelto di sfruttare duerouter diversi, uno per gestire il login e un altro per la navigazione all’internodell’applicazione. Il router per il login controlla solamente se l’utente è autenticato eha lo scopo di non permettere l’accesso alle pagine che necessitano di autenticazione.Come percorsi include Login Page e il secondary router, che racchiude il controllodella navigazione effettiva una volta che l’utente si è autenticato.

Come si può notare nella Figura 4.3, le pagine attraverso cui è possibile navigaresono le seguenti:

• Login Page È la pagina dove l’utente inserisce le proprie credenziali per ac-cedere al sistema CAMUS e ottenere i parametri per il corretto funzionamentodell’applicazione

• Logged Area Si tratta della parte dell’applicazione alla quale l’utente puòaccedere nel caso in cui sia autenticato e gestisce le pagine di selezione delcontesto e di visualizzazione dati:

– Main Page È la pagina principale dell’applicazione e permette all’utentedi mostrare tutti gli Interest Topic presenti nel suo CDT. La scelta dellacategoria desiderata permette di accedere alla Context Selection Page

76

4.1. Architettura del sistema

Logg

ed A

rea

Hom

eScr

een

Con

text

Sele

ctio

nPa

geR

esul

tsPa

geD

etai

lsPa

ge

Logi

nPag

e

Figura 4.3: Schema delle pagine

77

4. Progettazione di alto livello

– Context Dimension Page In questa pagina viene chiesto il contestoall’utente mediante un’interfaccia che si adatta a runtime man mano chel’utente effettua delle scelte per guidarlo nella definizione del contesto dainviare come richiesta al server. Una volta composto il contesto vienecostruita la query e inviata all’endpoint GraphQL del server CAMUS.

– Results Page Si tratta della pagina che deve mostrare l’intero datasetproveniente dal server e gestisce la paginazione dei risultati, a secondadella posizione del cursore dell’utente nella ListView

– Details Page In questa pagina vengono visualizzati i dettagli dell’oggettoselezionato e sono gestiti i collegamenti con le applicazioni esterne, permezzo della libreria di Linking di React Native o tramite moduli perso-nalizzati

4.1.2.2 Helpers

Le pagine descritte nella sezione precedente utilizzano alcuni componenti chesono in comune tra tutte le pagine dell’applicazione in quanto aiutano a eseguirefunzionalità comuni. Di seguito sono elencati i componenti che svolgono questocompito:

• Connection Manager In questo componente vengono gestite tutte le connes-sioni con l’endpoint GraphQL. Permette di gestire la fase di login e di scambiodati per scaricare il CDT, gli schemi di mashup e i dati. Per quanto riguarda idati sono esposti due metodi distinti, il primo per gestire la prima richiesta dinuovi dati, il secondo per quelle successive, chiedendo una nuova pagina comespiegato nella Sezione 6.4.3

• View Builder Si tratta del componente che costruisce le view dinamichepartendo dallo schema di mashup, scaricato assieme al CDT appena effettuatoil login

• StyleSheet Si tratta del foglio di stile nel quale sono impostati tutti i para-metri predefiniti per la visualizzazione dei componenti dell’applicazione

4.1.2.3 Actions e Stores

Per quanto riguarda la gestione dello stato dell’applicazione si è scelto di seguirein modo piuttosto rigoroso le linee guida fornite da Alt.js: le Action e gli Storedevono essere collegati tra di loro e riguardare delle funzionalità specifiche. Perquesto motivo sono state create quattro tipologie di coppie Action-Store che hannoil compito di gestire il salvataggio dei diversi dati dello stato dell’applicazione:

1. User Ha il compito di gestire tutti i dati anagrafici legati all’utente

78

4.2. Scenario d’uso

2. Data Memorizza tutto quello che riguarda i dati per l’applicazione, come ilCDT e i risultati che provengono dal server

3. View Gestisce gli schemi di mashup e il loro aggiornamento all’interno dell’ap-plicazione

4. Context Ha il compito di memorizzare le scelte in base al contesto fattedall’utente, permettendo di guidarlo nella definizione della propria situazione

Queste tipologie verranno spiegate nei dettagli nella Sezione 6.1.

4.2 Scenario d’uso

Viene introdotto un esempio di caso d’uso reale, che vuole il flusso di esecuzionedelle attività dell’utente a partire dal login fino alla visualizzazione della pagina deidettagli. Verranno mostrate le attività inizialmente lato client, mettendo in evidenzale attività svolte dall’utente, e lato backend, descrivendo come viene elaborata larichiesta. Introduciamo l’utente Andrea, che sarà il nome di fantasia che utilizzeremoin questo esempio. Supponiamo che si deve recare per un weekend a Milano conla sua fidanzata Barbara. Prima di partire ha comunicato a Giovanni, l’espertoCAMUS, del suo progetto di viaggio. Giovanni configura l’applicazione CAMUSpersonalizzata per Andrea con le informazioni del contesto che gli saranno utilia Milano. Terminato questo lavoro, Giovanni ritiene inoltre che siano utili dellemodifiche all’interfaccia grafica dell’applicazione di Andrea. Qualche giorno piùtardi Andrea e Barbara si trovano a Milano in zona Centro e stanno cercando unposto dove poter andare a cena, dato che ormai sono quasi le 20:00. Andrea apre lapropria applicazione CAMUS sul suo smartphone e inserisce le proprie credenzialidi accesso, dato che è la prima volta che la utilizza (Figura 4.4).

Figura 4.4: Pagina di autenticazione Figura 4.5: Schermata principale

79

4. Progettazione di alto livello

Figura 4.6: Selezione del contesto Figura 4.7: Risultati ricevuti

Eseguita l’autenticazione con successo, ad Andrea viene mostrata la scherma-ta principale con la possibilità di scegliere l’Interest Topic desiderato tra quellidisponibili (Figura 4.5). La scelta ricade su quello più appropriato: “Restaurants”.

A questo punto è necessario completare il contesto per poter effettuare la richiestadei ristoranti. Il sistema propone la schermata di selezione del contesto, permettendonel loro caso di scegliere solamente i mezzi di trasporto, dato che gli altri parametridel profilo di Andrea erano già stati inseriti da Giovanni. Essendo arrivati a Milanoutilizzando il treno, viene inserita la possibilità di raggiungere il ristorante con imezzi pubblici, in particolare con i bus (Figura 4.6).

Figura 4.8: Dettagli oggetto selezionato nella view DetailsPage

80

4.3. Flusso di esecuzione

Selezionando “Query” viene costruita la query, prendendo i termini dagli schemidi mashup e il contesto appena inserito, e inviata al server, il quale seleziona i servizida invocare in base al contesto appena ricevuto, li interroga e costruisce l’insieme dirisultati da restituire all’applicazione. Dopo qualche secondo Andrea riceve sul suosmartphone la prima pagina dei risultati da lui richiesti, cioè la view ResultsPage(Figura 4.7).

Dopo una rapida consultazione con Barbara, Andrea seleziona il ristorante “Ca-ruso” per vedere dei dettagli in più. Quindi, viene create dinamicamente la paginaDetailsPage Convinti della scelta e scoprendo che è raggiungibile anche a piedi, de-cidono di provare a telefonare per prenotare un tavolo per due persone, selezionandoil simbolo della cornetta (Figura 4.8). Il ristoratore conferma la prenotazione quindiAndrea e Barbara possono recarsi a cena.

4.3 Flusso di esecuzione

Questa sezione vuole mostrare al lettore il flusso di esecuzione delle attivitàall’interno della piattaforma. Nella sezione precedente si è parlato di un caso d’usoreale mentre ora si vuole entrare nel dettaglio delle attività svolte dal prototipo.Nelle Figure 4.9 e 4.10 vengono mostrati i diagrammi delle attività svolte rispet-tivamente dalla mobile app e dal server, che sono stati separati per mostrare conmaggiore chiarezza tutti i passaggi.

Context Selection Page

View Builder

Result Page

Details Page

Sensors User input

Home Page

Data Query

Actions

State

DispatcherGPS, Time, Network status, ...

CDTView Schema Result set

Login Page

Login Query

1

5

4

4

3

2 2

2

6 78

9

Server 2

Figura 4.9: Flusso dei dati dell’app Flux

Per mantenere coerenza con lo scenario d’uso, nelle seguenti sottosezioni si par-tirà con la fase di autenticazione dell’utente e alla selezione del contesto nella mobileapp. Verrà in seguito mostrato l’invio del contesto al server e i passaggi necessari

81

4. Progettazione di alto livello

Primary ServiceGraphQL

ServerContext Manager

Primary Service

Selection

Query Handler

Response Aggregator

Support Service

Selection

Response Parser

REST Custom

Bridge

CAMUS App

context

response

Figura 4.10: Flusso di una nuova richiesta

per la selezione e l’interrogazione dei servizi. In conclusione, una volta che la mobileapp riceve i dati, verrà mostrata la modalità di presentazione di queste informazionie le modalità di interazione.

Login

La prima schermata che appare nell’applicazione è quella di login; qui l’utenteinserisce le proprie credenziali e viene effettuata la richiesta GraphQL di login comedefinito nella Sezione 5.5.2. Vengono ricevuti il CDT e i mashup personalizzati perl’utente, così che l’applicazione possieda tutto ciò che è necessario per comporrel’interfaccia grafica e mostrare la view di selezione dell’Interest Topic.

Contesto

L’utente seleziona l’Interest Topic desiderato e viene reindirizzato alla pagina diselezione del contesto dove vengono mostrati i campi che possono essere compilati.Dopo aver definito i parametri del contesto, l’utente preme il pulsante per effettuarela richiesta al server: l’applicazione recupera i dati inseriti e allo stesso tempo i datidi posizione provenienti dai sensori del dispositivo. I dati di contesto sono compostiassieme ai termini semantici provenienti dagli schemi di mashup per costruire laquery GraphQL. Il router dell’applicazione mostra all’utente la pagina dei risultati,la quale durante l’attesa della risposta del server, notifica il caricamento tramiteun’animazione grafica. Il server riceve il contesto e ne inizia l’elaborazione. Laprima attività che viene eseguita è la creazione del CDT decorato, della quale sioccupa il Context Manager. In Figura 4.11 viene mostrato il diagramma di flussodelle attività svolte. Riceve in ingresso il contesto che è stato composto dall’utentee lo trasforma nella relativa versione decorata. Se il contesto è già stato ricevuto inuna precedente richiesta, viene recuperata dalla cache la versione decorata che è giàstata elaborata, altrimenti viene avviato il processo di trasformazione. Al fine di

82

4.3. Flusso di esecuzione

identificare univocamente ogni contesto viene generato un hash dell’oggetto ricevutoper poterlo memorizzare e recuperare in cache. In questo modo è possibile anchecondividere un contesto tra più utenti diversi.

context

oggetto presente in cache?

calcolo hash

decoratedCdt

creazione decoratedCdt

sì

no

salvataggio in cache

Figura 4.11: Flusso di creazione del CDT decorato

L’operazione successiva è la selezione dei servizi primari. Viene eseguita unavolta terminata la creazione del CDT decorato. In Figura 4.12 viene mostrato ildiagramma di flusso che mostra come viene gestita una richiesta.

La prima attività che viene svolta riguarda il controllo se la richiesta è già statagestita in passato. Se si tratta di una nuova richiesta, l’attività viene svolta daicomponenti che fanno parte del blocco “Primary Service” nella Figura 4.10. Ilprimo componente che viene eseguito è il Primary Service Selection, che si occupadi selezionare le operazioni che sono più idonee al contesto fornito dall’utente.

Risultati

Prodotto l’elenco delle operazioni primari, è necessario effettuare le interrogazioniper acquisire i dati. Per svolgere questo compito entra in gioco il Query Handler, cheha un duplice compito: il primo, con l’ausilio di uno o più Bridge, è l’interrogazionedei servizi prescelti mentre il secondo è l’acquisizione delle relative risposte. Unavolta ricevute le risposte provvede a trasformarle nel formato interno, tramite lefunzioni messe a disposizione dal Response Parser. Tutte le risposte ricevute vengonoinfine unite a formare un’unica lista e restituite per essere ulteriormente elaborate dal

83

4. Progettazione di alto livello

decoratedCdt

oggetto presente in cache?

recupero risultati salvati

sono presenti risultati ancora da mostrare?

risultati

acquisisco informazioni sulla

paginazione

sono disponibili ulteriori dati?

richiedo ulteriori risultati al servizio

mostro risultati rimanenti

aggiorno informazioni sullo

stato della sessione

interrogo il servizio

sì no

no sì

nosì

Figura 4.12: Flusso di richiesta dei risultati primari

Response Aggregator, che effettua un’attività di rimozione dei duplicati. L’elenco deirisultati identificato verrà dunque salvato per un periodo di tempo in cache in mododa poter essere riutilizzato per richieste future. L’altra eventualità si verifica quandola risposta è presente in cache. Questo caso ha una gestione un po’ più complessarispetto al precedente perché viene considerata anche la paginazione dei risultati.La prima verifica riguarda la disponibilità di informazioni da restituire al client.Se la quantità di dati contenuti in cache è sufficiente a evadere la richiesta vienesubito restituita la relativa porzione di informazioni. Altrimenti viene effettuatauna nuova richiesta verso i servizi che hanno ulteriori dati da mostrare. La regoladi ricaricamento dei dati è la stessa descritta nella Sezione 5.4.8. Qualsiasi casistica

84

4.3. Flusso di esecuzione

termina sempre con l’aggiornamento dello stato nella cache, in quanto vengono siasalvati l’elenco dei risultati sia il numero di elementi che il client ha già richiesto.Il processo termina una volta che tutti i servizi non ha più dati da mostrare. Inquel caso il client verrà informato del fatto che non sono più disponibili ulterioripagine. L’attività di acquisizione dei servizi di supporto comincia una volta creato ilCDT decorato e opera parallelamente all’acquisizione dei servizi primari. Coinvolgeunicamente il componente Support Service Selection, che si occupa di selezionarei servizi di supporto o gli intent richiesti dal client. In ingresso viene fornita lacategoria dei servizi che si vuole selezionare in base al contesto fornito. A questopunto il server è pronto per restituire i risultati all’applicazione, che provvede aprocessarli seguendo le regole definite negli schemi di mashup per mostrare i dati. Laprima view mostrata contiene l’elenco dei risultati ricevuti, con poche informazioniper permettere all’utente di avere una panoramica sui singoli elementi. Da questaschermata l’utente può selezionare qualsiasi elemento per visualizzarne i dettagli.Viene dunque mostrata una pagina contenente tutte le informazioni recuperate perl’elemento scelto. Inoltre vengono gestiti i servizi di supporto specificati nello schemadi mashup, in modo che sia possibile l’interazione con applicazioni di terze parti.

85

4. Progettazione di alto livello

86

Capitolo 5

Progettazione di dettaglio eimplementazione del backend

Questo capitolo illustra nel dettaglio la realizzazione del backend della piatta-forma CAMUS. Il capitolo si apre con l’esposizione dei descrittori dell’albero delcontesto e dei servizi. Verrà fornita un’analisi degli attributi che li caratterizza-no, con l’ausilio di esempi per chiarire meglio i concetti. In seguito verrà mostratoil diagramma Entità-Relazione del database e lo schema logico che ne consegue.Verrà esposto in seguito il diagramma delle classi del backend e vengono analiz-zati i dettagli implementativi dei singoli componenti. Una sezione verrà dedicataall’endpoint GraphQL, che permette alle applicazioni esterne di eseguire le attivitàmesse a disposizione dal backend. Il capitolo termina con la documentazione relativaalla configurazione del sistema, che permette la definizione di alcuni parametri uti-lizzati in fase di esecuzione per modificarne il comportamento. Una configurazionepuò essere definita tramite variabili d’ambiente o file di configurazione. Verrannodescritte entrambe le possibilità.

5.1 Descrittore dell’albero di contesto

Nella Sezione 2.1.1.1 è stato esposto il modello teorico del Context DimensionTree mentre in questa sezione si vuole mettere in risalto come l’albero di contestoviene descritto nel sistema. Sono state effettuate diverse semplificazioni per agevola-re la memorizzazione e il recupero delle informazioni dai vari nodi che compongonol’albero. Nelle seguenti sottosezioni vengono analizzati nel dettaglio i singoli oggettiche formano un albero di contesto.

87

5. Progettazione di dettaglio e implementazione del backend

5.1.1 Radice

Questo oggetto rappresenta la radice di un albero di contesto. È composto daiseguenti parametri:

• User Id L’elenco degli identificativi degli utenti ai quali questo albero è as-sociato. Viene lasciata la possibilità di definire più utenti perché uno stessoalbero può essere valido per più utenti con un profilo simile

• Context Contiene i nodi che compongono l’albero. Per una descrizione ap-profondita si fa riferimento alla Sezione 5.1.2

• Default Values Vengono elencati tutti i valori che l’esperto di settore ha spe-cificato siano sempre validi per gli utenti ai quali questo albero viene associato.È composto dal nome della dimensione e dal relativo valore che assume

Viene inoltre definito un CDT Globale, utilizzato come base per la creazione diquelli specifici per ogni utente. Questo albero ha la particolarità che non è associatoa nessun utente.

5.1.2 Nodi

Questo oggetto rappresenta un nodo dell’albero. In particolare vengono rap-presentati solamente i nodi di tipo dimensione tramite oggetti dedicati, mentre inodi contesto e parametro vengono rappresentati come sottocomponenti. Ogni nodopossiede i seguenti attributi:

• Name Il nome del nodo dimensione

• For Descrive la tipologia di nodo, utilizzata per assegnare un peso utile nellafase di selezione delle operazioni e per attribuire un valore ai parametri nellafase di invocazione dei servizi. I valori ammessi sono filter, parameter o ranking.Vengono inoltre ammesse le combinazioni filter|parameter e ranking|parameter:un nodo può essere solamente di tipo filter o ranking, al fine dell’assegnamentodei pesi, mentre può essere anche di tipo parameter, in quanto indica che verràutilizzato anche nella fase di composizione delle query. Se viene definito iltipo parameter devono essere assegnati diversi parametri, per specificarne lecaratteristiche

• Values Elenca i possibili valori che può assumere il nodo. Questo elencocorrisponde ai nodi di tipo contesto del modello del CDT

• Parameters L’elenco dei parametri associati al nodo. Per ulteriori dettaglisu questo oggetto si fa riferimento alla Sezione 5.1.3

88

5.1. Descrittore dell’albero di contesto

• Parents Contiene l’elenco di tutti i nodi dimensione dai quali discende il nodocorrente. Viene utilizzato per effettuare l’unione delle sottodimensioni di unnodo

Nel Listato 5.1 viene mostrato un esempio di nodo.

Listato 5.1 Esempio di nodo del CDT

"name": "InterestTopic","for": "filter","values": [

"Restaurant","Cinema","Theater","Hotel","Museum","Event"

]

5.1.3 Parametri dei nodi

Questo oggetto definisce i parametri che sono associati a un nodo dimensione.Corrisponde ai nodi di tipo parametro del modello del CDT. I parametri vengonoutilizzati per permettere all’utente di specificare dei valori di sua scelta (es.: località).È composto dai seguenti campi:

• Name Il nome del parametro

• Type Il/I formato/i del dato che vengono accettati

• Fields Questo elenco permette di definire dei campi che vanno ulteriormentea specificare il parametro. Un esempio viene dato dal parametro “Luogo”, chepuò essere specializzato nei campi “Latitudine” e “Longitudine”

Nel Listato 5.2 viene mostrato un esempio di parametro.

89

5. Progettazione di dettaglio e implementazione del backend

Listato 5.2 Esempio di parametro associato a un nodo

"name": "Location","for": "ranking|parameter","parameters": [

"name": "CityCoord","fields": [

"name": "Latitude"

,

"name": "Longitude"

]

]

5.2 Descrittore dei servizi

Affinché il sistema possa effettuare le richieste è necessario che sia presente unformato per descrivere le caratteristiche di ogni servizio (es.: l’indirizzo verso ilquale effettuare la richiesta, i parametri da inserire, ecc.). Per questo motivo èstato introdotto l’utilizzo di un descrittore dei servizi in grado di specificare tuttele possibili configurazioni che i servizi possono richiedere. I descrittori non sonoaltro che configurazioni dei servizi espressi tramite file JSON. Di seguito verrannoanalizzati nel dettaglio tutti i campi che compongono il descrittore. È stata separatala definizione delle informazioni generali del servizio dalle informazioni di dettagliodelle operazioni che espone. Il risultato sono due oggetti, uno di “descrizione generaledel servizio” e un “descrittore delle operazioni”. Nelle seguenti sezioni verrannoanalizzati gli attributi di entrambi gli oggetti.

5.2.1 Descrizione generale del servizio

È il punto di partenza per la descrizione di un servizio. Comprende i seguenticampi:

• Name Il nome del servizio

• Description Fornisce una descrizione delle funzionalità del servizio

• Protocol Definisce la tipologia con la quale accedere al servizio. Può assu-mere i valori “rest”, “query” o “custom”, per specificare rispettivamente che il

90

5.2. Descrittore dei servizi

servizio viene invocato secondo il protocollo REST, viene composta una querycon parametri o è necessario invocare un metodo particolare per l’accesso

• Base Path Rappresenta l’indirizzo di base del servizio. A partire da questoindirizzo verrà composto quello completo aggiungendo in coda i percorsi spe-cifici delle operazioni richieste. Non deve essere inserito al termine nessunoslash (“/”)

Nel Listato 5.3 viene mostrato un esempio di oggetto principale del servizio.

Listato 5.3 Esempio di servizio

"name": "GooglePlaces","protocol": "query","basePath": "https://maps.googleapis.com/maps/api/place"

5.2.2 Descrittore delle operazioni

Rappresenta le operazioni che sono messe a disposizione dal servizio. Un’opera-zione viene descritta dai seguenti campi:

• Service Contiene il riferimento al descrittore generale del servizio associatoall’operazione. Un’operazione può essere collegata esclusivamente ad un soloservizio

• Name Il nome dell’operazione

• Type Rappresenta la tipologia dell’operazione. Un’operazione può essere pri-maria o di supporto. Questa distinzione viene utilizzata principalmente perpermettere la catalogazione delle operazioni da mostrare nelle web app

• Description La descrizione dell’attività svolta dall’operazione

• Path Il percorso specifico per richiamare l’operazione. Questo valore vieneaggiunto al Base Path del servizio. Deve essere sempre preceduto da una slash(“/”)

• Protocol Permette di ridefinire il protocollo utilizzato esclusivamente perl’operazione corrente. È utile nei casi in cui un’operazione, per una qual-siasi ragione, utilizzi un paradigma di composizione della query diverso daquello specificato dal servizio. Per esempio, viene utilizzato per mappare gli“intent” su diversi sistemi operativi dei dispositivi, che hanno diverse regoledi composizione. Oltre alle tipologie definite per i servizi supporta anche ilprotocollo “android”

91

5. Progettazione di dettaglio e implementazione del backend

• Store Link Utilizzato esclusivamente per i servizi di supporto, permette di de-finire il link nello store di riferimento per scaricare l’app necessaria a utilizzarel’intent associato

• Bridge Name Questo campo è opzionale, definisce il nome del bridge con lalogica necessaria per invocare il servizio. È obbligatorio il suo utilizzo quandoper il servizio viene utilizzato il protocollo custom

• Parameters Definisce l’elenco dei parametri accettati in ingresso dall’opera-zione. Per ulteriori dettagli su questo oggetto si fa riferimento alla Sezione5.2.3

• Headers Permette di specificare gli attributi da aggiungere all’header dellarichiesta. Vengono utilizzati i campi “name” per specificare il nome dell’attri-buto e “value” per specificarne il valore

• Response Mapping Serve per definire le regole di associazione per mapparela risposta del servizio coi termini semantici utilizzati dal sistema. Maggioridettagli su questo oggetto vengono discussi nella Sezione 5.2.4

• Pagination Serve a raccogliere gli attributi necessari per gestire la paginazionespecifica di ogni servizio. Sono supportati meccanismi di paginazioni basatisul numero di pagina o su token. Questo oggetto viene analizzato nel dettaglionella Sezione 5.2.5

Nel Listato 5.4 viene mostrato un esempio di operazione. Nel campo “servi-ce” viene inserito il nome del servizio associato al posto del suo identificativo permaggiore chiarezza.

Listato 5.4 Esempio di operazione

"service": "GooglePlaces","name": "nearBySearch","type": "primary","path": "/nearbysearch/json","parameters": [ ... ],"responseMapping": ... ,"pagination": ...

5.2.3 Parametri delle operazioni

Quest’oggetto definisce i parametri in ingresso di un’operazione. I parametrigeneralmente sono composti da due campi: uno ne definisce il nome e l’altro il

92

5.2. Descrittore dei servizi

rispettivo valore. In alcuni casi vengono accettati più valori, quindi il descritto-re deve dunque essere in grado di gestire questa situazione. Un ulteriore compitoaffidato a questo oggetto è quello di acquisire il valore di un determinato parame-tro dal contesto. Viene inoltre fornito un semplice sistema di traduzione dei datiacquisiti dal contesto, per permettere le trasformazioni verso un valore idoneo perl’operazione corrente. Infine, soprattutto per le operazioni di supporto, viene permes-sa un’associazione del parametro verso uno o più termini semantici, per permetterealla mobile app di conoscere l’attributo dove andare a recuperare il valore concretoa runtime. Nello specifico, l’oggetto è così composto:

• Name Il nome del parametro. Questo campo è obbligatorio, in quanto definisceil nome che verrà utilizzato per comporre la query per richiedere i dati

• Description La descrizione della tipologia del parametro

• Required Specifica se il parametro corrente è obbligatorio o meno in unarichiesta. Non definire questo attributo equivale ad assegnargli valore false

• Type Definisce il tipo di dato che l’operazione si aspetta di ricevere. Le princi-pali tipologie di dato che vengono inviate verso i servizi sono stringhe, numerio date

• Default Indica un valore predefinito per il parametro. Questo campo è parti-colarmente utile per la web app relativa al Visual Mapping, in quanto permettedi ricevere degli esempi di risposta dei servizi da mostrare all’utente

• Collection Format Questo campo definisce il separatore da utilizzare nel casosiano presenti più valori per il parametro. Sono accettati i seguenti quattroseparatori: i) “csv”, comma separated values; ii) “ssv”, space separated values;iii) “tsv”, tab separated values; iv) “pipes”. Se non specificato viene utilizzatoil tipo csv

• Mapping CDT Definisce uno o più nodi dell’albero di contesto dove andaread acquisire il valore ricevuto dalla mobile app. Nel caso vengano associati piùdi un nodo viene seguito l’ordine di definizione nella fase di composizione dellaquery

• Mapping Term Definisce uno o più termini semantici da associare al para-metro. Questi termini vengono utilizzati a runtime per andare ad acquisire ilvalore del parametro dalle risposte ricevute dai servizi primari

• Translate Permette delle semplici trasformazioni dei valori acquisiti dall’al-bero di contesto per renderli conformi a quelli accettati dal servizio. È formatodai campi “from” e “to”, che specificano rispettivamente il valore di origine e

93

5. Progettazione di dettaglio e implementazione del backend

quello tradotto. Vengono definite tante traduzioni quanti sono i valori che puòassumere il rispettivo nodo del CDT

Nel Listato 5.5 viene mostrato un esempio di parametro di un’operazione.

Listato 5.5 Esempio di parametro di un’operazione

"name": "Location","required": true,"default": "-33.8670522,151.1957362","collectionFormat": "csv","mappingCdt": [

"CityCoord.Latitude","CityCoord.Longitude"

]

5.2.4 Formato della risposta

In quest’oggetto sono definite le regole con le quali vengono trasformate le rispo-ste ricevute dal servizio nel formato interno CAMUS, dove ogni attributo viene as-sociato a un rispetto termine semantico che ne definisce il contenuto. In particolare,vengono utilizzati i seguenti campi:

• List Definisce l’attributo che contiene l’elenco dei risultati. È utile nei casiin cui la risposta, oltre ai risultati, contiene al suo interno anche dei metadatirelativi l’interrogazione. Se non specificato si assume che l’elenco dei risultatisi trovi nella radice della risposta

• Items Permette di mappare i vari campi che compongono ogni oggetto deirisultati. In particolare vengono definiti il “percorso” dal quale recuperare ilvalore e il “termine semantico” da associare. I campi senza un’associazionesaranno ignorati dal processo di trasformazione e le relative informazioni an-dranno perdute. È necessario dunque effettuare l’operazione di mapping dellerisposte con attenzione, in modo da non trascurare informazioni importanti

• Functions Viene permesso l’utilizzo di funzioni specifiche per trasformare ivalori. Questa funzione riceve in ingresso il parametro “value”, che rappresentail valore corrente del campo, e deve restituire il nuovo valore che verrà sostituitoa quello originale. Oltre alla funzione specifica è necessario definire anchel’attributo sul quale eseguire questa trasformazione. L’attributo equivale altermine semantico definito nel punto precedente

Nel Listato 5.6 viene mostrato un esempio di formato di risposta.

94

5.2. Descrittore dei servizi

Listato 5.6 Esempio di formato di risposta

"list": "results","items": [

"termName": "title","path": "name"

,

"termName": "address","path": "vicinity"

,

"termName": "latitude","path": "geometry.location.lat"

,

"termName": "longitude","path": "geometry.location.lng"

],"functions": [

"onAttribute": "latitude","run": "return String(value)"

,

"onAttribute": "longitude","run": "return String(value)"

]

5.2.5 Paginazione

In quest’oggetto vengono descritti gli attributi necessari per gestire la pagina-zione delle risposte. In particolare il sistema è in grado di gestire due tecniche dipaginazione, quella basata sul numero di pagina e quella che utilizza dei token perrichiamare le pagine. L’oggetto è composto dai seguenti campi:

• Attribute Name Specifica il nome del parametro da aggiungere alla queryper richiamare una specifica pagina

• Type Definisce il meccanismo di paginazione da utilizzare. Sono ammessi duevalori: “number”, per la paginazione basata sul numero di pagine, e “token”,per quella che sfrutta i token per richiamare le pagine successive

95

5. Progettazione di dettaglio e implementazione del backend

• Token Attribute Serve per definire dove andare a leggere nella risposta iltoken relativo alla pagina successiva

• Page Count Attribute Definisce l’attributo che fornisce l’informazione delnumero di pagine totale che possono essere richieste

Nel Listato 5.7 viene mostrato un esempio di descrittore della paginazione.

Listato 5.7 Esempio di descrittore della paginazione

"pagination": "attributeName": "pagetoken","type": "token","tokenAttribute": "next_page_token"

5.3 Schema del database

La base di dati viene utilizzata principalmente per garantire la persistenza dicinque elementi: i) il descrittore dei servizi, ii) l’albero del contesto, iii) le associa-zioni tra operazioni e nodi del CDT, iv) le informazioni sugli utenti e v) gli schemidi mashup. In Figura 5.1 è possibile osservare il modello Entità-Relazione utilizzatoper la piattaforma CAMUS.

Queste entità permettono al sistema di svolgere le attività principali. Le primetre entità sono state esposte nelle precedenti sezioni, in quanto si tratta di ogget-ti complessi che richiedono di una spiegazione dettagliata. Le entità riguardanti imashup vengono associate all’utente per permettere la definizione di schemi persona-lizzati. Anch’esse necessitano di una descrizione dettagliata, per metterne in risaltole caratteristiche. La loro composizione verrà esposta nella Sezione 6.2.

Una volta definito il modello ER è necessario passare alla realizzazione delloschema logico del database, quello che verrà effettivamente utilizzato nell’imple-mentazione. Non esistendo uno standard per realizzare uno schema di questo tipoper i database non relazionali è stato scelto di utilizzare un diagramma delle clas-si per rappresentare i documenti che compongono il database. Ogni classe vieneintesa come un documento e i collegamenti evidenziati con una linea continua rap-presentano i sottodocumenti. Le linee tratteggiate indicano le referenze tra i varidocumenti.

In Figura 5.2 viene mostrato lo schema logico utilizzato per CAMUS.

96

5.3. Schema del database

Cdt

Glo

bal C

dtha

sGlo

bal

Sche

ma

User

own

Node

com

pose

dBy

Defa

ult

Valu

e

hasD

efau

ltVa

lues

dim

ensio

n

valu

e

nam

efo

r

Node

Pa

ram

eter

has

Para

met

ers

idna

me

type

Fiel

dha

sFi

elds

idna

me

type

Ope

ratio

ndi

men

sion

valu

e

latit

ude

long

itude

dim

ensio

n

valu

e

latit

ude

long

itude

cons

train

tCo

unt

idnam

e

surn

ame

mai

l

pass

word

toke

n

Serv

iceex

pose

Ope

ratio

n

id

nam

e

desc

riptio

npr

otoc

ol

base

Path

id

nam

e

type

desc

riptio

n

path

brid

geNa

me

Para

met

erha

sPa

ram

eter

s

Head

er

hasH

eade

rPa

ram

eter

Resp

onse

Pagi

natio

npa

gina

tion

Attri

bute

resp

onse

Form

at

id

id

id

id

attri

bute

Nam

e

type

toke

nAttr

ibut

epage

Coun

tAttr

ibut

e

list

Item

Ope

rate

cust

omFu

nctio

n

has

Item id

id

run

onAt

tribu

te

term

Nam

epath

nam

eva

lue

Tran

slate

defin

eTr

ansla

tion

idfro

m to

nam

ede

scrip

tion

requ

ired

type

defa

ult

colle

ctio

nFor

mat

map

ping

Cdt m

appi

ngTe

rm

id

id

id

id

Prim

ary

Serv

ice

inCd

t

has

Ope

ratio

n

cate

gory

Supp

ort

Serv

icein

Cdt

has

Ope

ratio

n

pare

nts

valu

es

Mas

hup

own

Item

Cont

ent

Glo

bal

Mas

hup

has

defin

eLi

st

hasG

loba

lM

ashu

p

idid

idid

type

style

cont

ents

topi

cs

defin

eDe

tails

stor

eLin

k

prot

ocol

Figura 5.1: Diagramma ER del database

97

5. Progettazione di dettaglio e implementazione del backend

CDTMashup

Operation

userId: [ObjectId]CDT Schema name: String

for: enumvalues: [String]parents: [String]

Node Schema

dimension: Stringvalue: String

Default Schemaname: Stringtype: String

Parameter Schemaname: Stringtype: String

Field Schema1 * 1 * **

idOperation: ObjectIdidCdt: ObjectIddimension: Stringvalue: Stringranking: Numberloc: [Number]

Primary Service SchemaidOperation: ObjectIdidCdt: ObjectIdcategory: Stringdimension: Stringvalue: Stringloc: [Number]

Support Service SchemaidOperation: ObjectIdidCdt: ObjectIdcategory: StringconstraintCount: Number

Support Service Constraint Schema

name: Stringsurname: Stringmail: Stringpassword: Stringtoken: String

User Schema

name: Stringdescription: Stringprotocol: StringbasePath: String

Service Description Schema

service: ObjectIdname: Stringtype: enumdescription: Stringpath:StringbridgeName: Stringprotocol: StringstoreLink: String

Operation Schema

list: StringResponse Schema

name: Stringvalue: String

Header Schema

name: Stringdescription: Stringrequired: Booleantype: Stringdefault: StringcollectionFormat: enummappingCdt: [String]mappingTerm: [String]

Parameter Schema

attributeName: Stringtype: enumtokenAttribute: StringpageCountAttribute: String

Pagination SchematermName: Stringpath: String

Item Schema

run: StringonAttribute: String

Operate Schema

from: Stringto: String

Translate Schema

*

0..1

0..1

0..1

1

1

1

0..1

*

*

1

*

*

1

0..1

globalId: ObjectIdGlobal Cdt Schema

userId: [ObjectId]Mashup Schema

mashupId: ObjectIdGlobal Mashup

topics: [String]Item Schema

type: Stringstyle: Stringcontents: [String]

Content Schema1

*1

2

*

Figura 5.2: Schema logico del database

5.4 Componenti

Come già evidenziato nella Sezione 4.1.1, l’architettura del backend è compostada diversi componenti. Questa soluzione è stata adottata per via dell’elevata fles-sibilità che garantisce. Ogni componente è specializzato in un compito preciso e ilconcatenamento di più componenti permette di realizzare funzionalità più comples-se per produrre il risultato desiderato. Per svolgere le principali attività vengonodunque create delle pipeline, dove il risultato di un componente viene acquisito eulteriormente elaborato dal successivo.

Altra caratteristica importante è l’assenza di informazioni sullo stato in ognicomponente. Una richiesta nasce nel momento in cui l’utente conferma l’attività emuore una volta che viene evasa. La ragione principale di questa scelta risiede nelfatto che sarebbe oneroso lato backend gestire tutte le informazioni della moltitudinedi utenti che sono connessi al sistema. Inoltre mantenere uno stato limiterebbe lascalabilità del sistema, in quanto se un utente inizia la sessione su di un determinatoserver dovrà continuare sempre su quello, rendendo complicato il bilanciamento deicarichi tra le diverse macchine.

A questo punto è necessaria una importante precisazione: per la gestione dellapaginazione è necessario l’utilizzo di alcune informazioni sullo stato. Questa affer-

98

5.4. Componenti

+getD

ecor

atedC

dt(co

ntext:

Obje

ct): P

romi

se<O

bject>

-mer

geCd

tAnd

Conte

xt(co

ntext:

Obje

ct): P

romi

se<O

bject>

-crea

teMap

(list: A

rray):

Map

-mer

geOb

jects(

list: A

rray,

map:

Map)

: Arra

y-g

etFilte

rNod

es(m

erge

dCdt:

Obje

ct, cd

t:Obje

ct): A

rray

-getR

ankin

gNod

es(m

erge

dCdt:

Obje

ct, cd

t: Obje

ct): A

rray

-getP

aram

eterN

odes

(mer

gedC

dt: O

bject)

: Arra

y-g

etSpe

cificN

odes

(mer

gedC

dt: O

bject)

: Arra

y-g

etNod

es(ty

pe: S

tring,

items

: Arra

y, sp

ecific

Flag:

Boole

an): A

rray

-getD

esce

ndan

ts(cd

t: Obje

ct, no

des:

Arra

y): A

rray

ContextManager

+getI

nstan

ce():

Obje

ct+g

etCdtB

yId(id

Cdt: S

tring)

: Pro

mise

<Obje

ct>+g

etCdtB

yUse

r(use

rId: S

tring)

: Pro

mise

<Obje

ct>+g

etGlob

alCdt(

): Pr

omise

<Obje

ct>+g

etSer

viceB

yOpe

ratio

nId(id

Oper

ation

: Obje

ctId)

: Pro

mise

<Obje

ct>+g

etSer

vices

ByOp

erati

onIds

(idOp

erati

ons:

Arra

y): P

romi

se<A

rray>

+filte

rPrim

aryS

ervic

es(id

Cdt: O

bjectI

d, att

ribute

s: Ar

ray):

Pro

mise

<Arra

y>+s

earch

Prim

aryB

yCoo

rdina

tes(id

Cdt: O

bjectI

d, no

de: O

bject)

: Pro

mise

<Arra

y>+fi

lterS

uppo

rtSer

vices

(idCd

t: Obje

ctId,

categ

ory:

Strin

g, att

ribute

s: Ar

ray):

Pro

mise

<Arra

y>+g

etSer

vices

Cons

traint

Coun

t(idCd

t: Obje

ctId,

categ

ory:

Strin

g, idO

pera

tions

: Arra

y): P

romi

se<A

rray>

+sea

rchSu

ppor

tByC

oord

inates

(idCd

t: Obje

ctId,

node

: Obje

ct): P

romi

se<A

rray>

+getU

ser(m

ail: S

tring,

pass

word

: Strin

g): P

romi

se<O

bject>

+che

ckUs

erLo

gin(m

ail: S

tring,

token

: Strin

g): P

romi

se<O

bject>

+getU

serM

ashu

p(us

erId:

Strin

g): P

romi

se<O

bject>

-sear

chBy

Coor

dinate

s(mod

el: O

bject,

idCd

t: Obje

ctId,

node

: Obje

ct): P

romi

se<A

rray>

+getR

edisV

alue(

key:

Strin

g): P

romi

se<O

bject>

+setR

edisV

alue(

key:

Strin

g, va

lue: O

bject,

ttl: N

umbe

r)

+insta

nce:

Objec

t-d

bUrl:

Strin

g-re

disAd

dres

s: St

ring

-radiu

s: Nu

mber

Provider

+sele

ctSer

vices

(dec

orate

dCdt:

Obje

ct): P

romi

se<A

rray>

-spec

ificSe

arch

(idCd

t: Obje

ctId,

node

s: Ar

ray):

Pro

mise

<Arra

y>-ca

lculat

eRan

king(

servi

ces:

Arra

y): A

rray

-sear

chBy

Coor

dinate

s(idC

dt: O

bjectI

d, no

de: O

bject)

: Pro

mise

<Arra

y>

-n: N

umbe

r-fil

terW

eight:

Num

ber

-rank

ingW

eight:

Num

berPrimaryServiceSelection

+exe

cuteQ

uery(

servi

ces:

Arra

y, de

cora

tedCd

t: Obje

ct): P

romi

se<O

bject>

-callS

ervic

e(de

scrip

tor: O

bject,

deco

rated

Cdt: O

bject,

pagin

ation

Statu

s: Ob

ject):

Pro

mise

<Obje

ct>

-brid

geFo

lder:

Strin

gQueryHandler

+map

pingR

espo

nse(

resp

onse

: Obje

ct, de

scrip

tor: O

bject)

: Pro

mise

<Arra

y>-re

trieve

ListO

fRes

ults(r

espo

nse:

Objec

t, list

Item:

Strin

g): A

rray

-getI

temVa

lue(ite

m: O

bject,

key:

Strin

g): S

tring

-tran

sform

Item(

item:

Obje

ct, de

scrip

tor: O

bject)

: Obje

ct-e

xecu

teFun

ction

s(item

s: Ar

ray,

desc

riptor

: Obje

ct): A

rray

-isInv

alidV

alue(

value

: Strin

g): B

oolea

n

ResponseParser

Bridge

+exe

cuteQ

uery(

desc

riptor

: Obje

ct, de

cora

tedCd

t: Obje

ct, pa

ginati

onAr

gs: O

bject)

: Pro

mise

<Obje

ct>-in

voke

Servi

ce(d

escri

ptor:

Objec

t, dec

orate

dCdt:

Obje

ct, pa

ginati

on: O

bject)

: Pro

mise

<Obje

ct>-m

akeC

all(a

ddre

ss: S

tring,

head

ers:

Arra

y): P

romi

se<O

bject>

-getP

agina

tionS

tatus

(des

cripto

r: Ob

ject, c

urre

ntPag

e: Nu

mber,

resp

onse

: Obje

ct): O

bject

-getS

tartP

age(

desc

riptor

: Obje

ct, pa

ginati

onAr

gs: O

bject)

: Strin

g

-timeo

ut: N

umbe

r-ca

cheT

TL: N

umbe

r

RestBridge

+pre

pare

Resp

onse

(resp

onse

: Obje

ct): P

romi

se<O

bject>

-findS

imila

rities

(resp

onse

: Arra

y): A

rray

-calcu

lateO

bjectS

imila

rity(o

bj1: O

bject,

obj2:

Obje

ct): N

umbe

r-m

erge

Items

(prim

ary:

Objec

t, sec

onda

ry: O

bject)

: Obje

ct

-thre

shold

: Num

berRe

sponseAggregator

+sele

ctSer

vices

(dec

orate

dCdt:

Obje

ct): P

romi

se<A

rray>

-selec

tSer

viceF

romC

atego

ry(ca

tegor

ies: A

rray,

deco

rated

Cdt: O

bject)

: Pro

mise

<Arra

y>-m

erge

Resu

lts(fil

terSe

rvice

s: Ar

ray,

custo

mSer

vices

: Arra

y, co

nstra

intCo

unt: N

umbe

r): A

rray

-comp

oseQ

uerie

s(des

cripto

rs: A

rray,

deco

rated

Cdt: O

bject,

categ

ory:

Strin

g): A

rray

-spec

ificSe

arch

(idCd

t: Obje

ctId,

node

s: Ar

ray):

Pro

mise

<Arra

y>-se

arch

ByCo

ordin

ates(i

dCdt:

Obje

ctId,

node

: Obje

ct): P

romi

se<A

rray>

SupportServiceSelection

+login

(mail

: Strin

g, pa

sswo

rd: S

tring)

: Pro

mise

<Obje

ct>+g

etPer

sona

lData

(mail

: Strin

g, tok

en: S

tring)

: Pro

mise

<Obje

ct>

UserManager

+res

olveR

esult

s(use

rId: O

bjectI

d, ca

ched

Objec

t: Obje

ct, pa

ginati

onAr

gs: O

bject)

: Pro

mise

<Obje

ct>SessionHelper

+getD

ecor

atedC

dt(us

erId:

Obje

ctId,

conte

xt: O

bject)

: Pro

mise

<Obje

ct>+g

etPrim

aryD

ata(u

serId

: Obje

ctId,

conte

xtHas

h: St

ring,

deco

rated

Cdt: O

bject,

pagin

ation

Args

: Obje

ct,

conn

ectio

nId: S

tring)

: Pro

mise

<Arra

y>+g

etSup

portD

ata(d

ecor

atedC

dt: O

bject)

: Pro

mise

<Arra

y>+lo

gin(m

ail: S

tring,

pass

word

: Strin

g): P

romi

se<O

bject>

+getP

erso

nalD

ata(m

ail: S

tring,

token

: Strin

g): P

romi

se<O

bject>

-star

tTim

er():

Obje

ct

+ses

sionE

xpira

tion:

Numb

erExecutionHelper

+com

pose

Addr

ess(d

escri

ptor:

Objec

t, dec

orate

dCdt:

Obje

ct, pa

geInf

o: St

ring)

: St

ring

-sear

chMa

pping

s(nod

es: A

rray,

name

: Strin

g): A

rray

-tran

slateV

alue(

value

: Strin

g, ru

les: A

rray):

Strin

g

QueryCom

poser

Figura 5.3: Diagramma delle classi del backend

99

5. Progettazione di dettaglio e implementazione del backend

mazione può sembrare un controsenso rispetto a ciò che è stato esposto nel paragrafoprecedente. È dunque essenziale definire in modo dettagliato cosa si intende per sta-to. La principale differenza consiste nel dove vengono salvate le informazioni. Nelparagrafo precedente, ogni volta che si menzionava il concetto di stato, si intende-vano tutte le informazioni relative l’utente salvate all’interno dei componenti, sottoforma di variabile. Questa soluzione può essere un collo di bottiglia non indifferen-te, in quanto tutte le richieste che nascono in una determinata macchina dovrannoessere gestite esclusivamente da essa. Si è adottata quindi una soluzione differente:i componenti non mantengono al loro interno alcuna informazione riguardo lo stato,che verrà invece memorizzato e reso disponibile da un servizio esterno. Questa so-luzione permette a tutti i componenti che ne hanno esigenza di andare a recuperarele informazioni sullo stato da una sorgente comune, che non limita la scalabilitàdel sistema. Questo servizio può a sua volta offrire dei sistemi di clustering peraumentare le perfomance in situazioni di elevato carico.

In CAMUS questa attività viene svolta da Redis, che è stato selezionato perl’elevata rapidità nell’evadere le richieste e nella possibilità di associare un periododi vita alle informazioni che vengono memorizzate. Viene ipotizzato che dopo unintervallo di tempo nel quale l’utente non effettua più interazione sulla sessione, essapuò ritenersi estinta e i suoi dati eliminati.

Per gestire le funzionalità del server viene utilizzato il web framework ExpressJS1.ExpressJS è un framework molto leggero, che mette a disposizione le funzionalitàbase affinché un server sia operativo. Ha la potenzialità di avere un ottimo sistemadi middleware, che permette di utilizzare altre funzionalità più avanzate.

Per GraphQL viene utilizzata l’implementazione specifica per Javascript rila-sciata da Facebook2 e l’estensione di Relay3 per gestire le connessioni. Affinché glischemi di GraphQL possano essere esposti dal server si sfrutta l’apposito middlewareExpress-GraphQL4.

MongoDB non possiede una struttura dello schema del database definita a prio-ri. Per garantire coerenza coi dati memorizzati si è scelto di utilizzare un ObjectRelational Mapping (ORM)5. Un ORM fornisce un livello di astrazione superiorea un driver nativo e permette di specificare come gli oggetti vengono mappati neldatabase e viceversa, definendo implicitamente uno schema del database. In parti-colare, per il progetto CAMUS è stato utilizzato un ORM specifico per Node.js dinome mongoose6.

1ExpressJS: http://expressjs.com/2GraphQL-js: https://github.com/graphql/graphql-js3Relay-GraphQL: https://github.com/graphql/graphql-relay-js4Express-GraphQL: https://github.com/graphql/express-graphql5Object Relational Mapping: https://it.wikipedia.org/wiki/Object-relational_mapping6MongooseJS: http://mongoosejs.com/

100

5.4. Componenti

Infine, per interfacciare Node.js con l’istanza di Redis in esecuzione viene utiliz-zato il modulo ioredis7.

In Figura 5.3 viene mostrato il diagramma delle classi di tutti i componenti cheformano il backend del sistema. Nelle seguenti sottosezioni verranno analizzate neldettaglio le attività svolte e i dettagli implementativi dei componenti principali delsistema.

5.4.1 Provider

Il Provider rappresenta il punto di accesso al database. È realizzato seguen-do il pattern singleton, che prevede una singola istanza della classe in comune pertutti i componenti. Le varie classi che necessitano di accedere al database posso-no recuperare l’istanza corrente tramite il metodo statico getInstance(). Durantel’inizializzazione si occupa di creare le connessioni verso MongoDB e Redis. Im-plementa tutti i metodi necessari per recuperare le informazioni dal database ecentralizza tutte le query in un singolo punto, in modo che gli altri componenti delsistema non debbano preoccuparsi di comporre le clausole. Inoltre, visto che diversimetodi vengono utilizzati da più componenti, si evitano duplicazioni di codice cheprovocano una riduzione della manutenibilità del sistema, in quanto una modifica aun metodo dovrebbe essere ripetuta più volte.

I metodi sono stati raggruppati in sei categorie, in base alla funzionalità:

1. CDT Methods Mette a disposizione le funzioni necessarie a recuperare glialberi di contesto. Possono essere cercati tramite identificativo, se si vuoleacquisire un albero specifico, oppure tramite utente, se si vuole recuperare ilsuo CDT personalizzato

2. Service Descriptor Methods Definisce le funzioni che vengono utilizzateper acquisire i descrittori dei servizi. I due oggetti, “descrizione generale delservizio” e “descrittore delle operazioni” vengono automaticamente integrati aformare un unico oggetto

3. Primary Service Methods Fornisce le funzioni di ricerca delle associazionitra i nodi del CDT e le operazioni primarie. Il metodo principale riguarda laricerca delle coppie <dimensione, valore> definite dalle dimensioni del conte-sto e i relativi valori. Possono entrare a far parte di questa categoria anche imetodi di ricerca specializzati, cioè tutte le funzioni che necessitano di logicheparticolari per recuperare le associazioni. Un esempio è fornito dalla ricercatramite coordinate: è presente un metodo che sfrutta le capacità di MongoDBdi eseguire query geospaziali

7ioredis: https://github.com/luin/ioredis

101

5. Progettazione di dettaglio e implementazione del backend

4. Support Service Methods Implementa i metodi di ricerca delle associazionitra i nodi del CDT e le operazioni di supporto. Rispetta le stesse convenzionidescritte nel punto precedente

5. User Methods Definisce i metodi che vengono utilizzati per l’autenticazionedegli utenti e il recupero delle informazioni personali, quali il proprio albero dicontesto o i mashup

6. Redis MethodsVengono messi a disposizione i metodi per richiedere o salvareun oggetto in Redis in base alla chiave che si desidera utilizzare

5.4.2 Context Manager

Il Context Manager è il componente dedicato alla gestione del contesto. Ricevein ingresso il contesto dell’utente, composto dalle coppie <dimensione, valore>, e iparametri relativi al proprio albero di contesto. La prima attività svolta è quelladi unire il contesto dell’utente e la descrizione del CDT presente nel database. Perunione si intende associare a ogni dimensione e parametro il relativo valore ricevuto.

In seguito inizia la fase di creazione del CDT decorato. Questa rappresentazionesarà quella che verrà utilizzata da tutti i componenti che seguono il Context Managernella pipeline. Il CDT decorato non è altro che il descrittore del CDT in una forma piùcomoda per essere utilizzata nelle elaborazioni, in quanto cataloga i nodi dell’alberoin quattro categorie ben specifiche, che potranno essere semplicemente recuperatedai componenti che ne hanno bisogno senza la necessità di andare ogni volta aleggere l’intero contesto. In particolare, il CDT decorato è composto dalle seguenticategorie:

• Filter Nodes Sono i nodi di tipo filtro che vengono utilizzati per selezionarele operazioni

• Ranking Nodes L’elenco dei nodi di tipo ranking che vengono utilizzati perselezionare le operazioni

• Specific Nodes Sono i nodi che non utilizzano la ricerca standard delle as-sociazioni ma richiedono una ricerca specifica. La definizione di entrambe letipologie verrà approfondita nella Sezione 5.4.3

• Parameter Nodes L’elenco dei nodi dai quali recuperare i valori da utilizzareper la composizione delle query

È da tenere in considerazione, come precedentemente fatto notare nella Sezione5.1, che alcuni nodi possono appartenere a più categorie nello stesso tempo. Questaeventualità capita spesso per i nodi che vengono utilizzati sia per filtrare i servizisia come parametro nella fase di composizione delle query.

102

5.4. Componenti

Un’altra attività svolta durante la composizione del CDT decorato è la ricerca deinodi figlio. Come definito nella Sezione 3.7 le associazioni possono essere specificatesia nei nodi foglia sia in quelli intermedi. È importante quindi verificare se un nodoattivo possieda dei figli perché in tal caso anch’essi possono dare un contributo nellesuccessive fasi di selezione. L’algoritmo per la selezione dei nodi figlio segue la logicaesposta nella Sezione 3.9.

5.4.3 Primary Service Selection

Il Primary Service Selection è il componente dedicato alla ricerca delle operazioniprimarie da interrogare. Riceve in ingresso il CDT Decorato e produce l’elenco degliidentificativi delle operazioni selezionate, assieme al relativo punteggio.

La prima attività svolta riguarda l’acquisizione delle operazioni che sono asso-ciate al contesto corrente. Questa fase viene divisa in due fasi:

1. Ricerca Standard Viene effettuata ricercando nel database tutte le opera-zioni che sono associate alle coppie <dimensione, valore> attive, ossia i nodidell’albero selezionati dall’utente. Vengono utilizzati sia i nodi di tipo filtro siaquelli di tipo ranking, distinguendoli nella fase di assegnamento dei pesi

2. Ricerca Specifica Utilizza dei metodi specifici per ricercare le associazio-ni. Un esempio è la ricerca delle operazioni tramite coordinate, che sfruttale funzionalità di MongoDB di effettuare query geospaziali. Le associazioniidentificate in questa fase vengono classificate come ranking

Una volta recuperate tutte le associazioni, vengono calcolati i punteggi da asse-gnare ad ognuno, con la procedura descritta nel dettaglio nella Sezione 3.9.

5.4.4 Query Handler

Il Query Handler è il componente che orchestra le chiamate verso i servizi pri-mari, recupera le risposte e le trasforma nel formato interno. Riceve gli identificatividelle operazioni primarie e ne acquisisce i descrittori completi dal database.

Una volta disponibili può iniziare la fase di richiesta dei dati. Per svolgere questocompito vengono utilizzati diversi bridge. È possibile così separare l’implementazionespecifica del servizio in un altro componente, in modo che i servizi che condividonola medesima logica possano utilizzare lo stesso bridge. Il Query Handler selezionadunque il bridge idoneo per interrogare il servizio e ne esegue il metodo executeQue-ry(), che si occupa di interrogare il servizio e restituire la risposta ricevuta. Oltreall’elenco dei risultati, viene restituito un oggetto contenente le informazioni sullostato della paginazione (es.: se sono disponibili ulteriori pagine o il valore per richia-mare la pagina successiva), se il servizio possiede una descrizione di come gestire lapaginazione.

103

5. Progettazione di dettaglio e implementazione del backend

Quando riceve una risposta provvede a trasformarla nel formato interno, basan-dosi sull’utilizzo di termini semantici che descrivono la semantica degli attributi. Ildescrittore contiene al suo interno le informazioni necessarie per effettuare questatrasformazione. In particolare è necessario definire le associazioni per ogni attributorilevante della risposta e il relativo termine semantico che lo descrive. Non è obbli-gatorio definire associazioni per tutti gli attributi di una risposta: se alcuni campinon sono utili possono essere omessi. Una volta terminata la trasformazione vienelasciata la flessibilità di eseguire delle funzioni personalizzate sui valori dei terminiin modo da uniformare eventuali dati formattati in modo non idoneo.

Una menzione va fatta alla gestione degli errori. Può capitare che alcuni servizinon siano raggiungibili a causa di problemi di rete. In tal caso il bridge restituisceun messaggio di errore al posto della risposta. Il Query Handler non tratta gli erroricome eventi bloccanti, ma si limita a registrare questi eventi in un log. Infatti, seper esempio devono essere interrogati tre servizi e solo uno dei tre non risponde, nonè conveniente interrompere l’intero processo, bensì verranno restituite le rispostericevute dagli altri due servizi.

Una volta ricevute le risposte dai servizi e terminata la fase di trasformazione,viene creata un’unica lista comprendente tutti gli elementi ricevuti. Vengono in pra-tica uniti i vettori ricevuti dai diversi servizi. Questo elenco rappresenta il risultatofinale, che verrà dato in carico al componente successivo nella catena.

5.4.5 Bridge

Un Bridge è il componente che si occupa di gestire le chiamate verso i serviziesterni e ricevere le risposte. È costituito da una classe astratta che deve essereestesa dalle implementazioni specifiche. In questo modo viene lasciata flessibilità diestensione ogni qual volta sia necessaria una logica diversa per invocare un servizio.In particolare viene forzata l’implementazione del metodo executeQuery(), che ricevein ingresso il CDT Decorato con tutte le informazioni necessarie per completare iparametri richiesti dal servizio.

Nella sezione seguente viene analizzata l’unica implementazione specifica cheviene fornita in dotazione col sistema, quella per l’utilizzo dei servizi di tipo REST.

REST Bridge

Il REST Bridge fornisce la logica per interrogare i servizi di tipo REST. Laprima attività che svolge è la composizione dell’indirizzo verso il quale il serviziodeve essere interrogato. A tal fine viene utilizzato il componente Query Composer(Sezione 5.4.9), che è specializzato nell’eseguire questa operazione. In questa faseentra in gioco anche l’informazione sulla prima pagina da interrogare, nel caso incui quella corrente non sia la prima chiamata che viene effettuata verso il servizio.

104

5.4. Componenti

Una volta composto l’indirizzo completo, viene effettuata la chiamata verso ilservizio. Le risposte ricevute vengono salvate in cache, quindi questa attività hadue varianti: se il dato è presente in cache, questo viene recuperato e fornito im-mediatamente in uscita, altrimenti viene interrogato il servizio e il risultato fornitoviene salvato in cache per utilizzi futuri. I dati restano in cache per un determinatoperiodo di tempo definito a priori dalla configurazione del sistema.

Se il servizio prevede l’utilizzo della paginazione viene analizzata la risposta allaricerca di informazioni sulla presenza di ulteriori pagine da richiedere. In partico-lare vengono cercati gli attributi relativi al numero totale di pagine o al token perrichiamare la pagina successiva, in base alla tipologia implementata dal servizio.

Infine vengono restituite in uscita la risposta del servizio insieme alle eventualiinformazioni riguardo la paginazione, che in particolare sono due: i) hasNextPage,che indica se è presente un’altra pagina; ii) nextPage, che specifica il numero dipagina o token da utilizzare per richiamare la nuova pagina.

Come descritto nella Sezione 5.4.4, nel caso si verifichi un problema durantel’interrogazione del servizio, il bridge deve restituire un messaggio d’errore con lamotivazione per la quale non è riuscito a completare l’operazione (es.: servizio nonraggiungibile, richiesta mal formata, ecc.).

5.4.6 Response Aggregator

Il Response Aggregator entra in gioco una volta che sono stati interrogati tutti iservizi. Riceve l’elenco dei risultati dal Primary Service Selection ed effettua diverseattività per pulire i dati o aggiungere ulteriori informazioni. È stato strutturato inmodo che possano essere richiamati diversi metodi, ognuno con un compito preciso,per garantire flessibilità nell’aggiunta di nuove analisi sui dati.

Attualmente nel prototipo viene eseguita unicamente la ricerca dei duplicati.Questa attività è stata descritta nel dettaglio nella Sezione 3.10, dove è stato anchefornito lo pseudocodice dell’algoritmo utilizzato (Algoritmo 3.2).

5.4.7 Support Service Selection

Il Support Service Selection è il componente dedicato alla selezione delle opera-zioni di supporto o intent per richiamare le app del dispositivo. Riceve in ingresso ilCDT Decorato che, oltre a contenere le selezioni effettuate dall’utente, elenca anchele categorie di servizi che si desidera ricevere. Le categorie servono per raggruppareassieme più servizi che svolgono una funzione simile. La modalità di selezione delleoperazioni adatte al contesto è stata analizzata nella Sezione 3.9. Questa attivitàviene ripetuta integralmente per ognuna delle categorie, in quanto si vuole ottenerealmeno un riscontro per tutte le categorie elencate. Come nel caso del REST Bridge,

105

5. Progettazione di dettaglio e implementazione del backend

anche questo componente sfrutta il Query Composer (Sezione 5.4.9) per comporregli indirizzi che verranno poi restituiti all’app.

5.4.8 Session Helper

Il Session Helper viene utilizzato quando è stata effettuata una prima richiestaai servizi e la mobile app richiede ulteriori dati. Si occupa di gestire il salvataggio incache della sessione ed eventualmente, quando il primo result set sta per terminare,richiama un’altra volta i servizi richiedendo la pagina successiva.

Per gestire la paginazione tra backend e mobile app vengono utilizzati due para-metri:

• First Questo campo specifica il numero di elementi che vengono richiesti

• After Definisce il cursore di partenza. Verranno quindi restituiti il numero dielementi specificati nell’attributo “first” dopo l’elemento con quello specificoidentificatore

Questi parametri vengono ereditati dal sistema di gestione della paginazione diGraphQL. La prima attività che viene eseguita è tenere traccia di quanti elementidel result set corrente sono stati visualizzati dall’utente. Questa informazione ènecessaria per conoscere quanti elementi rimangono ancora da visualizzare. A questopunto viene effettuata una verifica se sono disponibili abbastanza informazioni damostrare, tramite la formula:

elementi_mostrati ≤ totale_elementi− first− 1 (5.1)

Dove:

• elementi_mostrati indica il numero di elementi che sono già stati mostratiall’utente

• totale_elementi rappresenta il numero totale di elementi presenti nel resultset

• first è lo stesso attributo descritto in precedenza, che indica quanti elementisono stati richiesti dal client

Se l’equazione è rispettata vengono semplicemente restituiti i dati presenti incache, altrimenti il Session Helper si occupa di recuperare dalla cache le informazionisui servizi prescelti nella richiesta originale e sulle pagine da richiedere ed effettuale richieste ai servizi, sfruttando il Query Handler e il Response Aggregator.

106

5.4. Componenti

5.4.9 Query Composer

Sia nella Sezione 5.4.3 che nella Sezione 5.4.7 è stato menzionato il processo dicomposizione delle query per interrogare i servizi. Si è scelto di creare un componentead-hoc in quanto le due attività hanno delle lievi differenze che però non giustificanol’utilizzo di due logiche differenti. Inoltre la composizione degli indirizzi per i servizidi supporto sfrutta alcune regole che vengono utilizzate per i servizi primari. Daqui l’esigenza di avere un unico metodo che si occupa di analizzare il descrittoredei servizi per comprendere come comporre tra loro i parametri e fornire una querycompleta.

Il primo passo riguarda la selezione dei simboli da utilizzare nella query. Verrannoutilizzati simboli diversi nel caso il servizio sia di tipo REST o necessita di queryparametriche. Viene innanzitutto composto l’indirizzo di base, ossia quello formatodal basePath del servizio e il path specifico dell’operazione. Ora inizia la vera attività,ovvero la composizione dei parametri. Questa fase ha il compito di scorrere l’elencodei parametri definiti nel descrittore del servizio e verificare se è stato definito unvalore. Il valore può essere recuperato dall’albero di contesto o tramite i terminisemantici, in questo ordine di priorità. Ovviamente non tutti i parametri devonoper forza essere compilati. Esistono due casi in base al valore assunto dall’attributo“required”:

1. Parametro obbligatorio In questo caso deve per forza essere associato unvalore. Se non è presente nessuna associazione né con il CDT né con i terminisemantici verrà utilizzato il valore predefinito. Se non è stato definito nemmenoun valore predefinito verrà lanciata un’eccezione, in quanto il servizio senza unparametro obbligatorio non è utilizzabile

2. Parametro facoltativo In questo caso viene cercato prima un valore nell’al-bero di contesto e in seguito tra i termini semantici. Se viene trovata unacorrispondenza il rispettivo valore viene acquisito e il parametro entrerà a farparte della query

Durante la ricerca dei valori nell’albero di contesto viene anche eseguita la tra-duzione del valore, ove necessario. Se vengono trovate più di una corrispondenza, ivalori sono concatenati assieme e divisi tramite il separatore definito nel descrittore.Una volta terminata l’acquisizione il nome del parametro e il/i valore/i entrano afar parte dell’indirizzo.

Per terminare l’attività vengono messe assieme tutte le parti. All’indirizzo dibase viene aggiunta la parte dei parametri appena composta e anche l’attributorelativo alla paginazione, se richiesto.

107

5. Progettazione di dettaglio e implementazione del backend

Algoritmo 5.1 Algoritmo di composizione degli indirizziRequire:

descriptor ▷ The service descriptordecoratedCdt ▷ The decorated CDTpageInfo ▷ Information about pagination (optional)

Ensure:fullAddress ▷ The composed service address

querySymbols← configureQuerySymbols()baseAddress← descriptor.service.basePath+ descriptor.pathnodes← union(decoratedCdt.filterNodes, decoratedCdt.parameterNodes)for all param in descriptor.parameters do

if isEmpty(param.mappingCDT ) && isEmpty(p.mappingTerm) thenif isDefined(param.default) then

value← param.defaultelse

if param.required thenError(′Mandatory parameter′)

end ifend if

elseseparator ← configureSeparator(descriptor)if param.mappingCdt then

value← findV alueInCdt()else

value← acquireTerm()end if

end ifparameters← param.name+ querySymbols.assign+ value

end forif pageInfo then

fullAddress← baseAddress+ querySymbols.start+ parameters+querySymbols.separator + pageInfo

elsefullAddress← baseAddress+ querySymbols.start+ parameters

end ifreturn fullAddress

108

5.5. Endpoint GraphQL

5.5 Endpoint GraphQL

È possibile per le applicazioni interrogare il backend attraverso l’endpoint definitotramite GraphQL. In questa sezione si andranno ad analizzare le varie funzionalitàfruibili dal client. L’indirizzo di accesso rimane sempre lo stesso per tutti i casi,quello che cambia sarà un parametro nella richiesta che permette di identificarequale attività si desidera svolgere. In Figura 5.4 viene mostrato il diagramma delleclassi dello schema di GraphQL, mettendo in evidenza le connessioni tra i vari oggettie la tipologia dei campi.

Figura 5.4: Diagramma dello schema GraphQL

Il resto di questa sezione descriverà in dettaglio le varie attività che possonoessere invocate. Esse saranno identificate per semplicità di espressione col nome“endpoint”, visto che il fine ultimo è paragonabile a quello degli endpoint nel mondoREST.

5.5.1 Execute Query

È l’endpoint principale, riceve in ingresso il contesto dell’utente e restituisce leinformazioni recuperate, divise in primarie e di supporto. L’oggetto accettato iningresso è composto dai seguenti campi:

• User Mail L’indirizzo mail dell’utente

• Id Cdt È l’identificativo dell’albero di contesto che si desidera utilizzare

109

5. Progettazione di dettaglio e implementazione del backend

• Context Contiene le informazioni di contesto, ossia i nodi che sono attivi.Ogni oggetto è composto dai seguenti attributi:

– Dimension Rappresenta il nome del nodo dimensione

– Value Contiene il valore selezionato dall’utente per la dimensione

– Parameters Elenca i parametri associati alla dimensione. Ogni parame-tro è strutturato come di seguito:

* Name Il nome del parametro* Value Il valore definito dall’utente* Fields Contiene l’elenco dei campi associati al parametro. Ogni

campo viene descritto dal proprio “nome” e dal “valore” che assume

• Support Contiene l’elenco delle categorie di servizi di supporto che si voglionoricevere

Una volta ricevuto l’oggetto col contesto, tramite l’Execution Helper viene creatoil CDT Decorato. Una volta creato, verrà utilizzato come base per l’acquisizione delleinformazioni e la composizione dei servizi di supporto. Viene definito il seguenteoggetto come risposta:

• Connection Id Identificativo univoco della sessione. Viene utilizzato persegnalare al client se la risposta fa parte di una sessione precedente o si trattadi una nuova sessione

• Primary Connection Mette a disposizione l’elenco dei risultati integrati for-niti dai servizi primari. La particolarità è che si tratta di una connessione, unatipologia specifica di GraphQL che viene utilizzata quando si ha un elenco dielementi da mostrare. La caratteristica principale che mette a disposizioneriguarda la paginazione dei dati. Una volta definita la connessione, sempretramite l’Execution Helper, viene avviato il flusso di richiesta delle informa-zioni. A GraphQL viene restituito un vettore con i risultati. A partire daquesto elenco sarà suo compito dividerlo in parti in base alla richiesta ricevu-ta dal client. In particolare vengono utilizzati due parametri per specificarequali elementi si desiderano ricevere: i) first, dove viene specificato un nu-mero N di elementi che si desidera ricevere; ii) after, che definisce il cursoredell’ultimo elemento ricevuto nella richiesta precedente. Quando viene uti-lizzato unicamente il campo “first”, GraphQL restituisce i primi N risultati.Se viene specificato anche il campo “after” vengono mostrati gli N elementia partire dall’elemento successivo a quello definito dal cursore. Per cursore siintende un identificativo univoco che viene automaticamente calcolato da Gra-phQL per ogni elemento della risposta. Per permettere al client di conoscere

110

5.5. Endpoint GraphQL

lo stato della paginazione oltre all’elenco dei risultati viene restituito ancheun oggetto di stato, contenente principalmente due attributi: i) hasNextPage,valore booleano che indica se può essere recuperata un’ulteriore pagina; ii)endCursor, che fornisce il cursore dell’ultimo elemento ricevuto nella richiestacorrente. In questo modo viene lasciata libertà al client di gestire il numero dielementi da ricevere. Ogni oggetto che della risposta è composto dai terminisemantici che sono stati definiti nel sistema. Inoltre viene aggiunto un oggettoche indica da quali servizi, che possono essere più di uno nel caso di unionedi elementi duplicati, è stato recuperato l’oggetto e il punteggio assegnato alservizio in fase di selezione

• Support Connection Fornisce l’elenco dei servizi di supporto che sono statiselezionati. Come nel caso dei risultati primari viene utilizzata una connessioneGraphQL. Ogni oggetto viene rappresentato dal nome del servizio, la categoriaper la quale è stato selezionato e l’indirizzo composto

Nel Listato B.2 viene mostrato un esempio di richiesta per effettuare la ricercadi dati sia primari sia di supporto.

5.5.2 Login

Questo endpoint è dedicato all’autenticazione degli utenti. Riceve in ingressol’indirizzo mail e la password, cifrata con algoritmo SHA18, digitati dall’utente. Se idue parametri corrispondono a un utente vengono restituiti un token, utilizzato permantenere aperta la sessione, e il nome e cognome dell’utente, per personalizzarel’app con le informazioni personali.

5.5.3 Get Personal Data

Questo endpoint provvede a fornire all’utente i suoi dati personali, che possonoessere gli alberi di contesto e i mashup che gli sono stati associati dall’esperto disettore. In questo modo la mobile app può recuperare le versioni più aggiornate deglischemi relativi all’utente. In ingresso vengono richiesti l’indirizzo mail dell’utente eil token ricevuto nella fase di autenticazione. Se i due valori corrispondono, vengonorestituiti i dati richiesti. Il formato della risposta viene composto come segue:

• Cdt Rappresenta la radice dell’albero di contesto. Un CDT viene definito daiseguenti attributi:

– Id Cdt L’identificativo dell’albero di contesto

– Context Contiene le informazioni sul contesto, ossia i nodi che compon-gono l’albero. Ciascun nodo viene definito come segue:

8SHA1: https://en.wikipedia.org/wiki/SHA-1

111

5. Progettazione di dettaglio e implementazione del backend

* Name Il nome del nodo dimensione* Values L’elenco dei possibili valori che può assumere il nodo* Parameters Lista dei parametri associati al nodo. Ogni parametro

è composto dai seguenti campi:· Name Il nome dell’attributo· Type La tipologia di dato· Fields Elenco di campi che specializzano il parametro. La strut-

tura di un campo è molto simile a quella del parametro, infatticontiene gli attributi “Name”, che definisce il nome del campo, e“Type”, che ne specifica la tipologia

* Parents Elenco di tutti i parenti del nodo corrente

– Default Values Elenco dei valori che non vengono mostrati nell’albero dicontesto perché precedentemente selezionati. Questo oggetto è compostodagli attributi “dimension”, che rappresenta il nome del nodo dimensione,e “value”, che è il valore associato al nodo

• Mashup Rappresenta lo schema dei mashup. Fornisce alla mobile app leregole per comporre l’interfaccia grafica nelle diverse situazioni. Uno schemadi mashup è composto dai seguenti campi:

– ListQuesto oggetto fornisce le regole per rappresentare la lista dei risulta-ti, ossia la schermata di merge o master. In questa pagina viene mostratol’elenco dei dati recuperati, descritti da un insieme ridotto di attributi.Per specificare quali dati devono essere mostrati e come vengono utilizzatii seguenti attributi:

* Topics Elenco degli Interest Topic per i quali lo schema corrente èvalido

* Contents Definisce i componenti che devono essere utilizzati, il lorostile e dove recuperare i dati da essere mostrati. Ogni oggetto vienedefinito dai seguenti attributi:· Type Specifica la tipologia di componente da utilizzare (es.: text

per informazioni testuali, map per mostrare una mappa, websiteper creare un collegamento verso una pagina web, ecc.)

· Style Permette di definire uno stile diverso da quello predefinitoal componente. Se è presente permette di sovrascrivere lo stileoriginale Flexbox dell’elemento

· Contents Definisce quali sono i termini semantici dai quali èpossibile recuperare le informazioni. Viene inoltre data la pos-sibilità di inserire dei sottocomponenti, dello stesso tipo definitonell’attributo “Type”, per formare un componente aggregato

112

5.6. File di configurazione

– Details Questo oggetto definisce la composizione della schermata di det-taglio di un singolo elemento. Questa pagina viene richiamata una vol-ta che l’utente seleziona un elemento per controllarne le informazionispecifiche. Viene definito dagli stessi attributi della sezione “List”

Nel Listato B.4 viene mostrato un esempio di richiesta per ricevere i dati personalidell’utente.

5.6 File di configurazione

Per configurare agilmente determinati parametri del sistema, vengono sfruttatele variabili d’ambiente e viene messa a disposizione una cartella dove aggiungere deifile di configurazione. In caso di conflitto viene seguita la seguente scala di priorità:

1. Variabili d’ambiente Vengono inizialmente considerate le variabili d’am-biente

2. File di configurazione Il valore viene acquisito dal file di configurazione

3. Valore predefinito Se nessuno dei due precedenti passi ha prodotto un valorene viene utilizzato uno predefinito. Esistono casi dove un valore predefinitonon è utilizzabile (es.: indirizzo del database), quindi se non viene specificatoalcun valore l’applicazione lancerà un’eccezione

Vengono messe a disposizione le seguenti variabili d’ambiente:

• NODE_ENV Per definire l’ambiente nel quale avviare l’applicazione (es.:production, development, testing, ecc.)

• PORT La porta che si vuole utilizzare per richiamare gli endpoint

• MONGO_URI L’indirizzo di MongoDB. Può comprendere anche l’utente ela password di accesso al database

• REDIS_URL L’indirizzo di Redis. Può comprendere anche l’utente e lapassword di accesso al database

Nella cartella “config” è possibile aggiungere dei file per configurare altri para-metri. Possono essere creati più file di configurazione, che verranno caricati per idiversi ambienti nel quale può funzionare l’applicazione. Basta chiamare il file colnome dell’ambiente di destinazione (es.: production, development, qa, staging, ecc.)affinché venga selezionata la configurazione corretta. Viene fornita una configura-zione di “default”, utilizzata quando non è presente nessun file relativo all’ambientecorrente. Di seguito vengono elencati i parametri che possono essere configurati; traparentesi sono indicati i valori predefiniti di ciascun campo:

113

5. Progettazione di dettaglio e implementazione del backend

• server Contiene la configurazione del server

– port (3001) Definisce la porta che si vuole utilizzare per richiamarel’endpoint

• database Contiene la configurazione di MongoDB

– address Definisce l’indirizzo del database. Possono essere incluse leinformazioni di autenticazione

• redis Definisce la configurazione di Redis

– address (localhost:6379) Specifica l’indirizzo del database in-memory.Possono essere incluse le informazioni di autenticazione

• rest Specifica la configurazione del bridge per i servizi REST

– timeout Definisce i periodi di tempo dopo i quali scatta il timeout

* service (3000) Valore di timeout dopo il quale una richiesta verso iservizi esterni scade. Il valore viene specificato in millisecondi (ms)

* cache (1800) Specifica il tempo per il quale rimangono salvati in ca-che le risposte ricevute dai servizi. Il tempo viene espresso in secondi(s)

• primaryService Gestisce la configurazione del componente Primary ServiceSelection

– n (3) Definisce quante operazioni selezionare

– weight Specifica i pesi che vengono assegnati alle varie tipologie di nodo

* filter (1) Peso dei nodi di tipo filter* ranking (4) Peso dei nodi di tipo ranking

• similarity Configurazione del componente di ricerca dei duplicati

– threshold (0.85) Definisce la percentuale minima di similarità tra dueelementi affinché vengano considerati duplicati. Una valore maggiore in-dica un’elevata similarità tra gli elementi. Viene considerato come unapercentuale (es.: 0.9 equivale al 90% di similarità)

• paginationTTL (1800) Definisce il tempo per il quale rimane memorizzatolo stato di una connessione in cache. Il tempo viene specificato in secondi (s)

• debug (false) Indicatore booleano che abilita o disabilita il logging delle infor-mazioni su console

114

5.6. File di configurazione

• metrics (false) Valore booleano che abilita o disabilita la raccolta delle infor-mazioni sui tempi di esecuzione dei metodi principali e delle chiamate verso idatabase

Nessun campo è obbligatorio, a eccezione dell’indirizzo di MongoDB, se non spe-cificato tramite variabili d’ambiente. In assenza degli altri campi verranno utilizzatii rispettivi valori di default.

115

5. Progettazione di dettaglio e implementazione del backend

116

Capitolo 6

Progettazione di dettaglio eimplementazione della mobileapp

L’applicazione mobile CAMUS rappresenta l’altro elemento fondamentale dell’ar-chitettura. Fornisce all’utente finale l’interfaccia per accedere al sistema e semplifical’utilizzo e l’accesso ai dati. Il capitolo si apre con una descrizione dettagliata delleActions e degli Stores di Alt.js. Successivamente viene introdotto lo schema per de-finire le pagine e la logica di aggiornamento dei dati, seguendo il principio del flussodati unidirezionale. In seguito viene definita la struttura del file di mashup prove-niente dal server, che è indispensabile per la creazione delle schermate dell’app, perpoi trattare nello specifico i metodi necessari per la costruzione di queste schermate.Successivamente si illustra il flusso dei dati all’interno dell’applicazione e di comevengono gestite le richieste dati verso il server, tramite GraphQL, per effettuare leattività riguardanti il login e la ricerca delle informazioni contestuali per l’utente.In conclusione verrà trattato l’argomento riguardante i servizi di supporto.

6.1 Gestione dello stato

In questa sezione sono descritte nel dettaglio tutte le Actions e gli Stores utilizzatenell’applicazione e presentate nella Sezione 4.1.2.3

6.1.1 Actions

Le Actions sono i metodi utilizzati per modificare lo stato dell’applicazione.Vengono utilizzate principalmente in due modi:

• Data Fetching Quando è necessario scaricare gli elementi necessari per ilcorretto funzionamento dell’applicazione (CDT e mashup) o i dati provenienti

117

6. Progettazione di dettaglio e implementazione della mobile app

dalle richieste, le action hanno lo scopo di modificare lo stato per cambiare laview dell’applicazione a seconda dello stato della richiesta. Per esempio, quan-do si preme il pulsante per effettuare una nuova richiesta basata sul contesto,viene invocata un’azione per mantenere lo stato coerente tra più componentie permettere di mostrare in fase di caricamento uno Spinner. Una volta chela richiesta viene evasa e i dati sono disponibili, viene eseguita un’altra azioneper mostrarli all’interno di una ListView

• Application State Lo stato generale dell’applicazione viene salvato utilizzan-do delle Action chiamate dalle interazioni dell’utente con l’interfaccia grafica.Per esempio quando viene composto il contesto le diverse selezioni sono passa-te dall’utente tramite le Context Actions nelle Context Store, per poi rimaneredisponibili per la visualizzazione delle selezioni già effettuate o la costruzionedella query per i dati

Le Actions implementate nell’applicazione sono le seguenti:

• User Actions Sono le azioni che servono ad aggiornare i parametri relativiall’utente, come password, email e il suo identificativo della sessione:

– Update Email Metodo per aggiornare l’email dell’utente

– Update Password Metodo per aggiornare la password dell’utente

– Update Token Metodo per tenere in memoria il token della connessionecol server

• Context Actions Sono le azioni che gestiscono la selezione del contesto,consentendo di modificare le scelte effettuate dall’utente:

– Set Transport Metodo per salvare la tipologia di trasporto da partedell’utente

– Set Typology Metodo per salvare la tipologia nel caso di trasporto noncon mezzi propri

– Add Forbidden Metodo per aggiungere un parametro in quelli da na-scondere all’utente

– Remove Forbidden Metodo per rimuovere il parametro selezionatodalla lista di quelli da nascondere all’utente

– Update Last Context Metodo per salvare l’ultimo contesto inviato alserver, per poterlo riutilizzare nelle richieste per le pagine successive

• View Actions Sono le azioni relative alla gestione dei mashup ma non dellostato della navigazione, per le quali è utilizzato un componente aggiuntivosempre basato su Flux (React Native Router Flux):

118

6.1. Gestione dello stato

– Set Views Metodo per salvare il file con le view provenienti dal server

– Select Interest Topic Metodo per salvare l’Interest Topic selezionatodall’utente. Questa funzione è chiamata quando nella pagina inizialel’utente seleziona l’Interest Topic per la selezione della view appropriata

• Data Actions Trattano della gestione del CDT e dei risultati ottenuti dalserver:

– Update Results Metodo per aggiornare i dati dei risultati provenientidalla query basata sul contesto

– Results Failed Metodo per inviare il messaggio di errore provenientedalla richiesta

– Update Full CDT Metodo per aggiornare il CDT associato all’utente

6.1.2 Stores

Gli Stores salvano lo stato dell’applicazione e forniscono alle view nuovi datiogni volta che sono aggiornate. Per ogni interazione sui dati dell’applicazione chenecessitano di rimanere persistenti viene invocata una action dal componente e dallaview che si propaga prima negli store e successivamente aggiorna nuovamente la view.Si è scelto di suddividere gli Store per tipologia di operazione e dato trattata:

• User Store Nello User Store sono memorizzati tutti i dati relativi all’utente.In particolare viene memorizzata la mail dell’utente e l’identificativo del CDTa lui associato, che serviranno per poter effettuare le query GraphQL perottenere i dati

• Context Store Nel Context Store vengono gestiti i dati che riguardano idati di contesto, come le coordinate geografiche e le scelte delle tipologie ditrasporto pubblico, in modo da essere riutilizzate. Per quanto riguarda lerichieste di dati, una volta che il contesto viene composto per effettuare laprima query, questo payload viene salvato qui e poi riutilizzato nelle query deirisultati successivi

• View Store In questo store sono memorizzati tutti i dati relativi alle view.Qui viene salvato lo schema di mashup e l’Interest Topic corrente

• Data Store Si tratta dello store più complesso perchè deve gestire in mododinamico diverse tipologie di dato. Quando viene ricevuto il CDT, vengonoscanditi gli interest topic ed è creato un oggetto nel campo results compostoda un array di tanti oggetti definiti da due campi:

1. Results Rappresenta i risultati ricevuti per quell’interest topic, compren-de i dai servizi primari e i collegamenti per i servizi di supporto

119

6. Progettazione di dettaglio e implementazione della mobile app

Listato 6.1 Esempio Data Store Mashup

"results": [

"topic": "Restaurant","results":

"primaryResults": "data": [

"title": "Peck","address": "Via Spadari, 9, Milano","longitude": "9.187005400000002","latitude": "45.4635272","meta":

"rank": 1,"name": [ "GooglePlaces" ]

,[ ... ]

],"pageInfo":

"hasNextPage": false

,

"topic": "Event","results":

"primaryResults": "data": [ ... ],"pageInfo":

"hasNextPage": false

]

120

6.2. Struttura dello schema di mashup

2. Topic Rappresenta l’Interest topic associato ai risultati ricevuti dal ser-ver

Questa operazione è necessaria per poter gestire il fatto di avere comunquedei dati in memoria in condizioni di assenza di rete, anche per tipi diversi dirisultati provenienti dal server e per essere in grado di gestire una cardinalitàvariabile di tipologie di dati. Nel Listato 6.1 è mostrato come viene rappresen-tato lo stato nel caso in cui l’utente abbia a disposizione due Interest Topic ela suddivisione dei risultati per le due tipologie, in questo caso Restaurants edEvent. Si noti che oltre ai risultati sono salvati anche i parametri con lo statodella paginazione, per lasciare la possibilità di riprendere la visione di nuovirisultati.

6.2 Struttura dello schema di mashup

Per poter permettere una dinamicità nella struttura delle schermate che formanol’applicazione si è scelto di utilizzare uno schema di mashup molto semplice e allostesso tempo in grado di fornire i parametri necessari all’applicazione per costruire leviste in tempo reale. Si è scelto di utilizzare una rappresentazione in JSON in mododa essere facilmente interpretabile all’interno del motore JavaScript di React Native.Nel caso di CAMUS sono considerate due tipologie di schema di mashup: la list e ladetails. Nella tipologia list sono definite le view che descrivono il singolo item dellaListView e generalmente si compone di una quantità non eccessiva di componenti.Nel caso della list sono definiti gli elementi da mostrare quando è presente la listacomplessiva di risultati nella ListView. Nella tipologia details sono disponibili tuttii dettagli dell’item selezionato e sono definiti tutti i termini necessari a identificarel’elemento per l’utente. Considerando l’esempio dei ristoranti, per la lista sonoassociati i termini che servono a identificare l’oggetto, come il nome e l’indirizzo.Se poi l’utente vuole vedere la mappa e visualizzare gli estremi per contattare ilristorante deve aprire la pagina dei dettagli, dove acquisendo i termini dal file dimashup, sono visualizzati tutti i dettagli necessari per l’utente. Inoltre è specificatala tipologia dell’elemento da visualizzare, in modo da permettere all’app di utilizzarele librerie di collegamento con le applicazioni specifiche del sistema operativo.

Nel Listato 6.2 viene mostrato un esempio del file JSON di mashup della paginadi dettaglio e in Figura 6.1 la sua traduzione nelle due versioni dell’applicazione.

Di seguito sono elencate le diverse tipologie di dato che compongono l’oggettoche rappresenta i file di mashup:

• Type Il termine type indica la tipologia dell’elemento da visualizzare nellaview. È associato a un componente React Native, che verrà richiamato nellafase di costruzione dell’interfaccia grafica

121

6. Progettazione di dettaglio e implementazione della mobile app

Listato 6.2 Esempio Schema Mashup

"details": [

"topics": ["Restaurant","Event","Museum"

],"contents": [

"type": "text","contents": "title"

,

"type": "text","contents": "address"

,

"type": "map","contents": [ "latitude", "longitude" ]

,

"type": "phoneNumber","contents": "telephone"

]

]

• Topic Si tratta di un array di stringhe che indica tutte le aree di interesseassociate allo schema in questione. Si è scelto di utilizzare una struttura basatasu tag: una volta che l’utente sceglie l’interest topic viene utilizzato lo schemache lo possiede nei suoi tag

• Contents Indicano i termini del mashup o dei nuovi componenti innestati. Senell’oggetto padre è specificato un tipo gli elementi in contents rappresentanoi termini da richiedere nella query GraphQL. In caso contrario questo campoindica che in contents è presente un nuovo livello di annidamento. Ci possonoessere tanti annidamenti, fino a quando non si arriva ad avere un oggetto chepossiede il campo type

• Style Questo campo serve per definire uno stile da assegnare al componente.Permette di personalizzare l’aspetto del componente, andando a ridefinire lo

122

6.3. Rendering delle view

stile predefinito. Viene utilizzato Flexbox per la specifica degli stili

(a) Versione Android (b) Versione iOS

Figura 6.1: Schermata dei dettagli

6.3 Rendering delle view

Si tratta della funzionalità più delicata da progettare all’interno dell’applicazione,perché non è così semplice pensare di generare in modo dinamico delle pagine concosì tanta mutabilità a partire da un documento strutturato delle interfacce visuali.Mentre in codice nativo questo problema può presentare delle difficoltà a livelloimplementativo, l’utilizzo da parte di React di un Virtual DOM simile al linguaggioHTML offre il vantaggio di poter generare molto rapidamente una traduzione dalfile di mashup a un modello interpretabile dal motore di rendering dell’app. Perquesto motivo è stato creato un componente apposito, il View Builder, che, dato unoggetto contenente lo schema di mashup, riesce a gestire l’associazione dei contenutisemantici all’interno di questo schema con i componenti presenti nell’applicazione,restituendo il componente finale. Sono presenti all’interno due tipologie di rendering:il rendering del contesto e il rendering dei risultati.

6.3.1 Rendering a partire dal contesto

Il rendering del contesto è basato esclusivamente su elementi provenienti dalCDT. Non si è reso necessario l’utilizzo di schemi di mashup, in quanto tutti i datioccorrenti all’applicazione per costruire le view sono già presenti all’interno del CDT.Per ogni elemento del CDT viene eseguita un’associazione a componenti già esistentidi React Native, come per esempio Text per mostrare il nome dell’elemento o Pickerin caso di selezioni multiple. Di seguito sono mostrati i diversi metodi di costruzionedelle viste partendo dai singoli elementi del CDT:

123

6. Progettazione di dettaglio e implementazione della mobile app

• Interest Topic Gli Interest Topic hanno bisogno di essere selezionati nellapagina iniziale una volta effettuata l’autenticazione e caricati in una lista dipulsanti con due elementi per riga e con un’icona rappresentativa. I pulsanti ele icone sono predefinite nell’applicazione e necessitano soltanto di una associa-zione <nome,elemento> dal campo Interest Topic del CDT. Questa funzionemolto semplice viene eseguita direttamente all’interno della pagina principalesenza la necessità di utilizzare il View Builder

• Altri elementi Gli altri elementi del contesto sono elaborati all’interno delcomponente View Builder. Con una funzione ricorsiva viene scandito l’interoCDT ricevuto dal server con i campi da modificare e in base ai contenuti vienecostruito l’elemento della view, a seconda della tipologia. Per esempio, se perun campo è richiesto l’inserimento di un numero verrà mostrato un TextIn-put che permette il completamento solo con numeri, mentre se è necessarioeffettuare una scelta tra più elementi verrà mostrata una lista selezionabile.Assume una grande importanza anche la gestione delle esclusioni tra le ope-razioni. Se viene selezionato “With Car” non è corretto mostrare le possibilitipologie di trasporto pubblico, perché si conosce già a priori che l’utente nonselezionerà mai nello stesso momento come mezzo di trasporto l’automobile eil bus. Per questo scopo viene utilizzato il parametro parents presente in ognielemento del CDT; se il valore è stato selezionato dall’utente, allora gli sonomostrate tutte le sottocategorie. Per esempio quando l’utente seleziona “WithCar” non gli sono proposte tipologie diverse di trasporto con l’auto, mentre seseleziona “Public Transport” allora può scegliere una categoria ben definita ditrasporto pubblico, a seconda delle sue esigenze

6.3.2 Rendering dei risultati

Per quanto concerne i risultati ottenuti dalle query GraphQL elaborate dal server,entrano in gioco in maniera preponderante gli schemi di mashup. Per i motivispiegati nella Sezione 3.11, la risoluzione del problema necessita di un funzionamentopiù complesso rispetto alla visualizzazione del contesto. La funzione di renderingper quanto riguarda i risultati è la medesima sia per la lista che per i dettagli, quelloche cambia è il contenitore del componente View Builder: per la lista è un figlionel metodo di renderItem() della ListView, mentre per i dettagli definisce l’interapagina. Al componente View Render sono necessari due oggetti: il file di mashup e idati del singolo risultato. Si suppone che nel file di mashup gli elementi siano già statigenerati in ordine di visualizzazione, perché nella funzione di costruzione delle viewnon è possibile modificare tale ordine. Tuttavia è possibile modificare lo stile piùesterno del componente risultante per cambiare il layout dei figli del View Builder.Per prima cosa il View Builder deve scegliere le view associate all’Interest Topic

124

6.3. Rendering delle view

facendo una ricerca della prima vista che contiene il valore corrente dell’InterestTopic e passare questo oggetto alla funzione di rendering. A questo punto si è prontiper costruire la view del componente: viene scandito ogni elemento del file di mashupe si associa il valore dato dal termine dell’oggetto del risultato e viene restituito ilcomponente pronto per essere elaborato per la visualizzazione. Nel caso in cui nonfosse presente un valore per il termine desiderato ovviamente non viene visualizzatoalcun elemento, si restituisce una view base vuota, che non ha nessuna incidenza sullagrafica avendo dimensione nulla. Nel caso in cui esista un oggetto di tipo style, essoha la priorità rispetto a quello presente nel foglio di stile predefinito dell’applicazione.Nel prototipo sono disponibili queste tipologie di componenti specificabili nel campotype dell’oggetto di mashup:

• Text È il componente utilizzato per mostrare informazioni testuali. Per la suapersonalizzazione si utilizzano attributi diversi nel foglio di stile in comune pertutta l’applicazione o le specifiche presenti nell’attributo style del mashup

• Map È il componente che visualizza le mappe. Presenta due implementazionidifferenti per quanto riguarda iOS e Android, poiché come mappe di sistemautilizzano due applicazioni differenti. iOS mette a disposizione le mappe diApple, già integrate nel componente MapView fornito da React Native, mentreper Android vengono utilizzate le mappe di Google Maps, per le quali è statoutilizzato un modulo aggiuntivo

• Website Viene utilizzato per gli indirizzi web. Permette di aprire il collega-mento direttamente nel browser del dispositivo

• Email Permette di visualizzare l’indirizzo mail associato all’elemento, selezio-nando l’icona di invio email l’utente viene reindirizzato all’applicazione o allascelta di un’applicazione per comporre un messaggio da inviare all’indirizzospecificato

• Phone Questo componente gestisce il numero di telefono dell’elemento, conla possibilità di inviare un messaggio al numero specifico o di effettuare unatelefonata, sempre utilizzando le applicazioni predefinite del dispositivo mobile

• Support Si tratta del componente che gestisce i servizi di supporto con icollegamenti alle applicazioni esterne, verrà spiegato nel dettaglio nella Sezione6.5

6.3.3 Gestione degli stili

Per quanto riguarda la gestione degli stili si è scelto di adottare una soluzionemolto semplice, ma allo stesso tempo molto efficace. Si è partiti dalla condizione che

125

6. Progettazione di dettaglio e implementazione della mobile app

React Native utilizza come gestione dello stile Flexbox1, che è una variante basatasugli stili CSS ottimizzata per la gestione degli elementi che necessitano di adattarsia differenti dimensioni degli schermi. Il linguaggio utilizzato risulta essere molto si-mile a JSON e quindi è facilmente integrabile in JavaScript. L’elemento che gestiscegli attributi grafici è lo StyleSheet, che espone l’oggetto styles e gli attributi PRI-MARY_COLOR e SECODARY_COLOR. Nell’oggetto styles sono impostati tuttigli stili di ogni componente grafico dell’applicazione che vengono richiamati nellafase di costruzione delle view. In questo modo ogni modifica all’interno dell’oggettosi ripercuote in tutta l’applicazione. I due attributi per la gestione dei colori sonorisultati indispensabili in particolare per alcuni componenti, come la StatusBar diAndroid, che hanno come elemento impostabile solo il colore e non lo stile com-pleto. Ovviamente la modifica all’interno dello StyleSheet dei parametri di colore ènecessaria solo in un punto del codice, in modo da propagarsi in modo coerente perl’intera applicazione. Nel Listato 6.3 viene mostrato un esempio del foglio di stileutilizzato nell’applicazione. Si noti come i parametri che definiscono ogni singoloelemento sono abbastanza autoesplicativi, fornendo allo sviluppatore una maggioresemplicità di programmazione. Diversi parametri sono stati ripetuti, per permetterela visualizzazione del componente in modo ottimale sia in Android che in iOS.

Listato 6.3 Esempio Foglio di Stilevar styles = StyleSheet.create(

iosContainer: backgroundColor: 'white',marginTop: 70

,iosStatusBar:

color: 'black',buttonMaterial:

height: 36,backgroundColor: primary_color,borderColor: primary_color,borderWidth: 1,borderRadius: 8,marginBottom: 10,alignSelf: 'stretch',justifyContent: 'center'

,[ ... ]

)

1Flexbox su W3Schools: Htp://www.w3schools.com/css/css3_flexbox.asp

126

6.4. Query GraphQL

6.4 Query GraphQL

In questa sezione si vuole affrontare la gestione dei dati all’interno dell’appli-cazione, partendo dagli algoritmi per costruire le query GraphQL per poi parlaredella gestione della paginazione. Tutto lo scambio di dati tra l’applicazione e ilserver viene svolto utilizzando query GraphQL, come spiegato nella Sezione 4.1.1.Per implementare il modulo di gestione delle connessioni si è scelto di utilizzareLokka2, un client compatibile con GraphQL che permette di gestire le query comese fossero normali fetch() di JavaScript e lasciare una configurazione più libera eadattabile alle esigenze del sistema. Questo si sposa bene con il paradigma Flux,in quanto permette il salvataggio della maggior parte del contenuto della rispostanel Data Store con le modalità esposte nella Sezione 4.1.2.3 e rendendolo quindidisponibile per tutti i componenti dell’applicazione. Di seguito sono spiegate le duetipologie principali di query gestite con GraphQL, ossia le query di login e le queryper accedere ai dati.

6.4.1 Login Query

Le query per gestire il meccanismo di login sono molto semplici. Sono basate suidati inseriti dall’utente quando si trova nella Login Page e sulle risposte interme-die fornite dal server. Queste query servono per ottenere l’identificativo del CDTassociato all’utente e lo schema dei mashup con le definizioni delle sue view. I datinecessari per la costruzione della query sono l’indirizzo email e la password, che sonoinseriti dall’utente nella prima pagina che gli viene mostrata. Questi dati vengonosalvati nello User Store e sono conservati nello stato dell’applicazione, nel caso incui fosse necessario effettuare una nuova richiesta. Nel caso in cui l’indirizzo emaile/o la password siano errati viene notificato un errore mentre se uno dei due campiè mancante vengono richiesti nuovamente senza inviare nessuna richiesta. In casodi risposta affermativa viene restituito all’utente un token, generato ogni volta chel’utente effettua l’autenticazione. Questo token viene salvato sempre nello User Sto-re e successivamente inviato al server con la query getPersonalData() per ottenereil CDT e lo schema di mashup associati all’utente.

6.4.2 Data Query

Le query per gestire i dati necessitano di tutta una serie di operazioni preliminariperché sono presenti diversi parametri da ricavare per poter formare una richiestaGraphQL. Oltre alla definizione spiegata nella Sezione 5.5, di seguito viene spiegatala modalità di costruzione dei parametri che sono necessari per la composizione dellaquery utilizzando il metodo client.query() di Lokka:

2Lokka: https://github.com/kadirahq/lokka

127

6. Progettazione di dettaglio e implementazione della mobile app

• Email Si tratta della mail inserita dell’utente

• IdCdt Rappresenta l’identificativo del CDT, il quale appartiene a ogni singoloutente

• Context È l’oggetto che rappresenta il contesto attuale nel quale si troval’utente. Quando l’utente ha terminato la compilazione del contesto nellaContext Selection Page i parametri e i valori sono registrati nel Context Sto-re ma, per essere interpretati dal server, necessitano di una conversione in unoggetto ben definito. Il problema di una query GraphQL è che l’oggetto in que-stione deve essere ulteriormente convertito in una stringa unica per poi venirecollocato come payload nella POST/HTTP. Per svolgere questo compito vieneutilizzata una funzione personalizzata che permette di mantenere inalterata lachiave degli oggetti JavaScript e produce in uscita una stringa. Per poter con-vertire anche gli oggetti che sono innestati a un livello superiore viene utilizzatauna ricorsione che richiama la prima funzione. È necessario risolvere anche unaltro problema, cioè quello legato ai valori del CDT che possiedono il parame-tro “Parents”. In questo caso non è corretto inviare entrambi i parametri, masolamente quello figlio: è poi il server che ha la capacità di comprendere che èselezionato anche il parametro padre. Per esempio se si considera il parametro“Public Transport”, si hanno due possibilità. La prima è che se l’utente nonseleziona alcuna categoria allora l’applicazione invia l’oggetto così com’è nellaquery, ma viene chiamato la Action delle ContextActions “removeForbidden()”che, nel caso in cui sia stata selezionata in precedenza una tipologia che avevacome padre “Public Transport” . La seconda è che l’utente selezioni una tipo-logia specifica, come “Bus”: l’applicazione chiama la Action “addForbidden()”e il valore “Public Transport” viene inserito nell’elenco degli elementi da nonconsiderare mentre viene costruita la query

• Support Rappresenta la tipologia di servizi di supporto che l’utente richiedeper integrare al meglio i dati che gli necessitano

• PrimaryResults Rappresenta lo schema dei dati che devono essere restituitidai servizi invocati dal server per costruire l’insieme dei risultati per l’utente.GraphQL permette di eseguire delle richieste di dati altamente personalizza-te, permettendo di richiedere la minima quantità di dati indispensabili perl’utilizzo da parte dell’utente. Per poter svolgere questo compito si è scelto diutilizzare i termini semantici dei mashup, in particolare della tipologia details,perché si suppone che nel caso della lista si abbia un sottoinsieme dei termi-ni semantici. Come per la funzione di costruzione della view espressa nellaSezione 6.3, anche in questo caso è necessario acquisire lo schema associatoall’Interest Topic e poi selezionare i termini, per creare l’oggetto GraphQL

128

6.4. Query GraphQL

che definisce i Primary Results. Considerando l’esempio di schema del Listato6.2 si può notare come i termini nel campo contents siano “title”, “address”,“longitude”, “latitude” e “meta”. Come oggetto GraphQL è necessario passaretutti questi termini all’interno di Primary Results in un formato dove l’unicoseparatore è il carattere “a capo”, per ottenere un risultato simile a quellonella Figura 2.1

• SupportResults Lo stesso meccanismo utilizzato per i PrimaryResults vieneriproposto anche per i risultati di supporto. Invece di recuperare i mashup dagliStore viene riproposta la stessa definizione per ogni query, perché i servizi disupporto sono definiti sempre nello stesso modo con i campi category, service,url e storeLink

6.4.3 Gestione paginazione

Per quanto riguarda la gestione dei risultati l’applicazione sfrutta la paginazionemessa a disposizione da GraphQL. A livello client viene implementata quando vienerestituito il risultato della query basata sul contesto, per velocizzare e ottimizzarelo scambio dati col server. Nel modulo Connection Manager sono implementatidue metodi diversi per creare le query, uno per la prima richiesta e un altro per lesuccessive. Si tratta di due richieste non molto differenti tra loro:

1. Richiesta iniziale Nella richiesta iniziale è necessario acquisire i parametridel contesto costruiti dalle Context Selection Page e gli oggetti ricavati daiparametri definiti dall’utente e dai sensori, sotto forma in stringhe. Inoltrevengono definiti i parametri sulle dimensioni della pagina, ma senza nessunriferimento agli elementi precedenti. I parametri dell’oggetto ritornato dalserver che contiene le informazioni necessarie all’applicazione per richiedere lepagine successive è specificato nella Sezione 5.5.1

2. Richiesta pagine successive Quando vengono richieste le pagine successiveè sbagliato far ricavare nuovamente dai sensori e dall’utente il contesto, perchénon è detto che questo rimanga statico. Per esempio se l’utente è in viaggioin treno le coordinate geografiche cambiano molto velocemente e quindi per ilserver si tratta di un nuovo contesto, che implica la restituzione di un nuovoinsieme di risultati. In questo modo si potrebbero ottenere dal server dei datidiversi. Per risolvere questo problema si è scelto di memorizzare nel ContextStore i parametri immutabili della prima richiesta, come quelli di contesto, ledefinizioni dei dati e i servizi di supporto. La nuova query quindi recuperal’identificativo dell’ultimo elemento restituito dalla query della pagina prece-dente, ponendo quest’ultimo come parametro after e mantenendo costante ladimensione della pagina

129

6. Progettazione di dettaglio e implementazione della mobile app

Questi due metodi sono chiamati dall’applicazione in due fasi differenti: la richie-sta iniziale viene invocata quando l’utente ha appena definito il contesto e richiedenuovi dati, la richiesta delle pagine successive quando l’utente si trova nella ResultsPage e scorre fino in fondo la lista di risultati. Il server riesce a gestire lo statodelle richieste come spiegato nella Sezione 5.2.5 e l’applicazione deve stare attentasolamente a controllare il campo che indica l’esistenza o meno di una pagina succes-siva. Considerando sempre il Listato B.3, viene mostrata una risposta a una queryiniziale con numero di risultati nel parametro first impostato a 5, e con il parametrohasNextPage uguale a true per indicare che esistono ulteriori pagine da acquisire.Nel caso in cui l’utente voglia visualizzare altri risultati è necessario eseguire unarichiesta di una nuova pagina. Nella query per la seconda pagina è necessario aggiun-gere il parametro after seguito dall’identificativo dell’ultimo elemento della rispostaprecedente assieme al parametro first con lo stesso valore della richiesta precedente.A questo punto, essendoci già presenti dei risultati nel Data Store, i nuovi risultativengono concatenati assieme a quelli esistenti e aggiornano la view posizionandoliin coda a quelli già mostrati. Come ulteriore ottimizzazione nell’implementazionedella ListView è possibile impostare un’azione nel recuperare delle view quando sigiunge a una certa distanza prestabilita dalla fine della pagina. Quindi la richiestadella pagina successiva viene eseguita poco prima di raggiungere il termine dellalista, fornendo all’utente un’esperienza d’uso migliore.

6.5 Servizi di supporto

I servizi di supporto sono utilizzati esclusivamente nell’applicazione. Quandoviene effettuata una richiesta viene inserita la tipologia desiderata di servizi di sup-porto e il server restituisce un indirizzo che l’applicazione può gestire in diversimodi:

• Web Linking L’applicazione riceve un link per accedere all’endpoint del servi-zio, richiede i dati e li visualizza all’interno del componente preposto dell’app.Questa soluzione è gestita mediante una funzione del Connection Manager chegestisce le query nella modalità richiesta dal servizio da interrogare

• Deep Linking I Deep Link sono degli URI che permettono di lanciare unaapplicazione preinstallata sul dispositivo. Sono collegamenti molto simili agliURL HTTP, con la differenza che viene specificato il nome che identifical’applicazione da lanciare. Se l’applicazione desiderata non è presente sul di-spositivo è necessario gestire l’errore e reindirizzare l’utente sull’App Store osul Google Play Store per poterla scaricare. Questa tipologia di collegamentimigliora l’integrazione dell’applicazione CAMUS con l’intero sistema operativo

130

6.5. Servizi di supporto

In generale il funzionamento di queste tipologie di collegamenti è gestito dall’ap-plicazione con le stesse modalità. Nel risultato proveniente dal server viene restituitoun link del tipo nomeapp://?param=value e l’applicazione è in grado di sostituireal posto di value il valore proveniente dall’elemento dei risultati per poter aprirel’applicazione di supporto. La scelta che è stata fatta è di utilizzare due link diversiper ogni sistema operativo: il primo punta all’applicazione installata sul disposi-tivo, mentre il secondo allo store predefinito per scaricare l’applicazione. Questascelta permette di definire applicazioni diverse o di usare la stessa applicazione nelcaso in cui utilizzi link diversi a seconda del sistema operativo. Un esempio diapplicazione che ha questo problema è Google Maps: in Android l’URI è del tipogoogle.navigation:q=value, mentre in iOS è del tipo comgooglemaps://?saddr=value.In React Native la libreria di Linking è in comune tra le diverse piattaforme e quindiè necessario prestare attenzione al collegamento che viene passato. Nell’applicazionequesto viene implementato con il metodo Linking.canOpenUrl(URI) nel quale vienepassato al suo interno il link da aprire. Se il metodo ritorna un errore allora vieneaperto il collegamento che punta allo store mentre in caso di risposta affermatival’applicazione desiderata viene aperta. Nel Listato 6.4 viene rappresentato un esem-pio completo dell’oggetto che rappresenta il servizio di supporto proveniente dalserver, dove:

• Category Indica la categoria di appartenenza del servizio

• Service Rappresenta il nome del servizio

• Url Indica l’URL per invocare il servizio o aprire l’applicazione

• Store Link Rappresenta il link nello store di sistema per scaricare l’applica-zione se non è installata sul dispositivo

Listato 6.4 Esempio di servizi di supporto con intent

"supportServices": "category": "Transport","service": "Google Maps","url": "google.navigation:q=value","storeLink": "market://details?id=com.google.android.apps.maps"

131

6. Progettazione di dettaglio e implementazione della mobile app

132

Capitolo 7

Valutazione delle prestazioni

In questo capitolo viene elaborato un metodo per valutare l’efficienza della so-luzione implementata. A tal proposito si andranno ad eseguire diversi test perosservare il comportamento assunto dal sistema. Questa analisi permette di com-prendere quali siano i punti critici del sistema e fornisce delle informazioni utili percapire in futuro dove andare a effettuare modifiche per ottenere un miglioramentodelle performance.

Il capitolo si apre con una sezione dedicata allo studio del modello di compor-tamento del sistema e alla descrizione delle condizioni nei quali sono stati eseguitii test. Nella sezione successiva verranno svolti diversi test per comprendere quantotempo il sistema impiega a evadere le richieste e quale sia l’incidenza dei componentirispetto al tempo totale. Di seguito verrà analizzato il sistema in condizioni d’usopiù simili alla realtà, dove diversi utenti interagiscono col sistema e molte richiestedevono essere evase nel minor tempo possibile. Si vuole analizzare quale sia il puntodi saturazione del sistema e verificare se l’aumento delle caratteristiche della macchi-na permetta di ottenere dei miglioramenti. Infine viene studiato il comportamentodella mobile app in diverse condizioni di rete, per capire se l’utente può utilizzaresenza problemi l’app anche in condizioni nelle quali il collegamento non sia di qualitàeccellente.

7.1 Sistema di test e modello di simulazione

In questa sezione si vuole fornire una panoramica del sistema utilizzato e lametodologia seguita per effettuare i test.

Forniamo di seguito alcune definizioni che saranno utili per comprendere i testeffettuati:

• Service Time È il tempo che il sistema impiega a completare una richiesta.Tiene conto esclusivamente del tempo impiegato per le elaborazioni, non con-

133

7. Valutazione delle prestazioni

siderando eventuali ritardi dovuti dal canale di trasmissione o il tempo passatoin coda. Viene misurato in secondi

• Response Time Rappresenta il tempo totale che il sistema impiega a com-pletare una richiesta, compreso il tempo nel quale rimane in coda in attesa cheun’istanza si liberi. Viene misurato in secondi

• Arrival Rate (λ) Rappresenta la frequenza con la quale le richieste arrivanoal sistema. Viene misurata in richieste al secondo

In Figura 7.1 viene mostrata una schematizzazione del flusso di una richiesta.

Server

Service Time [s]

Response Time [s]

Arrival Rate[req/s]

Output Rate[j/s]

X Throughput

Figura 7.1: Sistema a coda singola

Si prosegue con una descrizione del comportamento del sistema. Si è giunti allaconclusione che il sistema in analisi può essere modellato come una coda M/G/1 [33],in quanto valgono le seguenti considerazioni:

• M/*/* La probabilità del tempo di arrivo delle richieste al sistema segue unadistribuzione Markoviana. Le richieste sono indipendenti tra loro e arrivanocontinuamente a un tasso costante λ

• */G/* La distribuzione di probabilità dei tempi del servizio non è nota, quindisi assume sia di tipo Generale

• */*/1 Viene utilizzato un singolo processo di Node.js per gestire le richiestein arrivo

I test sono stati tutti effettuati su una macchina virtuale. Il motivo di questadecisione è la flessibilità nella scelta dei componenti della macchina, in quanto èpossibile variare semplicemente il numero di core del processore e la dimensione

134

7.2. Tempo di risposta a una singola richiesta

Tabella 7.1: Caratteristiche della macchina di test

Parameter ValueCPU Intel Core i5-3550Cores 4CPU frequency 3.30GHzRAM 8 GB DDR3Disk SSD 60 GB + HDD 1TBHost OS Microsoft Windows 10 Pro (on SSD)VM software Oracle Virtualbox 5.0Guest OS Ubuntu 14.04 (on HDD)

della RAM. Le caratteristiche del sistema fisico utilizzato vengono elencate nellaTabella 7.1.

Grazie all’utilizzo di una macchina virtuale nei successivi test verranno modifi-cati il numero di core della CPU e le dimensioni della RAM. Dove non specificatoesplicitamente si assume che la macchina virtuale sia composta da una CPU con 1core e da 1 GB di RAM.

Per limitare il calcolo dei tempi all’interno del confine del sistema, sono stateprecaricate in cache le risposte dei servizi che si andranno ad utilizzare. In questomodo non ci saranno anomalie dovute al tempo necessario per interrogare l’effettivoserver che gestisce il servizio.

7.2 Tempo di risposta a una singola richiesta

In questa sezione si andrà ad analizzare il Service Time del sistema. Per evitareche le richieste entrino in coda si attende che la richiesta in corso termini prima dilanciarne un’altra.

Si è innanzitutto effettuata un’analisi per comprendere quali siano i parametriche condizionano il tempo di risposta del servizio. Gli elementi identificati sono:

• Dimensioni del contesto Il primo passaggio nel server è il parsing del con-testo, quindi si ipotizza che questo punto possa influire sulle prestazioni delsistema. Facendo delle stime su quanto possa essere grande un contesto incondizioni d’uso reali sono stati definiti tre livelli: i) piccolo, composto da2 elementi; ii) medio, formato da 5 elementi e iii) grande, composto da 8elementi

• Numero di servizi Rappresenta il numero di servizi che vengono interrogatiper acquisire le informazioni. Queste attività vengono gestite in parallelo peròsi ritiene comunque che avere più servizi da interrogare possa aumentare i tempi

135

7. Valutazione delle prestazioni

di esecuzione. Perciò sono stati effettuati test con tre livelli, che rappresentanoil numero di servizi che vengono invocati

Il primo test che si è andati a verificare è come questi due parametri incidono sulService Time. Sono state lanciate 500 richieste per ogni possibile coppia. I risultatipossono essere osservati in Figura 7.2.

numServices: 1 numServices: 2 numServices: 3

10

20

30

40

50

grande medio piccolo grande medio piccolo grande medio piccoloContext Dimension

Res

pons

e T

ime

[ms]

Service Time Overview

Figura 7.2: Analisi del Service Time con differenti configurazioni

Come ci si poteva aspettare, vista la relativa vicinanza tra le tre tipologie dicontesto, non ci sono grosse variazioni dovute alla dimensione del contesto, se nonun leggero aumento man mano che aumentano le sue dimensioni. Invece si puònotare come l’operazione che più incide è il numero di servizi da invocare. In questocaso il divario è più netto, a causa del maggior carico richiesto per completare questeattività.

In Figura 7.3 viene mostrata la distribuzione dei tempi di risposta con dimensionegrande del contesto e tre servizi interrogati.

Risulta un tempio medio di esecuzione pari a 19,5 ms mentre il caso peggiore è di48,86 ms. Quest’ultimo valore ci permette di calcolare l’arrival rate di saturazione,che rappresenta il limite massimo dopo il quale si verifica un accodamento dellerichieste. Questo valore risulta essere pari a 20,46. Verrà verificato nella sezionesuccessiva dove saranno eseguiti test con diversi valori di λ.

Un ulteriore test che si è andati a eseguire riguarda l’incidenza dei singoli compo-nenti in una richiesta. La configurazione utilizzata è la medesima del test precedente.È stata poi calcolata una media dei tempi raccolti divisi per singolo componente eseparati ulteriormente in tre categorie:

136

7.2. Tempo di risposta a una singola richiesta

0

40

80

120

20 30 40 50Response Time [ms]

Cou

nt

Service time distribution

Figura 7.3: Distribuzione del Service Time

1. Elaboration Rappresenta il tempo speso in elaborazioni

2. Database È il tempo speso nell’effettuare le query verso il database MongoDB

3. External È il tempo necessario per interrogare i servizi. In questo casorappresenta il tempo necessario per recuperare la risposta da Redis

In questo modo, oltre a osservare l’impatto di ogni componente sul tempo totale,è possibile capire anche quali siano le attività più onerose eseguite dal componentestesso. I risultati di questa analisi vengono mostrati in Figura 7.4.

Come ci si poteva aspettare dopo il primo test, il componente che ha un’incidenzamaggiore è il Query Handler, che si occupa proprio di interrogare i servizi e trasfor-mare le risposte. È l’unico componente che esegue tutte e tre le tipologie di attivitàed esse sono praticamente equidivise in termini di tempo di esecuzione. Gli altricomponenti hanno all’incirca il medesimo impatto sul tempo di esecuzione. Si puòosservare che per il Context Manager e il Primary Service Selection la maggior par-te del tempo viene speso nell’interrogare il database. Invece il Response Aggregatortrascorre tutto il tempo in elaborazioni, in quanto analizza i dati ricevuti dai servizisenza la necessità di interrogare il database.

137

7. Valutazione delle prestazioni

38%

62%

33%

67% 35%

30%

35%

100%

0

1

2

3

4

ContextManager PrimaryServiceSelection QueryHandler ResponseAggregatorComponent

Tim

e [m

s]

Function type

Elaboration

Database

External

Component Time

Figura 7.4: Analisi del tempo di esecuzione dei componenti

7.3 Tempo di risposta per richieste multiple

In questa sezione si vuole verificare come si comporta il sistema in condizionid’uso più simili alla realtà. Vengono eseguite richieste multiple che rappresentanole interazioni dei diversi utenti con il sistema. Verrà dunque misurato il ResponseTime di ogni richiesta, in quanto in alcuni casi le richieste saranno accodate primadi essere eseguite. Come esposto nella Sezione 7.1 la distribuzione degli arrivi ècontinua e indipendente, quindi è stata scelta una distribuzione esponenziale perdeterminare i tempi di arrivo delle richieste:

f(x;λ) =

λe−λx se x ≥ 0

0 se x < 0(7.1)

dove λ definisce l’arrival rate delle richieste e x il tempo tra una richiesta e lasuccessiva.

Si è dunque variato il valore di λ in un intervallo [5, 100] per osservare il com-portamento del sistema all’incrementare del numero di richieste. Si è voluto inoltreandare a osservare se il sistema sia realmente scalabile: a tal scopo è stato ripetutoquesto test con diverse configurazioni della macchina virtuale, andando ad aumen-tare il numero di core della CPU e la dimensione della RAM. I risultati vengonomostrati in Figura 7.5.

138

7.4. Tempo di risposta con condizioni di rete diverse

core: 1 core: 4

0

5000

10000

0

5000

10000

ram: 1

ram: 4

5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100Arrival Rate [Reqs/s]

Res

pons

e T

ime

[ms]

Exponential Distribution

Figura 7.5: Analisi del Response Time con differenti configurazioni

Come si può notare nel primo quadrante il sistema rimane stabile fino ad unvalore di λ pari a 20, dopo di che le richieste incominciano ad essere inserite in coda.Questo valore è congruo con quanto calcolato nella Sezione 7.2. Un dato interessanteè che il variare delle dimensioni della RAM non presenta evidenti benefici. Questorisultato può essere dovuto alle relative ridotte dimensioni del database, che quindinon necessita di grandi quantitativi di memoria per essere elaborato. In situazioninelle quali il database assume dimensioni più importanti questo parametro faràsicuramente sentire il suo peso.

Più interessante è il risultato ottenuto impostando la macchina virtuale con 4core. È possibile chiaramente notare un grosso miglioramento nella velocità di ese-cuzione. Nel caso migliore si passa da un λ pari a 20 ad uno pari a 60, ottenendo cosìuna capacità del sistema di evadere il triplo delle richieste senza doverle accodare.Questo miglioramento è dovuto per la maggior parte al database MongoDB, che èl’unico elemento del sistema studiato per sfruttare più core del processore. Sia No-de.js sia Redis lavorano invece con un solo thread: per ottenere migliori performanceè necessario mettere in funzione diverse repliche dei processi principali, in modo chele richieste vengano smistate verso il nodo più libero.

7.4 Tempo di risposta con condizioni di rete diverse

Oltre ai test sul carico del server sono state effettuate delle valutazioni per quantoriguarda le diverse condizioni di utilizzo dell’applicazione mobile. Avendo scelto

139

7. Valutazione delle prestazioni

come caso di studio quello del turismo è sorto spontaneo chiedersi in che modol’applicazione reagisse in movimento e in diverse condizioni di rete. Per esempio sel’utente si trova a casa propria sotto rete WiFi la velocità di caricamento dei risultatisarà diversa da quella misurata mentre si trova in alta montagna, dove la coperturadi rete è spesso minima.

Per valutare se i tempi di attesa rimangano sempre accettabili si è scelto diutilizzare il simulatore iOS e uno strumento aggiuntivo che introduce un ritardo nelcaricamento dei dati a seconda delle diverse condizioni di rete specificate. A partireda questo si sono scelte le tre condizioni di rete più significative: WiFi, 3G ed Edge.All’interno dell’applicazione è stato utilizzato un metodo di test che effettua unnumero significativo di richieste verso il server. Il test viene effettuato utilizzando50 richieste una di seguito all’altra, in modo da non peggiorare il tempo di rispostacaricando eccessivamente il server. La query utilizzata è quella di tipo ristoranti,continuamente ripetuta.

Nella Tabella 7.2 sono mostrati i parametri delle condizioni di simulazione, dovel’ADSL indica la connessione internet utilizzata dal computer e gli altri parametrisono quelli utilizzati nello strumento di modifica delle condizioni di rete. Come sipuò notare le aspettative di tempi di risposta in ordine crescente sono WiFi, 3G edEdge.

Tabella 7.2: Analisi velocità delle connessioni

Connection Type Download Speed Upload Speed Total DelayADSL 7 Mb/s 340 Kb/sEdge 240 Kb/s 200 Kb/s 840 ms3G 780 Kb/s 330 Kb/s 200 msWiFi 40 Mb/s 33 Mb/s 2 ms

Nella Figura 7.6 sono mostrati i risultati medi per ogni condizione di rete. Comeci si poteva aspettare i tempi di risposta più bassi sono dati dalla connessione WiFi,seguiti dal 3G e infine dalla Edge. La differenza tra WiFi e 3G è molto meno marcata,soprattutto perché per provare il tempo risposta è stata utilizzata una connessione amonte non molto performante, mentre per quanto riguarda la connessione Edge c’èmolta più differenza, come del resto era prevedibile dalle condizioni di simulazione.In qualunque caso, con l’utilizzo della paginazione per un caricamento scaglionato deidati e le loro ridotte dimensioni, anche i tempi di risposta in condizioni sfavorevolinon sono così elevati, consentendo all’utente in qualsiasi caso una soddisfacenteesperienza d’uso.

140

7.4. Tempo di risposta con condizioni di rete diverse

0

2000

4000

6000

wifi 3g edgeNetwork Type

Mea

n R

eque

st T

ime

[ms]

Network Analysis

Figura 7.6: Analisi dei tempi di risposta con reti diverse

141

7. Valutazione delle prestazioni

142

Capitolo 8

Conclusioni e sviluppi futuri

Questa tesi è mirata alla definizione di CAMUS, un sistema basato su una meto-dologia di progetto valida per diversi ambiti in grado di permettere la progettazionedi applicazioni mobili basate sulla personalizzazione dei dati ricercati dagli utenti inbase alla situazione di utilizzo.

Si è focalizzata molto l’attenzione sul contesto, a partire dai modelli che pote-vano essere utilizzati. Si è mostrato come una rappresentazione ad albero permettauna definizione molto completa e semplice delle possibili situazioni nelle quali ci sipuò trovare. In seguito si è analizzato il problema della ricerca delle migliori fontidalle quali acquisire informazioni. In particolare, è stato proposto un metodo diassociazione dei servizi ai contesti mediante delle semplici regole, che permettonodi selezionare solamente quelli più idonei in una particolare situazione. Si è potutoconstatare come l’utilizzo del contesto permetta di avere a disposizione una quantitàottimale di informazioni per poter prendere la decisione sia per quanto riguarda iservizi da interrogare sia, una volta ricevuti i dati, per filtrarli ulteriormente e fornirecosì risultati ancora migliori e mirati.

L’utilizzo del contesto è complementare all’uso delle tecniche di mashup, in quan-to queste ultime permettono di definire uno schema dinamico di generazione delleapplicazioni mobili che faccia uso di informazioni di supporto per arricchire i datiprincipali ricevuti dall’utente. Come è stato sottolineato più volte nella tesi, l’utilizzodi uno schema per la definizione della struttura dell’app permette di ottenere van-taggi sia per quanto riguarda la flessibilità di modifica in base alla situazione diutilizzo, sia per quanto riguarda l’associazione dei servizi di supporto.

Infine si è potuta valorizzare la figura dell’esperto di settore, che con la sua cono-scenza del dominio applicativo permette di aiutare l’utente nella personalizzazionedelle CAMUS app; infatti, alcune operazioni non sono automatizzabili ed è statoquindi necessario introdurre una figura umana che svolgesse determinati compiti, egli strumenti in grado supportarle.

Si può affermare che CAMUS è un progetto molto innovativo. Dalla descrizione

143

8. Conclusioni e sviluppi futuri

delle soluzioni in letteratura della Sezione 2.2 si è potuto constatare come esistanodiverse soluzioni, alcune volte anche migliori di CAMUS, ma che si focalizzano suuno solo degli aspetti trattati nel progetto. CAMUS è destinato a crescere, cercandodi inglobare le migliorie necessarie affinché diventi una soluzione sempre più efficacee sofisticata.

Con questa tesi si sono volute creare della basi solide per il framework. Fornireun’esperienza per l’utente semplice ma allo stesso tempo completa non è un’operazionesemplice. In particolare l’ostacolo principale riguarda l’acquisizione dei dati, in quan-to esistono una varietà infinita di fonti che possono essere interrogate. Inoltre ognunadi esse possiede i propri requisiti, che variano anche in maniera marcata tra una fon-te e l’altra. Nello sviluppo della tesi, dopo una risoluzione delle problematiche dimaggiore rilevanza, si è data priorità allo sviluppo di alcune funzionalità core, alcunevolte in versione semplificata, in modo da fornire un punto di partenza stabile dapoter espandere e migliorare. Nella prossima sezione verranno esposti alcuni puntiper migliorare la soluzione presentata in questa tesi.

8.1 Sviluppi futuri

In questa sezione esponiamo alcuni punti di miglioramento alle soluzioni proposteda questa tesi:

• Occorrerebbe lasciare più flessibilità di associazione degli alberi di contestoe dei mashup con gli utenti. Per quanto riguarda l’albero di contesto, unascelta può essere quella di dare una validità temporale al CDT, in modo chevenga mostrato all’utente solo in quella finestra. Può essere utile quandoun utente è in viaggio e necessita spesso di cambi radicali allo schema dicontesto. Per i mashup invece si può prevedere un meccanismo di selezionebasato sempre sul contesto, cercando di replicare il meccanismo di selezione peri servizi primari. Grossi vantaggi derivanti da questa scelta sono per esempiorelativi alla selezione dei servizi di supporto locali, in quanto verrebbe generatoun schema associato ad una particolare località e tale schema verrebbe sceltoa runtime dall’algoritmo come migliore per il luogo dove si trova l’utente

• Nella tesi, per la selezione dei nodi valori dell’albero di contesto, è stata adotta-ta la regola che è possibile selezionare al massimo uno tra i nodi figli dello stessonodo dimensione. Un’assunzione alla base di questa scelta è che i vari conte-sti siano tra loro disgiunti. È anche vero che non in tutti i casi quest’ultimaipotesi è verificata e questa regola risulta essere limitante nell’espressione delcontesto. Un esempio riguarda la scelta dei ristoranti: si ipotizzi che un uten-te voglia cercare un ristorante sia per pranzo che per cena. Sarebbe sensato

144

8.1. Sviluppi futuri

lasciargli la possibilità di selezionare entrambe le opzioni in modo che l’apppossa fornire, se disponibili, gli orari nei quali può prenotare un tavolo

• Al momento la risoluzione dei conflitti tra le dimensioni viene data in caricoall’esperto di settore, che si occupa di ridefinire i contesti per gli utenti. Inalcuni casi però una soluzione automatica e globale sarebbe più indicata. Peresempio, non si vuole permettere all’utente di selezionare contemporaneamentecome Interest Topic “Musei” e un qualsiasi valore della dimensione “TipologiaRistorante”. Come è possibile notare, il fulcro di queste associazioni è la ca-tegoria, che nel modello del contesto viene definita dagli Interest Topic. A talproposito è in corso di valutazione l’introduzione di un attributo “relatedTo”,da associare ad ogni nodo dimensione del contesto, per definire a quale catego-ria specifica quella dimensione fa riferimento. Questo attributo è utilizzabilea discrezione dell’esperto: se ad una dimensione non viene associata nessunacategoria particolare significa che è valida per tutte quante

• Sono stati spesso citati i “termini”, elementi necessari per permettere la con-versione di una risposta dal formato specifico del servizio a quello CAMUS.Non si è mai parlato invece di come vengono organizzati questi termini. Questoè uno dei punti aperti del progetto, per il quale sono state formulate diverseipotesi. Quella più rilevante riguarda l’utilizzo di un’ontologia come strutturaper i termini. In questo modo verrebbe arricchito il significato semantico diogni attributo. Le ontologie mettono inoltre a disposizione una complessa retedi connessioni tra i vari elementi che la compongono. Questa caratteristicagarantisce un’enorme flessibilità per l’implementazione delle funzionalità, inquanto permette di definire globalmente il significato di ogni attributo e lerelazioni che possiede con le altre entità

• Nel prototipo è stata data larga importanza all’integrazione dell’app CAMUScon il sistema operativo e le altre app presenti sul dispositivo. Viene inoltredata la possibilità di utilizzare dei servizi di supporto invocabili tramite URL.L’utilità è quella di permettere l’aggiunta di informazioni utili per l’utente.Per esempio, se è stato scelto di utilizzare i mezzi pubblici per spostarsi sa-rebbe utile mostrare un’indicazione del tempo necessario per raggiungere illuogo desiderato. Questa attività può essere svolta tramite un’interrogazioneverso il gestore dei trasporti pubblici per acquisirne una stima. La scelta delservizio, come è facilmente intuibile, deve variare in base alla città in cui ci sitrova e ad altri fattori. L’obiettivo è la creazione di componenti che accettinoinformazioni da diversi servizi. Il problema che si pone è molto simile a quellodei servizi primari: ogni servizio fornisce risposte descritte in modo diverso. Ènecessario dunque creare una soluzione per certi versi simile alla trasformazio-

145

8. Conclusioni e sviluppi futuri

ne delle risposte per i servizi primari, in modo che la view dell’app che devevisualizzarli sia in grado di leggere i dati ricevuti

• Un’ulteriore attività del Response Aggregator, che non è ancora stata imple-mentata, riguarda l’assegnazione di un punteggio a ogni elemento, in base alleinformazioni di contesto disponibili. Per esempio, sarà possibile assegnare unpunteggio più alto all’elemento che si trova più vicino rispetto all’utente e, pergli altri elementi, verrà assegnato un punteggio che varia in modo inversamenteproporzionale alla distanza dal punto di riferimento. Si stanno prendendo inconsiderazione anche logiche di selezione fuzzy per permettere una flessibilitàmaggiore nell’assegnazione dei vari punteggi

• La mobile app di per sè permette un’interazione molto semplice con l’utente,grazie anche al ridotto numero di schermate che gli vengono mostrate. Uneventuale punto di miglioramento riguarda uno studio sulla qualità della so-luzione proposta. Si può svolgere un sondaggio basato su un campione diutenti per valutare l’efficacia della soluzione implementata e per raccoglieresuggerimenti su come migliorarla ulteriormente

• Un problema estremamente complesso, che è stato risolto solo in parte con ilprototipo, riguarda le traduzioni dei parametri nel formato accettato dal ser-vizio. Nell’implementazione corrente viene utilizzato un sistema di traduzionedi tipo chiave-valore che permette di acquisire un’informazione dal contesto etrasformarla nel valore accettato in ingresso dal servizio. I dati da tradurreperò sono di tipologie estremamente diverse tra loro. Un problema comuneè quello della definizione della dimensione “Orario”, composta da “Mattina”,“Pomeriggio” e “Sera”. La maggior parte dei servizi accetta un numero o unintervallo numerico. Da qui nasce l’esigenza di un sistema per effettuare que-sta trasformazione. La difficoltà risiede nella variabilità di questi intervalli.Non è detto che in tutte le parti del mondo si ceni alla stessa ora. Un altroesempio è il caso della dimensione “Budget”. Per definire un budget vengonoutilizzati i valori “Basso”, “Medio” e “Alto”. In questo caso la difficoltà sta neldefinire cosa si intende per budget: di sicuro un budget basso per un ristoranteè diverso da quello di un hotel

• Nel prototipo è stato implementato unicamente il bridge relativo ai servizi ditipo REST. Questa scelta è dettata dal fatto che la maggior parte dei ser-vizi è interrogabile tramite questo protocollo. Un’utile aggiunta può esserel’implementazione di bridge per altri protocolli, come per esempio SOAP. Èconveniente utilizzare diverse implementazioni generiche in quanto un bridge,oltre alla logica di interrogazione e composizione degli indirizzi, deve gestireanche la paginazione dei dati

146

8.1. Sviluppi futuri

• Nel prototipo è stato introdotto un sistema base per l’autenticazione degliutenti. Il motivo della sua semplicità è a causa della prevista integrazione conservizi più flessibili e sicuri. È stata valutata l’integrazione con Passportjs1,un middleware per Node.js che si occupa di autenticazione degli utenti. La suacaratteristica principale riguarda le strategie, ovvero quale provider di auten-ticazione utilizzare. In questo modo è possibile fornire all’utente la possibilitàdi autenticarsi anche con i propri dati di accesso a Facebook o Google

• La mobile app al momento supporta solo una lingua. Sarà necessaria l’in-troduzione di un sistema che permetta di tradurre i testi nelle diverse lingueche si desidera supportare, per fornire un’interazione migliore con l’app anchealle persone che non conoscono l’inglese. Inoltre sarà preferibile introdurreun metodo di selezione della lingua anche per i servizi che supportano questascelta. In questo modo potranno essere recuperate le descrizioni riguardo leentità nella lingua più familiare all’utente

• Nella Sezione 3.10 si è parlato dell’ottimizzazione dell’algoritmo di ricerca delleentità duplicate. La tecnica utilizzata è solo una tra le tante disponibili. Èpossibile tentare con approcci di tipo machine learning per far sì che il softwareimpari di volta in volta a riconoscere gli elementi duplicati, ottenendo un tassodi riconoscimento migliore rispetto a quello attuale

1Passportjs: http://passportjs.org/

147

8. Conclusioni e sviluppi futuri

148

Bibliografia

[1] A. Schmidt, Ubiquitous computing-computing in context. PhD thesis, LancasterUniversity, 2003.

[2] C. Cappiello, M. Matera, and M. Picozzi, “A ui-centric approach for the end-user development of multidevice mashups,” ACM Trans. Web, vol. 9, pp. 11:1–11:40, June 2015.

[3] B. Schilit, N. Adams, and R. Want, “Context-aware computing applications,”in Mobile Computing Systems and Applications, 1994. WMCSA 1994. FirstWorkshop on, pp. 85–90, IEEE, 1994.

[4] B. N. Schilit and M. M. Theimer, “Disseminating active map information tomobile hosts,” Network, IEEE, vol. 8, no. 5, pp. 22–32, 1994.

[5] A. K. Dey, “Understanding and using context,” Personal and ubiquitouscomputing, vol. 5, no. 1, pp. 4–7, 2001.

[6] C. Bolchini, C. Curino, E. Quintarelli, F. A. Schreiber, and L. Tanca, “A data-oriented survey of context models,” SIGMOD Record, vol. 36, no. 4, pp. 19–26,2007.

[7] M. Baldauf, S. Dustdar, and F. Rosenberg, “A survey on context-aware sy-stems,” International Journal of Ad Hoc and Ubiquitous Computing, vol. 2,no. 4, pp. 263–277, 2007.

[8] C. Bolchini, E. Quintarelli, and L. Tanca, “CARVE: context-aware automaticview definition over relational databases,” Inf. Syst., vol. 38, no. 1, pp. 45–67,2013.

[9] C. Bolchini, C. Curino, G. Orsi, E. Quintarelli, R. Rossato, F. A. Schreiber,and L. Tanca, “And what can context do for data?,” Commun. ACM, vol. 52,no. 11, pp. 136–140, 2009.

[10] C. Bolchini, E. Quintarelli, and R. Rossato, “Relational data tailoring throu-gh view composition,” in Conceptual Modeling - ER 2007, 26th International

149

Bibliografia

Conference on Conceptual Modeling, Auckland, New Zealand, November 5-9,2007, Proceedings, pp. 149–164, 2007.

[11] F. Daniel and M. Matera, Mashups - Concepts, Models and Architectures. Data-Centric Systems and Applications, Springer, 2014.

[12] E. M. Maximilien, “Mobile mashups: Thoughts, directions, and challenges,”2012 IEEE Sixth International Conference on Semantic Computing, vol. 0,pp. 597–600, 2008.

[13] C. Cappiello, M. Matera, and M. Picozzi, Design, User Experience, and Usabili-ty. Web, Mobile, and Product Design: Second International Conference, DUXU2013, Held as Part of HCI International 2013, Las Vegas, NV, USA, July 21-26, 2013, Proceedings, Part IV, ch. End-User Development of Mobile Mashups,pp. 641–650. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.

[14] D. C. Schmidt, “Model-driven engineering,” COMPUTER-IEEE COMPUTERSOCIETY-, vol. 39, no. 2, p. 25, 2006.

[15] A. Caio and M. T. Guevara, “Mobimash: una piattaforma per lo sviluppo dimobile mashup,” Master’s thesis, Politecnico di Milano, 2011.

[16] W. W. W. Consortium et al., “Web services glossary,” Online: http://www. w3.org/TR/ws-gloss, 2004.

[17] W. W. Group, W. W. Group, et al., “Web services architecture,” 2004.

[18] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, and D. F. Ferguson,Web services platform architecture: SOAP, WSDL, WS-policy, WS-addressing,WS-BPEL, WS-reliable messaging and more. Prentice Hall PTR, 2005.

[19] D. Benslimane, S. Dustdar, and A. Sheth, “Services mashups: The new gene-ration of web applications,” IEEE Internet Computing, vol. 12, no. 5, p. 13,2008.

[20] R. T. Fielding, Architectural styles and the design of network-based softwarearchitectures. PhD thesis, University of California, Irvine, 2000.

[21] C. Bolchini, C. Curino, G. Orsi, E. Quintarelli, F. A. Schreiber, and L. Tan-ca, “Cadd: a tool for context modeling and data tailoring,” in Mobile DataManagement, 2007 International Conference on, pp. 221–223, IEEE, 2007.

[22] A. Miele, E. Quintarelli, E. Rabosio, and L. Tanca, “Adapt: Automatic datapersonalization based on contextual preferences,” in Data Engineering (ICDE),2014 IEEE 30th International Conference on, pp. 1234–1237, March 2014.

150

Bibliografia

[23] Facebook Inc., “Graphql specifications,” October 2015. https://facebook.github.io/graphql/.

[24] H. Lieberman, F. Paternò, M. Klann, and V. Wulf, End-user development: Anemerging paradigm. Springer, 2006.

[25] C. Cappiello, M. Matera, and M. Picozzi, “A ui-centric approach for the end-user development of multidevice mashups,” TWEB, vol. 9, no. 3, p. 11, 2015.

[26] A. J. Van Deursen and J. A. Van Dijk, “Using the internet: Skill related pro-blems in users’ online behavior,” Interacting with computers, vol. 21, no. 5,pp. 393–402, 2009.

[27] F. Corvetta and V. Rizzo, “Progettazione e sviluppo di mashup mobile contextaware: il progetto camus,” Master’s thesis, Politecnico di Milano, 2015.

[28] P. J. Molina, S. Meliá, and O. Pastor, “User interface conceptual patterns,”in Interactive Systems: Design, Specification, and Verification, pp. 159–172,Springer, 2002.

[29] M. Masse, REST API design rulebook. O’Reilly Media, Inc., 2011.

[30] A. K. Elmagarmid, P. G. Ipeirotis, and V. S. Verykios, “Duplicate record de-tection: A survey,” Knowledge and Data Engineering, IEEE Transactions on,vol. 19, no. 1, pp. 1–16, 2007.

[31] M. Odell and R. Russell, “The soundex coding system,” US Patents,vol. 1261167, 1918.

[32] L. R. Dice, “Measures of the amount of ecologic association between species,”Ecology, vol. 26, no. 3, pp. 297–302, 1945.

[33] V. Sundarapandian, Probability, statistics and queuing theory. New Delhi: PHILearning, 2009.

151

Bibliografia

152

Appendice A

Descrittori

Listato A.1 Descrittore dell’albero di contesto

"userId": [ "ObjectId" ],"context": [

"name": "String","for": "String","values": [ "String" ],"parameters": [

"name": "String","type": "String","fields": [

"name": "String","type": "String"

]

],"parents": [ "String" ]

],"defaultValues": [

"dimension": "String","value": "String"

]

153

A. Descrittori

Listato A.2 Schema dei Mashup

"userId": "ObjectId","list": [

"topics": [ "String" ],"contents": [

"type": "String","style": "String","contents": [ "String" ]

]

],"details": [

"topics": [ "String" ],"contents": [

"type": "String","style": "String","contents": [ "String" ]

]

]

154

Listato A.3 File di configurazione

"server": "port": "Numeric"

,"database":

"address": "String","redis":

"address": "String","rest":

"timeout": "service": "Numeric","cache": "Numeric"

,"primaryService":

"n": "Numeric","weight":

"filter": "Numeric","ranking": "Numeric"

,"similarity":

"threshold": "Numeric","paginationTTL": "Numeric","debug": "Boolean","metrics": "Boolean"

Listato A.4 Descrittore dei servizi

"name": "String","description": "String","protocol": "String","basePath": "String"

155

A. Descrittori

Listato A.5 Schema delle operazioni

"service": "ObjectId","name": "String","type": "String","description": "String","protocol": "String","path": "String","storeLink": "String","bridgeName": "String","parameters": [

"name": "String","description": "String","required": "Boolean","type": "String","default": "String","collectionFormat": "String","mappingCDT": [ "String" ],"mappingTerm": [ "String" ],"translate": [

"from": "String","to": "String"

]],

"headers": ["name": "String","value": "String"

],"responseMapping":

"list": "String","items": [

"termName": "String","path": "String"

],"functions": [

"run": "String","onAttribute": "String"

],"pagination":

"attributeName": "String","type": "String","tokenAttribute": "String","pageCountAttribute": "String"

156

Appendice B

Esempi di codice

Listato B.1 Esempio richiesta login

login (mail: "MAIL_ADDRESS",password: "ENCRYPTED_PASSWORD"

)

namesurnametoken

157

B. Esempi di codice

Listato B.2 Esempio richiesta executeQueryquery Restaurant

executeQuery (userMail: "USER_MAIL",idCdt: "CDT_ID",context: [

dimension: "InterestTopic",value: "Restaurant"

,[ ... ]

],support: ["Transport"]

)

primaryResults (first: 9, after: "YXJyYXljb25uZWN0aW9uOjg=") pageInfo

hasNextPageendCursor

data

titleaddresslatitudelongitudemeta

namerank

supportResults

data categoryserviceurlstoreLink

158

Listato B.3 Esempio risposta executeQuery

"data": "executeQuery":

"primaryResults": "data": [

"title": "Peck","address": "Via Spadari, 9, Milano","latitude": "45.4635272","longitude": "9.187005400000002","meta":

"name": ["GooglePlaces"

],"rank": 1

,[ ... ]

],"pageInfo":

"hasNextPage": true,"endCursor": "YXJyYXljb25uZWN0aW9uOjQ="

,"supportResults":

"data": []

159

B. Esempi di codice

Listato B.4 Esempio richiesta getPersonalData

getPersonalData (mail: "USER_MAIL_ADDRESS",token: "SESSION_TOKEN"

)

cdt idCdtcontext

namevaluesparameters

nametypefields

nametype

parents

defaultValues

dimensionvalue

mashup

list topicscontents

typestylecontents

details

topicscontents

typestylecontents

160