POLITECNICO DI MILANO Corso di Laurea in Ingegneria ... · API (Application programming interface),...

POLITECNICO DI MILANO

Corso di Laurea in Ingegneria Informatica

Dipartimento di Elettronica e Informazione

ViTe: Una piattaforma per la composizione di

mashup basata su VIsual TEmplate

Relatore: Chiar.ma Prof.ssa Maristella Matera

Co-relatore: Ing. Matteo Picozzi

Rovatti Maurizio, Matricola: 739918

Terrazzino Leonardo Savio, Matricola: 734100

Anno Accademico 2011/2012

Indice

I Introduzione 7

1 Introduzione 8

1.1 Obiettivi e motivazioni . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . 12

II Stato dell’arte 14

2 Web Mashup 15

2.1 I Mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Sviluppo dei Mashup . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Sviluppo lightweight . . . . . . . . . . . . . . . . . . . . 23

2.3 Composizione di Mashup . . . . . . . . . . . . . . . . . . . . . . 24

2.3.1 Differenti livelli di integrazione . . . . . . . . . . . . . . 25

2.3.2 Composizione a livello di presentazione . . . . . . . . . . 26

2.3.3 End-User Development . . . . . . . . . . . . . . . . . . . 27

2.4 Strumenti per lo sviluppo di Mashup . . . . . . . . . . . . . . . 29

2.4.1 Yahoo! Pipes . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.2 Quick and Easily Done Wiki . . . . . . . . . . . . . . . . 30

2.4.3 Damia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.4 JackBe Presto . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.5 Marmite . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.6 MashArt . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1

INDICE 2

2.4.7 ServFace . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.8 PEUDOM . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Piattaforme alternative 37

3.1 Mobile Mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.1 Il Web nei dispositivi mobili . . . . . . . . . . . . . . . . 37

3.1.2 Sviluppo di applicazioni mobili per l’utente finale . . . . 40

3.1.3 EUD di Mashup mobili . . . . . . . . . . . . . . . . . . . 42

3.2 Altre Piattaforme . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1 Multitouch . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.2 Smart TV . . . . . . . . . . . . . . . . . . . . . . . . . . 48

III Modelli e Architetture 50

4 Modelli di riferimento 51

4.1 Approccio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 I visual template . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3 Il paradigma di composizione . . . . . . . . . . . . . . . . . . . 58

4.4 Lo schema dell’applicazione . . . . . . . . . . . . . . . . . . . . 61

4.5 L’integrazione di sorgenti dati . . . . . . . . . . . . . . . . . . . 64

5 Architettura della piattaforma ViTe 67

5.1 Il Design Environment . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.1 1 Il visual front-end . . . . . . . . . . . . . . . . . . . . . 70

5.1.1.1 Il data panel . . . . . . . . . . . . . . . . . . . 72

5.1.1.2 Il visual panel . . . . . . . . . . . . . . . . . . 75

5.1.2 Il repository dei servizi . . . . . . . . . . . . . . . . . . . 77

5.1.3 Il runtime environment . . . . . . . . . . . . . . . . . . . 80

5.1.4 Il configuration server . . . . . . . . . . . . . . . . . . . 81

5.2 L’Execution Environment . . . . . . . . . . . . . . . . . . . . . 84

5.2.1 Data Fusion . . . . . . . . . . . . . . . . . . . . . . . . . 87

INDICE 3

5.2.2 Un esempio di composizione mappa generata . . . . . . . 89

6 Valutazioni 94

6.1 Test con gli utenti . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.1.1 Campione del test . . . . . . . . . . . . . . . . . . . . . . 95

6.1.2 Metodologia del test . . . . . . . . . . . . . . . . . . . . 96

6.1.3 Analisi dei dati . . . . . . . . . . . . . . . . . . . . . . . 99

6.1.3.1 Efficienza . . . . . . . . . . . . . . . . . . . . . 100

6.1.3.2 Facilita d’uso . . . . . . . . . . . . . . . . . . . 102

6.1.3.3 Soddisfazione dell’utente . . . . . . . . . . . . . 104

6.1.3.4 Affidabilita del Test . . . . . . . . . . . . . . . 107

IV Conclusioni 108

7 Conclusioni e lavori futuri 109

V Appendice 111

A Pre-Questionario 112

B Post-Questionario 114

C Opinioni degli utenti 119

C.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

C.2 Suggerimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Bibliografia 121

Elenco delle figure

2.1 Modello di tipo user-driven . . . . . . . . . . . . . . . . . . . . 17

2.2 Guadagno vs costo con i mashup . . . . . . . . . . . . . . . . . 18

2.3 Differenti scenari di creazione di un mashup . . . . . . . . . . . 21

2.4 Rappresentazione dell’integrazione dei dati su differenti layer . 25

2.5 Logo di Yahoo! Pipes . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6 Schermata del framework di Yahoo! Pipes . . . . . . . . . . . . 30

2.7 Logo di IBM QEDWiki . . . . . . . . . . . . . . . . . . . . . . . 30

2.8 Scheramata del framework di QEDWiki . . . . . . . . . . . . . . 31

2.9 Logo di JackBe Presto . . . . . . . . . . . . . . . . . . . . . . . 32

2.10 Schermata del framework di JackBe Presto . . . . . . . . . . . . 33

2.11 Logo di ServeFace . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.12 Schermata Peudom . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 Mobile Mashup Editor . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Generazione delle applicazioni mobili con PhoneGap . . . . . . . 44

3.3 Schermata e workflow di ogni tool di composizione . . . . . . . . 45

3.4 Dispositivo Multitouch . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 SmartTv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Architettura della piattaforma ViTe . . . . . . . . . . . . . . . . 53

4.2 List-template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Slider-template . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 Charts-template . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4

ELENCO DELLE FIGURE 5

4.5 Map-template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.6 Schermata del DE e composizione visuale drag-and-drop . . . . 60

4.7 Esempio Config.xml (1) . . . . . . . . . . . . . . . . . . . . . . . 62



4.10 Processo di integrazione dati . . . . . . . . . . . . . . . . . . . . 65

5.1 Architettura del Design Environment (DE) . . . . . . . . . . . . 70

5.2 Visual front-end del Design Environment (DE) . . . . . . . . . . 71

5.3 Rappresentazione ad insiemi del documento XML . . . . . . . . 74

5.4 Vista primaria e secondaria del Map-template . . . . . . . . . . 76

5.5 Inserimento di una sorgente dati nella piattaforma . . . . . . . . 79

5.6 Selezione di una sorgente dati della piattaforma . . . . . . . . . 79

5.7 Architettura Execution Engine (EE) . . . . . . . . . . . . . . . 86

5.8 Funzionamento della data-fusion nel template Map . . . . . . . 88

5.9 Esempio di data-fusion nel template Map . . . . . . . . . . . . . 89

5.10 Schermata principale Execution Environment (EE) . . . . . . . 90

5.11 Menu di selezione dell’applicazione all’interno dell’EE . . . . . . 91

5.12 Visteprimaria e secondaria del template Map nell’EE . . . . . . 92

5.13 Menu di ricerca e selezione dei filtri . . . . . . . . . . . . . . . . 93

6.1 Distribuzione degli utenti in base alla fascia di eta . . . . . . . . 96

6.2 Tempo medio per ogni attivita del task A . . . . . . . . . . . . 101

6.3 Tempo medio per ogni attivita del task B . . . . . . . . . . . . . 102

6.4 Valutazioni medie sulla facilita di utilizzo . . . . . . . . . . . . . 103

6.5 Risposte utenti alla domanda n°9 . . . . . . . . . . . . . . . . . 105

Elenco delle tabelle

3.1 Differenze tra mashup nativi e mashup web . . . . . . . . . . . . 40

6.1 Descrizione delle sotto-attivita per il test A . . . . . . . . . . . . 97

6.2 Descrizione delle sotto-attivita per il test B . . . . . . . . . . . . 98

6.3 Descrizione delle sotto-attivita per il test B (continua..) . . . . . 99

6

Parte I

Introduzione

7

Capitolo 1

Introduzione

L’evoluzione costante dell’informatica ha portato alla diffusione di servizi ba-

sati su web e di varie tipologie di dispositivi in grado di interfacciarsi ed uti-

lizzare tali servizi. Questo scenario, visto il grado di personalizzazione offerto

da questi servizi, invoglia gli utenti a partecipare allo sviluppo delle proprie

composizioni in modo da poter creare quelle piu adatte alle proprie esigenze.

Negli ultimi anni le tecnologie dei mashup sono percio emerse, permettendo la

definizione di paradigmi d i composizione alla portata degli utenti finali.

In informatica un mash-up e un sito o un’applicazione web di tipo ibrido,

cioe tale da includere dinamicamente informazioni o contenuti provenienti da

piu fonti. Un esempio potrebbe essere un programma che, acquisendo da un

sito web una lista di appartamenti, ne mostra l’ubicazione utilizzando il ser-

vizio Google Maps per evidenziare il luogo in cui gli stessi appartamenti sono

localizzati. Mash-up (letteralmente: ”poltiglia”), in termini informatici, indica

un’applicazione che usa contenuti da piu sorgenti per creare un servizio com-

pletamente nuovo. Il contenuto dei mash-up e normalmente preso da terzi via

API (Application programming interface), tramite feed (es. RSS e Atom) o

Javascript. I mash-up stanno rivoluzionando lo sviluppo del web permettendo

a chiunque di combinare dati da siti come Amazon.com, eBay, Google, Win-

dows Live e Yahoo! in modi innovativi[39].

8

CAPITOLO 1. INTRODUZIONE 9

Tuttavia, come dimostrato da alcune ricerche condotte negli ultimi anni [3],

soltanto pochi utenti sono in grado di creare le proprie applicazioni program-

mando l’integrazione dei servizi. Le principali difficolta che gli utenti incontra-

no nascono, soprattutto, quando gli strumenti utilizzati in fase di progettazione

non astraggono in modo adeguato dalle tecnologie e dai linguaggi di program-

mazione sottostanti. Inoltre, lo scenario appena descritto potrebbe risultare

piu critico se vengono introdotte le necessita, da parte dell’utente, di avere a

disposizione la propria composizione in ogni dispositivo con il quale e abituato

ad interagire. Questo perche le tecnologie native dei vari dispositivi sono mol-

to diverse tra loro e quindi difficili da essere gestite anche da utenti esperti di

tecnologie. In questo contesto, i paradigmi di composizione e gli strumenti che

astraggono dai dettagli implementativi potrebbero aiutare gli utenti, soprat-

tutto i meno esperti, nella composizione di servizi.

Tenendo conto delle osservazioni fatte fino ad ora, l’obiettivo principe di que-

sta tesi e lo sviluppo di un ambiente di lavoro per la costruzione “lightweight”,

la composizione user-driven e il rilascio (deploy) della propria composizione

di servizi. Il nostro framework e caratterizzato da un ambiente di sviluppo

destinato all’utente finale (End-User Development Desktop Environment), nel

quale il completamento di template visuali permette agli utenti di unire piu

sorgenti dati e configurare in modo semplice i dati da visualizzare nelle proprie

composizioni.

Le applicazioni cosı create sono applicazioni native dei singoli dispositivi che, in

contrasto coi Web mashup, non hanno necessariamente bisogno di un browser

Web come ambiente di esecuzione. Questa caratteristica, in caso di utilizzo di

dispositivi diversi dai comuni pc, facilita l’accesso dell’applicativo ai servizi na-

tivi dell’OS del dispositivo. Basandosi sul completamento di template visuali,

l’ambiente di design automaticamente genera e rilascia uno schema del mashup

finale. Il motore di esecuzione dell’applicazione e, quindi, in grado di scaricare


localmente e di interpretare lo schema: grazie a tecniche generative model-to-

code, costruisce dinamicamente l’interfaccia utente (UI) basata sui template

visuali precedentemente completati durante la fase di design del mashup, e

popola dinamicamente gli elementi visuali delle UI con i dati provenienti dai

differenti servizi da cui si e deciso far confluire i dati. L’applicazione finale,

costruita attraverso le scelte dei servizi e le politiche di integrazione, mostra

inoltre un ulteriore livello di flessibilita, dal momento che l’utente e in grado di

raffinare “on the fly” la selezione dei servizi. Questo aspetto di dinamicita, che

possiamo definire col paradigma “mashup-within-mashups”, favorisce il riuso

dei mashup mobili in differenti contesti d’uso.

1.1 Obiettivi e motivazioni

Alla luce delle precedenti considerazioni, crediamo vi siano numerose opportu-

nita per la ricerca e lo sviluppo in quest’area. Nel nostro lavoro siamo partiti

introducendo la nostra prospettiva sulla composizione di servizi e quindi abbia-

mo proposto alcune astrazioni e modelli sostenuti anche dall’implementazione

di una piattaforma Web. In particolare, abbiamo introdotto i seguenti contri-

buti:

� Processo di sviluppo leggero (lightweight development process). La

scelta di sviluppare un’applicazione per la composizione guidata di ser-

vizi nasce soprattutto dalla necessita di avere uno strumento di sviluppo

facile e veloce da usare indipendentemente dalla tipologia di utente che

la utilizza. Infatti, considerando la tipologia di utenti non esperti, e de-

siderabile avere un modello di mashup che nasconda la complessita del

back-end e semplifichi il processo di aggregazione dei dati e dei servizi at-

traverso metafore piu vicine all’organizzazione di un front-end. Il nostro

paradigma visuale di composizione, quindi, chiede all’utente di comple-

tare template visuali predefiniti coi dati estratti dai servizi selezionati.


Gli utenti visivamente scorrono i dati dei servizi e mappano quelli di

interesse sugli elementi del template visuale. In altre parole, gli utenti

manipolano esattamente gli elementi visuali che vedranno e con cui inte-

ragiranno nell’applicazione finale. Un editor di tipo WYSIWYG (What

You See Is What You Get) permette loro di ottenere immediatamente

esempi realistici sui dati che popoleranno gli elementi del template visua-

le e sul modo in cui i contenuti saranno fusi in un unica visualizzazione

nel caso di piu servizi coinvolti.

� Integrazione dei dati visual-oriented. Il nostro paradigma visuale

di composizione supporta differenti tipi di integrazione: join di unione e

d’intersezione per creare viste integrate di dati provenienti da differen-

ti core-service. La sfida principale e stata tuttavia quella di adottare

uno schema di integrazione rappresentante la fusione dei dati a livello

di presentazione, con l’obiettivo principale di ottimizzare la fruizione del

contenuto da parte degli utenti. Oltre a guidare il processo di compo-

sizione, la nozione di visual template guida l’identificazione di schemi

di integrazione locali (cioe di ciascuna sorgente) e globali permettendo

alle applicazioni che devono eseguire la composizioni (Execution Envi-

ronment) di applicare algoritmi di “Data Fusion” nel caso in cui i dati

restituiti dai servizi selezionati siano riconducibili allo stesso elemento.

� Modello di composizione. Dopo aver creato la composizione, le astra-

zioni fondamentali, utili alla descrizione della composizione stessa, ven-

gono incapsulate all’interno di un linguaggio di descrizione che e auto-

maticamente generato dall’ambiente di design di Vite e quindi utilizzato

dagli Execution Environment per la composizione dinamica dell’applica-

zione finale. Guardando oltre la nostra implementazione web-based, che

ha il semplice scopo di mostrare come e possibile utilizzare la descrizione

creata in fase di sviluppo, il modello descritto in precedenza puo essere

riutilizzato in differenti piattaforme e ambienti di esecuzione client-side.


� Dimostrazione dei concetti. Illustriamo un’architettura di riferimen-

to e inoltre forniamo un prototipo di implementazione basato su Web.

Attraverso uno studio sugli utenti abbiamo anche validato l’adeguatezza

del paradigma di completamento di template visuali facendo riferimento

alle abilita degli utenti.

1.2 Struttura della tesi

La tesi e strutturata nelle seguenti parti:

� Parte II: Stato dell’arte

– Capitolo 2: Web Mashup. In questo capitolo si introducono i ma-

shup, quindi i componenti che li costituiscono, le loro funzionalita

e le diverse tecnologie. Vengono discussi i paradigmi piu comuni

di composizione di mashup Web tramite componenti UI. Infine, si

illustrano gli attuali tool a supporto dell’utente per la creazione di

composizioni Web.

– Capitolo 3: Piattaforme alternative. In questo capitolo vengono

trattati i mashup che non fanno uso diretto del web, ovvero i mashup

per piattaforme alternative come i dispositivi mobile, i multitouch

informativi e le smartTV di ultima generazione. Dopo una breve

introduzione sull’attuale situazione e quindi sugli attuali trend di

crescita e di sviluppo per queste piattaforme, si illustrano quali sono

le maggiori potenzialita che offrono questi dispositivi.

� Parte III: Modelli e Architetture

– Capitolo 4: Modelli. Questo capitolo offre una panoramica dei

modelli che sono stati utilizzati per l’implementazione della piat-

taforma di sviluppo (Design Environment) e dell’applicazione che

esemplifica l’utilizzo della composizione creata (Execution Engine).


Vengono introdotte le nuove astrazioni tramite cui gli utilizzato-

ri finali, per mezzo di azioni visuali e guidati da template visuali

(Visual-Template), sono in grado di costruire viste unificate con i

dati estratti da piu sorgenti. Successivamente si descrive il modello

del mashup (schema-application) e il processo di integrazione dei

dati.

– Capitolo 5: Architettura. In questo capitolo si illustra l’architettura

dell’intera piattaforma, ViTe, per lo sviluppo di mashup multipiat-

taforma. In particolare vengono presentate, mettendone in risalto le

peculiarita, le due componenti fondamentali: il Design Environment

e l’Execution Engine. L’implementazione descritta riflette dunque i

modelli illustrati nel capitolo 4.

– Capitolo 6: Valutazioni. Valutazioni. In questo capitolo, dopo una

breve panoramica delle metodologie di conduzione dei test e della

selezione del campione statistico, si illustrano i procedimenti uti-

lizzati per effettuare i test con gli utenti finali. Dopo una prima

analisi delle tempistiche di composizione, vengono stimate attra-

verso opportune metriche la soddisfazione degli utenti e la facilita

d’uso dell’applicazione, sulla base di un questionario completato a

fine test.

� Parte IV: Conclusioni

– Capitolo 7: Sommario e lavori futuri. In quest’ultimo capitolo si

riassumo i principali risultati che sono stati raggiunti e si delineano

i lavori futuri.

� Parte V: Appendice

– Appendice A: Pre-Questionario

– Appendice B: Post-Questionario

Parte II

Stato dell’arte

14

Capitolo 2

Web Mashup

In questo capitolo si introdurranno i Web mashup, quindi i componenti che

li costituiscono, le loro funzionalita e le diverse tecnologie. Verranno dunque

discussi i paradigmi piu comuni di composizione di Web mashup tramite com-

ponenti UI. Infine, verranno illustrati gli attuali tool a supporto dell’utente per

la creazione di queste composizioni.

2.1 I Mashup

La nascita e lo sviluppo di servizi secondo il paradigma SOA (Service Orien-

ted Architecture) ha brevemente portato, nel corso degli anni, al concetto di

riutilizzo e d’integrazione delle risorse Web sotto forma di contenuti e servi-

zi Web end-user. Una delle piu grandi innovazioni che ha portato con se il

nuovo approccio al Web, ossia il Web 2.0, sono stati, e sono tuttora, i Ma-

shup: composizioni ibride di piu Web service che integrate e fuse tra di loro

generano un nuovo servizio, che comprende e integra contemporaneamente le

caratteristiche e le informazioni di tutti i suoi componenti. Tali applicazioni

Web si sono sviluppate sempre piu velocemente grazie anche a siti come Pro-

grammableWeb.com, diventato nel corso degli ultimi anni uno dei riferimenti

principali per gli sviluppatori di mashup specialmente per quanto riguarda la

ricerca di componenti base. I Web Mashup sono dunque siti Web dinamici,

15

CAPITOLO 2. WEB MASHUP 16

composti da interfacce Web-user, che integrano logica e contenuti rilasciati da

soggetti terzi tramite l’utilizzo di opportune API (Application Programming

Interface). I primi che hanno cominciato a rendere pubbliche le loro interfacce

per poter accedere ai propri servizi sono stati i grandi “Web competitor” tra

i quali spiccano i nomi dei soliti noti Google, Yahoo ed altri. La scelta di

queste aziende di rendere pubblici i propri servizi e stata adottata con uno

scopo principale: la diffusione di tali servizi. Conseguentemente, il numero di

API e in continuo aumento poiche, per ogni nuovo Web Service creato, ven-

gono rilasciate le specifiche e i dettagli necessari per la corretta fruizione del

servizio. Tuttavia, a causa dell’instabilita di un API, che potrebbe cambiare le

sue specifiche da un momento all’altro, costruire mashup ad hoc e una pratica

poco diffusa. I mashup sono quindi una forma di composizione e di riuso di

componenti pubblicati sul Web che genera un valore aggiunto agli stessi in

quanto trova nuove forme di utilizzo, innovative e creative, che spesso vanno

ben oltre lo scopo originario dei singoli componenti. Si ricordi che i primi

mashup sviluppati erano basati soprattutto sul riuso di contenuti estratti da

