Smart Chalet è progetto realizzato in Flutter e SpringBoot per il corso di laurea di Informatica L-31 presso l'Università di Camerino, nell’anno accademico 2021/2022, dagli studenti Vlad Dogariu e Denise Pagan per gli esami di Ingegneria del Software e Progettazione di Applicazioni Web e Mobili, seguendo i canoni di sviluppo proposti.
- Panoramica e funzionalità di base
- Tecnologie utilizzate durante lo sviluppo
- Gli utenti
- Iterazioni
- Autori
Reading Time: 5 min
Lo scopo dell’applicativo proposto è quello di realizzare un'applicazione che permetta la completa gestione di una spiaggia con il suo relativo servizio bar.
I ruoli ricoperti dagli utenti nell’applicativo sono : Cliente , Gestore , Personale Accoglienza , Animatore e Bar Staff .
Ogni utente, in base al ruolo con cui si è registrato, visualizzerà una schermata personalizzata e potrà compiere azioni diverse.
Il Cliente, una volta autenticato potrà prenotare un ombrellone o eventualmente modificare una prenotazione già effettuata. Una volta avuta la conferma della prenotazione, potrà usufruire del servizio bar incluso nell'applicazione grazie al quale selezionerà i prodotti desiderati tra quelli disponibili.
Ogni prenotazione ha una data, un numero di obrelloni ed infine di due identificativi: uno per il cliente e uno che identifica la prenotazione stessa.
La non autenticazione da parte dell'utente garantirà comunque dei servizi quali: la visualizzazione dello stato della spiaggia e la lista dei prodotti disponibili per il servizio bar.
Il Gestore tramite l'applicazione potrà prendere decisioni sulla gestione della spiaggia e del bar. In particolar modo potrà modificare il numero posti, modificare il tariffario, gestire quelle che sono le attività offerte dagli animatori e i prodotti disponibili per il servizio bar, nonchè effettuare o modificare una prenotazione al posto del cliente.
Così come il gestore, il Personale d'Accoglienza ha la possibilità di aggiungere una prenotazione o modificarla.
L'Animatore, invece, potrà aggiungere un'attività, impostando il nome dell'attività stessa, l'orario e il numero massimo dei partecipati. Tali attività potranno essere prenotate dal cliente sempre dopo l'avvenuta autenticazione e prenotazione dell'ombrellone.
Infine, lo Staff del Bar , tramite l'applicazione, riceverà gli ordini dai clienti.
Ogni ordine è associato ad un ombrellone tramite un Qr, che verrà chiesto al cliente di scansionare tramite il proprio telefono al momento dell'invio dell'ordine.
Al cliente, inoltre, viene data l'opportunità di recensire la spiaggia ed i suoi servizi.
Il lato Frontend è stato sviluppato mediante il framework Open Source Flutter e il suo relativo linguaggio Dart, un liguaggio, che permette di sviluppare un'applicazione Cross-Platform, al fine di avere un software Single-CodeBase che sia fruibile su iOS, Android e Web.
È stato scelto come State Management Cubit, un sottoinsieme della famosa implementazione del BLoC Pattern, grazie alla qualle è stato possibile suddividere le le varie aree in classi guidate da stati, permettendo una facile navigazione tra di esse e una struttura facilmente comprensibile.
Il Pattern Cubit è costituito da molte funzionalità dei pattern BLoC e Provider, pertanto è una combinazione dei due pacchetti in cui ci si libera dagli eventi e si fa affidamento sui metodi, mantenendo
una incredibile facilità di gestione.
Il lato Backend del sistema è stato sviluppato in Java con il supporto del framework Spring-Boot a cui è stato affrontato il compito di gestire le Rest API.
Per la persistenza dei dati ci si è affidati al database non relazionale MongoDB
Infine per il lato sicurezza abbimo implementato lo standard dei JWT (JSON Web Token).
Nella cartella Documentazione si possono osservare i modelli sviluppati e come si è proceduto durante le varie iterazioni del processo.
Come detto in precedenza ogni utente avrà un ruolo con il quale potra effettuare le proprie operazioni.
Qui sotto vengono riportate come esempio alcune schermate che si differenziano sulla base dell'avenuta/mancata autenticazione.
Il progetto è stato implementato con 5 interazioni, della durata massima di 3 settimane, rispettando gli standard dell'Unified Process
e l'utilizzo di Design Pattern.
Nella prima iterazione, la fare di avvio, si è discusso dei possibili attori che potessero partecipare e quindi usufruire dell'applicazione,
attraverso la partecipazione a differenti workshop e brainstorming individuali e di gruppo.
Una volta identificati tutti gli attori, nelle successive iterzaioni si è proceduto ad identificare i casi d'uso ad essi corellati, fino ad arrivare alla IV iterazione con il 90% dei casi d'uso sviluppati.
La III e IV iterazione si sono focalizzate sull'implementazione del codice e progettazione di tutto il sistema. In paricolar modo nella IV iterazione sono stati prefezionate alcune funzionalità ritenute più importanti,
come l'autenticazione e il fattore sicurezza, essendo così guidati dal rischio.
Alla fine della progettazione è stata aggiunta un'iterazione extra dedicata alla fase di testing. Per la fase di testing, oltre a svariati Unit Test, è stato utilizzato il software Postaman, una piattaforma API per gli sviluppatori per progettare, creare, testare e iterare le API.
Grazie ad esso è stato possibile replicare le chiamate e verificarne la correttezza
Alla fase di testing è seguita poi l'implementazione del frontend.