Alcune prove pratiche

ˆ cache similarity, che non è altro se non il salvataggio dei dati relativi alla similarità in cache in modo tale da avere sempre disponibili questi dati, concetto che già è stato accennato parlando delle ottimizzazioni apportate all'algoritmo fulcro della presente trattazione;

ˆ gestione dei processi;

ˆ gestione degli utenti, rendendo possibile un certo livello di personalizzazione, ad esempio mostrando allo specico utente solo un gruppo di componenti appartenenti ad una tipologia che lui solitamente utilizza (ad esempio un creatore di mashup, che crea mashup solo relativi all'ambito del turismo).

Ribadiamo, inne, che tutta la nostra architettura ruota sull'utilizzo dell'ap- plication server (nel nostro caso Jboss). In particolare si propone la specica archi- tettura per l'algoritmo di similarità in gura 5.1, dove tutte le componenti tranne il web client sono inseriti all'interno della piattaforma DashMash.

Vine mostrata anche l'architettura relativa alle valutazioni di qualità (gura 5.2), dove un Quality Manager, che risiede sul client invia una richiesta al servizio Rest, che appoggiandosi anche a JBoss fornisce il servizio di qualità e restituisce i risultati al client tramite Json (JavaScript Object Notation è un semplice formato per lo scambio di dati).

5.2 Alcune prove pratiche

In questa sezione ci dedichiamo a valutare i principali risultati ottenuti e a commentare il loro impatto. La sezione dedicata alle prove è stata introdotta anche per far comprendere più agevolmente come si presenteranno e risultati al- l'utente nale e e come egli potrà sfruttarli in modo ottimale. Verranno riportate i risultati di sperimentazione nella forma tabulare che si presenterà nell'interfaccia lato client. In questo modo non solo ci si è dedicati a descrivere il back-end lato server, ma si darà una visione d'insieme globale e più completa.

Per prima cosa diamo una descrizione dell'insieme di componenti che abbiamo utilizzato per le nostre prove:

5.2. Alcune prove pratiche

Figura 5.1: La distribuzione del calcolo della similarità nei componenti architetturali

5.2. Alcune prove pratiche

Figura 5.2: La distribuzione del calcolo della qualità nei componenti architetturali

ˆ FindPos: è un componente che a fronte di coordinate di latitudine e longi- tudine in input, restituisce in uscita un luogo geograco;

ˆ SearchPos: analogamente a FindPos, è un componente che a fronte di coor- dinate di latitudine e longitudine in input, restituisce in uscita un luogo geograco;

ˆ CaloriesShow: dato un percorso tra due luoghi espressi in termini di longi- tudine e latitudine e la velocità dello spostamento, restituisce in uscita le calorie bruciate;

ˆ CaloriesService: mostra gracamente il livello di calorie bruciate a fronte dell'aggiornamento di un indicatore delle calorie;

ˆ GeoNames: è un componente che a fronte di coordinate di latitudine e lon- gitudine in entrata, restituisce come output un indirizzo di un luogo (in termini di città e via);

5.2. Alcune prove pratiche

ˆ Gmap: è un componente che a fronte di coordinate di latitudine e longitu- dine, unitamente ad un livello di zoom in ingresso, mostra in output una mappa geograca.

Proponiamo quindi delle tabelle che ragurino delle matrici di compatibi- lità seriale e parallela ottenute simulando il nostro algoritmo su un gruppo di componenti (tabelle 5.1 e 5.2).

FindPos SearchPos GeoNames CaloriesService CaloriesShow Gmap

FindPos 1 1 1 0 0 1 SearchPos 1 1 1 0 0 1 GeoNames 1 1 1 0 0 1 CaloriesService 0 0 0 1 0 0 CaloriesShow 0 0 0 0 1 0 Gmap 1 1 1 0 0 1

Tabella 5.1: Matrice di compatibilità parallela simulata

FindPos SearchPos GeoNames CaloriesService CaloriesShow Gmap

FindPos 0 0 0 1 1 0 SearchPos 0 0 0 1 1 0 GeoNames 0 0 0 1 1 0 CaloriesService 1 1 1 0 1 1 CaloriesShow 1 1 1 1 0 1 Gmap 0 0 0 1 1 0

Tabella 5.2: Matrice di compatibilità seriale simulata

Si nota subito che le matrici sono sparse (e il grado di sparsità aumenta con il numero di componenti presenti) e simmetriche. Per quanto riguarda questa prova sulla compatibilità ci riteniamo molto soddisfatti, dal momento che si trova una eettiva rispondenza dell'algoritmo implementato alle aspettative che ci si era posti. Il confronto sintattico sui tipi è quindi riuscito. Riteniamo opportuno precisare che questo è solo un estratto minimale di tutte le prove che sono state fatte e che in generale tutte le altre prove hanno fornito risultati altrettanto validi, anche su gruppi più numerosi di componenti.

Proseguendo nella valutazione pratica del nostro algoritmo passiamo ora ad analizzare la matrice di similarità ottenuta sia col metodo di similarità verticale,

5.2. Alcune prove pratiche

sia col metodo di similarità orizzontale, sempre sul medesimo range di componenti (tabelle 5.3 e 5.4).

FindPos SearchPos GeoNames CaloriesService CaloriesShow Gmap

FindPos 1 0.923 0.457 0 0 0.516 SearchPos 0.923 1 0.521 0 0 0.608 GeoNames 0.457 0.521 1 0 0 0.712 CaloriesService 0 0 0 1 0 0 CaloriesShow 0 0 0 0 1 0 Gmap 0.516 0.608 0.712 0 0 1

Tabella 5.3: Matrice di similarità verticale simulata

FindPos SearchPos GeoNames CaloriesService CaloriesShow Gmap

FindPos 0 0 0 0.432 0.678 0 SearchPos 0 0 0 0.498 0.636 0 GeoNames 0 0 0 0.516 0.534 0 CaloriesService 0.432 0.498 0.516 0 0.879 0.328 CaloriesShow 0.678 0.636 0.534 0.879 0 0.327 Gmap 0 0 0 0.328 0.327 0

Tabella 5.4: Matrice di similarità orizzontale simulata

I valori ottenuti nelle matrici di similarità sono soddisfacenti in merito a quello che si era previsto che accadesse. I valori registrati sono stati ottenuti aggregando i singoli valori come descritto nello pseudocodice dell'algoritmo di similarità. Di nuovo troviamo matrici simmetriche, che ricalcano esattamente quanto ottenuto con le matrici di compatibilità, con la dierenza che in questo caso al posto di un generico 1, abbiamo dei coecienti accuratamente calibrati, come ampiamente de- scritto nela sezione dedicata all'algoritmo di similarità. Chiaramente i componenti confrontati con sé stessi avranno coeciente di similarità unitario nelle matrice di similarità. Le sperimentazioni sono state molteplici e tutte hanno condotto a risul- tati graticanti, parimenti a quelli mostrati nelle tabelle 5.3 e 5.4. L'utente tramite l'interfaccia graca potrà visionare anche i dati disaggregati e potrà variare i pesi descritti nell'algoritmo (chiaramente solo quelli variabili dall'utente tramite menù a tendina) a suo piacimento e a seconda delle sue speciche necessità.