pagine Web a completa insaputa del proprietario originario dei contenuti circa

il loro utilizzo finale. Tutto cio a conferma che la composizione di applicazioni

o processi a partire da servizi esistenti non e una disciplina nuova.

Da anni la community dell’Information Technology (IT) studia metodi e lin-

guaggi di composizione per i cosiddetti Web service con risultati molto buoni

(per es. BPEL [33]), e il campo dell’integrazione dei dati e ormai un’area con-

solidata, nonostante le nuove sfide poste da dati sempre piu eterogenei e meno

strutturati.

La vera innovazione portata dal paradigma mashup risiede nel fatto che, ol-

tre ai tradizionali metodi di integrazione dei dati e delle logiche applicative,

fornisce anche un’integrazione di elementi di presentazione visuale, grazie alla

standardizzazione di certe tecnologie Web (si ricordi GoogleMaps). La pro-


duzione di un mashup prevede una fase di prototipizzazione rapida, costituita

da un’integrazione veloce di differenti API e sorgenti dati, secondo un approc-

cio orientato all’utente (user-oriented). Uno dei principali punti di forza dei

mashup risiede nel permettere a persone, sprovviste di particolari abilita di

programmazione, di dare forma alle proprie idee innovative, in modo veloce e

relativamente semplice.

Figura 2.1: Modello di tipo user-driven [18]

Lo sviluppo di un mashup e composto da un insieme di fasi che sono in rela-

zione circolare [18]. Esso ha inizio nel momento in cui una persona incontra un

problema nella vita di tutti i giorni. Dal momento che e relativamente facile

costruire un mashup connettendo tra loro differenti servizi, la sua costruzione

avviene iterativamente ed e guidata dal funzionamento desiderato. Partendo

dunque da un determinato problema (come per es. la visualizzazione sulla

carta geografica dei cinema) si passa alla fase di costruzione e di design che

consiste nell’integrare e sincronizzare tra loro servizi, sorgenti dati e widget

disponibili sul Web. Nella fase seguente si avra quindi la fruizione del mashup,

che sara correttamente funzionante fino alla decisione dell’utente-sviluppatore

di introdurre per esempio nuovi servizi o sopperire eventuali problemi (come

la sostituzione di una sorgente dati a fronte dell’interruzione di un servizio

precedentemente utilizzato). Quindi il mashup viene utilizzato fino a quando

non si riscontra un nuovo problema che sara risolto applicando nuovamente

il ciclo di vita. Si tratta di un modello adattativo che a partire dal problema

iniziale si plasma su quelli successivi. La Figura 2.1 illustra il suddetto modello.


I mashup, come abbiamo detto, riusano servizi e dati esistenti e non richie-

dono eccessive abilita proprie dell’IT, garantendo la creazione di applicativi in

breve tempo, con bassi costi di produzione e mantenimento [27].

Figura 2.2: Guadagno vs costo con i mashup [27]

In ambito business i mashup permettono di suddividere i processi Enterprise

in parti piu piccole e modulari abilitando quindi il riuso di servizi gia esistenti.

Questo migliora il time-to-market e riduce i costi di sviluppo dell’applicazione.

In [27], e stato pronosticato che questo rappresentera un sostanziale vantaggio

competitivo per chi utilizzera i mashup, mentre coloro i quali non lo adotte-

ranno si ritroveranno inevitabilmente a essere svantaggiati.

Ad oggi esistono piu di 6000 mashup e oltre 4000 API Web che rappresen-

tano i componenti principali nella creazione di mashup. In base al dominio

operativo i mashup in genere possono essere classificati in tre categorie:

� mashup commerciali, di solito si possono definire come applicazioni che

combinano risorse informative Enterprise con altri servizi Web in una

singola presentazione. Il processo di sviluppo e flessibile poiche richiede

la continua collaborazione tra gli sviluppatori e i clienti, per la defini-

zione e l’implementazione dei requisiti di business. I mashup aziendali

dal punto di vista dell’interfaccia utente presentano diverse somiglianze


con le rich-internet-applications (RIA) per la dimensione di interattivita,

multimedialita e velocita di esecuzione.

� mashup di consumo, combinano diversi tipi di dati provenienti da mol-

teplici fonti Web e li organizzano attraverso una, piu o meno semplice,

interfaccia utente Web-client. Per esempio HealthMap [25] che raccoglie

diverse fonti di dati (per es., World Health Organization) per ottenere

una visione unificata e completa, su una mappa GoogleMaps, dello stato

attuale globale delle malattie infettive e il loro effetto sulla salute umana

e animale.

� mashup di dati, combinano dati e informazioni simili provenienti da piu

fonti, in un’unica rappresentazione. La combinazione di tutte queste

risorse crea un nuovo e distinto servizio Web diverso da quelli di partenza.

2.2 Sviluppo dei Mashup

La struttura dei mashup (composti da componenti modulari riutilizzabili) con-

sente di poter progettare ambienti di sviluppo orientati all’utente finale (end-

user), cioe facili da usare da colui che deve usufruire del mashup stesso (user-

friendly). Nella creazione dei mashup e possibile distinguere due approcci di

sviluppo:

� automatizzato: e l’approccio adatto all’utente che e privo di capacita

di programmazione. L’utente inserisce ed utilizza componenti “pronti

all’uso” (ready-to-use) che gli sviluppatori della piattaforma di creazione

del mashup hanno precedentemente preparato. La creazione del mashup

consiste dunque nell’assemblare questi componenti, generalmente tramite

paradigmi di interazione visuali.

� manuale: l’utilizzatore dell’ambiente di creazione del mashup e un uten-

te con ampie capacita di programmazione e dunque e in grado di scri-


vere il codice di gestione dei componenti e definire la loro coreografia e

orchestrazione.

Il tipo di mashup spesso determina l’approccio di sviluppo specifico. Per capire

meglio la realta del dominio dei mashup e necessario individuare gli attori

(sviluppatori) che partecipano alla catena di creazione del mashup finale [24,

23, 8]:

� sviluppatori esperti di mashup: esperti nella produzione veloce di mashup

di qualita tramite attivita di programmazione. Gli utenti finali non sono

direttamente coinvolti nella realizzazione.

� sviluppatori esperti nella creazione di servizi : esperti che sviluppano ser-

vizi che possono essere composti in mashup e possono fornire una “sand-

box” in cui gli utenti finali combinano loro stessi i mashup. Il ruolo degli

sviluppatori e quello di creare i servizi, mentre i mashup sono costruiti

dagli utenti piu vicini al dominio dell’applicazione.

� sviluppatori di piattaforme di costruzione di mashup: sono coloro i quali

sviluppano il tool che consente di assemblare i componenti che serviranno

alla creazione del mashup.

La Figura 2.3 mostra i differenti tipi di scenari nello sviluppo di mashup.

Quando i mashup sono costruiti centralmente (scenario A), le risorse per lo

sviluppo del mashup sono limitate agli esperti sviluppatori del dipartimento IT.

Vista questa limitazione, verranno create solo quelle applicazioni abitualmente

richieste. Comunque questo tipo di approccio permette di creare ogni tipo di

applicazione proveniente da servizi eterogenei.


Figura 2.3: Differenti scenari di creazione di un mashup [8, 24]

Quando il dipartimento IT focalizza le sue energie nel fare componenti stan-

dardizzati, questi possono essere utilizzati anche da utenti non sviluppatori

(scenario B). Questi utenti generalmente hanno una comprensione maggiore

del dominio dell’applicazione rispetto agli esperti dell’IT che hanno creato lo

strumento di mashup. Questo scenario di solito consente un basso livello di

integrazione dati e di parametrizzazione dei componenti data la poca abilita


di programmazione degli utenti.

Nell’ultimo scenario (C) e possibile notare la presenza di un tool per la crea-

zione del mashup. E’ lo scenario che rappresenta la sfida piu grande per lo

sviluppatore e allo stesso tempo il piu grande pay-off. Usando il suddetto tool

gli utenti sono in grado di crearsi il proprio mashup. Le possibilita di compo-

sizione sono limitate alle diverse combinazioni dei componenti offerti dal tool.

Gli utenti tuttavia non hanno limiti riguardo i di tipi di applicazioni che pos-

sono costruire. Questo scenario si potrebbe dire che copre la maggior parte di

bisogni degli utenti.

Un’altra caratteristica che differenzia gli scenari sopra proposti e il livello di

controllo della qualita dei mashup che vengono creati. Comprensibilmente si

puo immaginare che la qualita del mashup dello scenario A sara molto eleva-

ta dato che sara un mashup costruito ad-hoc da un esperto ITC. Comunque,

anche mashup di questo tipo possono essere carenti di caratteristiche quali

sicurezza, performance o affidabilita. Inoltre una soluzione complessa e ingom-

brante perderebbe i vantaggi tipici dei mashup come costi e tempi di creazione.

Gli scenari B e C danno dunque una maggiore liberta all’utente di scegliere e

creare le proprie applicazioni. Secondo Hippel [36], i mashup danno una sorta

di democraticita all’innovazione, permettendo agli utenti di conciliarsi con i

propri bisogni, superando i centri di calcolo e i service provider che spesso non

sono in grado di soddisfarli. Come detto prima, una potenzialita dei mashup

e quella di permettere la creazione veloce di prototipi che risolvono proble-

mi specifici. Tali prototipi possono poi evolvere verso soluzioni generali. Per

esempio, cambiando semplicemente le sorgenti dati e possibile creare mashup

per differenti contesti d’uso, mantenendo la struttura del prototipo iniziale.


2.2.1 Sviluppo lightweight

Poiche, come e risaputo, i mashup sono principalmente applicazioni Web, il loro

processo di sviluppo presenta le stesse caratteristiche delle applicazioni Web

generiche. Nello sviluppo per il Web le tempistiche di produzione sono diverse

rispetto alle tempistiche tradizionali di sviluppo software. Per esempio, laddove

la produzione software richiede mesi o anni, nella produzione Web i tempi si

restringono a settimane o a volte anche giorni. Si tratta dell’Internet-time (cioe

l’accesso rapido all’informazione ovunque), che rende i processi di costruzione

molto dinamici. Inoltre, anche se un‘applicazione e pronta ed e rilasciata in

rete, essa puo continuare a funzionare anche se nel back-end avvengono delle

modifiche sul software. I processi cosiddetti leggeri (lightweight) di creazione

del mashup, possono essere schematizzati in tre diverse attivita:

� ricerca e selezione: partendo da una determinata idea e arricchendola

con i bisogni personali, l’utente (compositore) seleziona sia i servizi che

forniscono i dati a lui necessari e sia le interfacce utente per la realiz-

zazione della sua applicazione. Questa attivita, dunque, implicitamente

contiene l’analisi dei requisiti e delle specifiche. Il programmatore che

costruisce la piattaforma deve aver preparato precedentemente il wrap-

ping per ogni componente API, che l’utente utilizzera. Il wrapping e uno

strato di astrazione software in grado di interagire con l’API del servizio

per poterlo interrogare.

� composizione del mashup: i tool di costruzione di mashup permettono

agli utenti con scarse o anche nulle abilita di programmazione Web di

comporre graficamente i componenti selezionati e di farne il setting per

la necessaria integrazione logica dell’applicazione composta. La reale pa-

rametrizzazione e nascosta all’utente che a video dovra eseguire solo sem-

plici passi assistito dal tool. Questa attivita e sostanzialmente diversa dai

tradizionali metodi di design e d’implementazione. In particolare, evita

quelle attivita che tradizionalmente sono obbligatorie, come per esem-


pio il design. Il rilascio (deploy) dell’applicazione mashup sara eseguito

semplicemente salvando l’applicazione nel server. Quando il compositore

(compositor) effettua il collegamento tra i diversi componenti e il tool di

mashup che crea il codice di collegamento (binding) sottostante. Dunque

il compositore deve solo interagire con i componenti eseguendo semplici

operazioni di drag-and-drop o di selezione nei menu presenti.

� uso e manutenzione: una volta che il mashup e stato salvato e depositato

sul server di hosting, il mashup sara pronto all’uso. Il mantenimento

dell’applicativo avviene quindi semplicemente a livello di composizione.

2.3 Composizione di Mashup

Nello sviluppo del software uno dei piu grandi dilemmi e quello di rilasciare un

prodotto che trovi un punto di intersezione tra quelli che sono i bisogni e quelle

che sono le preferenze dell’utente che lo utilizza. In tutti i modelli di sviluppo

del software una parte importantissima e proprio la validazione da parte degli

utenti che utilizzano l’applicazione, cioe la validita dell’oggetto (manufact) che

e stato creato con l’applicativo. In caso di non corrispondenza tra quello che

l’utente e riuscito a produrre e quello che voleva ottenere, egli dovra continuare

a iterare il ciclo di produzione/composizione fino a trovare il risultato deside-

rato. Come si puo intuire, questo aspetto potrebbe rilevarsi determinante in

termini sia di tempo che di denaro. Per fare un esempio, caliamoci nei bisogni

di ingegneri, fisici, geologhi, astrofosici ovvero di tutte le possibili figure profes-

sionali. In questi domini di lavoro, un tool di facile utilizzo, che permetta loro

di creare applicazioni tramite un processo di sviluppo lightweight, che produca

esattamente e in breve tempo cio di cui hanno bisogno, potrebbe aumentare

drasticamente la loro produttivita.

Per superare le tradizionali demarcazioni tra utente finale e designer delle appli-

cazioni, e stato necessario proporre nuovi modelli che si discostano dal classico


modello “waterfall top-down”. Negli ultimi anni, la rivoluzione del Web 2.0 ha

enfatizzato la “cultura della partecipazione”. Si tratta di un paradigma dove la

distanza tra designer e utente e spesso esigua e gli utenti finali sono sempre piu

spesso guidati nel “gioco” di costruzione di contenuti e di applicazioni. Anche

se questa soluzione incrementa notevolmente il coinvolgimento dell’utente, lo

sviluppo di tipo end-user non e la soluzione a tutti i problemi e spesso non

permette la creazione di una soluzione completa. Consapevoli di cio, il nostro

lavoro e stato anche quello di dimostrare che sotto adeguate ipotesi e vincoli,

un utente finale, tramite interfacce user-friendly e in grado di creare appli-

cazioni mashup adattabili a diverse tipologie di dispositivi che altrimenti gli

sarebbero impossibili da creare. Si cerchera ora di descrivere i framework piu

utilizzati e proposti in letteratura [11] per la semplificazione dello sviluppo.

2.3.1 Differenti livelli di integrazione

L’integrazione puo avvenire in forme diverse. In generale si distinguono 3 classi

principali: l’integrazione dei dati, l’integrazione delle applicazioni e l’integra-

zione delle interfacce utente.

L’integrazione dei dati (vedi Figura 2.4 (a)) presenta diversi problemi che van-

no dalla risoluzione dei disallineamenti tra i modelli dei componenti dei dati,

alla costruzione e alla manutenzione di modelli dei dati e mapping eseguiti

tramite query di schemi globali e locali . Richiede una scarsa collaborazio-

ne fra componenti e la comprensione della semantica del modello dei dati dei

componenti.

Figura 2.4: Rappresentazione dell’integrazione dei dati su differenti layer


Nell’integrazione a livello di applicazione (vedi Figura 2.4 (b)), un’applicazio-

ne composita ha una sua interfaccia utente, ma il livello di logica business e

sviluppato attraverso l’integrazione di funzionalita che le “applicazioni com-

ponente” (component-applications) offrono. Naturalmente questo approccio

funziona molto bene quando le applicazioni componente espongono un API

che viene mantenuta stabile nelle le versioni.

L’integrazione delle interfacce utente (vedi Figura 2.4 (c)) mira a comporre

applicazioni a livello di presentazione, lasciando la gestione dei dati e della lo-

gica di business a ciascun componente. L’integrazione UI e applicabile quando

l’integrazione a livello dati o applicazione non e fattibile e quando lo sviluppo

di una nuova interfaccia utente e troppo costosa. Per esempio quando le ap-

plicazioni non espongono le API di livello business.

Nell’integrazione dell’interfaccia utente e possibile quindi individuare quattro

passi:

� definizione dei modelli e dei linguaggi per le specifiche dei componenti.

� definizione dei modelli e dei linguaggi per le specifiche di composizione

dei componenti.

� scelta degli stili di comunicazione per l’interazione dei componenti.

� definizione della ricerca delle fonti dati, dei componenti e il meccanismo

di binding per la sincronizzazione dei componenti.

2.3.2 Composizione a livello di presentazione

Storicamente, le prime composizioni di componenti di presentazione sono nate

per applicazioni desktop, per poi col tempo migrare verso tecnologie sempre

piu indipendenti dal sistema operativo. E’ vero che queste tecnologie erano

indipendenti, ma necessitavano dei loro rispettivi ambienti di runtime (per

esempio JVM per RCP). Gli approcci che generalmente a oggi si usano sono:


� componenti di plugin per browser : l’esperienza di navigazione nel browser

spesso coinvolge caratteristiche di interfaccia utente avanzate. Dopo la

definizione del binding dei componenti durante la scrittura della pagina

da parte del Web designer, il browser scarica i componenti e a runti-

me vengono istanziati. Questi componenti spesso rendono disponibile la

modifica della loro modalita di visualizzazione (rendering), per mezzo di

ulteriori comunicazioni tra loro e la pagina Web che li contiene. Solita-

mente le interfacce, che sono messe a disposizione del cliente, sono molto

semplici e spesso richiedono solo una una piccola modifica al codice di

markup della pagina per essere incorporate.

� Web mashups : come gia spiegato i mashup sono particolari applicazioni

Web che consentono l’integrazione, su differenti livelli, di servizi, API o

sorgenti dati messi a disposizione in rete. I mashup sono dunque composti

da parti atomiche chiamate componenti (components) che, sincronizzati

e debitamente orchestrati, consentono l’integrazione di diversi contenuti

e generano un’applicazione con valore aggiunto.

� Web portals e portlets : sono altresı forme di composizione nella creazione

di applicazioni Web. In particolar modo i portlet sono applicativi soft-

ware componibili e interfacciabili tra loro, che compongono un portale

Web. Un esempio classico sono i componenti di interfaccia utente che

possono arricchire un portale, come calendari, condizioni meteo o e-mail.

Ciascun portlet e quindi una semplice applicazione a se stante che puo

essere chiusa o aperta dall’utente in base alle sue preferenze e avendo

quindi la possibilita di personalizzare la propria pagina in tempo reale.

2.3.3 End-User Development

Una nozione che e importante introdurre ai fini della comprensione del nostro

framework di lavoro, sono i principali approcci di composizione e sviluppo

esistenti:


� End-User Programming (EUP): permette all’utente il potenziamento e

il supporto alla costruzione del software tramite:

– pragrammazione per dimostrazione (programming by demonstra-

tion)

– paradigmi visuali

– programmazione visuale (visual programming)

– linguaggi di scripting e linguaggi specifici del dominio di applicazio-

ne

� End-User Software Engineering (EUSE): integra, oltre agli aspetti tipici

dell’approccio EUP (End User Programming) anche attivita a supporto

dell’affidabilita, dell’usabilita, dell’efficienza e del controllo della versione.

� End-User Development (EUD): simile all’EUP, e un approccio orientato

allo sviluppo di applicazioni molto diverse fra loro, che spaziano per

esempio dalle creazioni 3D ai mock-up di prototipi. Questo approccio sia

astrae completamente dal linguaggio di programmazione vero e proprio.

Il nostro approccio e quindi di tipo EUD. La nostra piattaforma e in grado di

fornire all’utente differenti tipi di soluzioni a problemi generalmente riscontra-

ti nell’utilizzo di sorgenti Web. Anche un utente end-user, con scarse o nulle

capacita di programmazione, sara in grado di compiere azioni come comporre

applicazioni mashup o integrare intelligentemente sorgenti dati Web.

La questione della facilitazione della creazione di applicazioni a partire da

componenti Web appartiene a una delle piu vaste aree di investigazione in

abito software engineering e data management [10]. D’altro canto, mentre

questi studi hanno semplificato l’integrazione a livello dati e applicativo, si e

avanzato poco nel facilitare l’integrazione a livello di presentazione. Coloro i

quali hanno sviluppato applicazioni grafiche sono a conoscenza che lo sviluppo

di interfacce grafiche e una delle parti che necessitano piu tempo nelle fasi di


sviluppo, come il testing e la manutenzione. Questo ci suggerisce che e buona

norma, o meglio essenziale, il riuso anche di componenti dotati di una propria

interfaccia utente (i cosiddetti componenti UI), quali Google Maps, YouTube

e Flickr. Comunque, oggigiorno lo sviluppo di UI e facilitato da diversi fra-

mework (per es., Java Swing), che forniscono componenti grafici come bottoni,

menu e simili. Il fatto pero di poter disporre di interfacce stand-alone negli

applicativi (per esempio GoogleMaps), e oggetto negli ultimi anni di una certa

attenzione.

2.4 Strumenti per lo sviluppo di Mashup

Al fine di velocizzare lo sviluppo di mashup e rendere possibile la creazione di

quest’ultimi anche agli utenti poco esperti in materia di programmazione, sono

nati numerosi tool e piattaforme di sviluppo. Ognuno di questi ambienti porta

