Architettura Sw e Dati
Sistema per il Turismo Gastronomico (STG)
Federico Valentini 726584,
Appello 14 Luglio 2015
Testo del problema (1)
Si deve realizzare un Sistema per il Turismo Gastronomico (STG), che consente a utenti nomadici di acquisire
informazioni su ristoranti, inserire e leggere commenti, stabilire contatti con altri utenti. STG interagisce con
una Guida Ristoranti GR online preesistente e con un sistema di gestione mappe GM (ad esempio Google
Maps).
Il sistema STG deve essere accessibile sia da PC sia da terminale mobile (smartphone o tablet) e deve
consentire a un turista T di:
●
●
●
Specificare una zona di suo interesse Z T fornendo un indirizzo stradale e una distanza massima. Nel caso
di terminale mobile, deve essere possibile specificare solo la distanza rispetto alla locazione attuale dell’
utente. La validità della zona di interesse di un turista scade dopo 24 ore e, nel caso di utilizzo di un
terminale mobile, quando il turista esce dalla zona
Acquisire l’elenco dei ristoranti in Z T , con possibilità di ordinarli in base alle valutazioni di prezzo o di
qualità
Selezionare un ristorante e visualizzare le informazioni relative, sia fornite da GR, sia fornite da altri
turisti
Testo del problema (2)
●
●
●
Inserire valutazioni e commenti su un ristorante, archiviati in forma anonima. Le valutazioni riguardano il
prezzo (in euro) e la qualità (su scala da 1 a 5). I commenti sono in forma testuale.
Aprire un thread di conversazione accessibile ad altri turisti V con una zona di interesse Z V a intersezione
non vuota con Z T . Il thread viene automaticamente chiuso quando scade la validità di Z T
Ricevere una notifica a fronte dell’apertura di un thread da parte di un altro utente V con una zona di
interesse Z V a intersezione non vuota con Z T
Si richiede di definire, utilizzando i formalismi opportuni:
●
●
●
●
●
l’architettura del sistema STG in termini di informazioni e flussi informativi, comprendendo le
informazioni che STG deve poter scambiare con GR e GM;
l’architettura logica STG in termini di componenti di elaborazione;
l’architettura concreta STG in termini di modalità di interazione fra componenti;
l’architettura di deployment di STG;
le scelte tecnologiche (componenti hw, reti di comunicazione, piattaforme sw) relative a STG
argomentando in modo quantitativo le scelte fatte in base alla natura e alla quantità di dati da elaborare,
archiviare, trasferire tra i vari componenti del sistema e rendere disponibili ai suoi vari utenti.
Testo del problema (3)
Si supponga che GR gestisca le informazioni per nome del ristorante e per indirizzo, cioè in quale via di quale
località si trova un ristorante, ma non gestisca informazioni di georeferenziazione. Si richiede di definire:
●
●
●
●
●
le modalità e i problemi di integrazione fra STG, GR e GM. Si supponga di disporre dello schema
concettuale e dello schema logico relazionale delle due basi dati a. di supporto al sistema STG, b. GR, e
del solo schema logico relazionale della base dati GM. Si scelgano tali schemi in modo coerente con
quanto usualmente avviene nella realtà, e cioè caratterizzati da diverse tipologie di eterogeneità. Si
richiede di definire;
lo schema concettuale della base dati GM;
lo schema globale delle basi dati STG, GR e GM, ottenuto per mezzo della integrazione dei singoli schemi
concettuali;
assumendo di utilizzare una architettura di integrazione dati (virtual data integration), e assumendo di
scegliere i mapping secondo la modalita’ Global as View, i mapping tra schema logico globale relazionale
e schemi locali di STG, GR e GM;
una interrogazione sullo schema globale, con il suo unfolding sui tre schemi locali.
Terminologia
Utente: turista che utilizza il sistema
Zona di interesse (o zona): zona designata dall’utente, il quale desidera ottenere informazioni riguardo i
ristoranti presenti
Sottozona comune: area creata dall’intersezione di due o più zone di interesse
Validità (di una zona di interesse): una zona può essere considerata valida o no a seconda di quanto tempo è
trascorso dall’indicazione della stessa da parte dell’utente (24 ore se effettuata da PC, altrimenti fino a quando
l’utente risulta fisicamente in quella zona specificata)
Assunzioni - Coordinate e distanza
La zona di interesse viene trattata come un dato composto da:
●
●
locazione (coordinate gps)
distanza (metri)
Con questi due parametri risulta possibile calcolare se due o più utenti abbiano una intersezione
comune utilizzando la “Formula dell’Emisenoverso” (http://stackoverflow.com/questions/365826/calculate-distancebetween-2-gps-coordinates)
Inoltre ipotizzo di settare un limite di distanza massima in modo da rendere l’applicazione più efficiente
e meglio utilizzabile.
Assunzioni - Guida Ristoranti
Guida Ristoranti (GR) risulta essere un sistema web già esistente (quindi esterno al progetto) che
permette di essere interrogato per recuperare informazioni relative ad un singolo ristorante.
Quindi assumo l’esistenza di un’API (Application Programming Interface) già definita che permette di
essere invocata inserendo il ristorante. Una volta invocata, il sistema esterno GR ritornerà le
informazioni (sotto forma di testo) presenti nel proprio database interno.
Queste informazioni andranno quindi ad integrare le informazioni di un ristorante generate dal nostro
sistema (commenti e valutazioni degli utenti).
Inoltre assumo che per ogni ristorante presente nel sistema GR esista una e una sola descrizione
testuale che riassuma le caratteristiche salienti e non del ristorante in questione.
Assunzioni - Apertura di un Thread
Il sistema, quando un utente decide di aprire un thread di conversazione riguardo alla propria zona di interesse,
ne consente la creazione anche nel caso non ci siano utenti attivi in quella zona.
Il thread rimane disponibile finchè la zona di interesse del turista risulta valida.
Al momento dell’apertura di un thread tutti gli altri utenti attivi in una sottozona comune vengono notificati.
Assunzioni - Login e Registrazione
Nei diagrammi che seguiranno tutte le azioni che sono intraprese dall’utente del sistema, implicano il corretto
login al nostro sistema.
Quindi nel modello dei casi d’uso verrà omessa l’include dell’azione di login in tutte le azioni che l’utente può
intraprendere, per rendere il diagramma più leggibile.
Inoltre sarà ovviamente presente una funzione di Registrazione che permette a turisti non iscritti di creare il
proprio profilo e diventare effettivamente un utente del sistema.
Architettura
del problema
Casi d’uso
Diagramma dei dati
Diagramma delle attività - Registrati
Diagramma delle attività - Login
Diagramma delle attività - Acquisisci elenco
ristoranti
Diagramma delle attività - Specifica una zona di interesse
Diagramma delle attività - Visualizza informazioni relative ad
un ristorante
Diagramma delle attività - Inserisci valutazione o
commento
Diagramma delle attività - Apri thread di
conversazione
Diagramma delle attività - Ricevi notifica
messaggio
Architettura
logica
Architettura Logica - Componenti rilevate
Architettura
concreta
Diagramma di sequenza - Registrati
Diagramma di sequenza - Login
Diagramma di sequenza - Inserisci valutazione o commento
Diagramma di sequenza - Apri thread di conversazione
Diagramma di sequenza - Ricevi notifica messaggio
Diagramma di sequenza - Specifica una zona di interesse
Diagramma di sequenza - Acquisisci elenco ristoranti
Architettura
di Deployment
Soluzione scelta - Architettura centralizzata
PRO:
1.
2.
3.
Bassi costi di gestione e sviluppo
Gestione centralizzata del sistema
Moderata larghezza di banda necessaria
CONTRO:
1.
2.
Gestione dei ritardi in caso di alto numero di richiesta (Internet Bottleneck)
Bassa resistenza ai guasti (malfunzionamenti possono potenzialmente bloccare il servizio)
Architettura di Deployment
Architettura
dei Dati
GM - Schema ER e Schema Logico
Google_Maps(id, via, civico, lat, long, città, provincia, stato)
GR - Schema ER e Schema Logico
Ristorante(id, nome, via, civico, città, provincia, descrizione)
STG - Schema ER
STG - Schema Logico
Utente(id_utente, nome, cognome, email, data_nascita, attivo, username, password, url_attivazione)
Zona di Interesse(id_zona, id_utente, distanza_locazione, valida_ora, long, lat)
Thread(id_thread, titolo, stato_thread)
Messaggio(id_messaggio, id_utente, id_thread, timestamp, testo_messaggio)
Commento(id_commento, id_ristorante, timestamp, testo_commento)
Valutazione(id_valutazione, id_ristorante, qualità, prezzo)
Corrispondenze/Eterogeneità (1)
STG
GR
TIPO
Scelta
Valutazione.id_ristorante
id
Sinonimia
id
Commento.id_ristorante
id
Sinonimia
id
Corrispondenze/Eterogeneità (2)
STG
GM
TIPO
Scelta
Ristorante.latitudine
Civico.lat
Sinonimia
lat
Ristorante.longitudine
Civico.long
Sinonimia
long
Scelte Architetturali (1)
Si è scelto di unificare gli schemi logici utilizzando il processo
EII (Enterprise Information Integration)
che ci permette di fornire un unica interfaccia per la visualizzazione di tutti i dati presenti nei singoli database.
Questo può essere implementato in due modi:
1.
2.
Data Warehousing: viene creato un nuovo database fisico in cui vengono copiati tutti i dati dei singoli DB
secondo lo schema logico globale (durante questa operazione possono essere effettuate operazioni per il
miglioramento della qualità dei dati, e.g. Record Linkage). Tutte le interrogazioni vengono eseguite sul
nuovo database. Periodicamente è necessario effettuare un riallineamento dei dati del database globale
con quelli dei singoli database locali.
Virtual Data Integration: viene creato uno schema logico globale che fornisce un’interfaccia unificata di
visualizzazione dei dati. Tutte le interrogazioni che vengono effettuate su questa interfaccia vengono
riadattate, attraverso un mediatore, agli schemi logici dei singoli database.
Scelte Architetturali (2)
La soluzione proposta si basa su Virtual Data Integration:
L’architettura prevede che i dati rimangano nei database attuali e siano acceduti tramite un mediatore che
riadatta le interrogazioni sullo schema logico virtuale a interrogazioni locali sui singoli database.
I mapping utilizzati dal mediatore sono stati definiti con la modalità Global As View (GAV).
Modello ER Integrato
Schema Logico Integrato
Utente(id_utente, nome, cognome, email, data_nascita, attivo, username, password, url_attivazione)
Zona di Interesse(id_zona, id_utente, distanza_locazione, valida_ora, long, lat)
Thread(id_thread, id_utente, titolo, stato_thread)
Messaggio(id_messaggio, id_utente, id_thread, timestamp, testo_messaggio)
Ristorante(id, nome, descrizione,via, civico, città, provincia, lat, long)
Commento(id_commento, id_ristorante, timestamp, testo_commento)
Valutazione(id_valutazione, id_ristorante, qualità, prezzo)
Mapping
-
Utente(id_utente, nome, cognome, email, data_nascita, attivo, username, password, url_attivazione)
CREATE VIEW Utente AS
SELECT id_utente, nome, cognome, email, data_nascita, attivo, username, password, url_attivazione
FROM STG.Utente
-
Zona di Interesse(id_zona, id_utente, distanza_locazione, valida_ora, long, lat)
CREATE VIEW Zona di Interesse AS
SELECT id_zona, id_utente, distanza_locazione, valida_ora, long, lat
FROM STG.Zona_DI_Interesse
-
Thread(id_thread, id_utente, titolo, stato_thread)
CREATE VIEW Thread AS
SELECT id_thread, id_utente, titolo, stato_thread
FROM STG.Thread
Mapping
-
Messaggio(id_messaggio, id_utente, id_thread, timestamp, testo_messaggio)
CREATE VIEW Messaggio AS
SELECT id_messaggio, id_utente, id_thread,timestamp, testo_messaggio
FROM STG.Messaggio
-
Commento(id_commento, id_ristorante, timestamp, testo_commento)
CREATE VIEW Commento AS
SELECT id_commento, id_ristorante, timestamp, testo_commento
FROM STG.Commento
-
Valutazione(id_valutazione, id_ristorante, qualità, prezzo)
CREATE VIEW Valutazione AS
SELECT id_valutazione, id_ristorante, qualità, prezzo
FROM STG.Valutazione
Mapping
-
Ristorante(id, nome, descrizione, via, civico, città, provincia, lat, long)
CREATE VIEW Ristorante AS
SELECT “”, nome_ristorante AS nome, ”” ,via, civico città, “” , ””, “”
FROM STG.Valutazione
UNION
SELECT “”, nome_ristorante AS nome, ”” ,via, civico città, “” , ””, “”
FROM STG.Commento
UNION
SELECT id_ristorante, nome_ristorante AS nome, descrizione, via, civico, città, provincia,””, “”)
FROM GR.Ristorante
UNION
SELECT “”, “”, “”, via, civico, città, provincia,lat, long
FROM GM.Google_Maps
Query
-
Recuperare i commenti relativi al ristorante “The Fork” di Milano, con sede in via Ponte Nuovo.
SELECT timestamp, testo_commento
FROM Commento
WHERE id_ristorante = ( SELECT id
FROM Ristorante
WHERE nome = ‘The Fork’ AND città = ‘Milano’ AND via = ‘Ponte Nuovo’
)
Unfolding
SELECT timestamp, testo_commento
FROM Commento
WHERE id_ristorante = ( SELECT id
FROM (
SELECT “”, nome_ristorante AS nome, ”” ,via, civico città, “” , ””, “”
FROM STG.Valutazione
UNION
SELECT “”, nome_ristorante AS nome, ”” ,via, civico città, “” , ””, “”
FROM STG.Commento
UNION
SELECT id_ristorante, nome_ristorante, descrizione, via, civico, città, provincia,””, “”)
FROM GR.Ristorante
UNION
SELECT “”, “”, “”, via, civico, città, provincia,lat, long
FROM GM.Google_Maps
)
WHERE nome = ‘The Fork’ AND città = ‘Milano’ AND via = ‘Ponte Nuovo’
)
