Anno Accademico 2014/2015

UNIVERSITÀ DEGLI STUDI DI TRIESTE

DIPARTIMENTO DI INGEGNERIA ED ARCHITETTURA

CORSO DI LAUREA TRIENNALE IN INGEGNERIA DELL'INFORMAZIONE

CURRICULUM INFORMATICA

PROGETTAZIONE ED IMPLEMENTAZIONE DI UNA PIATTAFORMA

SOFTWARE PER LA GESTIONE REMOTA E IL CONTROLLO DEGLI ACCESSI DI UNA SALA PROVE MUSICALI

RELATORE Chiar.mo Prof. Maurizio Fermeglia

LAUREANDO

Lorenzo Rossoni

1

Indice

1 Introduzione .............................................................................................................................................. 3

1.1 Obiettivo della tesi............................................................................................................................. 3

1.2 Risultato della tesi ............................................................................................................................. 3

1.3 Motivazione ....................................................................................................................................... 3

1.4 Stato dell’arte .................................................................................................................................... 4

1.5 Tecnologie ......................................................................................................................................... 4

1.6 Riassunto dei capitoli seguenti .......................................................................................................... 5

2 Analisi ........................................................................................................................................................ 6

2.1 Raccolta delle informazioni e definizione dei requisiti ...................................................................... 6

2.2 Analisi dell'infrastruttura per la piattaforma .................................................................................... 6

2.3 Analisi dettagliata dei casi d’uso ....................................................................................................... 7

2.3.1 Analisi dettagliata del caso d’uso dell’utente amministratore.................................................. 8

2.3.2 Analisi dettagliata del caso d’uso dell’utente fruitore .............................................................. 9

3 Progettazione della base di dati .............................................................................................................. 10

3.1 Glossario dei termini ....................................................................................................................... 10

3.2 Strutturazione dei requisiti .............................................................................................................. 10

3.3 Operazioni previste ......................................................................................................................... 11

3.4 Progettazione concettuale .............................................................................................................. 12

3.4.1 Entità e relazioni ...................................................................................................................... 12

3.4.2 Analisi delle entità ................................................................................................................... 13

3.4.3 Analisi delle relazioni e delle cardinalità ................................................................................. 15

3.4.4 Business rules .......................................................................................................................... 17

3.5 Progettazione logica ........................................................................................................................ 17

3.5.1 Tavola dei volumi ..................................................................................................................... 17

3.5.2 Tavola delle operazioni ............................................................................................................ 17

3.5.3 Ristrutturazione dello schema E-R .......................................................................................... 18

3.5.4 Scelta degli identificatori principali ......................................................................................... 20

3.5.5 Scelta delle chiavi esterne ....................................................................................................... 20

3.5.6 Schema fisico ........................................................................................................................... 21

3.6 Programmabilità .............................................................................................................................. 22

3.6.1 Vincoli di integrità e indici di unicità ....................................................................................... 22

3.6.2 Triggers e stored procedures ................................................................................................... 22

2

4 Progettazione della piattaforma ............................................................................................................. 24

4.1 Progettazione del portale web ........................................................................................................ 24

4.1.1 Area utente anonimo .............................................................................................................. 25

4.1.2 Area utente fruitore ................................................................................................................ 25

4.1.3 Area utente amministratore .................................................................................................... 25

4.2 Progettazione della Web API ........................................................................................................... 26

4.2.1 OAuth ....................................................................................................................................... 26

4.2.2 Notifications ............................................................................................................................ 27

4.2.3 Bookings .................................................................................................................................. 27

4.2.4 Users ........................................................................................................................................ 27

4.2.5 Rooms ...................................................................................................................................... 27

4.3 Progettazione dell’applicazione mobile .......................................................................................... 27

4.4 Progettazione del dispositivo di controllo remoto .......................................................................... 28

5 Interfaccia ................................................................................................................................................ 30

5.1 Interfaccia del portale web .............................................................................................................. 30

5.2 Interfaccia dell’applicazione mobile ................................................................................................ 34

5.3 Interfaccia del dispositivo di controllo ............................................................................................ 35

6 Implementazione ..................................................................................................................................... 36

6.1 Implementazione del portale web e della Web API ........................................................................ 36

6.2 Implementazione dell’applicazione mobile ..................................................................................... 40

7 Conclusioni .............................................................................................................................................. 43

7.1 Risultati ottenuti .............................................................................................................................. 43

7.2 Lavoro svolto ................................................................................................................................... 43

7.3 Scenari di sviluppo futuri ................................................................................................................. 43

8 Bibliografia e sitografia ............................................................................................................................ 45

8.1 Riferimenti bibliografici ................................................................................................................... 45

8.2 Riferimenti sitografici ...................................................................................................................... 45

3

1 – Introduzione

1.1 – Obiettivo della tesi

Lo scopo di questa tesi è la creazione e la progettazione di una piattaforma software finalizzata alla

gestione remota e al controllo degli accessi di una sala prove musicali.

Si intende fornire uno strumento capace di semplificare e automatizzare alcuni aspetti relativi

all'amministrazione e alla fruizione del servizio. In particolare tra le funzionalità destinate all'utente

amministratore troviamo:

Gestione delle transazioni e del credito utente Gestione del calendario delle prenotazioni Gestione remota dei locali adibiti a sala prove

Dal punto di vista dell'utente fruitore il progetto si propone di fornire un sistema semplificato che consenta:

Prenotazione da remoto Gestione delle transazioni e del credito utente Gestione dello storico delle transazioni e delle prenotazioni Accesso automatizzato ai locali tramite autenticazione NFC1 (Smartphone HCE2-enabled o

SmartCard3)

1.2 – Risultato della tesi

Il risultato di questa tesi è rappresentato dalla piattaforma software “Rehearsal Room Manager” costituita

da quattro elementi principali, i cui dettagli saranno analizzati successivamente in maniera più specifica.

Questi elementi sono:

Un portale web unificato per l’utente amministrazione e per l’utente fruitore accessibile

all’indirizzo web http://rehearsalroommanager.azurewebsites.net

Un’applicazione mobile per Smartphone e Tablet Windows 10 dedicata agli utenti fruitori

disponibile al seguente indirizzo web https://www.microsoft.com/store/apps/9nblggh3tq8l

Un dispositivo hardware di controllo remoto progettato per l’automazione dei locali adibiti a sale

prova

Un’infrastruttura di Web API REST4 il cui compito è di coordinare e interconnettere i precedenti

elementi

1.3 – Motivazione

L’idea alla base di questo progetto nasce dalla constatazione dell’esistenza di uno squilibrio tra l’offerta di

sale prova e la crescente domanda e dalla conseguente necessità di trovare soluzioni per abbattere i costi di

avvio e di gestione di una struttura adibita a tale scopo.

Mediante l’utilizzo di questa piattaforma infatti si intende automatizzare e centralizzare alcuni aspetti

1 https://en.wikipedia.org/wiki/Near_field_communication 2 https://en.wikipedia.org/wiki/Host_card_emulation 3 https://en.wikipedia.org/wiki/Contactless_smart_card 4 https://en.wikipedia.org/wiki/Representational_state_transfer

1 – Introduzione

4

fondamentali di tale attività, quali il sistema di prenotazione, di pagamento e di accesso fisico alla sala, in

maniera tale da ridurre al minimo l’impiego di personale dedicato.

1.4 – Stato dell’arte

Al momento dello sviluppo del progetto sono state individuate strutture che forniscono un sistema di

prenotazione online ma non forniscono un servizio analogo a quello che si intende fornire. Sono presenti

invece sul mercato alcuni prodotti commerciali dalle funzionalità simili dedicati però a diverse aree di

interesse.

1.5 – Tecnologie

Durante le varie fasi dello sviluppo del progetto si è fatto uso delle seguenti tecnologie e librerie software:

Applicazione web e Web API REST

o HTML5 e CSS3

o Microsoft ASP.NET MVC 55

o Microsoft .NET Entity Framework 66

o Newtonsoft Json.NET7

o Microsoft Azure Web Apps8

o Microsoft Azure SQL Database9

o Microsoft Azure Notification Hubs10

o SignalR11

o jQuery12

o Bootstrap13

Applicazione mobile