A questo punto non resta che proporre i risultati che si sono ottenuti tramite l'algoritmo per il calcolo della qualità. Prendiamo, ad esempio, i componenti già

5.2. Alcune prove pratiche

utilizzati per le altre sperimentazioni riportate. A fronte delle annotazioni inter- ne dei componenti (ovviamente relative alla qualità), si sono ottenuti i valori di qualità riportati in tabella 5.5.

Componenti FindPos SearchPos GeoNames CaloriesService CaloriesShow Gmap

Qualità 0.5562 0.6437 0.7687 0.6125 0.6001 0.989

Tabella 5.5: Valori simulati di qualità dei singoli componenti

Notiamo subito che questo dato di qualità ci permette di avere ulteriori infor- mazioni in merito ai componenti e ci fornisce un ulteriore spunto di scelta ai ni della componentizzazione. Si osserva infatti che due componenti molto simili come FindPos e SearchPos, hanno dierenti valori di qualità: in particolare SearchPos ha qualità maggiore rispetto a FindPos. Ovviamente oltre al dato di qualità l'uten- te può osservare i dati disaggregati, che permettono di valutare le caratteristiche qualitative singole. Nuovamente possiamo asserire che l'algoritmo si comporta nel modo sperato, fornendo valori ragionevoli. Ancora diciamo i dati riportati sono un sunto delle sperimentazioni fatte. Per concludere la sezione proponiamo un dato sulla qualità di un mashup. Si sono utilizzati cinque dei sei componenti descritti sopra, collegandoli tra loro in modo da formare un grafo con cinque nodi pari al numero dei componenti e gli archi orientati corrispondenti ai binding, come mo- srato in gura 5.3. Indubbiamente ci sono molteplici combinazioni possibili con questi cinque e/o con altri componenti, ma qui riportiamo un grafo o mashup di prova, a titolo esemplicativo.

Procedendo secondo il metodo dell'importanza si è ottenuta una qualità globale del grafo, o del mashup (analogamente), pari a 0.6380. Ricordiamo che l'algoritmo mette a disposizione dell'utente anche una funzionalità che permette di calcolare il dato disaggregato di qualità per il mashup (ad esempio solo la reputazione o solo la accuratezza e così via).

Concludiamo questa sezione dichiarandoci soddisfatti dei risultati ottenuti. Non si esclude, comunque, che vi possano essere ulteriori ottimizzazioni, ma per questo rimandiamo alla sezione relativa agli eventuali sviluppi futuri.