con se differenti approcci di creazione. Per poter avere una visione globale piu

chiara, vediamo in sintesi le particolarita e le funzionalita dei tool piu diffusi e

rappresentativi.

2.4.1 Yahoo! Pipes

Figura 2.5: Logo di Yahoo! Pipes

Partendo da una o piu sorgenti dati (data feed), attraverso un editor a inter-

faccia visuale e azioni drag-and-drop e possibile creare la propria applicazione

[42]. Questo tool si basa su un data processing pipeline (costruzione a stadi),

che consiste nell’interconnessione, tramite operatori, di piu sorgenti dati, come

per esempio dati di tipo feed, XML o RSS/Atom.


Gli operatori principali sono quelli che consentono la manipolazione dei dati

(per esempio filtering o sorting) e i piu sofisticati sono gli operatori di looping,

di espressioni regolari o di conteggio. Inoltre e possibile effettuare operazio-

ni di local data extraction (come per esempio le coordinate geografiche della

posizione attuale) oppure una estrazione piu globale su tag o parole chiave di

generiche fonti dati (terms extraction).

Figura 2.6: Schermata del framework di Yahoo! Pipes

2.4.2 Quick and Easily Done Wiki

Figura 2.7: Logo di IBM QEDWiki

Proposto da IBM [15], e un tool a supporto della creazione di mashup, che viene

eseguito all’interno del browser e che viene supportato dall’accesso all’IBM

Mashup Hub. Grazie all’hub messo a disposizione da IBM e possibile creare

data feed e widget. I mashup cosı creati, sono immediatamente visibili e vi e

la possibilita di rieditarli e condividerli subito nel Web. I mashup risultanti

sono dunque costituiti principalmente da widget basati su tecnologie come


JavaScript o PHP e i loro collegamenti ne determinano il funzionamento. La

costruzione del mashup avviene a partire da una pagina HTML che fa da

template. Su di essa vengono disposti i vari widget che sono collegati fra loro

in modo tale da “imprimergli” il comportamento finale desiderato.

Figura 2.8: Scheramata del framework di QEDWiki

2.4.3 Damia

DAMIA [26], prodotto anch’esso dall’IBM, e basato su un’interfaccia client

Web che mette a disposizione a sviluppatori e a utenti, un set di tool “easy-to-

use” per raggruppare insieme dati Web (per es., feed o RSS) con sorgenti dati

Enterprise (per esempio dati di tabelle Excel o di DataBase). Sono proprio

i benefici dell’integrazione di differenti varieta di dati a rendere DAMIA uno

strumento molto apprezzato nella creazione di mashup Enterprise. DAMIA,

in particolare, mette a disposizione le seguenti funzionalita:

� import di dati locali come fonti Excel o provenienti da database.

� import di dati XML, Atom e feed RSS provenienti dal Web.

� unione di fonti di dati Internet ed Enterprise.


� integrazione dati in modo da renderli usufruibili dai tool di mashup, che

sono in grado di presentarli tramite opportuni componenti di presenta-

zione.

Per quanto riguarda la composizione strutturale di DAMIA si evidenziano i

seguenti aspetti:

� interfaccia Web browser per l’accorpamento, la modifica e la visualizza-

zione dei dati.

� diverse funzionalita per la gestione e la composizione dei dati Web e dei

dati Enterprise.

� uno spazio Web dove immagazzinare o permettere lo sharing dei nuovi

feed creati

2.4.4 JackBe Presto

Figura 2.9: Logo di JackBe Presto

Questo tool, fornisce una piattaforma orientata alla creazione di composizioni

di servizi dedicati al mondo Enterprise [29]. Offre quindi un valido supporto

sia a sviluppatori software sia a utenti avanzati (power user). Le principali

funzionalita che si evidenziano in JackBe Presto sono:

� composizione di mashup attraverso interfacce grafiche, tool di drag-and-

drop e un linguaggio dichiarativo adatto ai mashup Enterprise.

� supporto all’Enterprise Mashup Markup Language (EMML[1]).

� accesso ai servizi Web, database SQL, fonti RSS e Web clipping.


� interfacce per collegamento ai principali tool Enterprise come Oracle

WebCenter, HP Sysnet e Excel di Microsoft.

Figura 2.10: Schermata del framework di JackBe Presto

2.4.5 Marmite

Marmite e anch’essa una piattaforma [14] che permette di ottenere come ri-

sultato un mashup. Questo tool ha come obiettivo la creazione da parte del-

l’utente finale, che non dispone di particolari capacita di programmazione, del

proprio mashup. Marmite permette di:

� accedere in modo facilitato alle API dei Web service.

� connettere le API dei Web service con semplici tecniche di combinazione

a video.

� avere uno strumento che dispone di operatori sui dati, sui flussi di dati e

sulla loro visualizzazione e rappresentazione.

2.4.6 MashArt

L’approccio di MashArt [5] si basa nell’aiutare programmatori non professio-

nali, con tecniche e astrazioni easy-to-use, a creare e gestire applicazioni Web

composite. In particolar modo MashArt fornisce le seguenti funzionalita:


� un modello unificato di componenti, capace di astrarre in componenti

UI (HTML), parti di applicazioni logiche (SOAP e servizi RESTful) e

sorgenti dati Web (feed o XML) usando un modello unificato di viste.

� un modello a composizione universale che permette a MashArt di con-

ciliare sia i bisogni di sincronizzazione di UI e sia l’orchestrazione dei

servizi.

� una piattaforma di sviluppo ed esecuzione che facilita la creazione, il

testing e il mantenimento dell’applicativo. MashArt e interamente re-

sidente nel layer server side e dunque completamente Web-based (zero

client-side coding).

2.4.7 ServFace

Figura 2.11: Logo di ServeFace

ServeFace [34] e una piattaforma a supporto della creazione di servizi model-

driven, pensata per lo sviluppo integrato di applicazioni basate su servizi.

Le interfacce utente sono create automaticamente a partire dai descrittori dei

servizi come WSDL. Per la composizione dei servizi sono possibili due approcci

differenti:

� Composizione di un servizio orientato alla presentazione (presentation-

oriented service composition), nel quale la creazione del servizio avviene

modellando graficamente l’applicativo tramite tecniche di UI.

� Composizione di servizi dedicati a specifici obiettivi (task-oriented service-

composition), che sfruttano certi modelli di interfacce grafiche per gene-


rare una nuova soluzione, creata specificatamente per una particolare

piattaforma, come per esempio gli smartphone.

2.4.8 PEUDOM

Infine, per concludere con gli ambienti di sviluppo mashup EUD, e importante

citare PEUDOM [38]. Questa proposta, per lo sviluppo di mashup, e basata

su un paradigma totalmente visuale, che cerca di astrarre il piu possibile il

processo di sviluppo da competenze tecniche. Come si evince dalla Figura

2.12, un tipico scenario di sviluppo e quello in cui l’utente ha a disposizione

una serie di componenti creati a partire da servizi e widget Web. Essi sono

quindi descritti in modo tale da esporre le proprie operazioni e parametri.

L’utente quindi, grazie alle opportune descrizioni, ha modo di sapere come

invocare correttamente i suddetti servizi senza dover programmare la logica di

invocazione delle operazioni che essi espongono.

Figura 2.12: Scenario per l’EUD di mashup in PEUDOM [21]


L’utente crea il proprio mashup tramite semplici operazioni visuali di drag-

and-drop, visualizzando immediatamente il servizio invocato tramite oppor-

tune componenti UI. Potra, a questo punto, creare legami di sincronizzazione

selezionando tra i possibili comportamenti messi a disposizione dai servizi regi-

strati. Il motore di esecuzione della piattaforma, infine, provvedera a eseguire

il mashup orchestrando la composizione.

La conoscenza di tutte queste soluzioni di tipo EUD per la creazione gui-

data di applicativi Web ci permettera di capire nel seguente capitolo (capitolo

3) come e possibile applicare queste tecniche di composizione anche in ambito

mobile, per arrivare quindi identificare un paradigma di composizione EUD di

mashup, per dispositivi mobili.

Capitolo 3

Piattaforme alternative

In questo capitolo illustreremo canali alternativi di sviluppo ed esecuzione dei

mashup, con particolare attenzione all’attuale situazione del “mondo mobile”,

alle potenzialita offerte da questi dispositivi ed ai principali paradigmi di svi-

luppo. Sara offerta infine una panoramica su alcune delle piattaforme di ultima

generazione quali i terminali Totem\Multitouch o le SmartTV.

3.1 Mobile Mashup

3.1.1 Il Web nei dispositivi mobili

L’universo “Mobile” e un ambito in continua espansione: si e evoluto a par-

tire dai primi telefoni cellulari degli anni ’80 e la sua diffusione e stata tale

da rendere normale il fatto che la maggior parte della popolazione giovane e

adulta abbia almeno un telefono cellulare. L’evoluzione dei dispositivi mobili

e guidata dagli avanzamenti nell’ambito delle infrastrutture, dei protocolli e

delle funzionalita di rete e dall’evoluzione delle tecnologie hardware e software.

Le ultime tecnologie hardware hanno permesso ai dispositivi mobili di ultima

generazione di avere a disposizione una potenza di calcolo superiore a quella

di un PC di inizio anni ’90. A differenza delle prime generazioni di dispositivi

mobili, le ultime generazioni non sono piu semplici telefoni cellulari, ma ter-

37

CAPITOLO 3. PIATTAFORME ALTERNATIVE 38

minali con certe funzionalita tipiche dei PC (per es., accesso internet, e-mail,

social network). Inoltre sono sempre piu diffusi i dispositivi tablet, in grado di

connettersi alle reti cellulari o Wi-fi per accedere a Internet.

Un recente studio [21] afferma che al giorno d’oggi l’ Internet Mobile sta

crescendo molto piu velocemente dell’Internet a livello desktop a causa della

convergenza dei seguenti trend [27]:

� connessione internet 3G

� social networking

� video streaming

� VoIP

Inoltre si sostiene che nell’arco dei prossimi cinque anni i dispositivi mobili

saranno il primo mezzo di accesso a Internet con un livello di utilizzo 10 volte

superiore rispetto a quella dei dispositivi fissi [27].

Oltre a considerare la grande evoluzione che c’e stata a livello hardware, e

importante tener conto dell’evoluzione del software per i dispositivi mobili. I

moderni sistemi operativi mobili consentono all’utente di poter installare veri

e propri applicativi software, all’interno del proprio terminale. I piu impor-

tanti player in questo ambito sono attualmente Apple e Google che, creando

rispettivamente App Store e Android Play Store, hanno messo a disposizione

degli utenti piu di un milione di applicazioni (700.000 per App Store, di cui piu

di 250.000 per iPad, e 700.000 per Android Play Store), create non solo dalle

aziende produttrici dei sistemi operativi ma anche da terze parti o da utenti

sviluppatori. Le applicazioni disponibili, per esempio dell’App Store di Apple,

sono divise su circa 20 categorie e spaziano dall’intrattenimento alla finanza,

alla medicina.


Esistono, sostanzialmente, due tipi di applicazioni: applicazioni native, realiz-

zate usando gli ambienti di sviluppo (SDK) messi a disposizione dai principali

produttori di sistemi operativi mobili, o Web App, cioe applicazioni per l’ac-

cesso a contenuti Web ottimizzate per i browser dei dispositivi mobili.

La crescente capacita degli attuali dispositivi mobili di interfacciarsi ai servizi,

calcolare dati e visualizzare risultati, unitamente alla loro capacita di rendere

piu accessibili le informazioni agli utenti finali tramite l’utilizzo di interfacce

grafiche (appositamente studiate per essere user friendly) ha reso lo sviluppo

di tali applicazioni una delle attivita chiave per programmatori e fornitori di

servizi.

Nonostante le migliorate capacita dei dispositivi mobili, il fornire l’accesso

all’informazione giusta nel momento giusto continua a essere una sfida. Poiche

i mashup sono stati concepiti con l’obiettivo di raccogliere dati da sorgenti

diverse per una fruizione piu facile e integrata, risulta di facile comprensio-

ne il loro crescente utilizzo in ambito mobile. Per esempio, la visualizzazione

di dati geo-localizzati su una mappa, cioe il mashup di servizi di mappe con

sorgenti di dati localizzati geograficamente, risulta una delle tipologie di ap-

plicazioni mobili piu utilizzate. La combinazione tra la flessibilita dei mashup

e la pervasivita dei dispositivi mobili svela infatti un mondo nuovo, quello del

Mashup Mobile, la cui potenzialita e soddisfare le necessita specifiche nascoste

nella “long tail” [19]. Non sorprende, quindi, l’ampio consenso per questo tipo

di applicazioni anche in ambito mobile, aumentando la diffusione di mashup

mobili.

D’altro canto, una delle piu grandi limitazioni nella produzione di software

per i dispositivi mobili e quella di dover attenersi alle restrizioni hardware e al-

le specifiche proprie di ogni telefonino, il che non e facile, data la grande vastita

di tipi di dispositivi e di fornitori. La varieta di linguaggi di programmazione


per ogni dispositivo hanno quindi reso ardua per lo sviluppatore software la

scelta di programmare in modo approfondito su questi dispositivi.

3.1.2 Sviluppo di applicazioni mobili per l’utente finale

Quando si parla di mashup mobili si puo fare una differenziazione tra “mobile

Web mashup”, costruiti utilizzando tecnologie Web tradizionali ed eseguiti nel

browser Web del dispositivo mobile, e “mobile mashup”, sviluppati per essere

eseguiti come applicazioni native, basate sulle tecnologie proprie del sistema

operativo del dispositivo.

Nella tabella sottostante si evidenziano le principali differenze tra i mashup

mobili nativi e i mashup Web mobili. Da questa tabella si evince come un

applicativo generico per mobile, costruito tramite interfaccia Web, presenti, a

nostro avviso, molte potenzialita.

Mashup Nativi Web Mashup

Completa esperienza dell’utenteFacilita e pochi costi di creazione

e manutenzione

Accesso completo al OS e all’HWSviluppatori liberi di usare

tecnologie e tecniche conosciute etools

Facilita di discovering, marketapp store

Facile pubblicazione, senza toolintermedi

Facilita di scale upNessuna necessita di update: e

cloud based

Supporto off-lineProcessi di revisione degli apps

store non necessari

Tabella 3.1: Principali differenze tra mashup mobili nativi e mashup mobilicreati attraverso la composizione di interfacce Web.

Nonostante l’utilita percepita, la composizione di mobile mashup da parte de-

gli utenti finali e ancora una problematica aperta. Infatti la maggior parte dei

mashup mobili esistenti non sono altro che applicazioni con una logica cablata


e non modificabile che invocano e integrano servizi diversi. La sfida principale

attuale e quella di promuovere in ambiente mobile i mashup come strumenti

per l’EUD, cioe in grado di dare la possibilita agli utenti finali di comporre

le proprie applicazioni aumentando in modo concreto e pervasivo la flessibilita

offerte all’utente-sviluppatore. Trattandosi di dispositivi mobili, quindi con ca-

ratteristiche diverse dai desktop tradizionali come la ridotta dimensione dello

schermo, la diversa modalita di interazione, e i differenti tempi di attesa fra

le richieste inviate e il tempo di ricezione della risposta, quando si parla di

EUD non e possibile pensare alle stesse modalita di composizione adottate in

ambienti desktop. Le necessita emergenti sono, quindi, quelle di fornire stru-

menti che permettano, in modo semplice e intuitivo la creazione di applicazioni

mashup native, personalizzate o personalizzabili.

Per raggiungere quest’obiettivo e possibile percorrere due strade diverse. La

prima e quella di trasferire la logica di composizione direttamente sui dispositi-

vi mobili. Tuttavia, i framework risultanti, essendo molto semplici, permettono

all’utente di definire solo delle micro-applicazioni [37] che si rivelano molto li-

mitate.

La seconda soluzione potrebbe essere quella di definire un ambiente desktop

che generi file di configurazione utilizzabili per guidare l’esecuzione di un’ap-

plicazione predefinita (“scheletro”).

Con il termine “mobile mashup” vengono dunque definite le applicazioni mobi-

li native costruite a partire dall’integrazione dei dati provenienti da differenti

servizi che possono essere remoti (per esempio disponibili nel Web), o locali

(cioe disponibile all’interno del terminale mobile). In accordo con il nostro

punto di vista, per poter rientrare nei bisogni contestuali degli utenti, le appli-

cazioni mobili finali, dovrebbero presentare anche ulteriori livelli di flessibilita:

l’integrazione e la sincronizzazione definite durante la fase di design potreb-


bero, ancora una volta, essere ridefinite dinamicamente dagli utenti, i quali

sceglierebbero “on the fly” i servizi di cui, in un dato momento, potrebbero

aver bisogno.

Indipendentemente dalla classe di mashup mobili (sopra illustrati) e dai servizi

scelti, per avvantaggiarsi del potenziale del paradigma mashup, l’utente deve

essere in grado di comporli, secondo il paradigma EUD [19, 4].

3.1.3 EUD di Mashup mobili

Ad oggi, lo sviluppo mobile end-user e ancora nella sua infanzia e presenta nuo-

ve questioni principalmente correlate alla necessita di identificare paradigmi di

composizione nuovi e modelli per l’applicazione finale che possano adattarsi

alle caratteristiche dei nuovi dispositivi mobili e al loro contesto d’uso [31]. Al-

cuni approcci, come gia anticipato, offrono ambienti di sviluppo direttamente

sul dispositivo mobile. A causa, pero, delle ben note limitazioni dei dispositivi

mobili (dimensioni schermo in primis), gli editor per dispositivi mobili ren-

dono possibile la creazione di applicazioni semplici, chiamate “micro-servizi”

(micro-services): app molto limitate sia in termini di contenuti offerti e sia in

termini di funzionalita. Per esempio il tool kit di creazione di servizi (Service

Creation Kit, SCK) [35, 32] consente agli utenti mobile di creare micro-servizi

che implementano semplici regole sulle azioni di contesto. Sulla base, quindi,

di certe regole il dispositivo compie determinate azioni, per esempio quando

un contesto selezionato e riconosciuto o si sono verificate determinate condi-

zioni definite dall’utente. In [31] vengono anche introdotti linguaggi visuali

che, ispirati dal paradigma GoogleAppInventor [12], permettono all’utente di

comporre blocchi, con funzioni o azioni che possono essere direttamente atti-

vate sul telefono. Gli approcci dei micro-service offrono, dunque, una metafora

visuale intuitiva per costruire applicazioni finali direttamente sul dispositivo

mobile. D’altro canto, data la loro semplicita, hanno lo svantaggio di non ren-

dere possibile in nessun modo la composizione di servizi remoti e API.


La piattaforma TELAR [6] fa qualche ulteriore passo in avanti, assistendo

l’utente nella costruzione dei mashup Web-based. Questi ultimi vengono de-

positati come pagine HTML, arricchiti con codice JavaScript ed eseguiti nel

browser del dispositivo mobile. TELAR in particolar modo, consente l’integra-

zione e la presentazione delle sorgenti dati con GoogleMaps. L’unica flessibilita

che presenta questo loro approccio, e il fatto che il client mashup (dunque il

Web browser mobile) sia in grado di caricare un file XML (quando la pagina

HTML che include il mashup e scaricata) contenente i parametri di configura-

zione che si riferiscono ai data provider che devono essere utilizzati. Il supporto

che offre e quindi la definizione dei parametri di configurazione che, in caso di

modifica, l’utente e costretto a cambiare, riscrivendo il codice XML e quindi

rifacendo il caricameto (upload) sul dispositivo.

Nell’articolo “A Cross-Platform Software System to Create and Deploy Mo-

bile Mashups” [22], si cerca di proporre una soluzione alla creazione di un

mashup mobile tramite un editor mashup che risiede nella macchina desktop.

L’applicazione e suddivisa in due parti: la parte di editor del mashup mobile e

il viewer-template che verra depositato sul dispositivo mobile. La piattaforma

che crea il mashup mobile e una Rich Internet Application (RIA) che viene in-

stallata sul client. Il viewer invece e stato implementato usando il framework

mobile Titanium Mobile (www.appaccelerator.com).

Figura 3.1: Mobile Mashup Editor e risultato sul corrispettivo view-template


I problemi riscontrati da questo studio sono:

� Stretto legame tra il kit di sviluppo SDK e le piattaforme dei dispositivi

mobili.

� Eterogeneita dei linguaggi di programmazione degli OS dei dispositivi

mobili.

� Assenza di un tool che agevoli la programmazione a un utente finale non

esperto.

Altra menzione va fatta, invece, nei riguardi di un applicativo che permette

di ottener da un Web mashup gia costruito un’applicazione mobile in modo

automatico senza nessuna configurazione. Si tratta di PhoneGap [28], uno

strumento di sviluppo open source, creato per fare da ponte tra le applicazioni

Web e i dispositivi mobili. Con PhoneGap e possibile scrivere un’applicazione

mobile sfruttando HTML, JavaScript e CSS, ma anche utilizzare le principa-

li risorse del dispositivo, quali file system, fotocamera, accelerometro, gps o

multitouch. In Figura 3.2 si puo vedere il flusso di attivita necessarie alla

generazione delle applicazioni mobili.

