Progettazione e sviluppo di una applicazione web per la gestione delle prenotazioni in ambito ristorativo

Alma Mater Studiorum · Università di Bologna

SCUOLA DI SCIENZE

Corso di Laurea in Scienze di Internet

PROGETTAZIONE E SVILUPPO

DI UNA APPLICAZIONE WEB PER

LA GESTIONE DELLE PRENOTAZIONI

IN AMBITO RISTORATIVO

Tesi di Laurea in Basi di Dati

Relatore:

Chiar.mo Prof.

Danilo Montesi

Presentata da:

Nicola Buongiorno

Sessione III

Anno Accademico 2012-2013

Indice

1 Introduzione 5

1.1 My Restaurant Booking Manager (MyRBM) . . . 6

1.2 Applicazione web . . . 8

1.3 Riassunto dei prossimi capitoli . . . 9

2 Analisi dei requisiti 11 2.1 L'idea . . . 12

2.2 Glossario . . . 14

2.3 Requisiti Funzionali . . . 15

2.4 Requisiti non funzionali . . . 17

2.5 Casi d'uso . . . 19

2.5.1 Diagramma dei casi d'uso . . . 19

2.5.2 Registra account . . . 21 2.5.3 Login . . . 22 2.5.4 Visualizza prenotazioni . . . 23 2.5.5 Prenota . . . 24 2.5.6 Modica . . . 25 2.5.7 Logout . . . 26

2.6 Diagramma delle attività . . . 27

3 Progettazione 29 3.1 Tecnologie utilizzate . . . 31

3.2 Database . . . 37

3.2.1 Entità Account . . . 38

3.2.3 Relazione make/eettua . . . 40

3.2.4 Creazione database . . . 41

4 Sviluppo e test 43 4.1 Struttura del sito MyRBM . . . 43

4.1.1 Funzioni rilevanti per la web-app . . . 45

4.1.1.1 Index (PHP) e functions (Javascript) . . . 46

4.1.1.2 Validate (Javascript) . . . 47

4.1.1.3 Functions (PHP) . . . 51

4.2 Navigazione del sito . . . 54

4.2.1 Home Page . . . 54 4.2.2 About . . . 56 4.2.3 Sign Up . . . 57 4.2.4 Log in . . . 60 4.2.5 Insert Reservation . . . 61 4.2.6 Manage reservation . . . 66 4.2.6.1 Modify Reservation . . . 71 4.2.7 Log out . . . 72 4.3 Test . . . 73 5 Conclusioni 77 5.1 Stima del costo . . . 77

Capitolo 1

Introduzione

Negli ultimi anni si è assistito ad uno sviluppo delle ICT (Information and Co-munication Technology) e delle relative applicazioni come fulcro funzionale allo sviluppo; nonstante ciò gran parte dei consumatori e dei gestori di attività risto-rative (ristoranti, pizzerie, trattorie ecc.) considerano l'impiego della tecnologia e internet una componente alternativa anzichè essenziale.

A partire dalle prime innovazioni tecnologiche si denota come l'impatto di inter-net abbia suscitato notevoli migliorie sia nel campo della gestione/progettazione che nel campo economico. Analizzando l'attuale periodo e confrontandomi con l'ambiente circostante ho potuto notare che circa l'80% delle strutture ristorati-ve si sia dovuta adeguare ai tempi e sviluppare forme di competizione inerenti all'ambito che la tecnologia sta sviluppando.

L'obiettivo di questa tesi è la progettazione e lo sviluppo di una web application attinente la gestione delle prenotazioni dei tavoli per un'attività ristorativa, in un mercato del tipo Business to Business (B2B) ovvero le transazioni che si vengono a instaurare tra fornitore di servizio (Web app) e consumatore (attività ristorativa). MyRBM (My Restaurant Booking Manager) è il nome che ho scelto per la Web app dopo un'attenta ricerca di mercato che si è focalizzata oltre che sull'analisi del nome dei possibili competitor, anche sull'impatto che lo stesso può avere sui possibili utilizzatori.

1.1 My Restaurant Booking Manager (MyRBM)

Attraverso una semplice interfaccia web il gestore dell'attività ristorativa ha la possibilità di visualizzare, inserire e modicare prenotazioni dei tavoli per i propri clienti. Nel caso pertinente alla ristorazione, in accordo con i tempi che seguono e sempre una maggiore autonomia del consumatore che attraverso la mediazione di internet è sempre più informato e critico nei confronti della gestione, vuole spendere il minor tempo possibile per lo screening delle proposte di qualità/prezzo. Il nuovo gestore nell'epoca del post-moderno si trova a dover congurare un rapporto con il proprio cliente, sia il più immediato possibile, sia nel modo più esaustivo ed ecace possibile, abbattendo i costi di ricerca e di prenotazione (di un tavolo). Nella mia congurazione di web application ho ritenuto la semplicità e la trasparenza come assunto fondamentale di base, essendo questa la ricetta di un buon management e di soddisfazione del top management (ristoratore).

Partendo dal presupposto che il consumatore non vuole solo la facilità di uti-lizzo ma anche immediato riscontro pratico e la premiazione della fedeltà, mi sono servito di un database come raccolta dati e ho fatto sì che il gestore, attraverso l'utilizzo di un'interfaccia elettronica (web), abbia accesso immediato e uno sto-rico delle prenotazioni del cliente per capire quando lo stesso può aver avuto un problema e magari orirgli una particolare promozione in futuro. L'idea, seppur non troppo rivoluzionaria, vuole ampliare il raggio di azione del termine stesso booking che n ora è stato quasi esclusivamente inteso come prenotazione di voli, hotel, appartamenti ecc. Ho voluto concentrare la mia ricerca verso un campo in fase di sviluppo, booking management restaurant; ampliando il contesto semantico del termine proprio (booking/prenotazione), sfruttando le tecnologie at-tuali che vanno oltre il mero utilizzo sico di carta e penna che in questi anni è stato causa di consolidati errori, oltre che grammaticali, di distrazione e negligenza da parte di un manager di un'attività ristorativa. Voglio mettere in evidenza che la gestione (es. ristorante) comprende, oltre gli aspetti economici di massimizza-zione del protto e quindi soddisfamassimizza-zione del cliente, anche l'organizzamassimizza-zione della sala in base alle esigenze di circostanza. In un esempio che vede la congurazione di un'attività ristorativa che utilizza MyRBM e che attraverso questa conosce e migliora i propri rapporti con la clientela, oltre che ottimizzare l'allocazione

attra-verso note aggiuntive, riesce a specicare e far sì che le prenotazioni rispecchino le diverse esigenze dei clienti. Si denota come il processo di customer care si venga così a consolidare vedendo i desideri del consumatore trasformati in una realtà ben delineata e precisa descritta da egli stesso nelle note; si pensi ai posti di prestigio e alla lotta per aggiudicarseli. Attraverso l'immagazzinamento delle conoscenze e preferenze e della frequenza di prenotazione, l'assegnazione di questi contesi posti di onore diviene non una questione prettamente economica ma di reciproca stima e fedeltà nei confronti del cliente. Voglio ulteriormente esplicitare la mia decisione di lasciare il libero arbitrio della gestione e della composizione della sala esclusi-vamente al direttore di sala, che di volta in volta deve arontare nuove richieste di composizione e agglomeramento tavoli in modo da garantire la totale custo-mer satisfaction [PreRog07], avviando così un processo di delizzazione che vede nella fedeltà stessa un reale guadagno (protto) da parte del gestore dell'attività ristorativa, sapendo che un cliente pienamente fedele (soddisfatto) porta maggiore protto piuttosto che andare a cercarne uno nuovo; la stessa fedeltà che intendo creare attraverso un usso diretto con il manager dell'attività ristorativa, che ri-conoscendo semplicità e trasparenza nel mio servizio, si troverà a gestire il proprio locale in maniera ottimale abbattendo i costi di gestione e di tempo.

La mia web application si inserisce in un mercato (restaurant booking) altamen-te competitivo, che va dal programma/software progettato e sviluppato esclusiva-mente ad hoc e gestito dal personale con un dispositivo elettronico (es. Direca1_),

al sito che propone un elenco di ristoranti/pizzerie circoscritto in base alla località e alle caratteristiche (es. book a restaurant2_{). Studiando ed analizzando il mercato}