o Microsoft Windows Universal Platform14 (XAML + C#)

o Newtonsoft Json.NET

Dispositivo di controllo remoto

o .NET Micro Framework 4.315

o .NET Gadgeteer16

o Json.NETMF17

Per la progettazione e lo sviluppo dei precedenti componenti software si è fatto uso dell’IDE Microsoft

Visual Studio 2015.

L’Applicazione Web, la Web API e il relativo database sono ospitati sulla piattaforma di cloud computing

5 http://www.asp.net/mvc 6 https://msdn.microsoft.com/en-us/data/ef 7 http://www.newtonsoft.com/json 8 https://azure.microsoft.com/en-us/services/app-service/web/ 9 https://azure.microsoft.com/en-us/services/sql-database/ 10 https://azure.microsoft.com/en-us/services/notification-hubs/ 11 http://signalr.net 12 https://jquery.com 13 http://getbootstrap.com 14 https://msdn.microsoft.com/en-us/library/windows/apps/dn958439.aspx 15 http://www.netmf.com 16 http://www.netmf.com/gadgeteer/ 17 https://github.com/mweimer/Json.NetMF

1 – Introduzione

5

Microsoft Azure sfruttando una sottoscrizione riservata agli studenti universitari fornita tramite il

programma DreamSpark18.

1.6 – Riassunto dei capitoli seguenti

Nel capitolo 2 verranno analizzate le informazioni raccolte e, sulla base di queste, saranno

determinati i requisiti del progetto. Successivamente ci si occuperà dell'analisi e della progettazione

dell'infrastruttura per la piattaforma

Il capitolo 3 si occuperà dell'analisi e della progettazione della base di dati per il sistema

Nel capitolo 4 verrà approfondita la fase di progettazione dei vari componenti della piattaforma

Il capitolo 5 si occuperà della progettazione dell’interfaccia per il portale web e per l’applicazione

mobile. Verranno inoltre presentati alcuni esempi tipici di utilizzo

Nel capitolo 6 saranno descritte le funzioni implementate all’interno del portale web e

dell’applicazione mobile

Nel capitolo 7 verranno esposte le conclusioni riguardanti il progetto e saranno presentati alcuni

possibili scenari di sviluppo e miglioramento

Infine nel capitolo 8 sarà presente una breve bibliografia e sitografia

18 https://www.dreamspark.com

6

2 – Analisi

2.1 – Raccolta delle informazioni e definizione dei requisiti

Lo scopo di questo progetto è la realizzazione di una piattaforma software per l’amministrazione delle

utenze di una sala prove, è quindi chiaro che una delle fondamentali funzionalità che questo dovrà fornire è

rappresentata da un sistema di gestione dei dati anagrafici e di fatturazione associati agli utenti.

Dopo una breve analisi dei ruoli, si possono distinguere all’interno del sistema due tipi di utenze cui la

piattaforma si rivolgerà: gli utenti fruitori saranno coloro che beneficeranno del servizio di noleggio delle

sale, mentre gli utenti amministratori saranno quegli utenti preposti alla supervisione e alla gestione del

sistema.

Considerati i presupposti del progetto, oltre alla gestione anagrafica, la piattaforma dovrà implementare un

sistema di gestione delle prenotazioni che dovrà essere in grado di gestire parallelamente e in maniera

semplice più sale prove e pensato in modo tale da scongiurare alcuni tipici inconvenienti, come ad esempio

l’immissione di prenotazioni concorrenti.

La piattaforma fornirà inoltre un meccanismo di credito utente, ricaricabile direttamente dal portale web o

dall’applicazione, volto a permettere un’efficiente amministrazione delle transazioni anche in caso di

disdetta delle prenotazioni.

Tale meccanismo consentirà inoltre all’utente di tenere facilmente traccia delle operazioni di prenotazione

effettuate e dei costi sostenuti direttamente dai propri dispositivi.

Infine sarà presente un sistema di automazione dei locali che includerà un meccanismo di autenticazione

basato su una chiave elettronica NFC (emulabile tramite Smartphone che supportano la tecnologia HCE) e

una serie di funzionalità dedicate alla gestione remota da parte degli amministratori.

Il meccanismo di autenticazione basato su chiave elettronica permetterà ad ogni utente fruitore di

possedere al più una SmartKey e uno Smartphone abilitati contemporaneamente ed è pensato per rendere

la gestione degli accessi più semplice e sicura, eliminando l’esigenza di una chiave fisica e permettendo una

facile revoca del diritto di accesso.

Per quanto riguarda invece le funzionalità remote, queste comprenderanno la possibilità di gestire

l’impianto di illuminazione e alimentazione principale delle singole sale e di bloccarne o sbloccarne

temporaneamente gli accessi.

2.2 – Analisi dell'infrastruttura per la piattaforma In questa sezione analizzeremo la struttura della piattaforma e le modalità di interazione tra le diverse parti

che la compongono. Come abbiamo precedentemente anticipato, queste sono:

Applicazione Web

Web API REST

Applicazione Mobile

Dispositivo di controllo remoto

L’Applicazione Web e l’Applicazione Mobile rappresentano l’interfaccia di comunicazione diretta tra

l’utente e il sistema, attraverso queste infatti l’utente può accedere ai servizi di prenotazione, di gestione

del credito e di modifica delle informazioni personali offerti dalla piattaforma.

2 – Analisi

7

Un ruolo fondamentale è svolto dalla Web API, questa infatti rappresenta la modalità con la quale sia

l’Applicazione Mobile che il dispositivo di gestione remota interagiscono con il sistema e la relativa base di

dati.

Tramite la Web API infatti il sistema è in grado di ricevere informazioni e impartire comandi ai dispositivi di

controllo remoto situati nelle sale, e sempre grazie alla Web API gli stessi dispositivi forniscono la

funzionalità di autenticazione e di accesso ai locali.

Smartphone

Database

PC

Applicazione WebWeb API

Dispositivo di accesso e di controllo remoto

SmartKey

Figura 1 – Struttura della piattaforma

La base di dati infine rappresenta il nodo principale dell’infrastruttura, ad essa sono infatti collegati

l’Applicazione Web e la Web API, ed in essa sono contenute tutte le informazioni che consentono al sistema

fornire e di coordinare le varie funzionalità.

2.3 – Analisi dettagliata dei casi d’uso Esamineremo ora le modalità fondamentali con cui gli utenti, amministratori e fruitori interagiscono con il

sistema e le fasi di tali interazioni.

2 – Analisi

8

Notifica di prenotazione

ConfermaNo

Notifica di conferma della prenotazione

Sì

Inserimento della prenotazione

Autenticazione mediante

Smartphone o SmartKey

L utente è autorizzato

No

Accesso fisico alla sala

Sì

Notifica di mancata conferma

Notifica di autenticazione

fallita

Figura 2 – Diagramma delle attività

Vediamo ora in dettaglio i casi d’uso dei due tipi di utente.

2.3.1 – Analisi dettagliata del caso d’uso dell’utente amministratore

I casi d’uso tipici dell’utente amministratore consistono in mansioni di gestione dello stato delle sale prova,

come ad esempio l’aggiunta o rimozione di sale in fase di configurazione iniziale e compiti di supervisione e

verifica delle registrazioni dei nuovi utenti e delle prenotazioni immesse nel sistema.

Ad esempio per confermare una prenotazione l’utente amministratore dovrà:

Effettuare l’accesso all’area riservata del portale web

Consultare le nuove notifiche o recarsi nella sezione predisposta alla gestione delle prenotazioni

Selezionare le prenotazioni in attesa di conferma e confermarla o eventualmente rifiutarla

Analogamente per gestire le sale esistenti o aggiungerne/rimuoverne l’utente amministratore dovrà:

Effettuare l’accesso all’area riservata del portale web

Recarsi nella sezione dedicata alla gestione delle sale

Aggiungere, rimuovere o modificare le sale inserendo le informazioni aggiornate quali ad esempio il

prezzo orario

Dalla stessa sezione l’amministratore potrà inoltre verificare lo stato attuale delle sale ed

eventualmente intervenire remotamente su alcuni parametri come ad esempio l’apertura delle

porte, l’illuminazione e l’alimentazione elettrica

2 – Analisi

9

2.3.2 – Analisi dettagliata del caso d’uso dell’utente fruitore

Consideriamo i casi d’uso dell’utente fruitore. Questi consistono principalmente nella registrazione e nella

prenotazione di una sala e fruizione della stessa.

La prima fase consiste nella registrazione, in una specifica sezione dedicata del portale web in cui è

richiesto all’utente di fornire le proprie generalità e informazioni personali per fini anagrafici e di

fatturazione.

In seguito alla registrazione e all’approvazione della stessa da parte di un amministratore, l’utente sarà

abilitato alla prenotazione e alla fruizione dei servizi offerti e potrà configurare il proprio Smartphone come

dispositivo di accesso tramite l’applicazione mobile dedicata o richiedere una SmartKey fisica da utilizzare al

momento dell’autenticazione presso le sale.

Vediamo ora le azioni che l’utente dovrà compiere per prenotare una sala:

Effettuare l’autenticazione al portale web

Recarsi nella home page e mediante il calendario di prenotazione selezionare la data e l’ora

prescelta

Inserire le informazioni di prenotazione quali la sala preferita, eventuali note e compagni di

sessione registrati presso la piattaforma con cui condividere il diritto di accesso

Attendere la notifica di avvenuta conferma della prenotazione da parte degli amministratori

Una volta collocata la prenotazione l’utente si recherà presso i locali nella data prefissata, a quel punto per

accedere alla struttura l’utente potrà utilizzare per autenticarsi il proprio Smartphone (se supportato e

configurato) o la SmartKey abilitata spedita a seguito della registrazione.

Potranno autenticarsi per l’accesso ai locali, non solo l’utente che ha inserito fisicamente la prenotazione,

ma anche tutti gli utenti che sono stati inclusi come compagni al momento della collocazione.

Una volta terminato il periodo riservato il sistema provvederà automaticamente allo spegnimento

dell’alimentazione elettrica per la sala (ad esclusione dei dispositivi di sicurezza), invitando gli utenti

occupati a liberare i locali.

10

3 – Progettazione della base di dati

3.1 – Glossario dei termini

Termine Descrizione Collegamenti

Utente amministratore o Amministratore

Rappresenta l’utente che si occupa di mansioni di gestione e manutenzione

Sala, Prenotazione

Sala Rappresenta una delle sale disponibili per la prenotazione, identifica inoltre la destinazione per i comandi di controllo remoto

Prenotazione, Utente, Amministratore

Utente fruitore o Utente

Rappresenta l’utente che gode del servizio di noleggio delle sale

Prenotazione, Transazione, Dispositivo di accesso

Prenotazione Rappresenta una prenotazione effettuata dall’utente

Sala, Utente, Transazione, Amministratore

Dispositivo di accesso Rappresenta uno dei dispositivi di accesso configurati per l’utente, può essere uno Smartphone compatibile o una SmartKey

Utente

Transazione Rappresenta un movimento sul conto dell’utente, può essere una ricarica del conto o l’addebito di una prenotazione

Utente, Prenotazione

3.2 – Strutturazione dei requisiti

Frasi di carattere generale

Si vuole realizzare una base di dati per l’archiviazione delle informazioni relative agli utenti della piattaforma e di quelle relative alle prenotazioni effettuate

Frasi relative agli utenti e amministratori

Esistono due tipi di utilizzatori della piattaforma: gli amministratori e gli utenti

Un profilo utente prima di essere utilizzabile necessita dell’approvazione da parte di un amministratore

Un amministratore si riserva il diritto di bloccare un profilo utente che non rispetta i termini di utilizzo

Ad ogni utente sono associati dati di carattere anagrafico e informazioni di fatturazione

Ad ogni utente sono associati dei dispositivi di accesso, al più uno per ogni tipo (Smartphone, SmartKey)

È possibile creare relazioni di amicizia tra i vari utenti per permettere di condividere con questi i diritti di accesso alle sale prenotate

Ad ogni utente è associato un credito che si modifica mediante accrediti (ricariche) e addebiti (prenotazioni). Ad ognuna di queste operazioni di accredito e addebito corrisponde una transazione

Un utente con saldo nullo o comunque non sufficiente non è in grado di effettuare prenotazioni

Frasi relative alle sale

Ogni sala è identificata da un nome, inoltre ogni sala possiede un identificativo univoco associato al dispositivo di controllo remoto presente nella stessa

Una sala può risultare temporaneamente non prenotabile, ad esempio nel caso di manutenzione tecnica

Ad ogni sala corrisponde una tariffa oraria che può subire variazioni nel corso del tempo

Ogni sala possiede una descrizione che ne espone le caratteristiche

Frasi relative alle prenotazioni

Ad ogni prenotazione è associata a una sala

Una prenotazione possiede una data di inizio e una di fine

3 – Progettazione della base di dati

11

Non possono esistere prenotazioni concorrenti, cioè non è possibile prenotare una sala per periodi di tempo che si intersecano tra loro

Una prenotazione prima di diventare effettiva necessita l’approvazione da parte di un amministratore

Ad ogni prenotazione sono associati uno o più membri, questi utenti potranno utilizzare i propri dispositivi di accesso al momento dell’autenticazione alla sala

Ad ogni prenotazione corrisponde una transazione (addebito) sul conto dell’utente che l’ha inserita

Una prenotazione può essere cancellata entro un tempo prestabilito dall’inizio della stessa

Frasi relative ai dispositivi di accesso

Ad ogni utente sono associati uno o più dispositivi di accesso

I tipi di dispositivo sono due: Smartphone o SmartKey

Il numero di dispositivi per ogni utente è limitato a uno per tipo

Un dispositivo può essere revocato da un amministratore ad esempio nel caso si ipotizzi una compromissione o manomissione dello stesso

Ogni dispositivo possiede un nome descrittivo per renderlo facilmente identificabile dall’utente

Ad ogni dispositivo corrisponde un identificativo univoco utilizzato per l’autenticazione

Ad ogni dispositivo è associato un codice che identifica il dispositivo fisico di riferimento (Smartphone o SmartKey)

Frasi relative alle transazioni

Ad ogni operazione di accredito (ricarica) è associata una transazione

Ad ogni operazione di addebito (prenotazione) è associata una transazione

Ogni transazione si riferisce a uno specifico utente

Ad ogni transazione corrisponde una data e un importo

Ogni transazione possiede alcune informazioni aggiuntive specifiche del tipo di transazione, ad esempio la prenotazione a cui si riferisce o l’identificatore della transazione monetaria reale

3.3 – Operazioni previste

Per i vari elementi sopra descritti sono previste le seguenti operazioni:

Utenti e amministratori

o Ricerca

o Inserimento

o Modifica

o Eliminazione

Sale

o Inserimento

o Modifica

o Eliminazione

Prenotazioni

o Ricerca

o Inserimento

o Modifica

o Eliminazione

Dispositivi di accesso

o Inserimento

o Modifica

o Eliminazione

3 – Progettazione della base di dati

12

Transazioni

o Inserimento

o Eliminazione

3.4 – Progettazione concettuale

Per realizzare lo schema E-R sarà utilizzata una strategia di tipo misto. Si parte individuando i concetti

principali e si realizza uno schema iniziale sulla base del quale poi si può decomporre, raffinare, espandere

e integrare, fino a raggiungere lo schema finale.

3.4.1 – Entità e relazioni

Nello schema E-R di Figura 3 sono rappresentate le entità che sono state individuate e le relazioni che

sussistono tra di esse.

Utente

Amicizia

SalaPrenotazione

Partecipazione

Noleggio

Dispositivo di accessoPossesso

Addebito accredito

Transazione

Riferimento

Figura 3 – Schema E-R iniziale

3 – Progettazione della base di dati

13

Dai requisiti espressi possiamo infatti definire le seguenti entità:

Utente amministratore o più semplicemente Amministratore

Utente fruitore o semplicemente Utente

Dispositivo di accesso

Transazione

Sala

Prenotazione

In particolare tra queste entità sussistono le seguenti relazioni:

Amicizia: rappresenta la relazione che intercorre tra due entità utente

Possesso: esprime la relazione di appartenenza di un dispositivo di accesso ad un determinato

utente

Partecipazione: consiste nella relazione di inclusione di un utente tra i membri abilitati all’accesso

alla sala prove relativi ad una determinata prenotazione

Noleggio: rappresenta la relazione tra una prenotazione e la sala a cui essa si riferisce

Addebito/accredito: identifica la relazione tra una determinata transazione e il relativo utente sul

conto del quale avviene l’addebitato o l’accredito

Riferimento: esprime la relazione tra una transazione sotto forma di addebito e la prenotazione a

cui questa si riferisce

3.4.2 – Analisi delle entità

Amministratore

Id Valore univoco che identifica un amministratore, è candidato a diventare la chiave primaria dell’entità «Amministratore»

Email Indirizzo e-mail dell’amministratore per fini di autenticazione

Password Hash della password per fini di autenticazione

Nome Nome dell’amministratore per fini identificativi

Cognome Cognome dell’amministratore per fini identificativi

Utente

Id Valore univoco che identifica un utente, è candidato a diventare la chiave primaria dell’entità «Utente»

Email Indirizzo e-mail dell’utente per fini di autenticazione

Password Hash della password per fini di autenticazione

Nome Nome dell’utente per fini anagrafici e di fatturazione

Cognome Cognome dell’utente per fini anagrafici e di fatturazione

Codice fiscale Codice fiscale dell’utente per fini anagrafici e di fatturazione

Paese Paese di residenza dell’utente per fini anagrafici e di fatturazione

Città Città di residenza dell’utente per fini anagrafici e di fatturazione

Indirizzo Indirizzo di residenza dell’utente per fini anagrafici e di fatturazione

Numero di telefono Numero di telefono dell’utente per fini anagrafici

Bilancio Stato del bilancio dell’utente aggiornato all’ultima transazione effettuata. Il valore predefinito è 0

Stato di conferma Rappresenta lo stato di conferma del profilo, è Confermato se l’utente è stato verificato e approvato da un amministratore, Non confermato altrimenti. Il valore predefinito è Non confermato

3 – Progettazione della base di dati

14

Dispositivo di accesso

Tipo Tipo di dispositivo di accesso, può essere Smartphone o SmartKey

Id dispositivo Id univoco del dispositivo di accesso associato al dispositivo hardware relativo

Token Token di sicurezza generato per il dispositivo, viene utilizzato per l’autenticazione mediante il dispositivo. Assieme al tipo e all’id dispositivo identificano univocamente un dispositivo di accesso

Descrizione Testo descrittivo del dispositivo per una più semplice individuazione

Stato abilitazione Rappresenta lo stato di abilitazione del dispositivo, è Abilitato se il dispositivo è configurato e funzionante, Disabilitato se disattivato o revocato. Il valore predefinito è Abilitato

Transazione

Id Valore univoco che identifica una transazione, è candidato a diventare la chiave primaria dell’entità «Transazione»

Importo Rappresenta l’importo della transazione che si riflette sul bilancio dell’utente. Assume valore positivo in caso di accredito e valore negativo in caso di addebito

Data Data di registrazione della transazione

Informazioni aggiuntive Rappresenta le informazioni aggiuntive relative alla transazione. Nel caso di un accredito contiene le informazioni sulla transazione monetaria reale, in caso di addebito un riferimento alla prenotazione che ha generato la transazione

Sala

Id Valore univoco che identifica una sala, è candidato a diventare la chiave primaria dell’entità «Sala»

Nome Corrisponde al nome della sala

Id dispositivo remoto Rappresenta l’identificativo del dispositivo di controllo remoto associato alla sala

Descrizione Descrizione della sala e delle sue caratteristiche

Costo orario Rappresenta il costo orario per il noleggio della sala. L’importo della transazione di prenotazione è calcolato in base a questo valore

Stato abilitazione Rappresenta lo stato di abilitazione della sala, è Abilitata se la sala è funzionante e prenotabile, Disabilitato se è non disponibile ad esempio per motivi di manutenzione. Il valore predefinito è Abilitata

Prenotazione

Id Valore univoco che identifica un amministratore, è candidato a diventare la chiave primaria dell’entità «Prenotazione»

Data di inizio Corrisponde alla data e ora di inizio della prenotazione

Data di fine Corrisponde alla data e ora di fine della prenotazione

Note Note aggiuntive associate alla prenotazione. È un attributo opzionale

Stato di conferma Rappresenta lo stato di conferma della prenotazione, è Confermata se la prenotazione è stata confermata da un amministratore, Non confermata altrimenti. Il valore predefinito è Non confermata

3 – Progettazione della base di dati

15

3.4.3 – Analisi delle relazioni e delle cardinalità

Amicizia (Utente → Utente) Cardinalità Attributi

Un utente può possedere più amici come non possederne nessuno

(0, N) Stato di conferma

Un’amicizia sussiste esattamente tra due utenti (1, 1)

Possesso (Utente → Dispositivo di accesso) Cardinalità Attributi

Un utente può possedere più dispositivi di accesso come anche non possederne alcuno. Il limite superiore è definito dal vincolo di un dispositivo per tipo

(0, N)

Ogni dispositivo di accesso è associato ad uno ed un solo utente

(1, 1)

Partecipazione (Utente → Prenotazione) Cardinalità Attributi

Un utente può partecipare a più prenotazioni come non partecipare ad alcuna

(0, N)

Una prenotazione deve essere associata ad almeno un utente

(1, N)

Noleggio (Sala → Prenotazione) Cardinalità Attributi

Una sala può essere noleggiata tramite più prenotazioni (col vincolo che i periodi non si intersechino) come non essere noleggiata affatto

(0, N)

Ogni prenotazione si riferisce ad una e una sola sala

(1, 1)

Addebito/accredito (Utente → Transazione) Cardinalità Attributi

Un utente può aver effettuato più transazioni ma può anche non averne effettuata alcuna

(0, N)

Una transazione può essere effettuata da uno e un solo utente

(1, 1)

Riferimento (Transazione → Prenotazione) Cardinalità Attributi

Una transazione può riferirsi ad una unica prenotazione ma può anche non riferirsi affatto ad una (accredito)

(0, 1)

Ad una prenotazione è associata una e una sola transazione (addebito)

(1, 1)

Possiamo a questo punto integrare gli attributi e le cardinalità nel diagramma E-R iniziale lo schema E-R

finale rappresentato in Figura 4.

3 – Progettazione della base di dati

16

Utente

Amicizia

SalaPrenotazione

Partecipazione

Noleggio

Dispositivo di accessoPossesso

Addebito accredito

Transazione

Riferimento

(0, N) (1, 1)

(1, N)

(0, N)

(0, N)

(1, 1)

(0, 1)

(1, N) (1, 1)

(1, 1) (0, N)

(0, N)

Id Emai

l

Pas

swo

rd

No

me

Cog

nom

e

Co

dic

e fi

scal

e

Pae

se

Cit

tà

Ind

iriz

zo

Nu

mer

o d

ite

lefo

no

Bila

ncio

Stat

o d

ico

nfe

rma

Tip

o

Id d

isp

osi

tivo

Toke

n

Des

criz

ion

e

Stat

o d

iab

ilita

zio

ne

Stat

o d

ico

nfe

rma

Id

Imp

ort

o

Dat

a

Info

rma

zio

ni

aggi

un

tive

Id

No

me

Id d

isp

osi

tivo

re

mo

to

Des

criz

ion

e

Cos

to o

rari

o

Stat

o d

iab

ilita

zio

eId

Dat

a d

i in

izio

Dat

a d

ifi

ne

No

te

Stat

o d

i co

nfe

rma

Figura 4 – Schema E-R finale

3 – Progettazione della base di dati

17

3.4.4 – Business rules

In base ai requisiti del progetto possiamo definire le seguenti condizioni di unicità e vincoli per alcuni

attributi delle entità appena viste:

Il bilancio di un utente deve essere sempre maggiore o uguale a 0,00

Non possono esistere più utenti con lo stesso indirizzo e-mail

Non possono esistere più utenti con lo stesso codice fiscale

Ad un utente possono essere associati al più un dispositivo di accesso per tipo

Il prezzo orario per una sala deve essere maggiore di 0,00

L’orario di fine di una prenotazione non può precedere o coincidere con l’orario di inizio

3.5 – Progettazione logica

Possiamo a questo punto procedere a definire alcuni indici di prestazioni mediante la costruzione di due

tabelle, la tavola dei volumi, che descrive il numero di occorrenze previste per le entità e per le relazioni, e

la tavola delle operazioni, la quale analizza invece il numero di occorrenze di entità e relazioni visitate

durante le operazioni.

3.5.1 – Tavola dei volumi

Concetto Tipo Volume Note

Amministratore E 10 Si prevedono un massimo di 10 amministratori per il sistema considerando una stima abbondante

Sale E 10 Si ipotizzano un massimo di 10 sale per struttura

Utente E 500 Si prevedono in media 500 utenti

Dispositivo di accesso E 1000 Si stimano al massimo 2 dispositivi per ogni utente

Prenotazione E 10000 Nel peggiore dei casi si hanno un totale di 24 prenotazioni al giorno per sala. Consideriamo un arco di tempo di 1 anno e approssimiamo

Transazione E 20000 Consideriamo una transazione di addebito per ogni prenotazione, in più ipotizziamo una media di 20 accrediti per utente nel corso di 1 anno

Partecipazione R 30000 Si prevede la partecipazione di una media di 3 utenti per prenotazione

Amicizia R 2500 Assumiamo che ogni utente possieda mediamente 5 amici

3.5.2 – Tavola delle operazioni

Operazione Tipo Frequenza

Registrazione o modifica di un amministratore W 10 / anno

Aggiunta o modifica di una sala W 10 / anno

Registrazione o modifica di un utente W 50 / mese

Aggiunta di un dispositivo di accesso W 100 / mese

Aggiunta di un’amicizia W 1 / mese

Inserimento di una prenotazione W 100 / giorno

Aggiunta di una partecipazione W 300 / giorno

Inserimento di una transazione W 150 / giorno

Lettura di un amministratore R 10 / giorno

Lettura di un utente R 100 / giorno

Lettura di un dispositivo di accesso R 500 / giorno

Ricerca di una sala R 150 / giorno

3 – Progettazione della base di dati

18

Ricerca di una transazione R 200 / giorno

Ricerca di una prenotazione R 500 / giorno

Lettura di una partecipazione R 1500 / giorno

Lettura di un’amicizia R 300 / giorno

3.5.3 – Ristrutturazione dello schema E-R

Considerando il diagramma E-R finale di Figura 5 possiamo notare che la relazione denominata

Partecipazione può essere scomposta, analizziamo infatti la relazione sussistente tra l’entità Utente e

l’entità Prenotazione. In base alle specifiche infatti un utente può partecipare a più prenotazioni ed ogni

prenotazione può essere condivisa tra più utenti, conseguentemente la relazione istauratasi tra le due

entità è di tipo molti a molti.

Con lo scopo di semplificare la realizzazione del relativo database relazionale è conveniente convertire una

relazione M:N in due relazioni 1:N e 1:M del tipo uno a molti mediante l’introduzione di un’ulteriore entità

denominata entità associativa.

Definiamo a questo scopo l’entità UtentePrenotazione, otteniamo allora per la relazione in questione lo

schema mostrato in Figura 5.

Utente Partecipazione UtentePrenotazione PrenotazionePartecipazione(0, 1) (1, N) (1, M) (1, 1)

Utente Appartenenza Prenotazione(0, N) (1, M)

Figura 5 – Relazione Utente-Prenotazione

Discorso analogo va fatto per la relazione Amicizia che intercorre tra due entità di tipo Utente.

La conversione effettuata mediante l’introduzione dell’entità UtenteUtente è in questo caso è mostrata

nello schema di Figura 6.

Utente Amicizia UtenteUtente PrenotazioneAmicizia(0, 1) (1, N) (1, M) (1, 1)

Utente Amicizia Utente(0, N) (1, M)

Figura 6 – Relazione Utente-Utente

3 – Progettazione della base di dati

19

Analizziamo ora le entità Amministratore e Utente, possiamo immediatamente notare come queste possono essere rappresentate come specializzazioni di una terza entità astratta chiamata Persona. Abbiamo in particolare la gerarchia descritta in Figura 7.

Persona

Id Emai

l

Pass

wor

d

Nom

e

Cog

nom

e

Cod

ice

fisc

ale

Paes

e

Cit

tà

Indi

rizz

o

Num

ero

di

tele

fono

Bila

ncio

Stat

o d

ico

nfe

rma

UtenteAmministratore

Figura 7 – Generalizzazione Amministratore-Persona-Utente

Si è scelto di rappresentare tale gerarchia sostituendo le generalizzazioni con relazioni.

Il medesimo approccio è stato scelto per rappresentare i due tipi di entità Transazione esistenti,

differenziandoli in Addebito e Accredito, in questo caso per sfruttare i vantaggi del vincolo referenziale con

l’entità Prenotazione. La gerarchia assume allora la forma rappresentata in Figura 8.

Transazione

Id Imp

orto

Dat

a

Info

rmaz

ioni

ag

giu

ntiv

e

AccreditoAddebito

Pren

otaz

ione

Figura 8 – Generalizzazione Accredito-Transazione-Addebito

3 – Progettazione della base di dati

20

3.5.4 – Scelta degli identificatori principali

Il passo successivo in vista della realizzazione fisica della base di dati è stata la determinazione degli

identificatori principali per ciascuna entità.

Ad ogni entità è stata assegnata una chiave primaria che la identifica in modo univoco, in particolare

abbiamo le seguenti associazioni.

Entità Identificatore

Persona Id, creato ad hoc

Dispositivo di accesso Chiave composta dagli attributi Tipo, Id dispositivo e Token, dati i requisiti di unicità di questi

Transazione Id, creato ad hoc

Sala Id, creato ad hoc

Prenotazione Id, creato ad hoc

3.5.5 – Scelta delle chiavi esterne

Giunti a questo punto dobbiamo realizzare le relazioni di cardinalità analizzate precedentemente,

introduciamo perciò per alcune entità le relative chiavi esterne e i vincoli di integrità referenziale.

Analizziamole entità per entità.

Utente

o FK_UtentePersona, rappresenta il vincolo con l’entità Persona nella relazione gerarchica

Utente-Persona

Amministratore

o FK_AmministratorePersona, rappresenta il vincolo con l’entità Persona nella relazione

gerarchica Amministratore-Persona

Dispositivo di accesso

o FK_DispositivoDiAccessoPersona, rappresenta il vincolo tra l’entità Dispositivo di accesso e

l’entità Utente per la relazione di Possesso

UtenteUtente

o FK_UtenteUtente1, rappresenta il vincolo con l’entità Utente che rappresenta il primo

partecipante alla relazione Amicizia

o FK_UtenteUtente2, rappresenta il vincolo con l’entità Utente che rappresenta il secondo

partecipante alla relazione Amicizia

Prenotazione

o FK_PrenotazioneSala, rappresenta il vincolo con l’entità Sala per la relazione Noleggio

UtentePrenotazione

o FK_UtentePrenotazione1, rappresenta il vincolo con l’entità Utente per la relazione

Partecipazione

o FK_ UtentePrenotazione2, rappresenta il vincolo con l’entità Prenotazione per la relazione

Partecipazione

Transazione

o FK_TransazioneUtente, rappresenta il vincolo con l’entità Utente per la relazione

Addebito/Accredito

Addebito

o FK_AddebitoTransazione, rappresenta il vincolo con l’entità Transazione per la relazione

gerarchica Addebito-Transazione

3 – Progettazione della base di dati

21

o FK_AddebitoPrenotazione, rappresenta il vincolo con l’entità Prenotazione per la relazione

Riferimento

Accredito

o FK_AccreditoTransazione, rappresenta il vincolo con l’entità Transazione per la relazione

gerarchica Accredito-Transazione

3.5.6 – Schema fisico

Figura 9 – Schema fisico del database

In Figura 9 troviamo lo schema fisico che identifica in maniera reale il database.

Le entità sono state rappresentate mediante tabelle secondo la tabella di mappatura seguente.

Entità Tabella

Persona Users

3 – Progettazione della base di dati

22

Amministratore AdministratorUsers

Utente CustomerUser

Dispositivo di accesso UserAccessDevices

UtenteUtente UserFriendships

Prenotazione Bookings

Sala Rooms

UtentePrenotazione UserBookings

Transazione Transactions

Addebito BookingTransactions

Accredito RechargeTransactions

3.6 – Programmabilità

Vediamo ora come sono state sfruttate le funzionalità di programmabilità della base di dati per rendere più

semplice ed efficiente la gestione e la modifica della stessa.

3.6.1 – Vincoli di integrità e indici di unicità

Al fine di garantire il rispetto delle business rules e l’integrità dei dati all’interno della base di dati, sono

stati implementati alcuni vincoli di check19 elencati nella tabella sottostante.

Tabella Espressione

CustomerUsers (Balance >= 0.0)

Rooms (HourPrice > 0.0)

Bookings DATEDIFF(hour, StartDate, EndDate) > 0

Sono inoltre stati aggiunti degli indici di unicità per assicurarsi che i vincoli di singolarità definiti dalle

business rules siano rispettati.

Tabella Indice Attributi

Users IX_UserEmail Email

CustomerUsers IX_UserTaxCode TaxCode

UserAccessDevices IX_AccessDeviceType UserId, Type

3.6.2 – Triggers e stored procedures

Con l’obiettivo di automatizzare la modifica del bilancio di un utente in seguito all’inserimento o

all’eliminazione di una transazione sono stati implementati i seguenti triggers20 relativi alla tabella

Transactions.

Il primo trigger incrementa (o decrementa) il saldo di un utente all’inserimento di una nuova transazione ed

è implementato mediante il seguente statement SQL:

CREATE TRIGGER UpdateUserBalanceOnInsert ON Transactions FOR INSERT AS BEGIN SET NOCOUNT ON

UPDATE cu SET cu.Balance = cu.Balance + ins.Amount FROM CustomerUsers cu JOIN inserted ins ON cu.Id = ins.UserId

END

19 https://en.wikipedia.org/wiki/Check_constraint 20 https://en.wikipedia.org/wiki/Database_trigger

3 – Progettazione della base di dati

23

Il secondo trigger invece decrementa (o incrementa) il saldo di un utente in seguito all’eliminazione di una

transazione, lo statement che lo implementa è il seguente:

CREATE TRIGGER UpdateUserBalanceOnDelete ON Transactions FOR DELETE AS BEGIN SET NOCOUNT ON

UPDATE cu SET cu.Balance = cu.Balance - del.Amount FROM CustomerUsers cu JOIN deleted del ON cu.Id = del.UserId

END

Transactions

UpdateUserBalanceOnInsert

UpdateUserBalanceOnDelete

CustomerUsers

INSERT Transaction DELETE Transaction

UPDATE Balance UPDATE Balance

Figura 10 – Grafo di attivazione dei triggers

24

4 – Progettazione della piattaforma

In questo capitolo affronteremo in dettaglio la fase di progettazione affrontata per i componenti principali

della piattaforma.

4.1 – Progettazione del portale web Il primo passo per la progettazione del portale web è stato definire la relativa struttura di base.

In Figura 11 è mostrato il grafico che rappresenta la struttura dell’applicazione con le relative funzionalità.

Accesso

Home page utenteHome page

amministratore

Cronologia prenotazioni

Conto personale

Amici Impostazioni

Informazioni personali

Dispositivi di accesso

Informazioni di accesso

ImpostazioniInformazioni di

accesso

Prenotazioni Utenti

Sale

Prenotazione

Registrazione Home page Contatti

Transazioni

Figura 11 – Struttura del portale web

In particolare le aree caratterizzate da uno sfondo scuro rappresentano le pagine del sito accessibili anche

senza aver effettuato l’autenticazione mediante la pagina di accesso.

Le parti che invece possiedono uno sfondo chiaro rappresentano diverse sezioni contestuali accessibili

senza la necessità di navigare verso una diversa pagina.

Dallo schema è inoltre possibile notare in seguito alla procedura di accesso avviene una differenziazione del

flusso di utilizzo in base alla tipologia di utente che ha effettuato l’autenticazione, nello specifico gli utenti

amministratori saranno reindirizzati verso una sezione dell’applicazione ad essi dedicata e predisposta alle

mansioni che questi dovranno compiere.

Analogamente gli utenti fruitori saranno indirizzati verso un’area specifica in cui potranno inserire nuove

prenotazioni, gestire il proprio profilo, il proprio conto e il proprio storico delle operazioni.

4 – Progettazione della piattaforma

25

Analizziamo ora le singole pagine e le funzioni svolte da esse.

4.1.1 – Area utente anonimo

Home page: è la pagina iniziale del sito web, permette una vista del calendario delle prenotazioni

per controllare la disponibilità ma non permette la prenotazione

Registrazione: rappresenta la pagina di registrazione per i nuovi utenti

Contatti: in questa pagina sono inserite alcune informazioni di contatto e un form per l’inserimento

di domande

Accesso: è la pagina di login mediante la quale gli utenti effettuano l’autenticazione

4.1.2 – Area utente fruitore

Home page: è la pagina verso la quale l’utente è reindirizzato dopo aver effettuato

l’autenticazione.

In questa pagina è possibile consultare il calendario delle prenotazioni ed eventualmente inserire

una nuova prenotazione

Cronologia prenotazioni: in questa pagina sono elencate le prenotazioni inserite dall’utente e

quelle a cui ha partecipato o parteciperà.

Da questa pagina è inoltre possibile gestire le prenotazioni inserite per aggiungere nuovi membri o

per richiederne la cancellazione

Conto personale: rappresenta la pagina di gestione del conto personale associato a ciascun utente.

In questa pagina è possibile visualizzare la cronologia delle transazioni, il proprio saldo attuale ed è

inoltre possibile effettuare una ricarica del conto mediante PayPal21 o carta di credito

Amici: mediante questa pagina è possibile gestire le proprie amicizie, le richieste in sospeso e

aggiungere nuovi utenti alla propria cerchia

Impostazioni: è la pagina attraverso cui l’utente gestisce le proprie impostazioni per la piattaforma.

Attraverso questa pagina l’utente può modificare le proprie impostazioni personali, cambiare le

proprie credenziali e infine gestire i propri dispositivi d’accesso

4.1.3 – Area utente amministratore

Home page: è la pagina verso la quale l’utente è reindirizzato dopo aver effettuato

l’autenticazione.

Questa pagina è offre all’amministratore una panoramica delle prenotazioni effettuate dagli utenti

e permette a questo di confermarle o rifiutarle

Utenti: in questa pagina è visualizzata una lista degli utenti iscritti alla piattaforma. Mediante

questa pagina è possibile gestire i vari profili e amministrarne le informazioni.

Tramite questa pagina un amministratore è in grado di convalidare e abilitare i profili appena iscritti

e in attesa di approvazione

Sale: questa pagina permette all’amministratore di gestire le sale prova, modificarne le

informazioni e disponibilità.

Sempre tramite questa pagina è possibile controllare lo stato di una determinata sala ed effettuare

delle operazioni da remoto

Impostazioni: è la pagina attraverso cui l’amministratore gestisce le proprie impostazioni per la

piattaforma.

In particolare attraverso questa pagina l’utente può modificare le proprie impostazioni personali

21 https://www.paypal.com/

4 – Progettazione della piattaforma

26

Queste ultime due aree possiedono inoltre un sistema di notifiche in tempo reale basato sulla tecnologia

SignalR che permette agli utenti e agli amministratori di avere riscontro immediato al verificarsi di alcuni

eventi.

Ad esempio un utente sarà notificato se viene aggiunto ad una prenotazione da un altro utente, nel

momento in cui riceve una richiesta di amicizia o alla conferma di una prenotazione da parte di un

amministratore.

Allo stesso modo un amministratore riceverà una notifica nel caso sia inserita una nuova prenotazione o

quando un nuovo utente si iscrive alla piattaforma.

Il sistema notificherà inoltre l’amministratore al verificarsi di alcune circostanze di errore nei dispositivi di

controllo remoto delle sale.

4.2 – Progettazione della Web API Analizziamo ora le funzionalità offerte dalla Web API che permettono al sistema di interfacciarsi con le

applicazioni mobile e il dispositivo di controllo.

In particolare la Web API è composta dai cinque endpoint, ciascuno con un compito specifico, mostrati in

Figura 12.

/oauth /api/notifications /api/users /api/rooms

Dispositivo di controllo remoto

/api/bookings

Applicazione mobile

Figura 12 – Struttura della Web API

Vediamo ora in dettaglio gli endpoint offerti.

4.2.1 – OAuth

L’endpoint con URI relativo “/oauth” rappresenta il servizio che offre le funzionalità di autenticazione per

l’applicazione mobile mediante protocollo OAuth 2.022.

Tramite questa API l’applicazione mobile permette agli utenti di effettuare l’accesso al proprio profilo e di

22 https://en.wikipedia.org/wiki/OAuth

4 – Progettazione della piattaforma

27

ottenere un access token23 che permette di utilizzare le risorse24 degli altri servizi web che richiedono

autenticazione.

4.2.2 – Notifications

Questo endpoint, di URI relativo “/api/notifications”, offre invece le funzionalità di registrazione e gestione

al sistema di notifiche push25 per l’applicazione mobile, offerto dall’infrastruttura Microsoft Azure

mediante Notification Hub.

Le notifiche push permettono all’applicazione di ricevere avvisi riguardo eventi che si verificano nell’ambito

del profilo utente direttamente sul proprio dispositivo, analogamente a quanto avviene nel portale web.

4.2.3 – Bookings

L’endpoint con URI relativo “/api/bookings” è uno dei servizi utilizzati dall’applicazione mobile.

Questo servizio in particolare permette all’applicazione di:

Visualizzare il calendario delle prenotazioni

Inserire nuove prenotazioni

4.2.4 – Users

L’endpoint con URI relativo “/api/users” rappresenta il servizio principale utilizzato dall’applicazione

mobile.

Tale servizio offre infatti tutte le funzionalità che permettono all’utente tramite l’applicazione di:

Ottenere le informazioni personali dell’utente

Visualizzare la cronologia delle prenotazioni

Esaminare lo storico delle transazioni e visualizzare il proprio bilancio

Consultare e gestire la lista delle proprie amicizie

4.2.5 – Rooms

Infine l’endpoint con URI relativo “api/rooms” offre le funzionalità necessarie al dispositivo di controllo

remoto per interagire con la piattaforma ed effettuare operazioni quali l’autenticazione degli utenti

mediante dispositivo di accesso o la gestione remota della sala a cui il dispositivo di controllo è associato.

4.3 – Progettazione dell’applicazione mobile

In modo analogo al portale web, l’applicazione mobile permette all’utente fruitore di accedere ai servizi

offerti dalla piattaforma anche in mobilità e direttamente dal proprio Smartphone.

Tale applicazione permette inoltre, sui dispositivi supportati, di fungere da dispositivo di accesso facendo

uso della tecnologia HCE che permette al telefono di emulare una SmartCard NFC.

Come il portale web, una volta effettuato l’accesso tramite la schermata di login, l’utente può accedere alle

varie sezioni in cui è divisa l’app, e in particolare:

Home: in questa sezione è possibile consultare il calendario delle prenotazioni ed eventualmente

inserire una nuova prenotazione

Cronologia prenotazioni: in questa sezione sono invece elencate le prenotazioni inserite dall’utente

e quelle a cui ha partecipato o parteciperà

23 https://en.wikipedia.org/wiki/Access_token 24 https://en.wikipedia.org/wiki/Web_resource 25 https://en.wikipedia.org/wiki/Push_technology

4 – Progettazione della piattaforma

28

Conto personale: rappresenta invece la sezione di gestione del conto personale associato a ciascun

utente. Da qui è possibile visualizzare la cronologia delle transazioni e consultare il proprio saldo

attuale

Impostazioni: questa è infine la sezione in cui è possibile impostare alcune opzioni per

l’applicazione. In particolare è possibile decidere, se il telefono lo supporta, se utilizzare o meno

quest’ultimo come dispositivo di accesso, è possibile inoltre disabilitare la recezione delle notifiche,

selezionare la modalità di vista predefinita per il calendario e impostare se aggiungere o meno un

appuntamento al calendario nel momento in cui viene inserita una prenotazione

L’applicazione è inoltre progettata per integrarsi con Cortana26, l’assistente personale dei dispositivi

Windows 10, per fornire funzionalità di ricerca vocale di sale prova e aggiunta delle prenotazioni effettuate

al calendario del dispositivo.

4.4 – Progettazione del dispositivo di controllo remoto

Per poter testare appieno tutte le potenzialità della piattaforma è stato progettato e costruito un prototipo

funzionante di dispositivo di accesso e controllo remoto.

Questo dispositivo è stato realizzato utilizzando la piattaforma Gadgeteer ed è schematizzato in Figura 13.

Figura 13 – Schema dispositivo di controllo remoto

Come visibile dallo schema, il dispositivo è composto da diversi moduli collegati alla scheda principale, nello

specifico questi componenti sono:

26 http://windows.microsoft.com/en-us/windows-10/getstarted-what-is-cortana

4 – Progettazione della piattaforma

29

Un modulo di alimentazione

Un led di stato che indica lo stato delle operazioni effettuate

Un modulo ethernet per la connessione del dispositivo alla rete internet

Uno schermo a caratteri per l’output di informazioni sulle operazioni effettuate e sullo stato del

dispositivo

Un buzzer27 per la notifica acustica dell’esito di alcune operazioni

Un lettore RFID e NFC per la lettura dei dispositivi di accesso

Un lettore di schede di memoria SD utilizzata per il mantenimento delle impostazioni di

configurazione e per il caching di alcune informazioni

Un orologio RTC28 per gestire in maniera efficiente e precisa eventi temporizzati e per mantenere

aggiornate la data e l’ora del dispositivo

Il dispositivo è inoltre pensato per potersi interfacciare con uno o più relè29 in modo da poter comandare

una serratura elettrica e automatizzare l’impianto di illuminazione della sala.

Per alcuni dei moduli, in particolare il modulo RTC e il lettore RFID è stato necessario implementare il driver

di controllo per la piattaforma .NET Gadgeteer e per il Micro Framework. Per la realizzazione di questi ci si è

basati sulla documentazione ufficiale dei relativi componenti riportata nella bibliografia.

Dal punto di vista del software, il dispositivo è interfacciato alla piattaforma mediante la Web API

precedentemente descritta.

Il dispositivo sfrutta inoltre la tecnologia e il protocollo SignalR per la comunicazione in real-time associata

alle funzionalità di controllo remoto. A questo scopo è stata creata una libreria software dedicata data

l’assenza di un’implementazione preesistente per il suddetto protocollo destinata alla piattaforma .NET

Micro Framework.

27 https://en.wikipedia.org/wiki/Buzzer 28 https://en.wikipedia.org/wiki/Real-time_clock 29 https://en.wikipedia.org/wiki/Relay

30

5 – Interfaccia

Dopo aver analizzato la fase di progettazione dei vari componenti che compongono l’infrastruttura,

vedremo ora come è stata la realizzazione dell’interfaccia grafica per gli elementi che ne dispongono.

Esamineremo in particolare come sono state sviluppate le GUI30 per l’applicazione web e per l’applicazione

mobile. Analizzeremo inoltre le soluzioni che sono state adottate per permettere al dispositivo di controllo

di comunicare il proprio stato e di fornire messaggi riguardanti le operazioni in corso e il loro esito.

5.1 – Interfaccia del portale web

Per la progettazione dell’interfaccia grafica per l’applicazione web si è fatto uso del linguaggio di markup

HTML5 e del linguaggio di formattazione CSS3, in particolare si è ricorsi alla sintassi ASP.NET Razor31 offerta

dal framework ASP.NET MVC che permette di utilizzare i costrutti HTML mescolati a codice C# per creare

pagine web dinamiche secondo il paradigma MVC32.

Per la realizzazione del sito web si è inoltra fatto uso del framework Bootrstrap e della libreria JavaScript

jQuery per rendere dinamiche le pagine e risolvere in modo semplice ed efficiente alcune problematiche

quali ad esempio l’adozione della tecnica di design web adattivo33 che permette all’interfaccia di una pagina

web di ridimensionarsi e riposizionare automaticamente gli elementi per adattarsi alle dimensioni del

riquadro di visualizzazione.

Figura 14 – Home page

In Figura 14 è rappresentata l’home page del portale web, sono visibili in particolar modo il calendario di

prenotazione e i collegamenti di navigazione per la pagina di accesso e di registrazione.

30 https://en.wikipedia.org/wiki/Graphical_user_interface 31 https://en.wikipedia.org/wiki/ASP.NET_Razor 32 https://en.wikipedia.org/wiki/Model–view–controller 33 https://en.wikipedia.org/wiki/Responsive_web_design

5 – Interfaccia

31

Figura 15 – Accesso

Mediante la pagina di accesso di Figura 15 gli utenti e gli amministratori possono autenticarsi e accedere

alla propria area privata dedicata.

Per registrarsi invece come nuovi utenti è necessario recarsi nella pagina di registrazione di Figura 16 e

compilare i campi necessari.

Figura 16 - Registrazione

Una volta effettuato l’accesso, l’utente può inserire una prenotazione semplicemente facendo click sulla

data e l’ora prescelta, se è disponibile una sala per la prenotazione in tale periodo apparirà la finestra

modale di Figura 17 che permetterà di finalizzare la prenotazione.

5 – Interfaccia

32

Figura 17 – Finestra modale di prenotazione

Una volta inserita la prenotazione, questa sarà consultabile nella pagina relativa alla cronologia delle

prenotazioni visibile in Figura 18. Dalla stessa pagina è inoltre possibile richiedere la cancellazione di una

prenotazione precedentemente aggiunta semplicemente facendo click sul pulsante raffigurante il cestino.

Figura 18 – Cronologia delle prenotazioni

In Figura 19 è invece rappresentata la pagina di riassunto del conto personale dell’utente.

Oltre al saldo corrente in questa pagina è possibile consultare lo storico delle transazioni ed eventualmente

ricaricare il conto tramite il servizio di pagamenti online PayPal.

5 – Interfaccia

33

Figura 19 – Conto personale

La Figura 20 mostra la pagina dedicata alla gestione degli amici, da questa pagina l’utente è in grado di

visualizzare, aggiungere o rimuovere amicizie dalla propria cerchia oppure accettare o rifiutare richieste di

amicizia in sospeso.

Figura 20 – Amici

Infine dalla pagina ritratta in Figura 21 l’utente potrà modificare alcune informazioni personali, sostituire le

credenziali di accesso e gestire i propri dispositivi di accesso.

5 – Interfaccia

34

Figura 21 – Impostazioni

5.2 – Interfaccia dell’applicazione mobile

Per quanto riguarda invece la progettazione dell’interfaccia grafica per l’applicazione mobile si è scelto di

rimanere fedeli alle linee guida34 suggerite da Microsoft per lo sviluppo di applicazioni per la piattaforma

Windows 10.

In particolare si è deciso di adottare il cosiddetto Hamburger menu35 per la navigazione tra le sezioni e di

implementare responsive design36 già citato per l’applicazione web. Tale tecnica di design permette

all’interfaccia di modificarsi e adattarsi alle dimensioni dello schermo e al dispositivo su cui viene eseguita,

in tal modo l’applicazione è fruibile non solo da Smartphone Windows 10 Mobile ma anche da PC e tablet

che utilizzano Windows 10 come sistema operativo.

Figura 22 – Alcune schermate dell’applicazione mobile

34 https://dev.windows.com/en-us/design 35 https://en.wikipedia.org/wiki/Hamburger_button 36 https://msdn.microsoft.com/en-us/library/windows/apps/dn958435.aspx

5 – Interfaccia

35

In Figura 22 sono mostrate alcune immagini rappresentanti l’interfaccia grafica dell’applicazione e le varie

sezioni da cui è composta, e l’integrazione con l’assistente personale Cortana che permette la ricerca vocale

di sale prove libere.

5.3 – Interfaccia del dispositivo di controllo

Dal momento che il dispositivo di controllo non possiede una vera e propria interfaccia grafica ma che a fini

di debug si è reso necessario che il dispositivo stesso possa comunicare l’esito e lo stato di alcune

operazioni, si è deciso di implementare un sistema di output basato su notifiche sonore, luminose e su uno

schermo a caratteri.

Figura 23 – Prototipo del dispositivo di controllo

Nello specifico il sistema di notifiche luminose è basato su un codice a tre colori, rosso, giallo e verde: il

primo sta a significare uno stato di errore, il secondo indica che un’operazione è in corso mentre il terzo

rappresenta un esito positivo. Analogamente le notifiche acustiche sono caratterizzate da due tonalità

diverse per lo stato di successo e lo stato di errore.

Il display a caratteri infine permette di visualizzare messaggi anche più lunghi dei 16x2 caratteri

nominalmente supportati dal modulo mediante l’utilizzo ti una tecnica di visualizzazione a scorrimento del

testo.

In Figura 23 sono evidenziati il led di notifica e il display a caratteri.

LED di notifica

Display a

caratteri

36

6 – Implementazione

Questo capitolo ha infine lo scopo di esporre il funzionamento interno del software che si cela dietro i

principali componenti della piattaforma.

Al fine di una trattazione più semplice verranno analizzati solamente alcune delle funzioni e porzioni di

codice sorgente che compongono le singole parti.

6.1 – Implementazione del portale web e della Web API

Con l’intento di rendere lo sviluppo dell’applicazione web più rapida si è deciso di ricorrere all’Entity

Framework come strumento di accesso ai dati forniti dal database.

In particolare l’Entity Framework è un set di tecnologie basate su ADO.NET37 che permette lo sviluppo

semplificato di applicazioni orientate ai dati.

Tale framework consente infatti allo sviluppatore di utilizzare i dati sotto forma di proprietà e oggetti

specifici indipendentemente dalle colonne e dalle tabelle del database sottostante in cui questi sono

archiviati. È perciò possibile operare a un livello superiore di astrazione nel momento in cui ci si trova a

dover gestire tali dati e tutto ciò consente di creare e gestire l’applicazione in maniera semplice e con meno

codice rispetto alle tradizionali applicazioni.

Questa scelta si riflette nel fatto che nel codice di accesso ai dati non sono presenti esplicite queries SQL ma

l’accesso ai dati avviene piuttosto mediante costrutti LINQ38, i quali vengono tradotti a runtime

automaticamente dal framework in linguaggio SQL.

Vediamo ora ad esempio il codice che si occupa di trovare tutte le prenotazioni in un arco temporale

definito dalle variabili startDate e endDate ordinandole per data di inizio

BookingStore.Bookings.Where(b => b.StartDate >= startDate && b.EndDate <= endDate).OrderBy(s

=> s.StartDate);

BookingStore.Bookings rappresenta il “contenitore” delle prenotazioni dalla quale vengono selezionate

quelle che rispettano i vincoli imposti. Tale costrutto LINQ viene tradotto al momento dell’esecuzione in

una query SQL simile alla seguente

SELECT * FROM Bookings WHERE StartDate >= @startDate && EndDate <= @endDate ORDER BY

StartDate

Per quanto riguarda invece la gestione del traffico HTTP, il framework ASP.NET MVC fornice la classe base

Controller39 che implementa i meccanismi per rispondere alle richieste effettuate al sito secondo il

pattern Model-View-Controller.

Ogni pagina del sito web possiede perciò il proprio Controller specifico che eredita dalla suddetta classe,

nello specifico ciascuna di tali classi implementa delle funzioni predisposte a rispondere a determinate

richieste HTTP40 discriminate per metodo e URI della risorsa di destinazione.

37 https://en.wikipedia.org/wiki/ADO.NET 38 https://en.wikipedia.org/wiki/Language_Integrated_Query 39 https://msdn.microsoft.com/en-us/library/system.web.mvc.controller(v=vs.118).aspx 40 https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_message

6 – Implementazione

37

Queste funzioni ricevono in input i parametri ricevuti mediante le richieste HTTP (parametri query string41

e/o form in caso di richieste POST42) in output la View sotto forma di contenuto HTML.

Specifica attenzione meritano i metodi che restituiscono le cosiddette viste parziali, utilizzate nell’ambito

della programmazione AJAX43 e che permettono l’aggiornamento di determinate porzioni della pagina web

senza la necessità di ricaricare l’intera pagina.

Questa tecnica trova particolare applicazione quando si tratta di visualizzare discrete quantità dati

organizzate in pagine tra cui l’utente può navigare senza però dover ricaricare la pagina nella sua interezza.

Analizziamo come esempio il Controller e le Views associate alla pagina “Cronologia prenotazioni”.

In Figura 24 è raffigurato il codice relativo all’implementazione della classe BookingsController che si

occupa di gestire il traffico HTTP per la pagina con URI relativo “/Bookings”, in particolare consideriamo i

metodi Index e Navigate.

La funzione Index si occupa di rispondere alle richieste di tipo GET verso la risorsa predefinita associata alla

pagina, restituendo in output la View mostrata in Figura 25 che si occupa di visualizzare il modello

BookingsModel contenente la lista delle prenotazioni dell’utente autenticato, impaginate a gruppi di 10

elementi.

Il metodo Navigate è preposto a gestire le richieste, sempre di tipo GET, destinate invece alla risorsa

caratterizzata dall’URI “/Bookings/Navigate”.

Questo metodo è stato creato nello specifico per permettere la navigazione della lista delle prenotazioni

mediante AJAX, esso riceve infatti in input l’indice della pagina da visualizzare e risponde con la

visualizzazione parziale di Figura 26 che si occupa di rappresentare le prenotazioni corrispondenti a tale

indice, sotto forma di elementi HTML.

Particolare menzione merita l’attributo Autorize44 a decorazione della classe BookingsController. Tale

attributo garantisce che solamente gli utenti autenticati possano accedere alla pagina gestita dal Controller,

in questo caso specifico solamente gli utenti appartenenti al ruolo Customer (che identifica l’utente

fruitore), gli utenti non autenticati o appartenenti ad un diverso ruolo riceveranno una risposta HTTP di

status code 40145.

Analogamente a quanto avviene per le pagine web, il framework ASP.NET fornisce una classe base che

funge da Controller per le Web API, tale classe è chiamata ApiController46.

A differenza di quanto abbiamo visto prima, i metodi di questa classe non restituiscono le Views associate ai

modelli sotto forma di contenuto HTML, bensì generano in output tali oggetti codificati secondo la

notazione JSON47, ne consegue che le Web API per la piattaforma è rappresentata semplicemente da un

insieme di classi che ereditano da tale classe base, completate dai metodi che si occupano di gestire le

richieste HTTP verso le risorse associate ai servizi che si intende fornire.

41 https://en.wikipedia.org/wiki/Query_string 42 https://en.wikipedia.org/wiki/POST_(HTTP) 43 https://en.wikipedia.org/wiki/Ajax_(programming) 44 https://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute(v=vs.118).aspx 45 https://en.wikipedia.org/wiki/List_of_HTTP_status_codes 46 https://msdn.microsoft.com/en-us/library/system.web.http.apicontroller(v=vs.118).aspx 47 https://en.wikipedia.org/wiki/JSON

6 – Implementazione

38

Figura 24 – BookingsController.cs

6 – Implementazione

39

Figura 25 – Index.cshtml

Figura 26 – _BookingListPartial.cshtml

6 – Implementazione

40

6.2 – Implementazione dell’applicazione mobile

Vediamo adesso come sono state implementate alcune soluzioni per l’applicazione mobile.

L’applicazione in questione è stata rilasciata per il momento esclusivamente per la piattaforma Windows 10

UWP data la familiarità con gli strumenti di sviluppo e il supporto ad alcune tecnologie richieste dai requisiti

del progetto.

Analizziamo a fini esemplificativi il codice associato alla sezione “Cronologia prenotazioni” dal momento

che le stesse tecniche sono utilizzate anche nelle altre sezioni dell’applicazione.

In Figura 27 è possibile esaminare il codice che si occupa di sincronizzare e visualizzare lo storico delle

transazioni per l’utente nella pagina il cui layout e visibile in Figura 28.

In particolare possiamo vedere come il compito di aggiornare la lista delle transazioni sia svolto dalla

funzione Refresh. Tale metodo si occupa di richiamare la Web API mediante il client HTTP identificato da

((App)Application.Current).Client, di effettuare l’impaginazione in pagine di 10 elementi tramite

l’oggetto PagedDataCollection e infine di effettuare il data binding48 all’elemento ListView49 denominato

BookingsListView a cui e demandata la rappresentazione effettiva degli elementi.

48 https://en.wikipedia.org/wiki/Data_binding 49 https://msdn.microsoft.com/library/windows/apps/windows.ui.xaml.controls.listview.aspx

6 – Implementazione

41

Figura 27 – BookingsPage.xaml.cs

6 – Implementazione

42

Figura 28 – BookingsPage.xaml

43

7 – Conclusioni

7.1 – Risultati ottenuti

Gli obiettivi prefissati per il progetto sono stati raggiunti mediante l’implementazione e la creazione dei

seguenti elementi:

Applicazione Web sviluppata con ASP.NET MVC 5

Web API REST sviluppata con ASP.NET MVC 5

Applicazioni Mobile per dispositivi Windows 10

Progettazione, firmware e drivers per il dispositivo di controllo remoto

Durante lo sviluppo di questo progetto sono inoltre state acquisite nuove conoscenze e approfondite altre,

in particolare riguardanti:

Sviluppo di applicazioni web ASP.NET MVC 5

Tecnologie web quali HTML5 e CSS3

Sviluppo e progettazione di software data-oriented mediante Entity Framework

Progettazione di una base di dati

Sviluppo di applicazioni per la piattaforma UWP destinate a dispositivi Windows 10

Tecnologia NFC, standard MIFARE50 e ISO 14443 A/B51

7.2 – Lavoro svolto

Al fine di realizzare il progetto software oggetto di questa tesi sono stati realizzati un totale di

1 database composto da 15 tabelle

Circa 3100 righe di codice C# a formare indicativamente 130 classi suddivise tra 6 progetti Visual

Studio

Più di 170 righe di codice JavaScript

Più di 550 righe di codice XAML

Circa 900 righe tra tag HTML e regole di stile CSS

7.3 – Scenari di sviluppo futuri

Il progetto non è attualmente operativo e necessita alcuni miglioramenti soprattutto dal punto di vista

dell’interfaccia grafica, del sistema di notifiche e del sistema di controllo remoto.

Una volta effettuate migliorie necessarie e sottoposto il software ad un’accurata fase di testing la

piattaforma potrà ritenersi pronta per debuttare sul mercato e diventare un prodotto commerciale.

Tra gli scenari di sviluppo futuri troviamo inoltre la possibilità di implementare un meccanismo che

consenta la suddivisione della spesa in caso di prenotazioni condivise tra più membri di uno stesso gruppo

ed eventualmente un sistema di registrazione e archiviazione online delle sessioni di prova in modo da

premettere agli utenti di accedere facilmente a queste direttamente dal portale o dall’applicazione,

50 https://en.wikipedia.org/wiki/MIFARE 51 https://en.wikipedia.org/wiki/ISO/IEC_14443

7 – Conclusioni

44

casomai fornendo l’integrazione con piattaforme di hosting musicale già esistenti, quali ad esempio

SoundCloud52.

Anche se inizialmente dedicato alla gestione di sale prova musicale, il progetto può facilmente vedere

applicazione anche in altri campi e situazioni in cui è necessaria l’automazione della gestione di luoghi

pubblici condivisi.

52 https://soundcloud.com

45

8 – Bibliografia e sitografia

8.1 – Riferimenti bibliografici

MFRC522 Product data sheet Rev. 3.6, NXP Semiconductors — 14 December 2011

SD2403 High Precision RTC module Product data sheet, Shenzhen wave electronic technology ltd

ISO/IEC FCD 14443-4 Identification cards — Contactless integrated circuit(s) cards — Proximity

cards — Part 4: Transmission protocol, ISO/IEC — 13 June 2007

AN1303 — MIFARE Ultralight as Type 2 Tag Rev. 1.5, NXP Semiconductors — 2 October 2012

AN1305 — MIFARE Classic as NFC Type MIFARE Classic Tag Rev. 1.3, NXP Semiconductors — 2

October 2012

AN10833 — MIFARE Type Identification Procedure Rev. 3.5, NXP Semiconductors — 27 March 2014

NFC Record Type Definition (RTD) technical specification, NFC Forum™— 24 July 2006

HTML5 CSS3 JavaScript — Pellegrino Principe, Apogeo — 19 September 2012

Programming Microsoft ASP.NET MVC, 3rd Edition — Dino Esposito, Microsoft — 15 February 2014

Microsoft Visual C# Step by Step, 8th Edition — John Sharp, Microsoft — 30 October 2015

Getting started with .NET Gadgeteer — Simon Monk, Make: Projects — 7 May 2012

8.2 – Riferimenti sitografici

https://en.wikipedia.org/

https://msdn.microsoft.com/en-us/library/

http://research.microsoft.com/en-us/projects/gadgeteer/

http://www.slideshare.net/mobile/mircovanini1/iot-with-signalr-net-gadgeteer-netmfwork/

http://blogs.msdn.com/b/nfc/archive/2015/05/01/how-to-write-an-nfc-host-card-emulation-hce-

app-with-windows-10-for-mobile.aspx

https://mva.microsoft.com/en-US/training-courses/a-developers-guide-to-windows-10-12618

https://mva.microsoft.com/en-US/training-courses/introduction-to-asp-net-5-13786

https://mva.microsoft.com/en-US/training-courses/adding-style-with-css-8474

https://mva.microsoft.com/en-us/training-courses/building-responsive-ui-with-bootstrap-8378

https://mva.microsoft.com/en-US/training-courses/introduction-to-jquery-8429