Figura 3.2: Generazione delle applicazioni mobili con PhoneGap

PhoneGap si rivela utile nel momento in cui non si vuole codificare nulla per

ottenere il viewer dell’applicazione, dato che per poter visualizzare il mashup

sul terminale e necessario semplicemente disporre di un browser, presente nei

comuni smartphone. D’altro canto uno degli svantaggi principali di questo tipo

di soluzione e che le applicazioni ibride non hanno l’accesso completo alle API

del dispositivo mobile e quindi rimangono limitate all’uso esclusivo di servizi

Web.


Un approccio interessante e riportato nell’articolo [18] in cui viene presentata

una piattaforma per la composizione di mashup nella quale gli utenti possono

configurare, attraverso un paradigma basato sui form (form-based paradigm),

alcune parametrizzazioni sulle query di invocazione dei servizi. Il limite di

questo approccio e dato dal fatto che l’integrazione dei servizi e possibile sol-

tanto tra quelli selezionati e la rappresentazione solo su determinate zone della

mappa. In tal modo l’approccio e orientato esclusivamente alla costruzione di

mashup per l’accesso a servizi basati su zone pre-determinate (zone-based).

Nell’articolo [30], gli autori illustrano un ambiente desktop (Figura 3.3) che, in

linea con la nostra prospettiva di sviluppo di applicativi di mashup orientati

all’utente (user-centric), genera automaticamente il codice per l’applicazione.

Figura 3.3: Schermata e workflow di ogni tool di composizione [30]

Tramite un linguaggio di composizione ad-hoc (MAIDL), sono dunque in grado

di comporre la descrizione dell’interfaccia dell’applicazione. Questo approccio,

basato sul paradigma publish-subscribe per la sincronizzazione dei servizi, si

richiama ai tradizionali modelli gia adottati dai Web mashup [9, 4], adottato

anche da noi per la sincronizzazione dei servizi. La suddetta piattaforma ha

lo scopo di velocizzare la prototipizzazione. Il vero punto debole del loro pa-


radigma di composizione, secondo il nostro punto di vista, e l’elevato tempo

di creazione impiegato da un utente esperto nella composizione (in media 51

minuti per 3 servizi).

La nostra validazione user-based, di cui si parlera nel capitolo 7, dimostrera

che gli utenti finali possono avere prestazioni (performance) di creazione mi-

gliori se hanno a disposizione differenti livelli di astrazione, dato che saranno

in grado di creare composizioni con lo stesso numero di servizi in poco tempo

(circa 8/9 minuti). Inoltre, anche se il loro approccio permette l’estrazione di

contenuti da documenti Web, non offre nessun supporto all’integrazione dati.

3.2 Altre Piattaforme

Anche se l’insieme dei personal computer e l’universo dei dispositivi mobile, dal

semplice cellulare ad i tablet-pc, rappresentano la maggior parte dei supporti

utilizzati dagli utenti per eseguire le proprie applicazioni basate su mashup,

esistono altre piattaforme che consentono l’utilizzo di applicazioni di questo

tipo. Tra i vari esempi a disposizione abbiamo scelto di analizzare le due

seguenti tipologie di canali poiche riteniamo siano piu promettenti nell’ambito

dell’attuale ricerca e di maggiore impatto sugli utenti finali.

3.2.1 Multitouch

La tecnologia Multitouch, naturale evoluzione di un comune schermo tattile,

costituisce un settore di grande interesse per la ricerca nell’ambito dell’intera-

zione uomo-macchina. Uno schermo tattile multi-tocco si differenzia dai suoi

predecessori per la sua sensibilita al tocco, localizzata contemporaneamente in

piu punti della superficie interessata. I multitouch combinano una parte hard-

ware, formata da uno schermo o un pad tattile che riconosce in simultanea piu

di un punto toccato da una mano, al software che riconosce ed interpreta tali

punti. Le potenzialita offerte da questa tecnologia ampliano notevolmente il


paradigma di interazione con l’utente, abilitato fin da subito all’utilizzo del di-

spositivo tramite un’intuitiva gestualita. In base alla grandezza degli schermi

ed alla capacita di elaborazione, i dispositivi multitocco possono supportare

piu di un utente per volta sulla medesima superficie.

L’utilizzo di mashup all’interno di una piattaforma multitouch appare quin-

di di grande utilita. La combinazione di una interazione utente immediata,

cosı come e offerta dalla piattaforma multitocco, con la naturale semplicita

di una applicazione di tipo mashup consente di costruire e sfruttare in tempi

rapidi ambienti interattivi di facile utilizzo, generando al contempo nuove pos-

sibilita di sinergia tra i paradigmi software oggetto della ricerca informatica e

le tecnologie hardware che le supportano ed abilitano.

Figura 3.4: Dispositivo Multitouch

Il principale campo di applicazione degli schermi multitocco e senza dubbio il

settore dell’educazione. In questo ambito la semplicita di accesso alle perife-

riche di input assume importanza primaria a causa della esperienza minima

richiesta agli utenti, in genere bambini o ragazzi con scarse conoscenze tecni-

che. Concentrando interamente nell’unico oggetto dello schermo tutti gli input

necessari al proprio funzionamento, la tecnologia multitocco si presenta come


strumento efficace e di sempre maggiore applicazione. E’ comunque interes-

sante notare come alcuni utilizzi di tali tecnologie abbiano esteso il campo di

utilizzo anche a fasce d’eta piu elevate, soprattutto tramite la combinazione

di servizi che forniscono dati georeferenziati con fonti di immagini fotografi-

che. Ne e un valido esempio la campagna di informazione e sensibilizzazione

intrapresa dalla Ideum in seguito al disastro ecologico della BP Oil del 2010,

fornendo ad organizzazioni educative come centri scientifici ed acquati alcune

piattaforme multitouch sulle quali erano eseguiti web mashup con fusione dati

tra Flickr e Google Maps [16] .

3.2.2 Smart TV

Si definiscono Smart TV i dispositivi che rientrano nella categoria di appa-

recchiature elettroniche di consumo che abbiano come principale caratteristica

l’integrazione di funzioni e di servizi legati a internet, e in particolare al co-

siddetto Web 2.0, all’interno di apparecchi televisivi. Piu in generale si fanno

rientrare in questa categoria tutti i prodotti del filone di convergenza tecnolo-

gica tra il mondo dei personal computer e quello della televisione.

Il collegamento alla rete rende possibile per questi dispositivi offrire l’usufrut-

to di servizi online tipicamente destinati a normali personal computer quali

navigazione internet, video on demand, Internet TV, servizi in streaming o

social network. Essendo sviluppate sulla base di una serie di caratteristiche di

interattivita proprie degli apparecchi televisivi e dei dispositivi ad essi collega-

ti immessi sul mercato dopo l’avvento del digitale terrestre e della televisione

satellitare, le Smart TV integrano e potenziano tali caratteristiche passando

di fatto da un televisore “a senso unico” ad una vera e propria postazione

multimediale con ampio sfruttamento dei vantaggi della rete.


Figura 3.5: SmartTv

Le principali Smart TV attualmente in commercio lavorano con sistemi opera-

tivi basati su kernel Unix, quando non direttamente operanti tramite Android

o sistemi similari. Ciascuna di queste piattaforme software mette a disposi-

zione un ambiente di sviluppo nativo tramite le librerie fornite dalle rispettive

SDK, con applicazioni implementabili generalmente tramite Java, Javascript

o vari derivati del linguaggio C. Anche grazie all’utilizzo di linguaggi facilmen-

te adattabili all’ambiente Web e possibile pensare all’integrazione nelle Smart

TV di applicazioni basate su mashup. In questa ottica i normali strumenti

di input a disposizione dell’utente vedrebbero ampliarsi il proprio orizzonte di

utilizzo, e le applicazioni stesse beneficerebbero di un insieme di utenti molto

ampio proprio in virtu della diffusione capillare del mezzo televisivo.

Parte III

Modelli e Architetture

50

Capitolo 4

Modelli di riferimento

Questo capitolo offre una panoramica dei modelli che sono alla base del para-

digma di composizione e di esecuzione dei mashup di ViTe. Vengono introdotte

le astrazioni tramite cui gli utenti finali, per mezzo di azioni visuali, collegano

i dati sulla base di uno scheletro predisposto (il visual template) costruendo

viste unificate con i dati estratti da piu sorgenti e predisponendo il loro accesso

per il momento dell’esecuzione.

4.1 Approccio

L’integrazione e la sincronizzazione di servizi all’interno dei mashup puo essere

attuata a diversi livelli [10]. Lavori precedenti, particolarmente la piattaforma

MobiMash, hanno affrontato l’integrazione dei dati sulla base di template vi-

suali nel contesto mobile. In tale ambiente tuttavia il livello di presentazione

deve sottostare a regole intrinseche di semplicita ed immediatezza. Le relative

capacita di elaborazione dei dispositivi mobili unitamente alle ridotte dimen-

sioni dei loro schermi rendono necessaria la confluenza dei dati integrati in un

modello visivo che sia concepito appositamente per l’ambiente mobile, sfrut-

tandone al meglio le caratteristiche peculiari senza compromettere l’esperienza

dell’utente.

51

CAPITOLO 4. MODELLI DI RIFERIMENTO 52

Proprio per far fronte a questo insieme di presupposti e nata la piattaforma Vi-

Te (Visual Template Editor), oggetto di questa tesi, il cui obiettivo principale e

semplificare la creazione di mashup tramite una logica di composizione visuale

basata su un set prefissato di template. Infatti, tramite questo ambiente e pos-

sibile integrare sorgenti dati operanti tramite servizi REST (Representational

state transfer) che restituiscano i propri risultati in formato XML o JSON,

anche se la struttura dell’applicazione, come vedremo piu avanti, facilita l’ag-

giunta di nuovi protocolli di comunicazione qualora se ne rendesse necessaria la

presenza per una maggiore flessibilita dell’applicativo. E’ importante ricordare

comunque che, allo stato attuale, la combinazione degli standard XML\JSON

rappresenta una percentuale dominante nell’universo dei servizi web.

Le sorgenti dati usufruibili nelle composizioni devono essere registrate specifi-

candone l’URI di base, indirizzo primario del servizio, e ciascuna delle query

utilizzabili, identificate dalle loro coppie <nome, valore>.

Dovendo consentire l’interazione a runtime di un qualsiasi servizio che sia stato

correttamente registrato e che risponda ai requisiti descritti precedentemente

e necessario uno strato di astrazione che si interponga tra essi ed i componenti

visuali del template, fungendo da adattatore. Tale componente, il wrapper,

permette di invocare correttamente i servizi durante l’esecuzione della compo-

sizione.

La piattaforma ViTe si compone di un Design Environment (DE) unificato

(ossia presente allo stato delle cose come unico applicativo adibito alla costru-

zione delle composizioni ViTe) e di un corrispettivo Execution Environment

(EE). In Figura 4.1 se ne mostra l’architettura ad alto livello. Il DE e un’appli-

cazione Web che permette agli utenti di comporre mashup visuali, in ambiente

desktop, attraverso il completamento di template predefiniti (visual template)

con semplici operazioni di drag-and-drop. Sulla base delle azioni e delle scelte


dell’utente il DE genera un descrittore codificato in linguaggio XML che rac-

chiude tutte le caratteristiche della composizione generata. Tale documento

viene salvato su un database lato server (Database ServerSide) che contiene

tutte le composizioni create dagli utenti. L’architettura del sistema e pensata

per consentire ad un qualsiasi modello di Execution Environment la compren-

sione dell’XML salvato e l’esecuzione della composizione in esso descritta. In

questo modo una composizione salvata diventa portabile su qualsiasi piattafor-

ma per la quale sia stato approntato un adeguato EE. Per rendere usufruibile

direttamente il prodotto della composizione agli utenti finali, in questa tesi e

stato predisposto un ambiente EE di tipo Web analogo all’ambiente di design.

Esso permette l’autenticazione dell’utente presso il server ed il caricamento

delle composizioni dei mashup precedentemente create. L’EE, sulla base dello

schema d’applicazione caricato, e in grado di generare il layer di presentazio-

ne dei dati, di invocare autonomamente le sorgenti (Remote Data Sources) e

di gestire le azioni sui componenti UI permettendo all’utente di eseguire le

operazioni pensate per quel tipo di EE, proprie del dispositivo in uso.

Figura 4.1: Architettura della piattaforma ViTe


4.2 I visual template

I template visuali sono gli ingredienti fondamentali di questo approccio imple-

mentativodi composizione. Essi offrono una rappresentazione immediata del

modo in cui i dati saranno mostrati nell’applicazione finale. Come illustreremo

successivamente in questo capitolo, il completamento dei template visuali at-

traverso l’associazione di elementi dello schema dei dati abilita un paradigma

di “integration-by-example”, attraverso il quale gli utenti possono selezionare i

dati d’interesse dalle sorgenti ed ottenerne subito la rappresentazione visuale,

provvedendo se necessario ad immettere dati propri nell’applicazione qualora

il template in questione lo consenta.

La struttura dei visual template deriva dall’osservazione delle piu comuni ap-

plicazioni basate sui contenuti (content-based), con un particolare riguardo al

mondo dei dispositivi mobile. Pur non essendo vincolata a tale ambito, ricor-

diamo che la piattaforma ViTe produce composizioni eseguibili all’interno di

Execution Environment distribuiti su differenti categorie di dispositivi. Tali

template sono generalmente organizzati secondo poche varianti di un pattern

ricorrente. Il modello principale utilizza due differenti layer di presentazione.

La vista primaria visualizza tutti i dati recuperati, come una lista di eventi

o prodotti o un insieme di location su una mappa, dove ciascuna istanza puo

essere rappresentata da una terna titolo\sottotitolo\immagine, o nel caso della

mappa, un insieme di POI (Point Of Interest). La vista secondaria si occupa

in genere di mostrare i dettagli dell’istanza selezionata.

Formalizzando il concetto di template visuali, a prescindere dalla loro con-

creta visualizzazione (sia essa basata su lista o mappa), ciascuno di essi puo

essere visto come una tupla VT =<vr1,vr2,...,vrn>, dove ogni vrk rappresen-

ta un renderer visuale utilizzato per la visualizzazione di un dato estratto da

una delle sorgenti selezionate dall’utente. Ciascun template visuale puo esse-

re decomposto in due sub-template, rappresentanti l’organizzazione delle due


differenti “viste” nell’applicazione finale:

� union sub-template (uvrk), mostra gli attributi dati che rappresentano in

modo conciso le istanze recuperate interrogando i servizi coinvolti

� merge sub-template (mvrk), mostra i dettagli di un’istanza di dati sele-

zionata nell’union sub-template.

Mentre l’union sub-template ha un’organizzazione fissa, la struttura del merge-

template e generalmente definita a posteriori, durante la composizione del ma-

shup, quando l’utente aggiunge gli elementi alla vista secondaria perche siano

visualizzati come dettaglio di alcuni o tutti gli item presenti nell’union sub-

template.

In accordo a questa struttura possono essere definite alcune tipologie base

di template visuali:

� List : gli item recuperati dai servizi sono organizzati in una semplice

lista. Tale organizzazione si adatta bene ad un ambiente mobile in cui

gli spazi ristretti della grafica portano a prediligere strutture semplici e

spartane. Un esempio pratico di utilizzo di tale template visuale puo

essere la piattaforma MobiMash: l’union sub-template (in Figura 4.2, a

sinistra) corrisponde in tale piattaforma ad una lista dove ciascun ele-

mento e rappresentato attraverso un segnaposto per un’immagine e due

campi con i label “title” e “subtitle”; il merge sub-template (in Figura 4.2,

a destra) consiste dunque in un numero arbitrario di immagini e campi

testuali con lo scopo di mostrare i dettagli di un elemento selezionato

nello screen precedente.


Figura 4.2: List-template, dettaglio del union sub-template (a) e merge sub-template (b)

� Slider : pensato principalmente per creare e navigare gallerie di immagi-

ni, consiste in un pattern di navigazione guidata (in Figura 4.3 un esem-

pio implementato da una libreria jQuery) tramite un union sub-template

in cui ogni item e rappresentato da un’immagine a schermo pieno insieme

a un campo titolo e uno sottotitolo. La selezione di un elemento dello

slider conduce poi alla vista secondaria, il merge sub-template, dove ven-

gono mostrati all’utente ulteriori dati sull’elemento selezionato.

Figura 4.3: Slider-template, esempio di utilizzo


� Charts: questo visual template raccoglie un insieme molto ampio di vi-

sualizzazioni, comprendendo modelli standard di organizzazzione di dati

come grafici a barre, a torta o modelli piu recenti come le tagclouds. Cia-

scuno di questi modelli puo avere differenti implementazioni delle proprie

viste. Una possibile vista primaria potrebbe essere il grafico complessivo,

con una vista secondaria che raccolga i dettagli dei singoli dati presenti.

Un interessante esempio di utilizzo e il componente Charts della piatta-

forma Peudom.

Figura 4.4: Charts-template nella piattaforma Peudom

� Map: consente l’utilizzo delle informazioni di georeferenziazione dei da-

ti. Ogni istanza recuperata e rappresentata come un punto di interesse

nell’union sub-template (in Figura 4.5, a sinistra), ed associata ad un

indicatore sulla mappa (marker) che ne rappresenta la posizione geo-

grafica. Il merge sub-template (in Figura 4.5, a destra) consiste in un

insieme di visual renderer che vengono organizzati dall’utente sulla base

dei dati recuperati dai servizi e che sono visualizzati tramite una casella

di dettaglio (balloon) associata al marker.


Figura 4.5: Map-template, dettaglio degli union (sinistra) e merge (destra)sub-templates

4.3 Il paradigma di composizione

Il paradigma di composizione visuale dell’editor si basa su due tipi di azioni da

parte dell’utente. La principale tipologia di interazione avviene tramite opera-

zioni di drag-and-drop studiate per essere il piu possibile semplici ed intuitive.

Tramite tali azioni l’utente puo integrare i dati dei servizi interrogati e definire

la struttura che tali dati assumeranno nella composizione finale. La seconda

tipologia e un intervento diretto dell’utente per modificare alcune caratteri-

stiche dei dati inseriti o per aggiungerne di nuovi senza utilizzare le sorgenti

predefinite.


L’ambiente grafico alla base del DE consiste di due pannelli principali

(Figura 4.6):

� Data-Panel, sul lato sinistro, che mostra i dati richiesti ai servizi selezio-

nati e precedentemente registrati.

� Visual-Panel, sul lato destro, che mostra il template visuale. Pur essendo

in una versione leggera e studiata specificamente per il DE, tale template

rispecchia l’aspetto che avra l’applicazione finale al momento della sua

esecuzione.

L’azione di drag and drop si concretizza nel prelevamento dal data-panel dei

dati d’interesse ed il loro collocamento tramite gesti semplici ed immediati sul

visual-panel. Il gestore della vista aggiornera dunque in tempo reale la pre-

view in base alle informazioni che l’utente ha implicitamente fornito con la sua

azione di trascinamento. L’utente, in fase di drag, puo selezionare qualsiasi

elemento presente nell’albero eccetto l’istanza del dato. Infatti, attraverso l’a-

zione di trascinamento, esso definisce quale elemento dello schema dati debba

essere associato a un elemento del visual-template.

Nell’esempio in Figura 4.6 l’utente associa il tag“venue address”nel data panel

al campo “location” del visual-panel che attualmente mostra lo screen mappa.

Sempre in Figura 4.6 l’associazione effettuata e tra il tag “title” e il campo

“detail” dello screen dettaglio. L’insieme di tutte queste azioni si traduce in

una operazione implicita di schema-mapping visuale. Gli schemi di ciascuna

sorgente dati vengono mappati sui campi di un visual template che rappresenta

un integration-schema, ovvero lo schema globale di tutte le sorgenti selezionate

per la composizione.

Quando l’associazione di ciascuna coppia, elemento schema ed elemento del

visual template, e completata, immediatamente il visual-renderer dispone di

tutte le informazioni necessarie per istanziare nel visual-template tutti i da-

ti che compongono lo screen mappa. Nel momento in cui l’utente rilascia il


campo “venue address” dell’evento (operazione di drop) sul campo “location”

del template, la vista della preview si popola di dati, ovvero di tanti marker

quanti sono gli eventi elencati nella risposta della sorgente dati che abbiano un

campo d’indirizzo valido.

Figura 4.6: Schermata del visual front-end del DE e paradigma di composizionevisuale drag-and-drop

Per quanto riguarda il template Mappa, il meccanismo subisce una netta dif-

ferenziazione a seconda che l’aggiunta di marker sia impostata su automatica

o su customizzata. Nel primo caso il popolamento avviene sulla base di una

singola azione dell’utente, il quale non deve trascinare ciascuna istanza per po-

polare la preview ma effettua solamente il drop di un elemento dello schema,

ed e la piattaforma a completare per lui in modo dinamico le operazioni di ag-

giunta. La natura iterativa presente nello schema dati delle sorgenti permette

infatti il recupero delle diverse istanze attraverso delle query XPath, definite

implicitamente dall’utente in fase di drag.


Nel caso di aggiunta customizzata, il dragging di dati nella vista primaria

comporta l’aggiunta di un marker corrispondente alla sola istanza interessata