in questione e volendomi esclusivamente dedicare alla gestione del booking della ristorazione da parte del manager, ho sviluppato un sistema erga omnes utilizza-bile gratuitamente da pc, smartphone e tablet e adattautilizza-bile ad ogni tipo di attività ristorativa. Dalla mia ricerca risulta che all'estero ma soprattutto in Italia, non esistono applicazioni che orono esclusivamente questo servizio e che siano econo-micamente accessibili, essendo la maggior parte inserite nelle due grandi categorie precedentemente descritte. Tutte queste applicazioni hanno in comune una serie di componenti aggiuntive che danno sì la possibilità di personalizzazione ma

aggiun-1_{Software di gestione ristoranti; URL: http://www.direca.it/}

gono elementi che possono distrarre il consumatore ed elementi di compilazione dati che sommati lo portano a un reale dispendio di tempo. Avendo semplicato e snellito i servizi sopra citati dalle funzionalità eccedenti e superue, ho focalizzato la mia attenzione sugli aspetti cruciali che sono la semplicità di comprensione e di utilizzo. Il sito che più si avvicina a MyRBM è simple Electronic Reservation Book3 _(simpleERB).

La seguente tabella mostra come le volute mancanze nella mia applicazione siano dettate dalla ricerca costante di massimizzazione del tempo[DinFab05].

prenotazione tavolo cliente nuovo gestione tavoli gestione ordini tempo di prenota-zione facilità utiliz-zo dispositivo MyRBM si si no no 2 si web simpleERB si no si si 3 no web Direca si si si si 4 no palmare ad hoc Tempo di prenotazione = ∑si; si = 1; no = 0.

1.2 Applicazione web

Una applicazione web è una applicazione client/server per un ambiente stateless, cioè senza memoria, che utilizza le tecnologie internet. Con il termine Web app si descrive un'applicazione accessibile via web per mezzo di una network, come ad esempio una Intranet o attraverso la rete Internet. Pertanto, saper programma-re per il web signica conosceprogramma-re i diversi meccanismi e strumenti per conservaprogramma-re o passare i dati, detti parametri, tra le diverse pagine dell'applicazione web. In pratica una Web-application, è un programma che non necessita di essere instal-lato nel computer in quanto esso si rende disponibile su un server in rete e può essere fatto funzionare attraverso un normale Web browser (es. Google Chrome, Mozilla Firefox, Opera, ecc.) in posizione di client. Il client, dopo aver instaurato una connessione con il server, invia la richiesta per un servizio; il server dopo aver

elaborato i dati necessari rende disponibile al client il servizio richiesto. A die-renza dei siti web statici (HTML), l'applicazione web viene realizzata con una o più tecnologie (PHP, Ajax, Servlet, Database ecc.) che permettono la creazione di un sito dinamico, cioè di un sito nel quale il contenuto delle pagine varia durante l'interazione.

Le applicazioni Web si pongono come valida alternativa alle tradizionali appli-cazioni Client/Server per vari motivi:

ˆ facilità di distribuzione e aggiornamento: un'applicazione Web risiede inte-ramente sul server, per cui la sua pubblicazione coincide con la distribuzione e l'aggiornamento ed è automaticamente disponibile a tutti gli utenti; ˆ accesso multipiattaforma: l'accesso all'applicazione è indipendente

dall'hard-ware e dal sistema operativo utilizzato dagli utenti;

ˆ riduzione del costo di gestione: l'uso di Internet come infrastruttura per un'applicazione Web riduce notevolmente sia i costi di connettività che i costi di gestione dei client;

ˆ scalabilità: un'applicazione Web ben progettata può crescere insieme alle esigenze dell'azienda senza particolari problemi.

1.3 Riassunto dei prossimi capitoli

Nel secondo capitolo viene denito il documento di analisi dei requisiti composto dal glossario dei termini utilizzati, l'idea da sviluppare, i requisiti funzionali e non funzionali, i casi d'uso e i diagrammi di attività.

Il terzo capitolo descrive la tecnologia e gli strumenti che sono stati acquisiti ed impiegati per la realizzazione dell'applicazione : XAMPP, Apache, MySQL, PHP, HTML, SQL, JavaScript su piattaforma Microsoft; e descrive la progettazione della base di dati utilizzata.

Nel quarto capitolo viene descritta l'implementazione del sito con la spiegazione di ogni pagina prodotta e i test eettuati su di esso.

L'ultimo capitolo comprende le conclusioni del lavoro svolto, una stima del costo per produrre la Web app e la sezione degli sviluppi futuri.

Capitolo 2

Analisi dei requisiti

Un requisito è una scrittura più o meno formale e rigorosa di una caratteristica del sistema, fatta dallo specialista. La gestione dei requisiti (acquisizione, analisi, negoziazione, specica, validazione) è il primo passo del processo di sviluppo e una delle fasi più critiche dello sviluppo software, perché inuenza in modo diretto il successo o il fallimento dei progetti.

L'altalena rappresentata in gura 2.11 _{è la metafora più comune per la}

gestio-ne dei requisiti gestio-nei progetti software. Lo scopo che si pregge questo documento è quello di formalizzare ciò che dovrà essere sviluppato e implementato nelle fa-si succesfa-sive del progetto. Per le speciche di progettazione verranno utilizzati diagrammi UML, in quanto sono uno standard ed evitano le possibili ambiguità. [PreRog07]

2.1 L'idea

Si vuole realizzare un'applicazione web based che permetta a degli utenti di eet-tuare prenotazioni. Lo scenario tipico è quello di un'attività ristorativa che vuole memorizzare le prenotazioni dei tavoli per i propri clienti. L'utilizzatore ideale del sistema è il gestore (manager) o dipendente di un ristorante, trattoria, pizzeria o altre attività che hanno bisogno di gestire prenotazioni dei tavoli. L'applicazione deve consentire l'inserimento, la visualizzazione, la modica e la rimozione delle prenotazioni. In particolare, tramite internet, deve essere possibile gestire le pre-notazioni dei tavoli richieste dai clienti dell'utente, che di solito avviene mediante telefonata o contatto diretto con il manager dell'attività; inoltre deve consentire la consultazione dello storico delle prenotazioni.

Il nome della web-app sarà My Restaurant Booking Manager (MyRBM). Le funzionalità richieste sono:

ˆ Registrazione dell'account utente ˆ Login dell'utente nel sistema ˆ Visualizzazione delle prenotazioni ˆ Prenotazione

ˆ Modica o rimozione di prenotazioni create in precedenza ˆ Logout dell'utente dall'applicazione

1_{La fonte dell'immagine che rappresenta la metafora dell'altalena (Fig. 2.1) è} il sito: http://www.francescocetola.it/2013/09/09/cosa-lutente-realmente-voleva-la-metafora-dellaltalena/

Esempio. Un dipendente di un ristorante riceve una telefonata da parte di un cliente Pippo, che vuole prenotare un tavolo per 4 persone a una certa data e ora, fornendo inoltre un contatto telefonico e/o indirizzo e-mail, ed eventualmente altri dettagli (note). Il dipendente verica la disponibilità di posto per la data e ora fornita e in caso di esito positivo inserisce la prenotazione con le informazioni del cliente; la prenotazione eettuata verrà visualizzata come mostrato in gura 2.2.

2.2 Glossario

TERMINE DESCRIZIONE SINONIMI

User Attore del sistema Utente, gestore,

dipendente, client, manager Cliente Attore esterno al sistema

che interagisce con l'Utente

clienti nuovi, clienti delizzati Login Azione dell'utente per

essere autenticato nel sistema

accesso al sistema, connessione, autenticazione Logout Azione dell'utente per

uscire dal sistema

uscita dal sistema, disconnessione Account Informazioni dell'utente

registrato nel sistema

account ristorante Prenotazione Inserimento delle

informazioni dettagliate del cliente che prenota nel

sistema

booking, reservation, promemoria

Visualizza prenotazioni Lista delle prenotazioni sulla home page

manage reservation Home Page Pagina principale

dell'applicazione dove è visualizzata la lista delle

prenotazioni

pagina principale

Filter Filtro che consente di visualizzare le prenotazioni

di una determinata data

ltro

Password sequenza di caratteri alfanumerici scelta dall'utente per accedere al

sistema

parola segreta

MyRBM Nome abbreviato della web-app

My Restaurant Booking Manager

2.3 Requisiti Funzionali

I requisiti funzionali descrivono le funzionalità ed i servizi forniti dal sistema (cosa deve essere fatto). Nel ciclo di sviluppo software i requisiti funzionali rappresentano i casi d'uso. Di seguito sono riportate nel dettaglio le funzionalità richieste.

Registra account

Rappresenta la pagina di benvenuto (welcome) dell'applicazione. Ogni utente che intende utilizzare l'applicazione deve essere registrato nel database. Al primo accesso l'utente per poter fare il Login nel sistema deve inserire dei dati personali di registrazione:

ˆ indirizzo e-mail ˆ nome del ristorante ˆ password

ˆ conferma password

Una volta che l'utente ha inserito i suoi dati, il sistema li memorizza nel database per poterli utilizzare successivamente in fase di login. Per l'autenticazione nel sistema l'utente dovrà inserire nome del ristorante come nome account e password scelta.

Login

Questa funzionalità permette al sistema di autenticare l'utente tramite l'account creato precedentemente nel caso d'uso registra account.

In fase di login il sistema mostra all'utente i campi in cui inserire nome del ristorante e password, verica la correttezza dei dati inseriti confrontandoli con i dati presenti nel database.

Se i dati inseriti risultano corretti, l'utente viene autenticato nel sistema e può usare l'applicazione, se i dati di autenticazione non sono corretti il sistema propone all'utente di modicarli.

Visualizzazione delle prenotazioni

Questo è l'aspetto più importante dell'applicazione, ovvero la funzione principale. La visualizzazione delle prenotazioni deve prevedere 3 viste:

1. Se non ci sono prenotazioni per il giorno attuale il sistema mostra nella home page There are no Reservations - Data attuale

2. Se sono presenti prenotazioni per il giorno attuale, nella home page verrà mo-strata una tabella con le prenotazioni odierne. Per ogni prenotazione vengono mostrate tutte le informazioni inserite, e vengono evidenziati i clienti che non erano presenti nel database, ovvero i nuovi clienti dell'attività ristorativa. 3. Il sistema deve prevedere una sezione Filter da cui è possibile visualizzare la

lista di prenotazioni di una data scelta dall'utente. Quindi l'utente seleziona una data e il sistema visualizza le prenotazioni relative alla stessa data se presenti, altrimenti visualizza There are no Reservations.

Prenotazione

L'utente che vuole memorizzare una richiesta di prenotazione concorda con il cliente data e ora.

Il sistema gli presenta un form in cui inserire le informazioni della prenotazione con i seguenti campi:

ˆ Data: la data della prenotazione ˆ Ora: orario della prenotazione ˆ Nome del cliente (facoltativo)

ˆ Cognome del cliente: riferimento al cliente

ˆ Numero di telefono (facoltativo): per poter eventualmente contattare il clien-te

ˆ Indirizzo e-mail: per memorizzare il cliente nel database ˆ Numero di persone: dato fondamentale della prenotazione

ˆ Note (facoltativo): in questo campo sarà possibile esprimere informazioni in più sulla prenotazione, ad esempio si può inserire che nel tavolo c'è una persona celiaca oppure il manager può inserire informazioni su un cliente. Il sistema crea l'evento alla data e ora stabilita, lo memorizza nel database e aggiorna la lista delle prenotazioni.

Modica - Rimozione

L'utente visualizza la lista delle prenotazioni, selezionando un determinato evento l'applicazione dovrà consentire la modica o eliminazione dello stesso.

Logout

Il sistema deve fornire la procedura di uscita dall'applicazione. Eettuando il logout l'utente viene scollegato dall'applicazione.

2.4 Requisiti non funzionali

I requisiti non funzionali non sono collegati direttamente con le funzioni implemen-tate dal sistema, ma piuttosto alle modalità operative, di gestione. Deniscono vincoli sullo sviluppo del sistema. In seguito verranno descritti tali requisiti.

Responsive web design

Nello sviluppo dell'applicazione è richiesto l'utilizzo della tecnica di web design Responsive, in modo che le pagine web adattino automaticamente il layout per fornire una visualizzazione ottimale in funzione dell'ambiente nei quali vengono visualizzati: pc, tablet, smartphone sono i principali.

Durata sessione

Se l'utente non esegue alcuna azione nel sistema, la sessione deve interrompersi dopo 20 minuti, quindi scollegare l'utente.

Visualizzazione delle prenotazioni

Le prenotazioni vengono elencate in una lista in ordine di data e con tutte le informazioni fornite dal cliente, inoltre deve essere intuibile quali sono i nuovi clienti dell'utente.

Linguaggio di markup

Il linguaggio di markup da utilizzare è HTML5.

Database

Le informazioni da salvare nel database riguardano gli account degli utilizzato-ri del sistema e le prenotazioni eettuate dal sistema. Per quanto utilizzato-riguarda le prenotazioni devono essere memorizzate le informazioni relative al cliente.

Lingua

L'applicazione deve essere in lingua inglese.

Sicurezza

Il sistema deve prevedere delle norme di sicurezza:

ˆ le password salvate nel database devono essere criptate

ˆ controllare le variabili che arrivano dai form per evitare attacchi di SQL Injection, Form Injection, Variable Injection.

Concorrenza

L'applicazione deve prevedere l'utilizzo di più account contemporaneamente, e uno stesso account deve poter essere utilizzato da più utenti allo stesso momento.

2.5 Casi d'uso

Un caso d'uso specica cosa ci si aspetta da un sistema (what?) ma nasconde il suo comportamento (how?). E' una sequenza di azioni, con varianti, che produ-cono un risultato osservabile da un attore e rappresenta un requisito funzionale. Ogni sequenza (detta scenario) rappresenta l'interazione di entità esterne al siste-ma (attori) con il sistesiste-ma stesso o sue componenti. Il usso principale degli eventi viene separato dalle varianti alternative.

L'attore rappresenta un soggetto o un'entità che non fa parte del sistema, ma interagisce in qualche modo con esso. Individua un ruolo che l'utente ricopre nell'interagire con il sistema. Gli attori eseguono i casi d'uso.

Nel nostro caso l'attore del sistema è l'utente (gestore/manager di un ristoran-te), i casi d'uso sono: Registra account, Login, Visualizza prenotazioni, Prenota, Modica, Logout.

2.5.1 Diagramma dei casi d'uso

Il diagramma dei casi d'uso è il modello che descrive i requisiti del sistema in termini di funzionalità (Casi d'Uso) e ambiente circostante (Attori). Mostra cosa deve fare il sistema.

