Iterazione 1
⏳ Non sono previsti vincoli di tempo per lo sviluppo del progetto.
💰 Non è inizialmente previsto un budget in termini di denaro, per questo motivo si dovrà optare per soluzioni free rispetto ad altre a pagamento.
[edit: sono stati stanziati i fondi per l'acquisto di un dominio!]
- Il sistema deve permettere al cliente di visualizzare l'intero menù.
- Il sistema deve permettere al cliente di visualizzare le specifiche di consegna, gli orari e i contatti del ristorante.
- Il sistema deve permettere al cliente di visualizzare le news.
- Il sistema di persistenza deve essere accessibile dalla maggior parte delle tecnologie in commercio, in particolare da applicazioni web e applicazioni mobile. Non deve essere necessario implementare più di 1 sistema di archiviazione dei dati.
- Il sistema deve permettere al manager di pubblicare le news.
- Il sistema deve poter inviare al cliente comunicazioni ed avvisi relativi alle news, attraverso e-mail, sms o altri tipi di notifiche.
- Il sistema deve permettere al cliente di richiedere la prenotazione di un tavolo.
- Il sistema deve permettere al manager di confermare la prenotazione.
-
[formato breve]
Il dispositivo del cliente richiede il menù.
Il sistema recupera le informazioni di ciascun alimento.
Un alimento può essere: una pizza, una generica pietanza o una bevanda.
Per una pizza occorre specificare: nome, prezzi dei vari formati, ingredienti. Di ogni ingrediente occorre sapere se è stato surgelato. Occorre anche conoscere la classe di appartenenza della pizza e delle pietanze, la quale, a sua volta, possiede una descrizione e un grado di importanza, che la rende più visibile delle altre classi.
E' specificato il fatto che ogni ingrediente ha un prezzo per essere aggiunto su una pizza alla quale non apparterrebbe.
Per la generica pietanza: nome, descrizione e prezzo.
Per le bevande: nome, formato(lattina, bottiglia, vetro o brick), quantità e prezzo. -
[formato breve]
Il dispositivo del cliente richiede le informazioni del locale.
Il sistema recupera le informazioni e restituisce: orario, costi di consegna, numero di telefono e indirizzo. -
[formato breve]
Il dispositivo del cliente richiede le news.
Il sistema recupera le informazioni e le restituisce: presumibilmente immagini e/o testo.
-
[scenario alternativo dei 3 casi precedenti]
Il dispositivo del cliente richiede le informazioni.
Il sistema non riesce a recuperare le informazioni. Esso deve allora restituire un messaggio di errore al cliente, specificando, se possibile, i motivi del disguido.
Durante la stesura dei casi d'uso sono stati evidenziati gli elementi di spicco, candidati a diventare oggetti del dominio.
Il cliente è uno stakeholder, non possiede informazioni che meritano di persistere nel sistema, non sarà un oggetto del dominio.
Il messaggio di errore è lo scenario alternativo dei 3 casi d'uso, la sua implementazione verrà gestita in fase di sviluppo, insieme alle altre eventuali eccezioni che si verificheranno.
Le informazioni che riguardano il locale è presumibile che non cambino nel corso della vita di questo progetto: è quindi presa la scelta di non utilizzare, per esse, un dispositivo di persistenza diverso dal codice nel quale saranno definite.
E' ragionevole pensare di memorizzare le rimanenti informazioni in una base di dati. Di seguito una possibile implementazione del diagramma Entità-Relazione.
La scelta risulta immediata, si sceglie un architettura client server, in particolare verrà realizzata un applicazione web.
Si utilizzerà apache tomcat come server web contenitore delle servlet java.
Ciò che occorre implementare:
- Il Database.
- Application server, come applicazione in java con una sua architettura.
- Le pagine web, che verranno trasmesse al cliente dal server.
Il server verrà eseguito in una VM sulla GoogleCloudPlatform. Come da vincoli si è fatto il possibile per utilizzare il servizio gratuito offerto da Google.
Sulla macchina è stato installato Ubuntu 20.04. Il suo indirizzo IPv4 (statico) è 35.247.103.238.
E' possibile connettersi alla VM solo tramite ssh, l'autenticazione è verificata tramite una coppia di chiavi ssh generata in fase di creazione della macchina.
A partire dallo schema e/r verrà implementato il db.
In accordo con i vincoli di costo, il database sarà ospitato sulla stessa vm del server. Verrà creata un istanza di mysql server. Il server accederà a quest'ultima in locale.
Le pagine web saranno create utilizzando i classici: HTML, CSS e Javascript. Verrà fatto uso di librerie, come bootstrap.
Le pagine risiederanno nello stesso package dell'application server, in quanto esso si occuperà della loro presentazione.
Si sceglie di utilizzare un architettura MVC.
La view sarà rappresentata dalle servlet.
Nella parte di dominio, oltre ai pojo degli oggetti del dominio(creati senza utilizzo di framework ORM), sarà presente un package chiamato services, contenente dei dao che intermedieranno con il database.
Infine un controller per mettere in comunicazione la view con il dominio sottostante.
Di seguito una rappresentazione UML di come sarà strutturato il programma. (sono stati aggiunti i colori per migliorare la leggibilità)
attenzione: indirizzo ip non aggiornato
Tutti i test sono stati effettuati con una classe temporanea contenente un main, essa è stata rimossa al momento del rilascio. E' inoltre stata utilizzata un' istanza locale di tomcat.
L'applicazione è stata rilasciata al pubblico ed è raggiungibile al sito pizzeriastrapizzami.com .
note:
occorre procurarsi una certificazione ssl in modo da garantire la navigazione tramite https, consigliato let's encrypt;
la porta 3306 di mysql-server è chiusa all'esterno, per il momento è possibile accedere al db solamente in modo manuale(ssh su gcp) o tramite hermes;
il deploy avviene nella cartella radice, tramite tomcat alla pagina /manager mediante file war. per ragioni di sicurezza esso non è pubblicato insieme al resto del codice;