dal trascinamento. Questo consente all’utente di aggiungere alla popolazione

dei marker punti di interesse personalizzati ed inserirvi dettagli che non siano

necessariamente vincolati alla sorgente. E’ possibile infatti integrare nel mede-

simo baloon informativo dettagli catturati da diversi item della stessa sorgente

o da item di sorgenti differenti.

Oltre alle azioni di drag and drop, l’utente puo interagire con la piattaforma

tramite inserimento diretto di dati personalizzati. Nel template mappa l’utente

puo aggiungere marker customizzabili tramite la scrittura negli appositi campi

della loro location o della coppia (latitude,longitude) ed eventualmente inserire

tra i dettagli di un marker custom dati personali specificandone manualmente

il nome del campo ed il contenuto.

4.4 Lo schema dell’applicazione

Sulla base delle azioni visuali di data-integration, il Design Environment (DE)

genera e salva sul server della piattaforma la configurazione che contiene le

regole per la generazione automatica dell’applicazione da eseguire. Il file di

configurazione, in formato XML, rappresenta lo schema di funzionamento del-

l’intera applicazione ed e dunque utilizzabile sia per avviarne l’esecuzione che

per caricare una composizione salvata all’interno del Design Environment e

provvedere al suo aggiornamento o alla sua modifica.

Per comprendere la logica di scrittura di questo file XML e bene procedere

ad una analisi delle sue varie parti. Si osservi il seguente frammento di codice,

generato ai fini dell’esposizione utilizzando una composizione creata sul visual

template Map.


Figura 4.7: Esempio Config.xml (1)

La prima sezione del file di configurazione, subito dopo il nome dell’appli-

cazione salvata, riporta tutte le informazioni necessarie alla piattaforma per

rintracciare ed interrogare correttamente i vari servizi aggiunti dall’utente alla

composizione. Per ciascun servizio (in questo esempio Eventful ed Upcoming)

deve essere specificato un URL di base e seguentemente tutte le query che

l’utente vi ha effettuato, composte dai nomi dei parametri utilizzati, dalle loro

tipologie e dai loro valori.



In questo secondo frammento e descritta la sezione “mapping”, che specifica il

template visuale in uso e le regole di composizione che l’utente ha utilizzato

per generare la propria applicazione.

Il primo blocco di codice, che identifica l’union sub-template, e composto dai

visual renderer (“vr”) della vista primaria (nel caso della mappa: Location,

Latitude e Longitude), specificando quali servizi forniscano a questi visual ren-

derer i dati da incapsulare nel template e, per ciascuno di essi, il nome della

query che recupera tali dati e l’indirizzo xpath necessario a catturarne le istan-

ze all’interno della risposta che i servizi interrogati da queste query avranno

inviato.

Il secondo blocco identifica il merge sub-template, corrispondente alla vista

secondaria del template visuale. I visual renderer qui contenuti sono opzionali

ed in numero variabile: e l’utente a scegliere infatti al momento del design

quali dati dei servizi vadano utilizzati come dettagli degli item della vista pri-

maria. Anche in questi visual renderer e specificata la query di riferimento e

l’indirizzo xpath del dato da catturare.


L’ultima parte del documento XML descrive e raccoglie i dati che l’utente


ha inserito manualmente come ulteriore personalizzazione della composizio-

ne. Nell’esempio fornito, basato sul template Map, tali dati sono costituiti

da punti di interesse customizzati (i marker statici) che l’utente ha impostato

sulla mappa e che sono dunque, da quel momento, slegati dalle risposte dei

servizi interrogati. La struttura della sezione “custom” rispecchia quella del-

la sezione “mapping”, essendo anch’essa divisa in una vista primaria ed una

secondaria, rispettivamente chiamata cunion e cmerge. A differenza della se-

zione precedente, pero, tali viste sono incluse in ciascun item che l’utente ha

inserito manualmente, consentendo cosı di personalizzare in modo elastico la

visualizzazione ed il contenuto di ogni punto di interesse customizzato.

4.5 L’integrazione di sorgenti dati

Avendo a disposizione un insieme di sorgenti dati registrate e un visual tem-

plate tra quelli disponibili nella piattaforma, l’utente costruisce il livello di

presentazione e implicitamente vi integra i dati (data source integration) dopo

avere selezionato una o piu sorgenti dati disponibili tra quelle precedentemen-

te inserite. Nel caso in cui l’utente volesse costruire un mashup estraendo

informazioni da differenti sorgenti dati, viene avviato un processo di data-

integration. Le azioni dell’utente sono mirate alla costruzione di una vista

unificata di dati (unified data view). L’approccio e composto da fasi che sono

simili a quelle tipiche dei processi tradizionali di data integration. Per suppor-

tare maggiormente gli utenti finali, a seconda del visual template in uso, alcune

fasi dell’integrazione vengono svolte automaticamente dal Design Environment.

Il processo di data integration, come mostrato in figura 4.10, inizia con una

fase di campionamento dei dati delle sorgenti (source data sampling), nella

quale ogni sorgente dati e selezionata e interrogata in base ai parametri e i

setting definiti in fase di registrazione del servizio. L’insieme dati risultante

e visualizzato nel data-panel dell’editor, tramite una rappresentazione auto-


matica degli item “attributo-valore”. L’utente seleziona il tipo di template

visuale come base della visualizzazione dei dati ricevuti dai servizi scelti, de-

finendo implicitamente uno schema globale (global schema) d’integrazione. Il

template fornisce infatti accesso uniforme all’insieme dei dati fornendone una

rappresentazione.

Figura 4.10: Processo di integrazione dati

Nella data integration, una questione fondamentale e la relazione tra schema

globale di integrazione e gli schemi locali delle sorgenti (source local schema).

Nell’approccio ViTe tale risultato e ottenuto tramite la mappatura visuale (vi-

sual mapping), attraverso la quale l’utente associa i campi estratti dai dati dei

servizi e visualizzati nel data panel, agli elementi del template visuale (visual

renderers).

In modo piu formale, consideriamo l’insieme delle sorgenti dati S = {s1, ..., sj}selezionate dall’utente per l’integrazione nel mashup. L’associazione di alcuni

attributi dei dati del servizio si con gli elementi del template visuale corrispon-

de alla funzione specifica di mapping M(si.h)→ vrk. L’insieme di tutti i campi

si.h che sono associati con i visual renderer che compongono lo schema visuale,

ls(si), cioe la riduzione dello schema delle sorgenti dati, e usata a runtime per


la creazione della vista unificata. Come precedentemente descritto, il template

visuale in ViTe e generalmente composto da due sotto-template. Dunque lo

schema locale puo essere visto come diviso in due parti:

� una riduzione dello schema del servizio rispetto al sub-template di unione,

uls(si) nel quale ogni attributo dei dati e mappato sul visual renderer di

questo sub-template di unione: ∀si.h ∈ uls(si) : si.h→ uvrk

� una riduzione dello schema dati del servizio rispetto al sub-template di

merge, mls(si), nel quale ogni attributo dei dati e mappato sul visual

renderer contenuto nel sub-template di merge: ∀si.h ∈ mls(si) : si.h →mvrk

E’ importante far notare che, essendo i visual templates il cuore concettuale

della piattaforma ViTe, la mappatura dei dati sui loro schemi di visualizzazione

puo avvenire in maniera radicalmente diversa. In alcuni casi, come nel template

List, sono state applicate politiche di integrazione automatica per collegare tra

loro in modo trasparente dati che, pur provenendo da sorgenti differenti, si

riferiscono al medesimo item. Pertanto una post-elaborazione di questi dati

ricalibra la visualizzazione della vista secondaria (merge sub-template) tramite

algoritmi di data fusion e duplicate detection offrendo all’utente una miglior

gestione della composizione creata.

Capitolo 5

Architettura della piattaforma

ViTe

In questo capitolo verra illustrata l’architettura dell’intera piattaforma ViTe,

per lo sviluppo di mashup basati su template visuali. Verranno pertanto pre-

sentate le due componenti del sistema, sommariamente descritte in precedenza:

il Design Environment (DE) e l’Execution Environment (EE), e ne verranno

messe in risalto le principali peculiarita.

5.1 Il Design Environment

La scelta di adottare un ambiente di sviluppo desktop basato sul Web e dovuta

alle maggiori potenzialita che tale ambiente concede. Il design di un mashup

da parte degli utenti, specie se poco esperti, e un’operazione complessa che

l’approccio visuale semplifica soltanto in maniera limitata. Per questa ragione

e consigliabile consentire la maggior completezza e facilita di utilizzo possibi-

le a chi si cimenta in questo genere di attivita. Un ambiente web dinamico,

pur garantendo la portabilita dell’applicazione di design su qualsiasi disposi-

tivo munito di un browser con supporto script (Javascript nel caso di ViTe)

esprime il massimo delle proprie potenzialita quando viene eseguito su un per-

sonal computer grazie alla sua maggiore capacita di calcolo e, generalmente,

67

CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 68

dalla possibilita di usufruire di schermi piu grandi. Le composizioni prodot-

te dall’ambiente potranno essere quindi piu articolate e di qualita nettamente

superiore alle loro controparti costruite su altri dispositivi.

La corrente implementazione dell’architettura del Design Environment di ViTe

consiste in un modulo client-side con un motore principale (runtime environ-

ment) che permette la composizione dei mashup. La scelta di un approccio

client-side e dovuta alla necessita di mantenere la soluzione semplice, soprat-

tutto dal punto di vista del deploy della piattaforma stessa. Tale approccio

semplifica enormemente l’utilizzo della piattaforma rendendolo accessibile via

internet da qualsiasi punto del globo senza necessita di installazioni preventive.

La scelta naturale della tecnologia per l’implementazione del runtime environ-

ment e stata HTML/JavaScript. Per la gestione dell’interazione dell’utente col

front-end si e fatto ampio uso delle librerie open source JavaScript jQueryUI

[17], poiche forniscono funzioni di interazione ed animazione avanzate e perso-

nalizzabili.

Tale tecnologia non e pero sufficiente a garantire ed abilitare molte delle fun-

zioni principali del sistema come la registrazione dei servizi, il salvataggio e

l’accesso multiutente. Per semplificare l’architettura client-side e permette-

re l’utilizzo di tali funzioni e stato necessario implementare anche una logica

server-side. La logica server-side e stata realizza in Java attraverso l’utilizzo

di pagine Java Server Pages (JSP) e Java Servlet. La piattaforma scelta per

l’esecuzione della applicazione Web che implementa queste specifiche e Apache

Tomcat, un contenitore servlet open source sviluppato da Apache Software

Foundation. La sua distribuzione standard include anche le funzionalita di

Web server tradizionale (che corrispondono al prodotto Apache) abilitando

cosı appieno la gestione della comunicazione col client. Per quanto concerne

invece la gestione della banca dati, che mantiene le informazioni su utenti,

composizioni e sorgenti dati, si e fatto utilizzo di un database server MySql


gestito dalla logica di back-end della piattaforma. Conseguentemente, le pa-

gine della piattaforma che permettono il login e la registrazione dell’utente,

corrispondenti alle prime pagine incontrate dall’utente durante la navigazione,

sono state realizzate con tecnologia JSP.

Il cuore dell’ambiente di design, ovvero il visual front-end in Figura 5.1, con-

siste invece in un’unica pagina JSP contenente tutto il runtime environment.

L’interazione del runtime environment col server della piattaforma si basa su

uno scambio di dati in background, strutturati in documenti XML, che con-

sente l’aggiornamento dinamico della pagina Web dell’editor senza esplicito

ricaricamento della stessa. In questo modo il server e impegnato solamente

in attivita utili e necessarie, mentre tutto il carico del lavoro durante la com-

posizione del mashup e gestito dal client. Una interazione piu pesante con il

server, con conseguente ricaricamento della pagina JSP, e richiesto soltanto

durante l’operazione di switch tra template differenti. In questo senso si puo

dire che il runtime environment stesso sia mono-template, istanziato su uno

dei template disponibili ogni volta che l’utente sceglie di usufruire di uno di essi.

La Figura 5.1 descrive l’architettura globale del Design Environment e pre-

senta i principali moduli che la compongono, sia client-side che server-side, ed

e formata da due componenti:

� il runtime-environment, ovvero l’applicativo client-side JavaScript che si

interfaccia col front-end;

� il configuration-server, ovvero il server di back-end. Implementa le fun-

zionalita richieste dal runtime environment, accedendo ai dati presenti

nel DB server. Esso non offre servizi solamente al Design Environment,

ma anche all’Execution Environment web-based qualora un dispositivo

ne richiedesse l’utilizzo.


Figura 5.1: Architettura del Design Environment (DE)

5.1.1 1 Il visual front-end

L’ ambiente grafico (Figura 5.2) alla base del DE consiste in due pannelli

principali:

� data-panel, sul lato sinistro, che mostra i dati richiesti ai servizi selezio-

nati e precedentemente registrati.

� visual-panel, sul lato destro, che mostra il template visuale in uso, con

una preview che mostra come apparira l’applicazione al momento dell’e-

secuzione.


Figura 5.2: Visual front-end del Design Environment (DE)

Appena i dati presenti nel data-panel sono associati attraverso azioni di drag-

and-drop, il pannello visuale e aggiornato con una preview dell’effetto dell’as-

sociazione realizzata. Cio facilita notevolmente la composizione permettendo

all’utente di avere sempre sotto controllo il risultato finale e di apportare le

modifiche necessarie in caso non sia soddisfatto di quanto realizzato.

Oltre alla preview, all’interno del visual panel vi sono altri componenti fon-

damentali, strumenti indispensabili per la creazione della composizione. Tali

componenti sono:

� pannello di navigazione, generalmente posto al di sotto della casella di

preview, consente all’utente di muoversi fra le differenti viste e selezionare

le opzioni di composizione desiderate.

� pannello di inserimento, posto invece in genere al di sopra della pre-

view, e composto dalle varie caselle di dropping in cui l’utente trascina i

dati dal data panel. Tale pannello non e quindi statico ma viene aggior-

nato in base alle scelte che l’utente compie sul pannello di navigazione


o a eventuali interazioni dirette dell’utente sulla preview. Nel caso in

cui il template in uso consenta all’utente l’inserimento manuale di dati,

l’inserimento avviene all’interno di tale pannello.

Lo sviluppatore dispone inoltre di un menu in testa ai panelli di lavoro che

offre ulteriori funzionalita. Esso e strutturato in due sezioni:

� shortcut-menu, costituito da bottoni di dimensioni consistenti che rap-

presentano punti d’accesso veloci alle funzionalita di registrazione delle

sorgenti dati nel repository offerto dalla piattaforma, di selezione del-

le sorgenti dati necessarie alla composizione del mashup, al salvatag-

gio della composizione e all’esecuzione della stessa tramite l’apertura

dell’Execution Environment.

� main-menu, e il menu dedicato alle informazioni utente e al cambiamento

del template in uso. Permette inoltre il logout dalla sessione di lavoro.

5.1.1.1 Il data panel

Il data panel e il pannello dell’editor (in Figura 5.2 a sinistra) adibito a conte-

nere la rappresentazione dei dati provenienti dalle sorgenti selezionate dall’u-

tente durante la composizione. La risposte XML o Json dei servizi, interrogati

automaticamente dal sistema dopo la scelta dell’utente, vengono elaborate e

rappresentate in forma visuale. Il pannello e strutturato in modo tale da mo-

strare le risposte di piu servizi contemporaneamente grazie ad un menu a tab

che permette di navigare agevolmente tra le risposte delle differenti sorgenti se-

lezionando quella da utilizzare a seconda delle esigenze del momento. La scelta

della rappresentazione visuale, pur essendo strutturata concettualmente sotto

forma di albero, si e pero concentrata su una visualizzazione ad insiemi, nella

quale cioe ogni elemento corrispondente ad un tag XML viene rappresentato

come un insieme di forma rettangolare-ellissoidale. All’interno di tale insieme

sono contenuti eventuali nodi figli, rappresentati come sottoinsiemi, e le istanze

dati corrispondenti. La scelta di una architettura visuale basata su albero e


dovuta in primis alla naturale struttura di un file XML, che rispecchia quella

di un albero, e secondariamente alla necessita di mantenere e rappresentare le

relazioni che intercorrono tra i nodi che compongono il documento XML. In

tal modo e possibile mantenere le relazioni semantiche implicite presenti nel-

l’albero XML palesandole all’utente, evitando di porlo in difficolta rendendolo

sprovvisto di tali riferimenti. A tale struttura e stata poi associata la visualiz-

zazione ad insiemi descritta poc’anzi. E’ doveroso far notare come la generica

assenza di annotazioni da parte del fornitore del servizio renda assai ardua

una interpretazione piu raffinata dei dati ed una conseguente rappresentazione

piu versatile e intuitiva per lo sviluppatore della composizione. Allo stesso

tempo, pensare di affidare l’attivita di annotazione dei dati a un utente non

esperto in fase di registrazione della sorgente dati non e parsa, allo stato delle

cose, una strada percorribile, poiche avrebbe rischiato di invalidare uno degli

obiettivi principali della piattaforma, rappresentato dalla semplicita di utilizzo.

Struttura dei dati

Il mapping tra il file XML e la sua rappresentazione ad albero non e diretto.

Difatti i tag di un documento XML presentano ulteriori informazioni che non

sono gerarchicamente organizzate come un albero, per esempio gli attributi di

un tag di apertura e il testo contenuto fra un tag di apertura e il corrispettivo

tag di chiusura. Quest’ultimi (attributi e testo) sono riferiti a un tag specifico

ma non sono con esso in relazione di subordinazione (figlio) o di dominanza

(padre), bensı allo stesso livello. Pertanto si e scelto di rappresentare questi

elementi come sottoinsiemi dell’insieme-tag di appartenenza mantenendo cosı

il legame semantico che sussiste tra un tag e i suoi attributi o il suo testo.

Un’ulteriore distinzione e stata fatta: l’albero presenta all’utente sia lo schema

dei dati sia le istanze dei dati.

Per distinguere i nodi appartenenti alla rappresentazione ad insiemi dalle istan-

ze stesse del dato, ovvero il testo di un tag e il valore di un attributo, e stata


introdotta una lieve differenziazione visuale (Figura 5.3).

Figura 5.3: Rappresentazione ad insiemi del documento XML

Si noti che, al fine di realizzare la composizione del mashup, le istanze dei dati

non sono sempre necessarie, mentre lo e sempre lo schema dei dati stessi. Ol-

tre a rappresentare un’ulteriore informazione che lo agevola nella comprensione

dello schema, infatti, le istanze sono utilizzabili direttamente in quei template

che prevedano il drag&drop di singoli elementi delle risposte XML. In questo

senso essi sono alternativi allo schema dei dati, poiche la loro aggiunta nella

composizione avviene a prescindere dalla loro collocazione nella mappatura dei

sottoinsiemi. Quando un dato viene trascinato“staticamente”da un utente che

lo vuole inserire nel mashup, esso cessa di essere considerato dall’applicazione

come una foglia dell’albero e diviene un dato fine a se stesso. Per facilitarne

ulteriormente la comprensione della struttura sono state introdurre funzioni di

supporto (facilities) sulle istanze dei dati, come la preview delle immagini in


presenza di url ad esse riconducibili o l’apertura delle ulteriori risorse Web nel

browser. In tal modo si e tentato di colmare il piu possibile il gap tra il docu-

mento XML e l’utente finale del DE, liberandolo dall’onere di dover compiere

una pre-annotazione dello schema della sorgente dati.

Generazione della struttura dati visuale

La generazione dell’albero concettuale e della conseguente struttura visuale ad

insiemi avviene in modo automatico a partire dal documento XML ottenu-

to dopo l’invocazione del servizio. Un algoritmo di visita dell’albero, di tipo

depth-first, genera il codice HTML adatto. Tale codice puo quindi essere ren-

derizzato direttamente sotto forma di albero oppure, come si e scelto di fare

in questo caso, tramite la sopracitata visualizzazione ad insiemi.

5.1.1.2 Il visual panel

Il visual panel e il pannello dell’editor adibito a mostrare lo stato della com-

posizione attualmente realizzata all’interno del template in uso. Data la sua

dipendenza pressocche totale dal visual template selezionato, il pannello non

ha una stuttura fissa. Ogni template tende comunque a dargli una visualizza-

zione il piu fedele possibile al corrispondente ambiente di esecuzione, sia esso

costituito da applicazioni su dispositivi mobili o da web-application su browser.

Mentre alcuni template assumono forme differenti a seconda dell’ambiente di

utilizzo, altre tipologie hanno il vantaggio di essere aderenti a standard di con-

venzioni e visualizzazione universalmente accettati. La necessita di trovare

delle costanti, e quindi di mostrare i contenuti in una determinata maniera,

nasce dall’esigenza di adattare la piattaforma ad ogni contesto e dominio ap-

plicativo (business, entertainment, information, ecc.). La presentazione, pur

non essendo “estranea” al contesto, e concentrata nella definizione dei template

visuali ed e dunque indipendente dalla tipologia e dalle peculiarita delle varie

sorgenti dati.


Figura 5.4: Map-template, a sinistra la vista primaria e a destra un esempiodi vista secondaria