Figura 2.3: Diagramma dei casi d'uso

Di seguito vengono descritte le speciche dei casi d'uso con scenari principali e alternativi. Uno scenario è una sequenza di passi che descrivono l'interazione tra un sistema e un attore (che dovrebbe trarre vantaggio dall'interazione).

2.5.2 Registra account

ˆ Nome caso d'uso: Registra account ˆ Id: UC1

ˆ Attori: Utente ˆ Precondizioni:

1. l'utente non è registrato nel sistema ˆ Scenario principale:

1. l'utente accede per la prima volta al sistema

2. il sistema visualizza la scelta tra Login e Registra account 3. l'utente sceglie Registra account

4. il sistema visualizza i campi da compilare per registrare l'account ristorante 5. l'utente inserisce i dati di registrazione

6. il sistema verica la correttezza dei dati

(a) se i dati non sono corretti il sistema evidenzia i campi da modicare e ritorna al punto 4

7. se i dati sono corretti il sistema conclude la fase di registrazione 8. l'utente può eettuare il login

ˆ Postcondizioni:

1. L'utente è registrato nel sistema ˆ Scenario secondario:

2. il sistema visualizza i campi da compilare per la registrazione dell'account 3. l'utente inserisce i dati

4. il sistema verica che i dati sono gia presenti nel database

5. il sistema avvisa l'utente che i dati inseriti sono già stati utilizzati ˆ Postcondizioni:

1. Inizia il caso d'uso Login

2.5.3 Login

ˆ Nome caso d'uso: Login ˆ Id: UC2

ˆ Attori: Utente ˆ Precondizioni:

1. L'utente ha avviato il sistema ˆ Scenario principale:

1. il caso d'uso inizia quando l'utente avvia l'applicazione da un browser 2. il sistema visualizza i campi dove inserire username e password dell'utente 3. l'utente inserisce username e password

4. il sistema verica se username e password sono corretti

(a) se username e password non sono corretti si ritorna al punto 2. 5. Se username e password sono corretti il sistema visualizza la homepage

1. l'utente è autenticato nel sistema e visualizza la home page dell'applicazione ˆ Scenario secondario:

1. l'utente non è registrato nel sistema

2. il sistema avvia il caso d'uso Registra account ˆ Postcondizioni:

1. inizia il caso d'uso Registra account

2.5.4 Visualizza prenotazioni

ˆ Nome caso d'uso: Visualizza prenotazioni ˆ Id: UC3

ˆ Attori: Utente ˆ Precondizioni:

1. L'utente ha eettuato il login ˆ Scenario principale:

1. Il sistema mostra la lista delle prenotazioni del giorno attuale 2. L'utente visualizza le prenotazioni del giorno attuale

ˆ Postcondizioni:

1. L'utente può eettuare modiche alla lista prenotazioni ˆ Scenario secondario 1:

1. Il sistema mostra la lista delle prenotazioni del giorno attuale

3. Il sistema chiede all'utente la data interessata 4. L'utente sceglie la data da visualizzare

5. Il sistema mostra la lista delle prenotazioni della data scelta ˆ Postcondizioni:

1. L'utente visualizza le prenotazioni della data scelta e può eettuare modiche ˆ Scenario secondario 2:

1. L'utente vuole visualizzare le prenotazioni di una certa data (attuale o non), in cui ancora non esistono prenotazioni

2. Il sistema avvisa l'utente che per quella data non ci sono prenotazioni ˆ Postcondizioni:

1. L'utente visualizza che non ci sono prenotazioni per una determinata data

2.5.5 Prenota

ˆ Nome caso d'uso: Prenota ˆ Id: UC4

ˆ Attori: Utente ˆ Precondizioni:

1. L'utente ha eettuato il login nel sistema ˆ Scenario principale:

1. Il caso d'uso inizia quando l'utente vuole inserire una prenotazione 2. Il sistema chiede all'utente i dati della prenotazione

4. Il sistema verica la correttezza dei dati

(a) se i dati inseriti non sono corretti il sistema avvisa l'utente e ritorna al punto 2

5. se i dati sono corretti il sistema aggiunge la prenotazione ˆ Postcondizioni:

1. L'utente può visualizzare o modicare la prenotazione eettuata

2.5.6 Modica

ˆ Nome caso d'uso: Modica ˆ Id: UC5

ˆ Attori: Utente ˆ Precondizioni:

1. L'utente ha creato la prenotazione ˆ Scenario principale:

1. Il caso d'uso inizia se l'utente vuole eettuare modiche ad una prenotazione 2. Il sistema mostra la lista delle prenotazioni

3. L'utente sceglie la prenotazione da modicare 4. Il sistema mostra i dettagli della prenotazione 5. L'utente eettua le modiche desiderate

6. Il sistema controlla la correttezza dei dati modicati

(a) se i dati inseriti non sono corretti il sistema avvisa l'utente e ritorna al punto 4

7. Se i dati inseriti sono corretti il sistema aggiorna la prenotazione ˆ Postcondizioni:

1. L'utente visualizza la prenotazione aggiornata ˆ Scenario secondario:

1. L'utente vuole cancellare una prenotazione 2. Il sistema mostra la lista delle prenotazioni 3. L'utente sceglie la prenotazione da eliminare

4. Il sistema elimina la prenotazione scelta e aggiorna la lista prenotazioni ˆ Postcondizioni:

1. L'utente visualizza la lista delle prenotazioni aggiornata

2.5.7 Logout

ˆ Nome caso d'uso: Logout ˆ Id: UC6

ˆ Attori: Utente ˆ Precondizioni:

1. L'utente ha eettuato il login ˆ Scenario principale:

1. il caso d'uso inizia quando l'utente vuole uscire dal sistema 2. l'utente chiede al sistema di disconnettersi

3. il sistema disconnette l'utente ˆ Postcondizioni:

2.6 Diagramma delle attività

Il diagramma delle attività, in UML, è un diagramma di usso (con alcuni elementi aggiuntivi) che mostra una sequenza di attività. Viene utilizzato per rappresentare i passi (le transazioni) che compongono il usso di un caso d'uso, descrivono quindi il comportamento dinamico di un sistema. La rappresentazione delle attività è comoda in quanto consente di rappresentare sinteticamente usso principale e ussi alternativi. Il diagramma in gura 2.4 mostra il usso delle attività dell'utente per visualizzare, aggiungere o modicare prenotazioni.

Capitolo 3

Progettazione

In questa fase si denisce l'architettura software su cui si baserà la realizzazione del prodotto My Restaurant Booking Manager. Ho scelto una strutturazio-ne tipica su tre livelli logico-funzionali (applicazioni Three-Tier) ma che possono essere distribuiti anche su più li velli (applicazioni Multi-Tier)

L'applicazione Web Three-Tier si sviluppa su 3 livelli [PMA13]:

ˆ Presentazione (Cliente): costituisce l'interfaccia utente dell'applicazione e corrisponde al browser Web. Le tecnologie scelte da utilizzare sono HTML (formato per la presentazione di ipertesti) e CSS (foglio di stile per documenti HTML).

ˆ Applicazione (Servente Web): è il livello logico della web-app, la componente elaborativa. Dal lato server (Server-side) utilizza la tecnologia PHP, dal lato client(Client-side) utilizza il linguaggio di scripting Javascript.

ˆ Dati (Servente RDBMS): consente di modellare e gestire il contenuto infor-mativo dell'applicazione. La tecnologia usata a questo livello è il Database relazionale MySQL.

La gura 3.11 _{rappresenta gracamente la struttura di una web application:}

1_{Fonte dell'immagine:} scuola.linux.it/docs/altre_scuole/planck/tecnologie-web/tecnologie-web12.html

Figura 3.1: Struttura web application

Gli strumenti che ho scelto di utilizzare sono:

XAMPP che è una piattaforma software open source costituita dal server web Apache, il database MySQL, un interprete PHP5 e l'applicazione php-MyAdmin per la gestione via web delle basi di dati, cui si accede collegandosi all'indirizzo http://localhost/mysql.

Gli script eseguiti nella parte Client-side sono scritti nel linguaggio Javascript e qualche funzione dalla libreria jQuery. HTML per la visualizzazione delle pagine al client che vengono create dinamicamente dalle pagine PHP che risiedono nel Server.

Per la stesura del codice PHP ho utilizzato l'ambiente di sviluppo open source Eclipse per PHP.

XAMPP è facile da usare rispetto ad altri software simili, basta scaricarlo gratuitamente e installarlo. Una volta installato XAMPP bisogna caricargli le pagine PHP, gli script Javascript ed eventuali fogli di stile CSS ed è possibile avviare il server Apache e il software incluso MySQL. Quando il server è attivo è possibile gestire il database tramite l'interfaccia graca phpMyAdmin.

Per eettuare i test ho usato l'indirizzo locale http://localhost/myrbm dove myrbm è il nome del package contenti tutti i le necessari; quindi da un qual-siasi browser è possibile testare il funzionamento del codice inserito collegandosi all'indirizzo impostato su XAMPP.

3.1 Tecnologie utilizzate

In questa sezione sono descritte in dettaglio le tecnologie utilizzate per la realizza-zione dell'applicarealizza-zione. Lo studio di esse ha occupato una parte rilevante del mio lavoro in quanto sono tecnologie di nuova generazione.

HTML

HTML (Hypertext Markup Language - linguaggio di marcatura di Ipertesti) è il linguaggio per creare pagine ipertestuali (pagine web). HTML non è come un linguaggio di programmazione ma un semplice sistema di contrassegno, i cui TAG vengono riconosciuti ed interpretati dai browser web. Questo potente mezzo di comunicazione consente di visualizzare i contenuti delle pagine nella veste gra-ca preferita e permette l'introduzione di elementi multimediali (suoni, immagini, lmati ecc.) nonché la consultazione di documenti in modo non sequenziale. I do-cumenti HTML sono spesso chiamati "Pagine Web", in pratica un le in formato HTML è un le che, oltre a contenere il testo che verrà visualizzato dal browser, contiene anche dei comandi (racchiusi sempre tra i simboli "<" e ">" chiamati "tag") che associano al testo un particolare attributo. Gli elementi del linguaggio vengono detti mark up tag o semplicemente tag: essi di solito sono utilizzati a coppie, e possono contenere uno o più attributi. Generalmente l'aspetto di un tag è il seguente

<nome tag> Testo inuenzato dal tag </nome tag>

Una pagina in codice HTML può essere redatta con un semplice editor di testi e salvata con estensione .html o .htm. Quando il browser (Mozilla Firefox, Google Chrome ecc.) carica un le HTML, legge e interpreta i tag in esso contenuti e presenta il risultato di tale elaborazione sullo schermo. Poiché i le sono soggetti all'interpretazione del browser può succedere che alcune parti del testo o alcune sue particolari formattazioni possano essere interpretate in modo diverso da browser dierenti.

JAVASCRIPT

Javascript è un linguaggio di scripting per applicazioni client, server che aggiunge elementi interattivi alle pagine web (HTML) con la possibilità di interfacciarsi a database o di gestire i le. Linguaggio di scripting sta ad indicare che i programmi creati in Javascript sono interpretati e non compilati, quindi non possono essere eseguiti direttamente dal sistema operativo, ma è necessario disporre di un browser che possa interpretare ed eseguire le istruzioni. L'utilizzo principale di Javascript riguarda l'ottimizzazione di pagine HTML, per creare pagine dinamiche e inte-rattive. Javascript è un linguaggio dinamico orientato agli oggetti; esso ha tipi e operatori, oggetti nucleo, e metodi. La sua sintassi deriva dai linguaggi Java e C, quindi molte strutture da questi linguaggi ricorrono anche in Javascript. Per poter scrivere codice Javascript è suciente un editor di testo da salvare con estensione .js per poter essere richiamato nelle pagine HTML, oppure si può essere inserire codice Javascript direttamente all'interno dei le HTML utilizzando gli opportuni tag: <script type=text/javascript>codice Javascript</script>.

CSS

Nel progetto sono stati utilizzati i CSS o fogli di stile a cascata (dall'inglese Casca-ding Style Sheet). Essi sono un insieme di regole redatte dal W3C (World Wide Web Consortium) per denire l'aspetto delle pagine HTML e XHTML. La loro caratteristica fondamentale è la possibilità di separare i contenuti dalla format-tazione e imporre una programmazione più chiara e facile da utilizzare, sia per l'autore che per l'utente. Una pagina web è formata fondamentalmente da due elementi: i contenuti veri e propri che la pagina intende fornire e la formattazione , cioè l'aspetto con cui i contenuti saranno mostrati all'utente.

PHP

PHP (acronimo ricorsivo di Hypertext Prepocessor) è un linguaggio di scripting interpretato (non compilato) server-side, con licenza open source, originariamente concepito per la realizzazione di pagine Web dinamiche. Attualmente è utilizzato principalmente per sviluppare applicazioni Web. Il codice PHP viene usato per

ge-nerare dinamicamente i documenti HTML che il client deve ricevere e visualizzare nel browser, ad esempio quando il server web Apache deve gestire un documento richiesto con estensione .php utilizza il processore PHP che restituisce alla ne dell'elaborazione un documento HTML.

I le PHP sono strutturati come un documento HTML, ma contengono sezioni di codice PHP delimitate da <?php e ?>; l'interprete eettua il parsing del le e sostituisce le sezioni di codice PHP con il codice HTML risultante dall'esecuzione. L'output di PHP è un documento HTML, il client riceve tale output senza vedere il codice PHP che lo ha generato.

Per l'accesso al database MySQL PHP mette a disposizione molte funzioni, quali ad esempio mysql_connect(), mysql_select_db(), mysql_query() ecc.

XAMPP

XAMPP è una piattaforma software gratuita costituita da Apache Http Ser-ver, un database MySQL e tutti gli strumenti necessari per usare i linguaggi di programmazione PHP e Perl. Il nome XAMPP è un acronimo dove

X = cross-platform (multipiattaforma) A = Apache (server HTTP)

M = MySQL (database) P = PHP (interprete) P = Pearl (interprete)

Ho scelto di usare questo software per creare il mio web server per la sua semplicità di installazione e utilizzo, soprattutto per creare siti da testare in locale prima di renderli pubblici sulla rete; inoltre la comodità di XAMPP sta anche nel fatto che molte sue funzioni possono essere intuitivamente congurate via web con un browser grazie alla funzione phpMyAdmin. L'interfaccia principale del programma (Pannello di Controllo) è descritta in gura 3.2.

Figura 3.2: Pannello di controllo XAMPP

WEB SERVER APACHE

Apache (o meglio Apache HTTP Server) è una piattaforma server web modulare in grado di operare nei sistemi operativi più diusi. Le pagine .php contengono dei codici destinati a produrre dei comportamenti e a generare dinamicamente conenuti HTML, perchè ciò sia possibile è necessaria la mediazione di un web server. Un web server è un programma che si occupa di ascoltare un canale di comunicazione per intercettare una richiesta da servire. Il client, utilizzando un browser, invia un messaggio di richiesta HTTP , contenente la URL, attraverso il collegamento di rete al web server; questo, catturata la richiesta, risponde, sempre attraverso il protocollo HTTP , con una pagina HTML con il contenuto informativo desiderato dal client. L'insieme dei web server presenti su internet forma il WWW ossia il W orld W ide W eb, il servizio piu sfruttato della rete.

Il web server Apache presenta un'architettura modulare, quindi ad ogni richie-sta del client, vengono svolte funzioni speciche da ogni modulo di cui è composto,

come u nità indipendenti. Ciascun modulo si occupa di una funzionalità, ed il controllo è gestito dal core2_:

Figura 3.3: Architettura modulare di Apache web server

Le linee continue dello schema rappresentano il usso dei dati reale, le linee trat-teggiate il usso dei dati astratti che formano la pipeline. I moduli che compongono il web server Apache sono:

Core: programma principale composto da un ciclo sequenziale di chiamate ai moduli.

Translation: traduce la richiesta del client.

Access control: controlla eventuali richieste malevoli. MIME Type: verica il tipo di contenuto.

Response: invia la risposta al client e attiva eventuali procedure. Logging: tiene traccia delle operazioni che sono state eseguite.

Il core suddivide la richiesta sequenzialmente ai vari moduli, usando i parametri di uscita di un modulo come parametri di accesso per l'altro modulo, creando così l'illusione di una comunicazione orizzontale fra i moduli (pipeline software). Sopra il ciclo core c'è un ulteriore ciclo di polling svolto da un demone che interroga continuamente le linee logiche da cui possono pervenire messaggi di richiesta.

MYSQL

Innanzitutto una base di dati (database) è un insieme di dati logicamente correlati fra loro. I Data Base Management System (DBMS) sono prodotti software in grado di gestire database che hanno grandi quantità di dati, che condividono i dati fra più utenti e applicazioni e che utilizzano dei sistemi di protezione e autorizzazione per l'accesso ai dati. Esistono diversi tipi di DBMS: gerarchico, reticolare, relazionale, ad oggetti; il modello che più si adatta alle mie esigenze è il modello relazionale che organizza i dati in tabelle, basandosi sulle relazioni fra essi.

MySQL è un sistema di gestione di basi di dati relazionali multi-piattaforma distribuito dalla compagnia svedese `MySQL AB' come software libero sotto li-cenza GPLV2 (General Public License version 2 ). Più precisamente MySQL è un RDBMS ("Relational DataBase Management System"), ossia un sistema di ge-stione per database relazionali, che si basa sul linguaggio SQL (Structured Query Language è il linguaggio standard di interrogazione dei database). MySQL si occupa della strutturazione e della gestione a basso livello dei dati stessi, in modo da velocizzarne l'accesso, la modica e l'inserimento di nuovi elementi.

Software utilizzati

ˆ Windows 8.1 pro x64 : sistema operativo ˆ XAMPP: web server

ˆ Eclipse: ambiente di sviluppo (IDE) open source ˆ ArgoUml: per la realizzazione dei diagrammi UML

ˆ Lyx: editor graco per il linguaggio LaTex utilizzato per la stesura di questo documento

ˆ Lucidchart: per la realizzazione del diagramma dei casi d'uso ˆ Notepad++: editor di testo

ˆ Mozilla Firefox, Google Chrome, Opera, Internet Explorer: browser usati per ricerca, sviluppo e test.

3.2 Database

Quando i dati sono molti e salvarli su lesystem risulta ineciente bisogna usare il supporto di una base di dati [Apa].

L'analisi dei requisiti ha portato all'individuazione di due entità fondamentali: Account e Reservation. Le entità e le associazioni che intercorrono tra esse sono rappresentate nel seguente schema Entity/Relationship.

Figura 3.4: Schema Entity/Relationship

Lo schema logico ottenuto è il seguente:

ACCOUNT (email_manager, restaurant_name, password)

RESERVATION (id_reservation, email_manager, email_customer, name_c, sur-name_c, tel_c, time_booking, date, number_of_people)

ACCOUNT_MAKE_RESERVATION (mail_manager, id_reservation)

Nelle sezioni seguenti verrà approfondita l'analisi delle entità , precisando il ruolo di ciascuna.

3.2.1 Entità Account

L'entità Account serve per tenere traccia di tutti gli utilizzatori del sistema (ma-nager ristorante). Il compito principale di Account è la gestione delle credenziali per poter eettuare il login tramite e-mail e password scelti dall'utente in fase di registrazione.

Gli attributi di Account sono i seguenti:

e-mail_manager serve a identicare univocamente un utente del sistema (pri-mary key)

restaurant_name serve per visualizzare il nome dell'attività ristorativa gestite tramite il sistema.

password utilizzata in fase di login insieme all' e-mail per autenticare l'utente nel sistema. Questo campo per motivi di sicurezza viene salvato nel database criptato.

L'entità account risulta la seguente:

Un esempio di tabella Account è rappresentato in gura 3.6.

Figura 3.6: Esempio di tabella Account

3.2.2 Entità Reservation

L'entità Reservation tiene traccia di tutte le prenotazioni eettuate dagli utenti. Gli attributi di Reservation sono i seguenti:

id_reservation serve ad identicare univocamente la prenotazione

email_manager utilizzato per associare la prenotazione ad un determinato uten-te

email_customer serve ad identicare il cliente3 _{che ha richiesto la prenotazione}

name_c nome del cliente

surname_c cognome del cliente tel_c numero di telefono del cliente time_booking ora della prenotazione date data della prenotazione

number_of_people specica il numero di posti a sedere che si vuole prenotare L'entità reservation risulta quindi la seguente:

Figura 3.7: Entità reservation

Un esempio di tabella Reservation è rappresentato in gura 3.8.

Figura 3.8: Esempio di tabella Reservation

3.2.3 Relazione make/eettua

La relazione make è intesa come eettua una o più prenotazioni. Ogni account è associato a uno o molte prenotazioni; ogni prenotazione è associata a un account;

ˆ Entità: Account, Prenotazione

3.2.4 Creazione database

Il database utilizzato è MySQL. La creazione delle tabelle che serviranno all'ap-plicazione è avvenuta nel seguente modo:

1. L'entità Account viene tradotta nella tabella account, con inserimento di dati per test

Figura 3.9: creazione tabella account SQL

2. L'entità Reservation viene tradotta nella tabella reservation, con inseri-mento di dati per testare il corretto funzionainseri-mento

Capitolo 4

Sviluppo e test

È la fase realizzativa. Ogni modulo, come unità indipendente, viene implementato e controllato per assicurarne la correttezza [Xam].

4.1 Struttura del sito MyRBM

Ogni pagina è formata da un menu che si trova in posizione ssa nella colonna a sinistra (Fig. 4.1). Ogni elemento del menu è costituito da una pagina PHP:

ˆ Home: home page del sito che dopo il login rimanda l'utente alla pagina Manage Reservation;

ˆ About: pagina che descrive le informazioni dell'applicazione;

ˆ Sign Up: pagina di benveuto che consente la registrazione al servizio; ˆ Log in: pagina di autenticazione;

ˆ Insert Reservation: è costituita da un form che riceve le informazioni della singola prenotazione da inserire nel database;

ˆ Manage Reservation: pagina principale che consente la visualizzazione delle prenotazioni del giorno in corso, oppure di una data scelta dall'uten-te, consente inoltre la modica o rimozione di una prenotazione tramite i pulsanti Modify e Cancel posti di anco ad ogni prenotazione;

ˆ Log out: pagina che scollega l'utente dalla sessione. I le sorgenti (php, js, css) prodotti sono i seguenti:

about.php: pagina descrittiva dell'applicazione home.php: pagina principale della web-app

index.php: pagina di gestione dei cookie di sessione

insertreservation.php: pagina che eettua le prenotazioni login.php: pagina di gestione login

logout.php: pagina che scollega l'utente dalla sessione

managereservation.php: pagina di visualizzazione e gestione delle prenotazioni modifyreservation.php: si occupa di modicare le informazioni del database nb_function.php: classe di funzioni comuni a tutte le altre classi (pattern

Sin-gleton)

functions.js: script per la gestione dei cookie

validate.js: insieme di script per i controlli di sicurezza dei dati inseriti nel sistema myrbm.css: foglio di stile del sito

myrbm.sql: contiene il codice SQL per la creazione e l'inserimento delle tabelle nel database.

La gura 4.1 mostra la struttura graca dei le prodotti con l'IDE Eclipse.

Figura 4.2: Struttura delle classi da Eclipse

4.1.1 Funzioni rilevanti per la web-app

Quando si realizzano applicazioni Web è molto utile denire una volta per tut-te alcune carattut-teristiche comuni a tuttut-te le pagine del sito oppure porzioni di codice da utilizzare in punti diversi dell'applicazione stessa; I le sorgenti in-dex.php, nb_function.php, function.js, validate.js e myrbm.css sono stati creati per essere utilizzati nelle altre classi php. In seguito vengono forniti dettagli implementativi di suddette classi.

4.1.1.1 Index (PHP) e functions (Javascript)

Il le index.php è la pagina di default richiamata quando viene digitata la URL o una specica pagina del sito web; verica se nel browser che si sta utilizzando sono abilitati i cookies (altrimenti invita l'utente ad abilitare i cookies nel pro-prio browser per poter utilizzare l'applicazione) e fa un redirect alla Home page (home.php).

I cookies sono dei piccoli le di testo che sono generati e letti sul lato server sul quale è posto il sito web, e che vengono creati e memorizzati sul lato client ottimizzando in tal modo le risorse di memoria sul server.

Il codice Javascript è il seguente:

Figura 4.3: codice Javascript cookies

I metodi per creare il cookie (createCookie) e per richiamarlo (getCookie) sono in un le Javascript chiamato functions.js che viene utilizzato nelle pagine php server side:

Figura 4.4: funzioni Javascript per creare i cookies 4.1.1.2 Validate (Javascript)

Il le script validate.js contiene una serie di funzioni in Javascript per eettuare controlli sugli input dal lato client. Nelle pagine dove vengono immessi dati da elaborare, vengono eettuati controlli sulla correttezza delle informazioni inserite per ogni tipo di campo disponibile. Se dopo il controllo, i dati immessi risulano corretti viene visualizzato in HTML la dicitura ok accanto il campo compilato, ad esempio nel campo e-mail deve esserci un indirizzo e-mail valido per essere accettato:

Figura 4.5: esempio controllo campo input valido

Figura 4.6: esempio controllo campo input non valido

Nelle pagine di inserimento dati che vengono salvati nel database, solo se tutti i campi inseriti risultano valid si abilita il pulsante Submit, altrimenti rimane disabilitato al ne di salvaguardare la sicurezza dei dati trasmessi al server. In particolare, mediante funzioni oerte dalle api PHP (sanitize) vengono svolti due controlli: il primo si occupa dell'individuazione (e la successiva rimozione) dei caratteri speciali di MySQL (apice singolo, apice doppio, backslash, cancelletto, ecc.), mentre il secondo verica che non vi siano dei tag HTML all'interno delle stringhe immesse nei campi di input. In questo modo un utente che vuole inserire codice malevolo nei campi di input viene bloccato.

I tipi di campi presenti nella web app lato client sono:

ˆ String: l'inserimento di semplice testo (campi restaurant name, password) viene gestito dallo script validateString() che eettua un controllo sulla stringa inserita e visualizza ok oppure Invalid.

ˆ E-mail Sign: il controllo di un indirizzo e-mail per registrare l'utente (Si-gn up) avviene grazie alla funzione validateEmail_Si(Si-gn() che stabilisce se l'email inserita è ok oppure Invalid email in questo modo:

Figura 4.7: funzione JS per validare email

ˆ is_ok_Sign() è la funzione che abilita il tasto submit se i campi restaurant name, e-mail e password risultano corretti, altrimenti il tasto rimane disabilitato:

Figura 4.8: funzione JS che abilita il tasto submit

Le altre funzioni eettuano il controllo dei dati inseriti nel form insert reser-vation, tramite le seguenti funzioni:

ˆ validateName(): controlla la correttezza del campo surname (il cognome del cliente);

ˆ validateEmail(): simile alla funzione validateEmail_Sign() descritta pre-cedentemente;

ˆ validateTime(mess): controlla il formato dell'orario inserito per la prenota-zione che deve essere hh:mm per essere accettato;

ˆ validateNum(mess): viene usato nel campo num_of_people per controllare che venga inserito un numero;

ˆ validateDate(): verica se il formato della data inserita è corretto, cioè nel formato (inglese) mm/gg/aaaa (diverso dal formato italiano gg/mm/aaa):

Figura 4.9: funzione JS per la validazione della data

ˆ is_ok_Insert(): in ne viene eettuata la verica sui campi obbligatori per valutare se abilitare o meno il tasto submit:

Figura 4.10: funzione JS per validare i campi insert 4.1.1.3 Functions (PHP)

La classe nb_functions.php gestisce le connessioni ed è stata implementata uti-lizzando il design pattern Singleton. Nell'ingegneria del software il pattern Sin-gleton è utilizzato per limitare ad una sola le istanze di un oggetto. Questo è utile quando è necessario avere esattamente un'unica istanza di un oggetto per coordinare le azioni all'interno del proprio sistema, oppure quando si hanno degli aumenti di ecienza condividendo una sola istanza. L'utilizzo del pattern Sin-gleton permette l'eliminazione delle variabili globali che sono ormai ritenute una pratica obsoleta; eliminando l'utilizzo delle variabili globali avremo la possibilità di scrivere codice più ordinato, facilmente manutenibile e meno propenso agli errori. Il diagramma UML del design pattern Singleton è il seguente:

Figura 4.11: Design Pattern Singleton Le funzioni implementate in questa classe sono:

ˆ ceckSession(): gestisce i parametri di sessione per ogni client; più in par-ticolare, per ogni utente autenticato nel sistema vengono salvate nei cookie le credenziali per consentirgli la navigazione tra le pagine; se così non fos-se l'utente sarebbe costretto a eettuare il login per ogni pagina che visita. Inoltre viene impostato a 20 minuti il tempo massimo di inattività, dopo questo periodo di tempo il client viene disconnesso e deve rieseguire il login per poter continuare ad utilizzare il servizio. La funzione è la seguente:

Figura 4.12: funzione PHP di gestione della sessione

ˆ sanitizeString($var): questa funzione ripulisce la stringa passata come ar-gomento (lato server) da eventuali caratteri non validi attraverso l'uso di metodi PHP appositi:

ˆ setDB(): è la funzione che crea la connessione con il database MySQL per consentire l'accesso ai dati. tramite la chiamata PHP mysqli_connect che accetta i parametri db_host, db_user, db_password e db_name:

Figura 4.14: funzione PHP per connessione al database

ˆ destroySession(): utilizza la funzione PHP session_destroy() che elimina tutti i dati associati alla sessione corrente. Non desetta nessuna delle variabili globali associate alla sessione o desetta il cookie di sessione.

ˆ nav_bar(): la barra di navigazione è implementata in questa classe in modo da non doverla ricreare per ogni pagina del sito:

4.2 Navigazione del sito

In questa sezione viene illustrato il funzionamento del prodotto nito My Re-staurant Booking Manager, con gli screenshot delle pagine e parti di codice più signicative con brevi commenti.

4.2.1 Home Page

La home page per un utente che accede al sito la prima volta si presenta in questo modo:

Figura 4.16: screenshot Home page utente non autenticato

L'utente cliccando sul link proposto viene reindirizzato alla pagina di login. Se invece l'utente ha già eettuato l'accesso la home diventa:

Figura 4.17: screenshot Home page

Questa è la pagina di benvenuto all'utente con il link per visualizzare la lista delle prenotazioni. Il link per visualizzare le prenotazioni fa un redirect alla sezione Manage Reservation.

Il codice PHP che genera il contenuto da visualizzare nella pagina HTML è il seguente:

Figura 4.18: codice php home page

Nel codice HTML è presente lo script che legge i cookie di sessione utilizzando la funzione ceckSession() della classe nb_function.php descritta precedentemente.

Lo stesso script è implementato in tutte le altre pagine lato server:

Figura 4.19: script che crea i cookies di sessione

la prima riga di codice viene visualizzata eventualmente se nel browser in uso non è abilitato Javascript.

Nella parte HTML il menu di navigazione visualizzato a sinistra viene generato, come in tutte le altre pagine, dalla funzione nav_bar() disponibile nella classe nb_function.php:

Figura 4.20: codice HTML che visualizza il menu

4.2.2 About

La pagina About (Fig. 4.21) fornisce le caratteristiche della Web application, per consentire all'utente di conoscere le funzionalità del sito, e il contatto dell'autore mediante la pagina Google Plus.

Figura 4.21: Pagina About

4.2.3 Sign Up

La pagina Sign Up consente la registrazione di un utente al sistema, memorizzando i suoi dati nel database. I campi da inserire sono:

ˆ Restaurant name: il nome del ristorante che si vuole gestire

ˆ E-mail: indirizzo mail del gestore

ˆ Password: parola segreta per garantire la sicurezza dell'account.

Figura 4.22: screenshot pagina Sign Up

Una volta che l'utente ha inserito i dati vengono salvati nel database per consentire successivamente la procedura di login.

Il form che consente l'inserimento dei dati eettua una chiamata Post su se stesso (con una chiamata di tipo POST si può richiedere una risposta al servente inviandogli contemporaneamente dei dati, da inserire nel corpo della richiesta, come argomento del metodo send) in questo modo:

Figura 4.23: metodo Post per inserimento dati

il controllo sulla correttezza dei campi viene eseguito con il seguente codice PHP:

Figura 4.24: codice PHP controllo campi input

se i campi risultano corretti e non vuoti, vengono eettuati i controlli di tipo sanitize sui valori inseriti nei campi di input. Se i dati risultano corretti viene aperta la connessione con il database per aggiungere le informazioni dell'utente nella tabella account (query di inserimento dati), nel seguente modo:

Figura 4.25: query inserimento dati account nel database

se l'inserimento dati è andato a buon ne l'utente viene reindirizzato alla pagina manage reservation, altrimenti è invitato a ripetere la procedura di registrazione.

4.2.4 Log in

La pagina di Login è molto semplice, richiede all'utente indirizzo e-mail di regi-strazione e password scelta. Se l'e-mail o la password risultano corrette il client viene reindirizzato alla pagina contenente la lista delle prenotazioni del giorno at-tuale, se invece e-mail o password (o entrambe) risultano errate o non presenti nel database, l'utente viene avvisato e invitato a riprovare il login (se l'utente non è registrato può selezionare la pagina Sign Up).

Figura 4.26: screenshot pagina Login

L'inserimento dei dati avviene sempre con una chiamata di tipo POST alla pagina stessa:

Figura 4.27: metodo Post per inserimento dati di autenticazione

Una volta eettuato il controllo della correttezza dei dati inseriti (simile al codice della pagina Sign Up) viene fatta una query di selezione nella tabella

account per vericare i dati di autenticazione per un determinato utente; se la procedura di autenticazione è andata a buon ne il client viene reindirizzato alla pagina di gestione delle prenotazioni, altrimenti vine invitato a rieseguire il login:

Figura 4.28: query di selezione per autenticazione dell'utente

4.2.5 Insert Reservation

La pagina Insert Reservation svolge una delle funzioni principali, cioè consente l'inserimento della prenotazione di un tavolo. Per l'inserimento dei dati relativi al cliente che vuole prenotare il form è il seguente:

Figura 4.29: screenshot pagina Insert reservation

Il form HTML del metodo POST per l'inserimento dei dati è strutturato in questo modo:

Figura 4.30: form Html inserimento dati

Per ogni campo di inserimento viene eettuato il controllo con il relativo metodo dello script validate.js per stabilire la correttezza delle informazioni inserite al

ne di abilitare o meno il tasto submit (il tasto submit viene abilitato solo se tutti i campi obbligatori sono seguiti dalla dicitura ok in HTML che è il risultato dell'elaborazione dei metodi presenti nello script validate.js). Omette il codice relativo a suddetti controlli in questo documento perchè è molto simile alla procedura di registrazione dell'utente. La query di inserimento della prenotazione nella tabella reservations, se la procedura è andata a buon ne, è la seguente:

Figura 4.31: query inserimento dati prenotazione

I campi obbligatori per eettuare una prenotazione sono contrassegnati da un asterisco *, è possibile eettuare la prenotazione anche omettendo i dati non obbligatori come illustra il seguente esempio:

Figura 4.32: screenshot inserimento prenotazione

Per quanto riguarda il campo New Customer che indica se il cliente che ha pre-notato è un nuovo cliente dell'attività ristorativa (cliente è diverso da client/utente, invece si riferisce all'agente esterno al sistema che richiede la prenotazione di un tavolo), viene eettuata una query di selezione per stabilire se per il manager in questione esiste già una prenotazione associata all'indirizzo e-mail del cliente:

Figura 4.33: query di selezione nuovo cliente

se il cliente è nuovo viene visualizzato nella lista delle prenotazioni la voce Yes nel campo New Customer; se invece il cliente ha gia eettuato una prenotazione, signica che non è più nuovo cliente, quindi viene aggiornato il database rimuo-vendo la dicitura Yes impostata precedentemente per quel determinato cliente identicato dalla chiave email_customer.

L'inserimento della data viene eettuato tramite la funzione datapicker di jQuery per comodità e velocità di utilizzo:

Figura 4.34: screenshot datapicker

il codice seguente richiama le librerie jQuery per utilizzare la funzione data-picker() per l'inserimento della data:

Figura 4.35: script jQuery datapicker

4.2.6 Manage reservation

Manage reservation è la pagina di visualizzazione e gestione delle prenotazioni. Di default questa pagina mostra la lista di prenotazione del giorno attuale:

Figura 4.36: screenshot pagina Manage Reservation con prenotazioni Se per il giorno attuale non sono presenti prenotazioni la pagina è visualizzata in questo modo:

Figura 4.37: screenshot pagina Manage Reservation senza prenotazioni Il tasto Filter consente di visualizzare le prenotazioni relative ad una data scelta dall'utente tramite la funzione datapicker della libreria jQuery allo stesso modo della procedura di inserimento della prenotazione:

Figura 4.38: screenshot tasto Filter

Il form HTML che riceve la data in ingresso è una chiamata di tipo GET alla pagina stessa:

Figura 4.39: metodo Html Get per ltrare la data

Se viene premuto il tasto Filter senza selezionare alcuna data, viene mostrata la lista di prenotazione di tutte le date (All Date):

Figura 4.40: screenshot Manage Reservation con tutte le prenotazioni

Il codice PHP che visualizza la tabella delle prenotazioni in ordine di data e ora, dopo aver controllato la correttezza dell'input (data da ltrare) è il seguente:

Figura 4.41: codice PHP visualizzazione prenotazioni

i costrutti if-than-else controllano la data inserita che può essere null se non viene ltrata la data, quindi vengono visualizzate le prenotazioni del giorno attuale, all se viene premuto il tasto lter senza selezionare alcuna data, la web-app visualizza tutte le prenotazioni; oppure se viene selezionata una data specica, vengono mostrate le prenotazioni di quella data se presenti.

Manage Reservation consente, inoltre, di eettuare modiche sulle singole pre-notazioni tramite il tasto Modify di anco ad ogni prenotazione, oppure elimi-nare le singole prenotazioni mediante il tasto Cancel. Se viene premuto il tasto Cancel la prenotazione viene eliminata direttamente dal database nel seguente modo:

Figura 4.42: metodo PHP per la cancellazione di una prenotazione

se invece viene premuto il tasto Modify l'applicazione rimanda l'utente alla pagina Modify Reservation.

4.2.6.1 Modify Reservation

La pagina Modify Reservation è simile a Insert Reservation, i campi sono pre-compilati con le informazioni della prenotazione salvata nel database. E' possibile eettuare delle modiche alla prenotazione e dopo i soliti controlli all'input pre-mendo il tasto Update si aggiornano le informazioni presenti nel database. La visualizzazione HTML è la seguente:

Il form HTML che raccogli i dati di input, fornendo i campi precompilati dalla prenotazione eettuata in precedenza è:

Figura 4.44: metodo Post dati input per modica prenotazione

Il codice che aggiorna il database dopo aver eettuato i controlli sugli input è il seguente:

Figura 4.45: codice che aggiorna una prenotazione nel database

4.2.7 Log out

La funzione Logout consente all'utente di scollegarsi dal sito cliccando Log out nella barra di navigazione a sinistra:

Figura 4.46: screenshot pagina di log out

Il codice PHP che esegue il logout e mostra il relativo messaggio a video è il seguente:

Figura 4.47: codice PHP logout

4.3 Test

Il testing rappresenta una delle attività più importanti per assicurare la qualità del software. Dopo aver generato il codice sorgente, si deve collaudare il software per scoprire (e correggere) quanti più errori possibili prima di rilasciare il prodotto. Quando il software è stato realizzato, spesso è necessario apportare delle modiche, sia perché il software non risulta rispettare completamente le speciche ssate, sia perché si ritiene necessario perfezionare alcune funzionalità e caratteristiche. Si

possono fare piccole modiche oppure, se siamo molto lontani dai requisiti, si può scegliere di fare la reingegnerizzazione del sistema, in pratica ripartire da capo. Finita con successo la fase di manutenzione si può eseguire il rilascio del sistema. La parte di reingegnerizzazione del sistema che eettuando i test è avventua una volta non viene riportata in questo documento.

I test sono stati condotti simulando tanti possibili scenari d'uso propri e im-propri al ne di testarne la robustezza funzionale; sono stati condotti quindi dei test di utilizzo della webapp su più dispositivi, anche contemporaneamente, e sono stati simulati quasi tutti i possibili scenari di utilizzo.

Gli aspetti dell'applicazione su cui sono stati eettuati i test con esito positivo riguardano principalmente:

ˆ Database: sono stati eettuati tutti i test di inserimento, interrogazione e cancellazione sul database (query) per vericarne il corretto funzionamento; ˆ Compatibilità: utilizzo della web-app in browser dierenti e dispositivi dif-ferenti; per la simulazione di una grande varietà di dispositivi è stato utiliz-zato il servizio web responsivepx1 _{che consente di simulare il layout della}

web app sui diversi dispositivi (smartphone e tablet) che dieriscono per le dimensioni dello schermo; [TRD]

ˆ Sicurezza: inserimento di dati validi nei rispettivi campi di input, gestione in sicurezza dei dati memorizzati nel database;

ˆ Concorrenza: lo stesso account (username e password) può essere utilizzato da più utenti contemporaneamente; il database è utilizzato in concorren-za anche quando diversi account interagiscono con la web app allo stesso momento.

L'unico test fallito è rappresentato in gura 4.47 e riguarda l'inserimento delle informazioni nei campi di input;

se l'inserimento dell'informazione (compilazione campo input) avviene median-te digitazione dalla tastiera o copia e incolla, viene eettuato il normale controllo dell'input e in caso di esito positivo si abilita il pulsante di inserimento;

se invece l'inserimento dell'input avviene mediante selezione di un informazione inserita precedentemente dal browser (che il browser ricorda) non viene eseguito il controllo sui campi di input2_{, quindi è uguale ad un campo vuoto (il tasto di}

inserimento rimane disabilitato) ed è necessario digitare almeno un carattere nel campo di input per l'esecuzione della procedura di controllo. Dalla gura 4.47 si nota che non viene eseguito il controllo di input, infatti di anco ai campi non è visualizzato (in HTML) il risultato del controllo (ok oppure invalid).

Figura 4.48: Inserimento dati di prenotazione mediante selezione dell'input dal browser

2_{Il controllo dei campi di input è la funzione che se risulta positiva visualizza nel browser ok} di anco al campo di inserimento, altrimenti visualizza invalid e non viene abilitato il tasto di inserimento.

Capitolo 5

Conclusioni

In conclusione, questa tesi presenta una soluzione eciente per la gestione del-le prenotazioni di un'attività ristorativa (es. pizzeria, ristorante, trattoria, bar ecc.). I risultati ottenuti rispettano i vincoli di progetto discussi in fase di analisi. L'applicazione web creata (My Restaurant Booking Manager) permette la gestione delle prenotazione a tutti i ristoratori (manager) che intendono usarla; infatti han-no un accesso completo ai loro dati (di prehan-notazione) contemporaneamente; infatti il sistema gestisce oltre che la concorrenza di più account che usano la Web app allo stesso momento, anche la concorrenza di più utilizzatori dello stesso account, molto utile per la condivisione del lavoro tra più collaboratori.

Il sito MyRBM è attualmente oine in attesa di perfezionamenti della graca e la creazione del logo.

5.1 Stima del costo

Si è cercato a questo punto di fare una stima del costo per produrre la web appli-cation MyRBM mediante il modello COCOMO, che è il metodo più diuso di stima dei costi del software.

Il COCOMO [Coc11] è un modello matematico usato da chi progetta software per stimare alcuni parametri fondamentali come il tempo di consegna e i mesi-persona necessari per lo sviluppo. Con questo metodo si cerca di fare una stima dello sforzo impiegato per la realizzazione di un progetto software.