Il visual template esemplificato nella figura 5.4, denominato “map-template”,

e composto da due viste differenti:

� “union”: vista primaria che contiene ed organizza su di una mappa inte-

rattiva, fornita dal servizio GoogleMaps, un insieme di punti di interesse,

rappresentati ciascuno da un marker colorato. La struttura visuale di

questi elementi, il marker, e quindi fissa e prestabilita. Ogni marker e

identificato nella composizione da una coppia (latitudine,longitudine) o

da una location indicante l’indirizzo del punto d’interesse. Il marker e

di colore rosso quando la sua aggiunta alla composizione viene gestita

in modo automatico dalla piattaforma in base ad uno schema dati in-

dicato dall’utente. I marker di colore blu rappresentano invece i punti

d’interesse che l’utente ha aggiunto “staticamente” (ossia manualmente

con una specifica azione di trascinamento) a partire da un’istanza di dato

contenuta nel data panel.


� ”merge”: vista secondatia che si attiva all’apertura del baloon informa-

tivo di uno o piu marker. Tali balloon, in quanto finestre d’informazio-

ne, contenengono i dettagli relativi al punto d’interesse selezionato. Per

quanto anch’esso dotato di una struttura di base rigida (il balloon), la

vista secondaria puo assumere diverse caratteristiche visuali a seconda

del numero e della tipologia di dati che l’utente vi destina tramite il

trascinamento dei dettagli. Ogni elemento di questa lista di sara carat-

terizzato da una intestazione, ossia il nome del dettaglio modificabile, e

da un contenuto, ovvero il valore del dettaglio.

5.1.2 Il repository dei servizi

La necessita da parte del compositore del mashup di disporre di diverse e innu-

merevoli sorgenti dati, per rendere piu articolato ed efficace il prodotto finale

realizzato, obbliga il DE a disporre di un repository di sorgenti dati costruito

dall’utente stesso attraverso un processo di registrazione guidato. In fase di

design e possibile accedere al repository e selezionare le sorgenti dati d’inte-

resse per la composizione. Le stesse sorgenti saranno quelle utilizzate dall’EE

per generare il mashup al momento dell’esecuzione.

Il repository e strutturato in modo da permettere la registrazione di servizi

RESTful che una volta invocati restituiscono dati in formato XML o Json.

La descrizione dei dati da catturare nelle risposte dei servizi avviene tramite

specificazione dei loro xpath, anche se e previsto l’inserimento, in un secondo

tempo, di interpretatori che estendano le capacita di identificazione dei dati

oltre l’utilizzo di path strettamente legati alle sintassi XML/Json.

Una tipica sorgente dati e rappresentata da una URL di base che identifica

il servizio, una stringa secondaria da accodare alla prima che ne specifica un’o-

perazione tra le varie eventualmente disponibili e da una serie di parametri che

specifichino la query vera e propria da inoltrare.


Il modello del repository delle sorgenti dati e costituito dai seguenti elementi:

� categoria: l’elemento categoria colleziona un insieme di servizi appar-

tenenti allo stesso genere tematico (per esempio libri, eventi, viaggi,

ecc.).

� servizio: l’elemento servizio colleziona tutte le informazioni che identifi-

cano uno specifico Web Service. I dati registrati in questo elemento sono

costituiti dal nome del servizio, da una breve descrizione che ne specifica

le funzionalita e dall’URL base del servizio. E’ quindi esclusa da que-

sta la querystring (cioe la stringa di caratteri che segue generalmente il

carattere “?” e che consente di passare al server uno o piu parametri).

� operazione: l’elemento operazione e costituito da un insieme di para-

metri. Rappresenta in pratica una particolare querystring. Un servizio

puo avere differenti operazioni, potendo quindi essere invocato con dif-

ferenti set di parametri. Anche la risposta stessa del servizio dipendera

dall’operazione tramite la quale e stato interrogato. L’operazione puo

essere opzionale (di default) se il servizio non prevede una querystring

aggiuntiva all’URL di base.

� parametro: l’elemento parametro rappresenta il singolo parametro ap-

partenente alla querystring dell’operazione e consiste in una coppia di

valori <nome, valore>.

Registrazione di una sorgente dati La registrazione della sorgente dati e

realizzata attraverso un wizard (Figura 5.5) che guida l’utente nell’inserimento

delle informazioni tramite una procedura precisa. Questa fase ha come requi-

sito indispensabile che l’utente abbia delle conoscenze relativamente avanzate

nell’ambito tecnico-informatico. In caso contrario la procedura di registrazione

dovrebbe essere riservata ad un amministratore del repository che provveda a


popolarlo di sorgenti dati che, successivamente, possano essere utilizzate con

facilita dagli utenti sviluppatori del mashup.

Figura 5.5: Procedura di inserimento di una sorgente dati nella piattaforma

Selezione di una sorgente dati

Anche in questo caso la scelta del wizard permette all’utente di selezionare

la sorgente dati tramite una serie di passi successivi, agevolandone la ricerca.

L’utente seleziona innanzi tutto la categoria a cui appartiene il servizio deside-

rato, poi il nome del servizio e in ultimo una particolare operazione fra quelle

disponibili per quel servizio. Tramite questa procedura viene selezionata la

sorgente dati d’interesse e, automaticamente, viene costruito l’url dell’interro-

gazione. L’editor e ora in grado di invocare il servizio coi parametri corretti e

di generare la rappresentazione dei dati nel data-panel.

Figura 5.6: Selezione di una sorgente dati della piattaforma


5.1.3 Il runtime environment

Il runtime environment rappresenta il componente principale dell’architettu-

ra (Figura 5.1) essendo il motore che realizza la logica su cui poggia l’intero

ambiente grafico, nel quale l’utente puo portare a termine le proprie compo-

sizioni. I sotto elementi che lo compongono sono adibiti a svolgere specifiche

funzionalita, facilmente desumibili dal nome, e sono:

� action manager : componente dedicato alla gestione dell’interazione con

l’utente. E’ l’unico punto d’ingresso del runtime environment. Esso

intercetta le azioni che l’utente compie nel front-end e le esegue, soddi-

sfacendo le richieste espresse dall’utente. Nel caso per esempio di azioni

di drag-and-drop tra il data-panel e il visual-panel (union o merge sub-

templates) esso interagisce col model manager modificando cosı lo stato

della composizione. Nel caso di azioni come la richiesta di salvataggio di

una composizione o la selezione di una sorgente dati presente nel reposi-

tory del server esso invece interagisce col connection-manager che abilita

la connessione dati col server.

� model manager : componente adibito a gestire lo stato dell’editor, a sua

volta composto dallo stato delle sorgenti dati in uso e lo stato della

composizione del mashup (il mapping degli schemi delle sorgenti dati sul

visual template). Lo stato e salvato in appositi bean ed e modificato dal

model manager ogni qual volta l’action manager ne fa richiesta. In tal

modo lo stato e mantenuto sempre aggiornato.

� visual-panel manager : componente dedicato alla gestione del visual-

panel. Il suo compito e quello di modificare il contenuto del visual-panel

in base alla descrizione dello stato attuale della composizione. Quando lo

stato della composizione cambia, a fronte di un’azione dell’utente (come

il drop di un nuovo elemento in un sub-template), esso riceve la notifica

dal model-manager di aggiornare la vista per mantenere coerente lo stato

con il visual front-end che si presenta all’utente.


� data-panel manager : componente dedicato alla gestione del data-panel.

Nel momento in cui lo stato delle sorgenti dati in uso muta, esso ne riceve

notifica dal model manager e si adopera per costruire il panello contente

una struttura visuale delle attuali sorgenti dati interpellate.

� connection manager : componente adibito alla comunicazione col configuration-

server. Implementa il protocollo di comunicazione col server offrendo un

set di metodi che permettono l’invio/ricezione di dati al/dal server sotto

forma di documenti XML.

Il modello adottato nella gestione del runtime environment e il classico modello

MVC (Model View Control) [40]. I componenti che lo implementano sono

l’action-manager (control), il model manager (model) e il data-panel e visual

panel manager (view).

5.1.4 Il configuration server

Come si puo notare in Figura 5.1, il configuration server presenta due soli

punti d’ingresso, rappresentati dal Controller-Servlet e dal Proxy-Servlet. Il

Controller-Servlet e una servlet adibita al dispatch delle richieste provenienti

dal client, codificate sotto forma di comandi, verso le Action. Il vantaggio di

parametrizzare i comandi che il client puo eseguire su server e costruire un

generico controllore servlet risiede nell’autosufficienza della servlet stessa. Per

la gestione di nuove funzionalita da introdurre un domani nella piattaforma

non sara piu necessario aggiungere nuove servlet a quelle esistenti, ma sara

sufficiente aggiornare gli handler di ricezione e di dispatching.

Le Action sono comuni oggetti Java, pensati per essere piu semplici delle ser-

vlet che li gestiscono e strettamente focalizzati sul lavoro che compete loro.

Le servlet, specialmente in applicazioni di grandi dimensioni, devono confron-

tarsi con lo svantaggio della loro permanenza in memoria fino alla rimozione

da parte del servlet engine. Utilizzare piu servlet per gestire le azioni richieste


dall’execution-engine del client significherebbe avere molte servlet quiescenti in

memoria, ovvero in uno stato di parziale attivita. Le Actions vengono invece

trattate come qualsiasi altro oggetto java e possono quindi essere deallocate

dal garbage-collector quando non piu effettivamente necessarie.

Il Controller-Servlet implementa i metodi per servire richieste HTTP di tipo

POST e GET e provvede ad effettuarne il dispatch verso le Actions corrispon-

denti. La selezione della destinazione opera sulla base del valore del parametro

‘cmd’ che definisce la tipologia richiesta di azione. Una volta instanziata cor-

rettamente, l’Action recupera tutte le informazioni necessarie ad eseguire il

comando richiesto leggendo gli altri parametri della richiesta HTTP (e il con-

tenuto dati) e risponde in modo autonomo al client senza dover piu interloquire

con il controller.

Il client puo richiedere attualmente al server l’esecuzione di diverse azioni:

� login: azione che implementa l’autenticazione dell’utente che desidera

accedere alla piattaforma. Essa verifica semplicemente se l’utente di-

spone delle credenziali corrette accendendo al database e verificando la

presenza dello username e della password inserite nella form di login.

� registration: azione che fornisce la funzionalita di registrazione nel data-

base delle informazioni che concernono un nuovo utente della piattaforma

(per es., nome, cognome, indirizzo, data di nascita, username, password,

ecc.).

� load : l’azione load risponde a un comando di richiesta di una risorsa

presente sul server. Durante la composizione del mashup nel Design En-

vironment spesso il runtime environment necessita di alcuni informazioni

di cui dispone solo il server. Per esempio, il client potrebbe voler disporre

dell’elenco di tutti i servizi appartenenti a una certa categoria, dell’url

di una sorgente dati, ecc.


� save: l’azione save permette invece di salvare una risorsa sul server. Per

esempio essa e richiesta dal runtime environment quando deve salvare

una nuova sorgente dati o una nuova composizione dell’utente.

� delete: l’azione delete e invece necessaria ogni qual volta si abbia la

necessita di cancellare una risorsa presente sul server.

Le azioni si interfacciano alla base di dati del server attraverso degli oggetti

Java, i cosiddetti bean, che rappresentano le risorse presenti sul database e

incapsulano tutti i metodi necessari per recuperare o inserire i dati da o per

il DB. I bean modellano risorse quali le categorie, i servizi, le operazioni di

una sorgente dati, i salvataggi degli utenti, e cosı via. Il DB Manager for-

nisce invece la connessione e i metodi per poter eseguire query sulla base di

dati in modo sicuro. Il Mail Manager e invece un componente di importanza

secondaria, dal momento che non e funzionale all’architettura principale. Ta-

le componente abilita le funzioni di notifica all’utente attraverso e-mail. Per

esempio, al termine della action registration si preoccupa di notificare la riusci-

ta dell’operazione fornendo all’utente, nella mail di benvenuto, l’username e la

password scelti al momento dell’iscrizione. Il Proxy-Servlet e l’ultimo compo-

nente fondamentale dell’architettura, unico punto d’ingresso del server insieme

al Controller-Servlet. Si tratta di una servlet adibita a svolgere la funzione di

proxy tra il runtime-environment e i servizi Web da esso interrogati. Se si ha il

bisogno di accedere attraverso Ajax [13] a un servizio Web che e in esecuzione

su di un server che non appartiene allo stesso dominio dell’applicazione Web,

allora questa azione viene impedita dalla same-domain-policy. La politica della

stessa origine e un concetto importante di sicurezza per una serie di linguaggi

di programmazione browser-side, quale e il JavaScript. In pratica impedisce a

script scaricati dalla rete di accedere, tramite qualsiasi tipo di richiesta HTTP,

a risorse che si trovano su server diversi rispetto a quello iniziale che ha invia-

to lo script. Questa inibizione non riguarda solo host diversi tra di loro, ma

anche processi in ascolto su porte diverse della stessa macchina. Nel nostro

caso specifico il runtime environment ha la necessita di inviare delle richieste


RESTful alle sorgenti dati per ottenere i dati e lo schema da visualizzare nel

data panel. Ma essendo uno script JavaScript a svolgere questa richiesta, es-

so e bloccato dalla same-domain-policy. Esistono diverse vie per superare le

limitazioni imposte da questa politica:

1. Json-p: (JSON with Padding [41]) caricamento dei dati nel tag <script>

inseriti nel documento inviato come risposta dal server interrogato. Per-

mette, al ricevimento di dati, di invocare una funzione di callback auto-

matizzata (come spesso viene fatto per le richieste Ajax basate su Xm-

lHttpRequest). Questo approccio, nonostante permetta di accedere a file

JavaScript remoti, presenta un grosso limite: non si ha alcun controllo sul

codice generato dalla richiesta, che verra quindi eseguito automaticamen-

te dall’interprete JavaScript appena esso lo ricevera dal server. E’ inoltre

necessaria la cooperazione tra il website sorgente e la Web application

che lo interroga.

2. Proxy : molto efficace ma ha lo svantaggio di consumare banda e potenza

di calcolo.

Data l’impossibilita di usufruire della cooperazione dei servizi remoti, a priori

sconosciuti alla piattaforma ViTe, e stato necessario utilizzare un Proxy che

permettesse l’inoltro delle richieste effettuate dal runtime environment alle sor-

genti dati appartenenti a domini differenti.

Il Proxy, essendo costituito da una servlet, non e interessato dalle limitazioni

presenti nei browser e dunque puo interrogare i servizi appartenenti a qualun-

que dominio e inoltrare la risposta al runtime environment essendo incluso nel

suo medesimo dominio applicativo.

5.2 L’Execution Environment

L’Execution Environment (EE) rappresenta la controparte dell’ambiente di

composizione dei mashup visto precedentemente. Per quanto sia possibile im-


plementare varie forme di EE per ciascuno dei template modellizzati, il nostro

lavoro si e focalizzato sullo sviluppo di un ambiente di esecuzione per il solo

template Map, fornendo cosı un caso d’uso tipico per l’intera architettura Vi-

Te. Tale ambiente, come gia accennato nel capitolo precedente, e costituito da

un’applicazione Web eseguibile su qualsiasi browser con supporto per codice

Javascript. L’applicazione consta in un motore in grado di caricare da server

remoto i file di configurazione generati dal Design Environment, ricostruendo

poi su questa base la configurazione dei dati e la presentazione degli stessi,

oltre a gestire l’interazione con la UI. Tale interazione si basa naturalmente

sul template in uso e, nel caso del template mappa da noi scelto per l’imple-

mentazione di prova, e costruito attorno ad una mappa interattiva del servizio

GoogleMaps. I dati presentati nell’interfaccia sono ottenuti invocando e co-

reografando le operazioni dei vari servizi coinvolti nella creazione del mashup,

secondo la logica di integrazione dei dati e di composizione a livello di pre-

sentazione definita dall’utente in fase di design. Per questa ragione, la stessa

visualizzazione deve essere sufficientemente versatile da adattarsi a qualsiasi

servizio utilizzato. In altri ambienti di esecuzione le informazioni provenienti

da diverse sorgenti possono essere poi estese richiamando una ricerca su un

gruppo di API predefinito qualora in fase di design l’utente ne avesse manife-

stato l’interesse associando ai dati dei collegamenti automatici (Web-binding).

Tale funzionalita, utilizzata ad esempio per il template Lista, non e stata imple-

mentata per il template mappa poiche non e risultata direttamente interessante

per l’utente finale.

In Figura 5.7 e presentata l’architettura dell’Execution Environment e le inte-

razioni dei componenti che la compongono che cooperano al fine di presentare

il mashup finale all’utente secondo quanto definito nell’xml di configurazione.


Figura 5.7: Architettura Execution Engine (EE)

I componenti che costituiscono l’EE svolgono naturalmente ruoli differenti:

� schema interpreter : e il componente che ha il compito di interfacciarsi

col configuration server, di recuperare e soprattutto interpretare lo sche-

ma xml dell’applicazione scelta dall’utente. Dopo aver fatto richiesta al

server del corretto file di configurazione, ne fa il parsing e salva il con-

tenuto, cioe le informazioni di configurazione del mashup, in appositi

oggetti dell’application model.


� application model : e un componente fondamentale adibito a mantenere

il modello dati dell’applicazione; Tale modello e composto da un insie-

me di classi, strutturati e pensati in modo da tener traccia di tutte le

informazioni necessarie a guidare l’EE durante l’esecuzione, ivi compresi

i dati recuperati a runtime dai servizi interrogati.

� Web data manager : questo componente si occupa di effettuare le in-

terrogazioni alle sorgenti dati che l’utente ha stabilito in fase di design,

utilizzando le indicazioni contenute nell’Application Model. Effettuato il

parsing delle risposte ottenute, il web data manager provvede a salvare i

dati recuperati all’interno del visual template model.

� visual template model : mantiene le informazioni sullo stato del visual

template in esecuzione. Anch’esso formato da classi adeguatamente com-

pletate coi dati recuperati dalle sorgenti e mappati negli oggetti tramite

regole prefissate caratterizzate dal template in uso.

� load manager : questo componente rappresenta, insieme al modello del

template visuale, la parte dell’Execution Environment maggiormente di-

pendente dal template in uso. Il load manager si occupa dell’istanzia-

zione, la generazione e la gestione delle schermate dell’applicazione e di

tutti gli aspetti del visual template per il quale e stato predisposto (nell’e-

sempio precedente, il template mappa). Secondo un approccio model-to-

code, ciascuna attivita contiene la logica per generare a runtime il codice

che gestisce lo screen (o parte dello screen) di propria competenza, insie-

me a tutti i componenti UI, facendo uso delle informazioni contenute nel

modello del visual template (visual template model) e dell’applicazione

(application model).

5.2.1 Data Fusion

Quando la composizione viene eseguita, vengono abilitati automaticamente

dall’Execution Environment meccanismi di data fusion integrati. L’obiettivo


di una tale politica e quello di effettuare un rendering visuale dei dati che

sia il piu possibile semplice e maneggevole per l’utente finale, eliminando le

ridondanze e raggruppando dati comuni allo stesso item nello stesso elemento

grafico (qualora il template in uso lo preveda). Il procedimento di fusione

dei dati e descritto nella Figura 5.8 utilizzando come esempio di riferimento il

template Map.

Figura 5.8: Schema del funzionamento della data-fusion nel template Map

Il cuore del sistema di integrazione e costituito dal Position Manager. Quan-

do questo riceve una richiesta di aggiunta di un nuovo marker (Add Marker

Request) alla mappa interattiva, consulta un elenco delle posizioni gia con-

traddistinte da marker (Position List) e, nel caso sia gia presente in lista una

posizione coincidente con quella del marker da aggiungere, fonde i dati di que-

st’ultimo con quelli gia associati alla posizione trovata (Marker to Fuse). In

caso contrario provvede all’aggiunta del nuovo marker sulla mappa (Add New

Marker) aggiornando di conseguenza l’elenco delle posizioni inserendovi il nuo-

vo punto di interesse. Nell’esempio visuale che segue (Figura 5.9) possiamo

notare come una coppia di marker, corrispondenti ad un marker automatico e

ad uno customizzato, sia stata unificata visivamente in un unico marker bico-

lore il cui baloon informativo contiene le informazioni derivanti da entrambi gli

item che afferiscono alla medesima posizione geografica. Tale meccanismo di


fusione opera analogamente anche per insiemi numerosi di marker, di natura

mista (come visto nell’esempio) od omogenei tra loro.

Figura 5.9: Esempio del funzionamento della data-fusion nel template Map

5.2.2 Un esempio di composizione mappa generata

La schermata iniziale dell’Execution Environment e mostrata in Figura 5.10.

L’interfaccia ha una struttura visuale fissa che viene poi popolata dinamica-

mente al momento del caricamento dei dati.

Selezione delle sorgenti dati

Le sorgenti dati coinvolte nel mashup sono raggruppate per categoria in un

menu a scomparsa nella schermata principale dell’EE.

All’interno di ogni singola categoria sono presenti le sorgenti dati utilizzate per

la costruzione del mashup in fase di design, che forniscono i dati ora attual-

mente visualizzati nell’interfaccia. Ciascuna sorgente nell’elenco e selezionabile

per il “filtraggio” dei suoi dati nella visualizzazione.


Figura 5.10: Schermata principale con menu di selezione delle sorgenti aperto(a sinistra)

Esistono pertanto due livelli differenti di selezione delle sorgenti. Il primo livello

avviene in fase di design quando l’utente ha scelto le sorgenti dati da utilizzare

nella composizione dell’applicazione. Un secondo livello, consistente nella sele-

zione appena descritta, avviene direttamente nell’ambiente di esecuzione delle

fonti che intende utilizzare per la visualizzazione del mashup, scegliendo solo

quelle che in quel momento risultano piu rilevanti.

Selezione del mashup

All’interno della schermata principale (Figura 5.10) l’applicazione presenta an-

che un pulsante di caricamento, con relativo “menu” di scelta, che consente

all’utente di selezionare la composizione da caricare tra quelle salvate su server

remoto.

All’interno di tale menu trova posto un elenco delle composizioni attualmente

attive sul configuration server (Figura 5.11) e, per ciascuna di esse, vengono

forniti nome ed ID oltre ad una breve descrizione che ne permette l’identifica-

zione univoca. La descrizione puo contenere eventualmente anche informazioni


legate alle sorgenti dati che compongono l’applicazione e il visual-template se

l’utente lo ha ritenuto necessario in fase di salvataggio. Una volta selezio-

nata la composizione desiderata, l’execution environmant richiede al server

l’xml di configurazione e genera automaticamente la presentazione e la logica

dell’applicazione sulla base di quest’ultimo.

Figura 5.11: Menu di selezione dell’applicazione all’interno dell’EE

Il visual template

Come precedentemente accennato, l’ambiente di esecuzione da noi creato pre-

senta un solo template di visualizzazione: il template “mappa”. Per popolare

questo template con i dati necessari viene seguito lo schema di data integration

presentato nel capitolo 4.

In Figura 5.12 viene mostra la struttura del template “mappa” che e costi-

tuito da due sub-template: la vista primaria (cioe il sub-template union) e la

vista secondaria (cioe sub-template merge).


Ciascun elemento della vista primaria (i marker) e costruito sulla base del

suo campo location, costituito da un indirizzo valido, o dalla analoga coppia

<latitudine,longitudine> che ne identifichi univocamente la posizione geogra-

fica. Nella vista secondaria vengono invece riproposti tutti i dati che l’utente

ha ritenuto utile inserire come dettagli all’interno dei baloon informativi del

marker selezionato.

Figura 5.12: Le viste primaria e secondaria del template Map nell’EE(visualizzate in contemporanea)

L’ambiente di esecuzione del template mappa presenta inoltre uno spazio vi-

suale pensato per fornire all’utente insieme di filtri che permettano la selezione

di un sottoinsieme di elementi della vista primaria in base ad una ricerca te-

stuale lungo un campo della vista secondaria. E’ possibile ad esempio cercare

il marker che identifichi la posizione geografica di un evento al quale l’utente e

interessato tramite la ricerca del campo “title” tra i titoli degli eventi contenuti

nei baloon informativi. Tale operazione e possibile pero soltanto se l’utente ha

attivato il filtraggio su quel particolare dettaglio in fase di design. In figura

5.13 e evidenziato il menu di ricerca e selezione filtri.


Figura 5.13: Menu di ricerca e selezione dei filtri

Capitolo 6

Valutazioni

Per la valutazione del tool di composizione creato e per ottenere un feedback

sulle scelte compiute nell’approcciarsi al problema, e stato necessario eseguire

dei test con gli utenti finali. Nel corso di questo capitolo, dopo una breve

panoramica delle metodologie usate e del campione statistico selezionato, ver-

ranno esposti i risultati dei test condotti su due differenti tipologie di utenti:

Esperti e Non Esperti. Tali test hanno consentito di effettuare analisi sulle

tempistiche di design ed esecuzione e, anche grazie ad un questionario finale, e

stato possibile stimare la soddisfazione degli utenti e la facilita di utilizzo degli

aspetti chiave del tool.

6.1 Test con gli utenti

Per la validazione del paradigma di composizione adottato per la nostra piatta-

forma, nei riguardi dei requisiti dell’EUD, abbiamo condotto uno studio basato

su utenti, per valutare l’usabilita dell’approccio adottato nell’implementazione

degli ambienti di composizione ed esecuzione dei mashup. Attraverso una serie

di test abbiamo potuto valutare in modo oggettivo l’efficacia, l’efficienza e la

facilita di composizione (ease of use) e, piu soggettivamente, la soddisfazione

dell’utente nel vedere realizzata la sua applicazione.

94

CAPITOLO 6. VALUTAZIONI 95

L’esperimento si e focalizzato principalmente sull’efficacia e sull’intuitivita del

paradigma di composizione, tenendo conto della necessita di rendere fruibile

l’ambiente anche a chi non abbia conoscenze avanzate in campo informatico. E’

stata valutata la capacita degli utenti di ciascun gruppo (esperti e non esperti)

di portare a termine i task previsti dal test, monitorando i tempi necessari al

loro completamento. L’utilizzo da parte degli utenti della piattaforma ViTe ha

cosı offerto un esempio sufficientemente realistico del comportamento medio

del target di utenza di riferimento dell’applicazione.

L’obiettivo primario del test consisteva quindi nel riscontrare un buon livel-

lo di efficienza nella creazione della composizione da parte degli utenti. Se-

condariamente sono stati considerati gli aspetti di soddisfazione del campione,

tentando di rilevare in quale misura gli utenti si sentissero a proprio agio nel-

l’utilizzo della piattaforma e in quale percentuale questa fosse percepita come

uno strumento utile. Di pari importanza e stata la considerazione del grado

di learnability dell’applicativo stesso da parte degli utenti. E’ stata comunque

tenuta in considerazione una possibile riduzione (anche sensibile) delle tempi-

stiche di completamento dei task nel caso di utenti esperti. Il loro bagaglio

tecnico avrebbe potuto infatti favorire la rapida comprensione dei task spe-

rimentali e l’individuazione degli step necessari al loro completamento. Essi

potrebbero inoltre avere avuto una maggior consapevolezza delle operazioni in

svolgimento, aumentandone la percezione del controllo sul tool stesso.

6.1.1 Campione del test

Lo studio ha coinvolto 26 partecipanti caratterizzati da diversi background

(studenti, impiegati, lavoratori ecc. . . ) e con eta comprese tra i 23 ed i 70

anni. Il bacino di utenza e stato mantenuto il piu vario possibile nei limiti

numerici del campione. La popolazione del campione e stata poi suddivisa in

due gruppi: gli “utenti esperti” con un background che comprende esperienze

avanzate in ambito informatico\Web e gli utenti non esperti, mai esposti ad


attivita che richiedessero un esperienza tecnica in campo IT.

Figura 6.1: Distribuzione degli utenti in base alla fascia di eta

Gli utenti sono stati istruiti, tramite un tutorial introduttivo della durata di 5-

7 minuti, all’ambiente di sviluppo e ai meccanismi base di composizione. Tale

breve tutorial ha illustrato agli utenti le principali funzionalita della piattafor-

ma e ne ha mostrato un esempio di utilizzo. Prima di iniziare il test vero e

proprio si e fatto loro compilare un breve pre-questionario in modo da acquisi-

re le informazioni generali sulla loro esperienza ed il loro livello di conoscenza

sulle materie in esame.

6.1.2 Metodologia del test

Durante la sessione di testing, agli utenti sono stati proposti due task (test

A e test B) di progressiva difficolta. Entrambi i taks sono stati progettati in

modo da guidare l’utente in un percorso di attivita che lo potesse condurre al

completamento degli obiettivi prefissati. Alcune sotto-attivita dei task, relati-

ve alle diverse fasi della composizione e dell’esecuzione, sono state monitorate

annotando i tempi di esecuzione e le eventuali difficolta degli utenti. Compa-

rando le tempistiche di svolgimento si e potuta ottenere un’idea piu precisa

dell’efficacia e della semplicita dell’ambiente ViTe. Alla fine delle due sessioni

di test (test A e test B) tutti gli utenti hanno dovuto compilare un questionario

per valutare la loro soddisfazione nell’utilizzo del tool. Seguira ora una breve

descrizione dei task proposti e delle attivita che li compongono.


User Test A

Nel primo test si e richiesto all’utente di portare a compimento il seguente

task (Task A):

Per organizzare il tuo tempo libero, vuoi tenere sott’occhio gli eventi disponibili

in citta, creando una composizione di tipo “Map”. Per fare cio, aggiungi alle

sorgenti dati i servizi di Eventful ed Upcoming. Utilizza le coordinate di lati-

tudine e longitudine fornite da ciascun servizio per visualizzare sulla mappa i

marker degli eventi corrispondenti. Aggiungi poi a questi marker, da entrambi

i servizi, i dettagli relativi alla descrizione e all’indirizzo degli eventi caricati.

Salva infine la composizione con il nome “My Events”.

Si riportano di seguito le sotto-attivita del task A con le relative descrizioni.

Sotto attivita TestA

Descrizione

Selezione Web Service

Dopo aver cliccato sull’icona di selezioneservizi, si seleziona il tipo di categoria

(eventi), servizi (Eventful, Upcoming) einfine le operazioni di ricerca di default.

Data mappingprimario

Tramite operazioni di drag-and-drop siaggiungono alla preview del visual template

mappa le latitudini e le longitudini deglieventi da entrambi i servizi.

Data mappingsecondario

Tramite operazioni di drag-and-drop siaggiungono ai baloon informativi dei marker

gli elementi “description” ed “address” deldata panel.

Salvataggio delloschema

Cliccando sull’icona di “save”, scrivere nomee descrizione dell’applicazione, e quindi

effettuare il salvataggio su server.

Tabella 6.1: Descrizione delle sotto-attivita per il test A


User Test B

Nel secondo test si e richiesto all’utente di portare a compimento il task se-

guente (Task B):

Stai pianificando un viaggio a Milano, e ti servono informazioni per organiz-

zare al meglio il tuo soggiorno. Decidi quindi di utilizzare una composizione di

tipo “Map”. Per fare cio, aggiungi alle sorgenti dati gli hotel e le stazioni della

metropolitana del servizio Google Places. Utilizza le coordinate di latitudine e

longitudine fornite dai due servizi per visualizzare sulla mappa i marker corri-

spondenti ad alberghi e stazioni. Aggiungi ai marker degli alberghi il dettaglio

relativo al nome dell’hotel, impostandolo poi come filtro. Aggiungi ai marker

delle stazioni metropolitana il dettaglio relativo al nome della stazione. Ag-

giungi ora un nuovo marker nella location “Duomo Milano”. Dopo aver aperto

una nuova sorgente dati del servizio Flickr, cambia la query di ricerca in “Duo-

mo Milano”. Aggiungi come dettaglio al marker appena creato una delle foto

restituite dal servizio. Lancia infine l’esecuzione della composizione creata, ed

effettua la ricerca dell’hotel “Hotel dei Cavalieri”.

Si riportano di seguito le sotto-attivita del task B con le relative descrizioni.

Sotto attivita TestB

Descrizione

Selezione Web Service/ 1

Dopo aver cliccato sull’icona di selezioneservizi, si seleziona il tipo di categoria

(travel), servizi (Google Places) e infine leoperazioni di ricerca di Hotel e Subway

Stations.

Data mappingprimario

Tramite operazioni di drag-and-drop siaggiungono alla preview del visual template

mappa le latitudini e le longitudini degliitem di entrambi i servizi.

Continua... Continua...

Tabella 6.2: Descrizione delle sotto-attivita per il test B


continua.. continua..

Data mappingsecondario / 1


degli Hotel gli elementi “name” e siseleziona la loro opzione di filtraggio.

Data mappingsecondario / 2


delle stazioni metropolitane gli elementi“name”.

Data mappingprimario “custom”

Cliccando sull’icona di aggiunta marker, siimposta la location “Duomo Milano”

nell’apposita casella e si clicca sul pulsante“add”.

Selezione Web Service/ 2

Dopo aver cliccato sull’icona di selezioneservizi, si seleziona il tipo di categoria(multimedia), servizio (Flickr) e infine

l’operazione di ricerca di default. Si cliccapoi sul pulsante “Change Service Query” e

si cambia il campo text in “Duomo Milano”cliccando poi sul pulsante “Submit”

Data mappingsecondario “custom”

Tramite operazioni di drag-and-drop siaggiunge al baloon informativo del marker

custom un’immagine del servizio Flickr.

Application running

Dopo aver cliccato su “ExecutionEnvironment” ed aver confermato la

richiesta, si seleziona dal menu di filtraggioil filtro “name” e si ricerca la stringa “Hotel

dei Cavalieri”.

Tabella 6.3: Descrizione delle sotto-attivita per il test B (continua..)

6.1.3 Analisi dei dati

Tutti i partecipanti sono stati in grado di completare i task senza difficolta

eccessive. Non sono state riscontrate differenze di tempo tra gli utenti esperti

e i non esperti tali da pregiudicare l’accessibilita di particolari fasce di utenza

all’ambiente di composizione.

Come primo step di analisi e stata testata la normalita della distribuzione dei


dati temporali di ciascuna fascia di utenza applicando il test di Shapiro-Wilk,

al fine di individuare il test di significativita piu adatto a verificare le ipotesi

in questione. Il risultato di questo test sulla popolazione di utenti (W=0.8674,

p=0.02478 ) non supporta l’ipotesi di normalita di tale distribuzione. Per va-

lori del p-value inferiori a 0.05 e infatti preferibile il test non parametrico di

Wilcoxon-Mann-Whitney.

Tramite tale test abbiamo dovuto affrontare la verifica dell’omogeneita di due

popolazioni (X e Y variabili aleatorie rappresentanti rispettivamente il tempo

impiegato per svolgere il test da parte di un utente esperto e il tempo impie-

gato per svolgere il test da parte di un utente non esperto). Per applicare il

test di Wilcoxon e necessario assumere che:

� I due campioni di studio del nostro test sono reciprocamente indipendenti

� le osservazioni all’interno di ogni campione sono indipendenti

� tali osservazioni sono confrontabili

6.1.3.1 Efficienza

Il test di Wilcoxon-Mann-Whitney ci ha dimostrato che l’esperienza tecnolo-

gica pregressa non costituisce una discriminante per le tempistiche di com-

pletamento dei task assegnati. Impostando tale test abbiamo quindi assunto

come ipotesi nulla che le due popolazioni di utenti abbiano la medesima di-

stribuzione. L’ipotesi alternativa afferma invece che le due popolazioni hanno

comportamenti differenti in base alle conoscenze informatiche personali. For-

malmente, chiamata Fx la distribuzione dei tempi degli utenti esperti ed Fy la

distribuzione per gli utenti non esperti e stato impostato il test con il seguente

sistema di ipotesi: H0 : Fx = Fy

H1 : Fx 6= Fy


Il risultato del test (U=47 p=0.4707), calcolato ad un livello di confidenza del

95%, dimostra come non vi sia evidenza empirica sufficiente a rifiutare l’ipote-

si di omogeneita (H0). Possiamo quindi assumere che le due popolazioni (nel

nostro caso gli utenti esperti e non esperti) hanno la medesima distribuzio-

ne. Questi dati confermano quindi che il tool permette anche agli utenti non

esperti di portare a compimento il task in un tempo limitato. I tempi medi

di completamento del Task A sono stati di 3m30s per i novizi e di 3m36s per

gli esperti, mentre per il Task B sono stati di 5m20s per i novizi e 4m46s per

gli esperti. La differenza tra le tempistiche di completamento dei task A e B

e dovuta al maggior numero di sottoattivita del secondo task rispetto al primo.

I grafici seguenti mostrano l’andamento dei tempi medi durante il comple-

tamento dei task.

Nei Grafici in figura 6.2 e 6.3 sono riportati i tempi medi per gli utenti non

esperti (azzurro) e per gli utenti esperti (blu) rispettivamente per il Task A e

per il Task B. Sull’asse delle ascisse sono ripotarti i numeri progressivi delle

sotto attivita di ciascun task, mentre sulle ordinate troviamo le tempistiche di

esecuzione calcolate in secondi.

Figura 6.2: Tempo medio per ogni attivita del task A


Questi grafici evidenziano ancora una volta la facilita d’uso del tool. Supportati

da tali analisi abbiamo quindi la conferma che l’approccio di composizione

utilizzato non richiede nessuna esperienza tecnica in ambito di composizione

di Web service.

Figura 6.3: Tempo medio per ogni attivita del task B

6.1.3.2 Facilita d’uso

La facilita d’uso e stata confermata dai dati raccolti attraverso le domande

presenti nel questionario post-esperimento (Appendice B), che conteneva nu-

merosi quesiti studiati appositamente per cogliere questo tipo di aspetti. Do-

mandando quindi all’utente di giudicare il livello di facilita dell’identificazione

ed inclusione dei servizi nella composizione e della definizione delle regole per

l’integrazione dei dati abbiamo potuto estrarre informazioni utili a valutare la

facilita d’uso del nostro applicativo.

Altre domande miravano invece ad ottenere un giudizio complessivo sul tool.

Le risposte erano modulate su una scala da 1 a 7, con 7 pari ad un alto livello

di facilita e 1 un parimenti alto livello di difficolta. Nel grafico sottostante

possiamo vedere le medie e gli scarti quadratici medi delle risposte alle prime 8


domande del post-questionario, che riguardavano direttamente la facilita d’uso

dell’applicativo.

Figura 6.4: Valutazioni medie sulla facilita di utilizzo per le prime 8 domande

Calcolando la media di tali valori si ottiene una valutazione media pari a 5.6/7

per gli utenti esperti e di 5.3/7 per i non esperti, con uno scarto quadratico

medio pari rispettivamente a 0.92/7 ed 1.22/7. Per questa serie di dati i valori

massimi e minimi, calcolati sulla media delle 8 domande, sono stati rispettiva-

mente di 6.9/7 e 4.1/7 per gli utenti esperti, e di 7/7 e 3/7 per gli inesperti. La

valutazione, riportata su scala positiva centesimale, equivale ad un voto medio

di circa 80/100 per gli esperti e 75.7/100 per i non esperti.

Le valutazioni sulla facilita di utilizzo sono state sottoposte ad un test di omoge-

neita. L’ipotesi di partenza considerava una possibile differenza tra le risposte

date dagli utenti esperti rispetto ai meno esperti. Questi ultimi sono dotati

infatti di un occhio critico meno allenato verso i problemi tecnologici e posso-

no al contempo risultare piu esposti a procedure e formalismi con i quali non

hanno familiarita. Testare l’omogeneita delle due distribuzioni e stato dunque

necessario per esplorare questo aspetto.

Sia la distribuzione delle risposte date dagli utenti esperti che quella degli


utenti meno esperti sono risultate assimilabili ad una distribuzione normale

tramite il test di normalita di Shapiro-Wilk (con valori pari rispettivamente a

W= 0.9262 e p=0.4823 per gli esperti, W=0.8894 e p=0.2313 per i non esper-

ti). Sulle due popolazioni e stato quindi efettuato un t-test di omogeneita, con

il seguenta sistema di ipotesi: H0 : Fx = Fy

H1 : Fx 6= Fy

dove Fx ed Fy rappresentano le distribuzioni delle risposte date rispettivamente

dagli utenti esperti e non esperti. Il risultato del test (t=0.9739, p=0.4467 )

confuta l’ipotesi di una sensibile differenza tra il comportamento delle due fasce

di utenti (H1). Ad un livello di confidenza del 95% la differenza tra le medie

osservate non e infatti significativa e puo considerarsi dovuta ad una semplice

fluttuazione statistica. Questa analisi ci ha quindi portato a concludere che

le valutazioni degli utenti sulla facilita di utilizzo del tool sono omogenee tra

le due fasce di utenti e non vengono influenzate in modo sensibile dalle loro

esperienze pregresse

6.1.3.3 Soddisfazione dell’utente

Il valore che indicava la soddisfazione relativamente al paradigma di compo-

sizione assistito e stato acquisito usando una scala semantica differenziale (si

rimanda ad A.2 in Appendice) che richiedeva all’utente di giudicare il tool su

12 diverse dimensioni (per esempio chiaro, utile, semplice, divertente, efficace,

affidabile,..). Anche in questo caso gli utenti hanno dovuto esprimere la loro

valutazione avendo a disposizione una scala da 7 (molto positivo) a 1 (molto

negativo). Possiamo vedere riassunti nel grafico sottostante i valori medi di

risposta a questo gruppo di domande, con gli scarti quadratici associati ad

esse.


Figura 6.5: Risposte utenti alla domanda n°9 (Appendice B)

Come indice complessivo di soddisfazione dell’utente e stata utilizzata la media

dei valori rilevati per questi 12 quesiti. La soddisfazione media e stata dunque

pari a 5.2/7 per gli utenti esperti, e a 5.3/7 per i non esperti, con uno scarto

quadratico medio pari rispettivamente a 0.94/7 ed 1.1/7. I valori massimi e

minimi calcolati sulla media delle 12 dimensioni in esame sono stati rispettiva-

mente di 6.5/7 e 3.8/7 per gli utenti esperti, e di 6.9/7 e 3.3/7 per gli inesperti.

La valutazione, riportata su scala centesimale, equivale ad un voto medio di

circa 75/100 per entrambe le popolazioni.

Tale valutazione puo facilmente essere confrontata con la soddisfazione perce-

pita, che l’utente dichiara esplicitamente dando un voto complessivo al metodo

di composizione. Su una scala da 1 (molto negativo) a 10 (molto positivo), il

valore risultante e stato nettamente favorevole, con una media pari ad 7.6 ed

uno scarto quadratico medio pari a 0.8.

Tra le ultime domande veniva richiesto all’utente di giudicare la propria per-

formance come creatori di composizioni e di indicare poi in percentuale la

quantita di requisiti che a loro giudizio erano stati in grado di completare. In


media, gli utenti hanno dichiarato di essere stati in grado di coprire l’89.6% dei

requisiti a loro assegnati durante lo svolgimento dei due task (min = 50%, max

= 100%, dev.standard = 13%). Riguardo alla soddisfazione come compositori

di mashup, rilevata su un scala da 1 (molto negativo) a 4 (molto positivo),

abbiamo ottenuto una risposta media pari a 3.1/4 con deviazione standard di

0.6/4. La valutazione, riportata su scala centesimale, equivale ad una valuta-

zione media pari a circa 76.9/100.

Queste metriche possono essere considerate indicatori della sicurezza acqui-

sita dagli utenti nell’utilizzo del tool, e quindi indirettamente della facilita

d’uso e della soddisfazione degli utenti.

Anche gli indici di soddisfazione sopra descritti sono stati sottoposti a test

di omogeneita. L’ipotesi di partenza, in questo caso, riguardava la possibilita

che le conoscenze pregresse degli utenti influissero in modo significativo sulla

loro esperienza di utilizzo del tool. Gli utenti esperti, in particolare, avreb-

bero potuto confrontare istintivamente l’esperienza di composizione appena

sperimentata con ambienti analoghi usati precedentemente. Questa possibili-

ta, generalmente preclusa agli utenti meno esperti, poteva esser causa di un

divario sensibile nelle loro risposte.

Sia la distribuzione delle risposte date dagli utenti esperti che quella degli

utenti meno esperti sono risultate assimilabili ad una distribuzione normale

tramite il test di normalita di Shapiro-Wilk (con valori pari rispettivamente

a W= 0.9485 e p=0.4155 per gli esperti, W= 0.9545, p=0.03703 per i non

esperti). Sulle due popolazioni e stato quindi efettuato un t-test di omogeneita,

con il seguenta sistema di ipotesi:H0 : Fx = Fy

H1 : Fx 6= Fy


dove Fx ed Fy rappresentano le distribuzioni delle risposte date rispettivamen-

te dagli utenti esperti e non esperti. Il risultato del test (t=0.2567, p=0.7998 )

smentisce anche l’ipotesi di una differenza significativa tra il comportamento

delle due fasce di utenti nella valutazione della propria esperienza di composi-

zione (H1). Ad un livello di confidenza del 95% la differenza tra le medie delle

popolazioni non risulta infatti significativa. Possiamo dunque concludere che

i livelli di soddisfazione non vengono sensibilmente influenzati dalle esperienze

pregresse degli utenti

6.1.3.4 Affidabilita del Test

Analizzando i risultati dei test qui illustrati, si e dovuta considerare una misu-

ra del livello di affidabilita delle risposte fornite dagli utenti. E’ stato quindi

effettuato il calcolo del coefficiente di Cronbach (Cronbach’s alpha [2]) per te-

st psicometrici su campioni di utenti. Valori elevati di tale coefficiente, nello

studio di un questionario di atteggiamenti, indicano che i soggetti esaminati

esprimono un atteggiamento coerente riguardo a ciascuna dimensione di inda-

gine.

Per il primo gruppo di domande, riguardanti la facilita d’uso, il coefficiente

calcolato e risultato pari ad a=0.73. Per il secondo gruppo di domande, sulla

soddisfazione dell’utente, il coefficiente e risultato pari ad a=0.75. Poiche la fa-

scia di accettabilita di Cronbach si ha per valori 0.7 ≤ a < 0.8 si puo concludere

che per entrambi i gruppi di domande i test effettuati sono affidabili.

Parte IV

Conclusioni

108

Capitolo 7

Conclusioni e lavori futuri

L’oggetto di questa tesi e stato lo sviluppo light-weight, focalizzando l’atten-

zione sugli End-User, di mashup multipiattaforma. Abbiamo discusso come

adeguate astrazioni, principalmente basate sulla costruzione di template vi-

suali, possano abilitare un processo di integrazione dei dati “leggero”, arrivan-

do alla definizione di viste unificate di dati provenienti da vari servizi. Per

raggiungere questi obiettivi e stato necessario introdurre il concetto di vista

“primaria” (definita nel file xml con il tag <union>, e vista “secondaria” con il

tag <merge>, di cui si e parlato nel Capitolo 4) che abilitano i meccanismi di

data fusion in fase di esecuzione realizzati in base al template visuale in uso. La

bonta e l’efficacia di queste scelte e stata confermata dallo studio condotto con

gli utenti, di cui si e discusso nel capitolo 6, nel quale si evidenzia un utilizzo

uniforme dell’applicazione a prescindere dal livello di esperienza dell’utente.

Riguardo l’implementazione, sono state fatte delle scelte mirate alla possibilita

di definire diversi tipi di template utilizzabili dagli utenti finali. Infatti, pur

avendo attualmente a disposizione un insieme “pilota” costituito dai template

Lista e Mappa, vi e la possibilita di aggiungere nuovi template (come quelli

descritti nel capitolo 4) incardinandoli in una struttura gia predisposta al lo-

ro inserimento. Il tutto e reso possibile grazie all’adozione di un’architettura

basata su un’interfaccia base, contenente tutti i metodi necessari al design en-

109

CAPITOLO 7. CONCLUSIONI E LAVORI FUTURI 110

vironment per una corretta visualizzazione, che ogni template implementa in

modo differente in base alle sue esigenze.

Gli esempi mostrati in questa tesi fanno riferimento a configurazioni di servizi

e d’integrazione semplici in cui spesso si fa uso di regole di default. Tutta-

via, estendendo in modo opportuno la piattaforma ViTe, siamo convinti sia

possibile aumentarne le potenzialita e il bacino di utenza fornendo funziona-

lita avanzate utili agli utenti piu esperti. Si potrebbe infatti consentire una

configurazione piu dettagliata dei servizi, abilitare interrogazioni in cascata

(aventi come parametri di interrogazione uno o piu dati prelevati dai risultati

di precedenti richieste), o permettere l’aggiunta e la rimozione “on-the-fly” (in

fase di design) dei parametri di esecuzione delle query ed altri aspetti avanzati

di configurazione della piattaforma. I lavori futuri potrebbero, quindi, esse-

re indirizzati al miglioramento dell’ambiente di design lungo queste direttrici.

Suggeriamo anche l’introduzione di meccanismi di raccomandazione [7], sia du-

rante la fase di design, per aiutare il compositore nella scelta dei servizi e dei

pattern di composizione, sia durante l’esecuzione dell’applicazione, per aiutare

l’utente finale a raffinare le selezioni dei servizi sulla base del contesto d’uso e

dei parametri di qualita del servizio (QoS ).

Un’altra direzione di ampliamento che potrebbe rivelarsi promettente e la de-

finizione di mashup cooperativi. Come evidenziato anche dagli utenti durante

la fase di test, sarebbero utili meccanismi “sociali” per la condivisione con altri

utenti delle composizioni create (Appendice C). Tale caratteristica puo miglio-

rare la cooperazione in team nei contesti Enterprise. Questo tipo di approccio

potrebbe anche includere la possibilita di esporre i mashup come risorse del

processo. In questo modo i prodotti di uno o piu utenti possono essere intera-

mente riutilizzati (come servizi) nella definizione di mashup da parte di altri

utenti cooperanti [20].

Parte V

Appendice

111

Appendice A

Pre-Questionario

112

1. Quanta familiarità/esperienza hai nel campo dell’informatica?

nessuna pochissima poca nella media abbastanza molta moltissima

1 2 3 4 5 6 7

2. Per quante ore al giorno usi il computer? |_____________|

3. Sei un utente abituale del Web? Si No

4. Utilizzi abitualmente servizi di mappe online (es. Google Maps)? Si No

5. Hai mai provato a creare applicazioni Web? Si No

6. Hai mai provato ad usare web service? Si No

7. Hai mai provato a usare un tool per aggregare servizi diversi (per es., I-google, Yahoo!Pipes)?

Se si, quali?

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

8. Sai cosa e' un mashup?

Se si, prova a darne una definizione:

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

Dati socio-anagrafici

1. Età |_____________|

2. Sesso maschio femmina

CODICE ___________

Appendice B

Post-Questionario

114

( Segna con uno ed un solo cerchietto il numero corrispondente alla tua personale opinione )

1. Capire quali dati possono essere estratti dai vari servizi è stato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto

Facile 1 2 3 4 5 6 7 Difficile

2. Dover selezionare i dati e collocarli in modo corretto è stato: molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


3. Dover definire la logica con cui dati presi da servizi diversi si “fondono” nell’applicazione finale è

stato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


4. Aggiungere elementi e/o dati personalizzati nella composizione è stato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


5. Monitorare lo stato della composizione (per es. servizi inclusi, filtri, fusioni di dati) è stato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


6. In caso di errore, quanto è facile tornare indietro?

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


CODICE ___________

Questionario

Ringraziandoti per avere collaborato a questa valutazione, ti chiediamo adesso di esprimere le tue

impressioni e i tuoi giudizi sul tool e sui metodi di creazione che hai utilizzato. Il questionario è

rigorosamente anonimo. Tutte le informazioni che avrai la gentilezza di fornirci verranno considerate

strettamente confidenziali. Cerca di essere il più sincero e accurato possibile. Se qualche domanda ti

sembra poco chiara non esitare a chiedere spiegazioni.

7. Ritrovare i dati di interesse tramite la composizione creata è stato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


8. In generale, imparare a utilizzare il tool è stato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto


(Per ogni coppia di aggettivi, segna con uno e un solo cerchietto il numero corrispondente alla tua

personale opinione)

9. Il metodo di creazione delle composizioni che hai utilizzato ti è sembrato:

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto

facile da usare 1 2 3 4 5 6 7 difficile da usare

faticoso 1 2 3 4 5 6 7 riposante

chiaro 1 2 3 4 5 6 7 ambiguo

utile 1 2 3 4 5 6 7 inutile

impegnativo 1 2 3 4 5 6 7 semplice

inefficiente 1 2 3 4 5 6 7 efficiente

divertente 1 2 3 4 5 6 7 noioso

inaffidabile 1 2 3 4 5 6 7 affidabile

efficace 1 2 3 4 5 6 7 inefficace

gradevole 1 2 3 4 5 6 7 sgradevole

flessibile 1 2 3 4 5 6 7 rigido

soddisfacente 1 2 3 4 5 6 7 insoddisfacente

10. Esprimi un voto complessivo sul tool e sul metodo di composizione, usando una scala da 1 (molto

negativo) a 10 (molto positivo)

(Scrivi il numero nell'apposito spazio) |_____________|

(Segna con uno ed un solo cerchietto il numero corrispondente alla tua personale impressione)

11. Quanto ti senti soddisfatto della tua performance di “creatore di mappe personalizzate”?

Per nulla Poco Abbastanza Molto

1 2 3 4

12. In percentuale, quanti dei requisiti dettati dal compito che ti è stato assegnato ritieni di avere

coperto con l’applicazione che hai creato?

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

13. Supponendo che le applicazioni generate con lo strumento che hai usato possano essere usate sia

sul computer che su dispositivi mobili (quali smartphone o tablet), quanto ritieni che possa essere

utile tale strumento?

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto

Utile 1 2 3 4 5 6 7 Inutile

14. Secondo te, qual è il vantaggio principale del tool che hai utilizzato?

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

15. E qual è il suo limite principale?

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

16. Dal punto di vista delle funzionalità offerte, pensi che lo strumento che hai utilizzato sia completo?

molto abba-

stanza

un po' né l'uno

né l'altro

un po' abba-

stanza

molto

Completo 1 2 3 4 5 6 7 Incompleto

Se incompleto, cosa vorresti fosse disponibile?

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

17. Quanto pensi che le conoscenze sui mashup e l’integrazione di servizi possano facilitare l’utilizzo

del tool?

Per nulla Poco Abbastanza Molto Non possiedo tali conoscenze

1 2 3 4

18. Useresti questo tool nella tua quotidianità se lo avessi a disposizione? Si No

Verifica di avere risposto a tutte le domande. Grazie della collaborazione!

Appendice C

Opinioni degli utenti

Riportiamo, di seguito, alcuni pareri tratti dalle risposte degli utenti ai post-

questionari (Appendice B).

C.1 Vantaggi

“Ho ritenuto utile la possibilita di impostare delle composizioni di ricerca da

utilizzare su device diversi”

“Interfaccia User-Friendly”

“Lo strumento permette la personalizzazione delle composizioni in poco tempo”

“Riuscire ad avere una visione globale di cio che ritengo di mio interesse”

“Poter tenere traccia degli eventi in modo semplice, intuitivo e con la pos-

sibilita di associare a tali eventi informazioni multimediali e di localizzazione.

Utile soprattutto se utilizzato da smartphone e tablet”

“E’ necessario imparare solo pochi comandi per poter creare una composizione”

119

APPENDICE C. OPINIONI DEGLI UTENTI 120

“E’ semplice da usare”

“Poter collegare anche servizi tra loro concettualmente distanti”

C.2 Suggerimenti

“Si potrebbero distinguere i marker tramite colori/forme diverse in base al ser-

vizio utilizzato” (rif. Template Mappa)

“Si potrebbe migliorare la gestione del cambio dei servizi”

“Sarebbe utile dotare il tool di funzionalita social per la condivisione delle

proprie composizioni”

“Facilitazione nell’interfaccia con funzionalita di Help”

“Abilitare le funzionalita avanzate (per utenti esperti) soltanto su richiesta”

“Facilitare l’esplorazione del pannello dati” (rif. risposte dei servizi)

“Superare le limitazioni dei servizi nativi utilizzati (Es. Google Maps)”

“Accentuare le differenze tra pulsanti con funzioni simili per evitare ambiguita”

Bibliografia

[1] Enterprise Mobility Markup Language ( EMML ).

http://en.wikipedia.org/wiki/EMML (Motorola).

[2] Cronbach’s alpha. http://en.wikipedia.org/wiki/Cronbach’s alpha.

[3] Abdallah Namoun; Tobias Nestler; Antonella De Angeli. Conceptual and

Usability Issues in the Composable Web of Software Services. ICWE

Workshops 2010.

[4] C. Cappiello; M. Matera; M. Picozzi; G. Sprega; D. Barbagallo; and

C. Francalanci. Dashmash: A mashup environment for end user deve-

lopment. In Proc. of ICWE 2011, Paphos, Cyprus, June 20-24, 2011,

volume 6757 of LNCS, pages 152-166. Springer, 2011.

[5] F. Daniel; F. Casati; B. Benatallah; and M.C. Shan. Hosted universal

composition: Models, languages and infrastructure in mashart. LNCS

5829, pages 428 - 443, 2009.

[6] A. Brodt and D. Nicklas. The telar mobile mashup platform for nokia

internet tablets. In Proc. of EDBT 2008, pages 700-704. ACM, 2008.

[7] M. Picozzi; M. Rodolfi; C. Cappiello; and M. Matera. Quality-based recom-

mendations for mashup composition. In Proc. of ComposableWeb 2010,

in print, 2010.

[8] C. Cappiello; F. Daniel; and M. Matera. A quality model for mashup

components. In ICWE, pages 236-250, 2009.

121

BIBLIOGRAFIA 122

[9] J. Yu; B. Benatallah; R. Saint-Paul; F. Casati; F. Daniel; and M. Matera.

A framework for rapid integration of presentation components. In Proc.

of WWW 2007, pages 923-932, 2007.

[10] B. Benatallah; F. Casati; M. Matera; F. Daniel; J. Yu and R. Saint-Paul.

Understanding ui integration: A survey of problems, technologies,and

opportunities. IEEE Internet Computing, 11(3):59-66, 2007.

[11] G. Fischer. End-user development and meta-design: Foundations for cul-

tures of participation. Journal of Organizational and End User Computing

(JOEUC), 2009.

[12] GoogleAppInventor. http://www.appinventorbeta.com/about/.

[13] Anthony T. Holdener. Ajax: the definitive guide. O’Reilly, 2008.

[14] J. Wong; J. I. Hong. Making mashups with marmite: towards end-user

programming for the Web. 2007.

[15] IBM. Qedwiki, http://services.alphaworks.ibm.com/graduated/qedwiki.html.

[16] Ideum. http://ideum.com/blog/2010/06/bp-oil-spill-multitouch-mashup/.

[17] JQueryUI. http://docs.jquery.com/Main Page.

[18] D. Soroker; Y. S. Paik; Y. S. Moon; S. McFaddin; C. Narayanaswami; H.

K. Jang; D. Coffman; M. C. Lee; J. K. Lee; and J. W. Park. User-driven

visual mashups in interactive public spaces. In Proc. of MobiQuitous 2008.

ACM, 2008.

[19] F. Daniel; M. Matera; and M. Weiss. Next in mashup development: User-

created apps on the Web. IT Professional, 13(5):22-29, 2011.

[20] Marco Fisichella; Maristella Matera. Process flexibility through custo-

mizable activities: A mashup-based approach. ICDE Workshops 2011:

226-231.

BIBLIOGRAFIA 123

[21] E. M. Maximilien. Mobile mashups: Thoughts, directions, and challenges.

In Proc. of ICSC, pages 597-600. IEEE Computer Society, 2008.

[22] Sandra Kaltofen; Marcelo Milrad; and Arianit Kurti. A Cross-Platform

Software System to Create and Deploy Mobile Mashups. Web Engineering:

10th International Conference, ICWE 2010, Vienna, Austria, 2010.

[23] Z. Obrenovic and D. Gasevic. Mashing up oil and water: Combining

heterogeneous service for diverse users. IEEE Internet Computing, pages

56-64, Nov/Dec 2009.

[24] M. Ogrinz. Mashup patterns: Designs and examples for the modern

enterprise. Addison-Wesley, 2009.

[25] World Health Organization. http://www.healthmap.org/.

[26] D. E. Simmen; M. Altinel; V. Markl; S. Padmanabhan; and A. Singh.

Damia: data mashups for intranet applications. In J. T.-L. Wang, editor,

SIGMOD Conference, pages 1171-1182. ACM, 2008.

[27] S. Peenikal. Mashups and the enterprise. MphasiS - HP, 2009.

[28] PhoneGap. http://www.phonegap.com/.

[29] JackBe. Jackbe presto. Technical report, http://www.jackbe.com/. 2010.

[30] P. Chaisatien; K. Prutsachainimmit; and T. Tokuda. Mobile mashup ge-

nerator system for cooperative applications of different mobile devices. In

Proc. ICWE 2011, volume 6757 of LNCS, pages 182-197. Springer, 2011.

[31] S. Cuccurullo; R. Francese; M. Risi; and G. Tortora. Microapps develop-

ment on mobile phones. In Proc. of IS-EUD 2011, volume 6654 of LNCS,

pages 289-294. Springer, 2011.

[32] J. HA¿kkilA¿; P. KorpipA¿A¿; S. Ronkainen; and U. Tuomela. Interac-

tion and end-user programming with a context-aware mobile application.

In Proc. of INTERACT 2005, volume 3585 of LNCS, pages 927-937, 2005.

BIBLIOGRAFIA 124

[33] Matjaz B. Juric; Benny Mathew; Poornachandra G. Sarang. Business

Process Execution Language for Web Services. 2006.

[34] ServFace. http://141.76.40.158/servface/.

[35] M. Davies; A. Fensel; F. Carrez; M. Narganes; D. Urdiales; and J. Da-

nado. Defining user-generated services in a semantically-enabled mobile

platform. In Proc. of iiWAS 2010, pages 333-340, 2010.

[36] E. von Hippel. Democratizing innovation. MIT Press, 2005.

[37] O. Chudnovskyy; H. Gebhardt; F. Weinhold; and M. Gaedke. Business

process integration using telco mashups. Procedia CS, 5:677-680, 2011.

[38] C. Cappiello; F. Daniel; M. Matera; M. Picozzi; M. Weiss. Enabling

End User Development through Mashups: Requirements, Abstractions and

Innovation Toolkits. Atti del convegno IS-EUD 2011, pp. 9-24, Springer

Verlag.

[39] The Free Encyclopedia Wikipedia. http://it.wikipedia.org/.

[40] Cedric Dumoulin; George Franciscus; David Winterfeldt. Struts in action:

building Web applications with the leading Java framework. Manning,

2003.

[41] JSON with Padding. http://json-p.org.

[42] Yahoo. http://pipes.yahoo.com/pipes/.

Date post:	17-Jun-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

POLITECNICO DI MILANO Corso di Laurea in Ingegneria ... · API (Application programming interface),...

Documents