Università degli Studi di Padova
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Sviluppo di un’interfaccia web con il
framework Angular
Tesi di laurea triennale
Relatore
Prof.Lamberto Ballan
Laureando
Manfredi Smaniotto
Anno Accademico 2017-2018Manfredi Smaniotto: Sviluppo di un’interfaccia web con il framework Angular, Tesi di laurea triennale, c Settembre 2018.
I computer sono incredibilmente veloci, accurati e stupidi. Gli uomini sono
incredibilmente lenti, inaccurati e intelligenti. L’insieme dei due costituisce una forza
incalcolabile.
— Albert Einstein
Dedicato a tutte le persone che desideravano partecipare a questo evento ma non sono
riuscite ad esserci.Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata
di circa trecento ore, dal laureando Manfredi Smaniotto presso l’azienda Sync Lab srl.
Gli obiettivi da raggiungere erano molteplici.
In primo luogo era richiesto l’apprendimento delle più utilizzate tecnologie nell’ambito
dello sviluppo web quali il framework Angular per la realizzazione di interfacce web
dinamiche, il framework Bootstrap per l’utilizzo di libreria grafiche testate, affidabili
e responsive e in generale tutte quelle tecnologie comunemente usate per testare il
funzionamento e l’accessibilità dell’interfaccia da sviluppare.
In secondo luogo era richiesto lo sviluppo di una web application allo scopo di gestire
le prenotazioni di un servizio mensa presente in un collegio universitario di Padova,
concentrandosi sulla parte di raccolta e presentazione dei dati e delegando la loro
gestione ad un servizio back-end basato sul framework Spring.
Terzo ed ultimo obiettivo era l’integrazione di front-end e back-end in vista di un futuro
utilizzo dell’applicazione.
v“Life is really simple, but we insist on making it complicated”
— Confucius
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Lamberto Ballan, relatore
della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori per il sostegno, il grande aiuto e per
essermi stati vicini in ogni momento durante gli anni di studio.
Una dedica speciale ai miei amici, che ogni giorno hanno condiviso con me gioie,
sacrifici e successi. L’affetto e il sostegno che mi hanno dimostrato rendono questo
traguardo ancora più prezioso.
Padova, Settembre 2018 Manfredi Smaniotto
viiIndice
1 L’azienda 1
1.1 Profilo aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Settori di impiego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Organizzazione del progetto 3
2.1 Il contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Gli obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 I requisiti in sintesi . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Analisi dei requisiti 7
3.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Progettazione e codifica 23
4.1 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Il framework Angular . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Typescript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.4 Npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.5 JSON Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.6 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.7 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Progettazione e sviluppo 27
5.1 I design pattern utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.2 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.3 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Architetture software e paradigmi utilizzati . . . . . . . . . . . . . . . 28
5.2.1 Reactive programming . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Conclusioni 31
6.1 Considerazioni riguardo agli obiettivi raggiunti . . . . . . . . . . . . . 31
6.2 L’accessibilità del sito . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3 Considerazioni riguardo il framework Angular . . . . . . . . . . . . . . 33
6.3.1 L’esperienza in sintesi . . . . . . . . . . . . . . . . . . . . . . . 33
ixx INDICE
6.3.2 I vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3.3 Gli svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4 Risvolti futuri dell’applicazione . . . . . . . . . . . . . . . . . . . . . . 34
Glossario 35
Bibliografia e sitografia 37Elenco delle figure
1.1 Logo Synclab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Diagramma di Gantt per la pianificazione dello stage . . . . . . . . . . 5
3.1 Scenario principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 UC1: Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 UC2: Visualizzazione errore . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 UC5: Inserimento prenotazione . . . . . . . . . . . . . . . . . . . . . . 11
3.5 UC6: Visualizzazione prenotazioni . . . . . . . . . . . . . . . . . . . . 12
3.6 UC7: Inserimento prenotazione . . . . . . . . . . . . . . . . . . . . . . 13
3.7 UC8: Selezione menu del giorno . . . . . . . . . . . . . . . . . . . . . . 14
3.8 UC9: Visualizzazione pietanze . . . . . . . . . . . . . . . . . . . . . . . 15
3.9 UC10: Inserimento nuova pietanza . . . . . . . . . . . . . . . . . . . . 16
6.1 Pagina di login del sito . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Calendario per la selezione della giornata all’interno del sito . . . . . . 32
6.3 Pagina di inserimento e rimozione delle pietanze presenti dentro alla
piattaforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Elenco delle tabelle
3.1 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . . 19
3.2 Tabella del tracciamento dei requisiti qualitativi . . . . . . . . . . . . 21
3.3 Tabella del tracciamento dei requisiti prestazionali . . . . . . . . . . . 21
3.4 Tabella del tracciamento dei requisiti di vincolo . . . . . . . . . . . . . 21
xixii ELENCO DELLE TABELLE
Capitolo 1
L’azienda
1.1 Profilo aziendale
Figura 1.1: Logo Synclab
Sync Lab S.r.l. è una società di consulenza informatica fondata nel 2002 con sedi a
Napoli, Roma, Milano e Padova.
Fin dai primi anni Sync Lab è rapidamente cresciuta nel mercato ICT, consolidando i
rapporti con clienti e partner, ha raggiunto un organico aziendale di oltre 200 risorse,
una solida base finanziaria e una diffusione sul territorio attraverso le sue quattro sedi.
L’organico aziendale è andato crescendo in modo continuo e rapido, in relazione
all’apertura delle varie sedi ed alla progressiva crescita delle stesse.
La grande attenzione alla gestione delle risorse umane ha fatto di Sync Lab un
riferimento in positivo per quanti volessero avviare o far evolvere in chiave professionale
la propria carriera.
Il basso turn-over testimonia la voglia dei collaboratori di condividere il progetto
comune, assumendo all’interno di esso ruoli e responsabilità che solo un processo
evolutivo così intenso può offrire.
I ricavi hanno avuto un incremento proporzionale alla crescita dell’azienda beneficiando
dell’approccio adattivo e diversificato al mercato.
1.2 Servizi offerti
Sync Lab Srl è un’azienda leader nella consulenza tecnologica, impegnata in un processo
continuo di identificazione e messa in opera di soluzioni per i clienti finalizzate alla
creazione di valore. Essa supporta le esigenze di innovazione di tutte le organizzazioni
ed in ogni settore di mercato nell’ambito Information Technology, con servizi in ambito:
∗ Business Consultancy
12 CAPITOLO 1. L’AZIENDA
∗ Project Financing
∗ IT Consultancy
L’azienda ha come punti di forza la qualità dei servizi offerti (certificazioni ISO
9001, ISO 14001, ISO 27001, OHSAS 18001) ed un’accurata gestione delle risorse
umane.L’approfondita conoscenza di processi e tecnologie, maturata in esperienze
altamente significative e qualificanti, fornisce ad essa l’expertise e Know How necessari
per gestire progetti di elevata complessità, dominando l’intero ciclo di vita: Studio di
fattibilità, Progettazione, Implementazione, Governance e Post Delivery.
L’offerta di consulenza specialistica trova le punte di eccellenza nella progettazione
di architetture Software avanzate, siano esse per applicativi di dominio, per sistemi
di supporto al business (BSS), per sistemi di integrazione (EAI/SOA), per sistemi di
monitoraggio applicativo/territoriale.
Il laboratorio RD di Sync Lab è sempre al passo con i nuovi paradigmi tecnologici
e di comunicazione, ad esempio Big Data, Cloud Computing, Internet delle Cose,
Mobile e Sicurezza IT, per supportare i propri clienti nella creazione ed integrazione di
applicazioni, processi e dispositivi.
Le attività in ambito Educational ed RD permettono all’azienda di acquisire una
profonda conoscenza degli strumenti di finanza agevolata fruendone direttamente ed
interagendo con enti di supporto ai progetti innovativi dei propri clienti. L’azienda,
grazie alla rete di relazioni a livello nazionale ed internazionale, ha ottenuto importanti
finanziamenti in progetti RD europei (FP7 e H2020) della Comunità Europea.
1.3 Settori di impiego
Sync Lab si sta sempre più specializzando in vari settori d’impiego: dal settore bancario
a quello assicurativo con una nicchia importante nell’ambito sanità, in cui vanta un
prodotto d’eccellenza per la gestione delle cliniche private. L’azienda inoltre ha
recentemente fondato una collegata Sync Security che si occupa espressamente del
mondo della cyber security e sicurezza informatica in genere.Capitolo 2
Organizzazione del progetto
2.1 Il contesto
La problematica presa in esame per lo sviluppo dell’applicazione è la gestione delle
prenotazioni di un servizio mensa di un collegio universitario di Padova.
In particolare si è voluto affrontare il problema di digitalizzare il sistema delle or-
dinazioni effettuate dagli studenti al fine di raccogliere i dati da visualizzare nella
preparazione delle pietanze e per la gestione della contabilità del servizio.
Il target di utilizzo dell’applicazione è stato individuato in un gruppo di persone tra
i 18 e i 25 anni presumibilmente abituato a frequentare quotidianamente interfacce
web, in particolar modo da dispositivi mobile e tablet, motivo per cui lo sviluppo
dell’interfaccia utente dell’applicazione ha privilegiato una strategia mobile first per
quanto riguarda la componente di design; l’interfaccia utente lato amministratore
è stata invece sviluppata per un utilizzo principalmente desktop, assicurandosi che
comunque non venisse compromessa la navigazione su tutti gli altri dispositivi.
2.2 Gli obiettivi del progetto
Sin dal primo momento si è desiderato di poter vedere il prodotto finale utilizzato da
un gruppo di persone alle quali poter chiedere pregi e difetti di una versione quasi
definitiva della piattaforma in vista di una sua futura commercializzazione.
Si è quindi pensato di mettere al lavoro un gruppo di tre persone a cui affidare lo
sviluppo di interfacce grafiche e servizi back-end in modo, per quanto possibile, separa-
to, pianificando di collegare entrambe le parti nel corso delle ultime due settimane di
stage.
Ciò che ha reso accattivante e molto appetibile questo progetto è stato l’utilizzo di
tecnologie moderne, già molto diffuse nel settore informatico e con uno sviluppo garan-
tito da una grande community e dal supporto di aziende molto conosciute nel settore.
Non a caso sia la parte front-end dell’applicazione che la parte back-end si sono poste
l’obiettivo di mettere in contatto i framework Angular e React con dei microservizi
realizzati con Spring framework per poter vedere come questi ambienti si interfaccino
tra loro e tutte le varie problematiche presenti nel loro utilizzo pratico.
Per poter sviluppare l’applicazione si è quindi svolto uno studio preventivo riguardante
sia le tecnologie vere e proprie, sia i pattern architetturali sulle quali esse poggiano le
34 CAPITOLO 2. ORGANIZZAZIONE DEL PROGETTO
proprie basi; è stato dedicato del tempo nella ricerca di strumenti volti al solo sviluppo
dell’applicazione in modo da poter rendere indipendente la realizzazione di entrambe
le parti dell’applicazione.
Infine si è voluto creare delle interfacce di comunicazione tra parte front-end e back-end
secondo l’architettura software Rest, realizzando opportuni endpoint per il passaggio
dei dati da e verso l’interfaccia front-end.
2.2.1 I requisiti in sintesi
Il progetto si è posto come obiettivo l’adempimento dei seguenti requisiti:
∗ Requisiti obbligatori:
– Utilizzo del framework Angular(v6.0.0);
– Realizzazione di una pagina di login;
– Creazione di una interfaccia utente da cui prenotare e personalizzare le
proprie prenotazioni in una data giornata precisata;
– Creazione di una interfaccia amministratore da cui organizzare i pasti per
una data giornata del mese, inserire le pietanze disponibili, mostrare i dati
delle prenotazioni degli utenti, inserire ed eliminare una prenotazione;
– Interfacciamento tramite chiamate Rest con il servizio back-end;
– Esportazione dei dati di prenotazione in formato xlsx o compatibile tramite
download.
∗ Requisiti desiderabili:
– Test di funzionamento dell’applicazione in condizioni di normale utilizzo;
– Utilizzo dei dati per il login di un database esterno ispirato ad Active
Directory (Microsoft Windows)
∗ Requisiti facoltativi:
– Implementazione di un sistema di notifica per il cambio di menù del giorno
a tutte le persone che hanno già effettuato la prenotazione
– Implementazione di un sistema di notifica agli utenti che non hanno ancora
effettuato una prenotazione entro un certo orario2.3. PIANIFICAZIONE 5
2.3 Pianificazione
In accordo con l’azienda è stato organizzato un piano di lavoro a cadenza settimanale
comprensivo di una settimana di studio del framework da utilizzare, sei settimane di
sviluppo dell’applicazione e una settimana dedicata all’integrazione dell’interfaccia
front-end con i servizi back-end.
Preventivamente è stato assegnato del tempo extra affinchè le attività non fossero
eccessivamente strette coi tempi e consentissero uno sviluppo per quanto possibile non
condizionato da eventuali imprevisti.
Figura 2.1: Diagramma di Gantt per la pianificazione dello stageCapitolo 3
Analisi dei requisiti
Figura 3.1: Scenario principale
78 CAPITOLO 3. ANALISI DEI REQUISITI
3.1 Casi d’uso
Per lo studio dei casi di utilizzo del prodotto sono stati creati dei diagrammi. I
diagrammi dei casi d’uso (in inglese Use Case Diagram) sono diagrammi di tipo
UML dedicati alla descrizione delle funzioni o servizi offerti da un sistema, così come
sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. Poichè le
interazioni con l’utente sono al centro dell’attenzione in questo progetto, sono stati
formulati vari casi d’uso con i quali è stato possibile modellare in modo completo i
vari scenari di utilizzo dell’applicazione
Figura 3.2: UC1: Autenticazione
UC1: Autenticazione
Attori Principali: Utente non autenticato.
Precondizioni: L’utente è arrivato alla schermata di login del programma.
Descrizione: Vengono visualizzati i campi username e password da compilare e un
tasto per avviare la procedura di login.
Scenario principale:
1. L’utente inserisce le proprie credenziali nei campi username e password cliccando
poi sul pulsante "Login"
2. L’utente accede alla piattaforma3.1. CASI D’USO 9
Postcondizioni: L’utente visualizza la prima schermata dell’applicazione oppure un
errore di inserimento delle credenziali.
Figura 3.3: UC2: Visualizzazione errore
UC2: Visualizzazione errore
Attori Principali: Utente autenticato/non autenticato.
Precondizioni: L’utente sta compiendo un’azione qualsiasi con il sito ma vi sono
difficoltà nella comunicazione con il back-end.
Descrizione: L’utente commette un errore nell’inserimento dei dati oppure i servizi
momentaneamente non rispondono.
Scenario principale:
1. L’utente visita una pagina
2. Tramite la web application viene fatta una qualsiasi azione di lettura o scrittura
di dati verso i servizi back-end
3. Viene visualizzato un errore corrispondente al problema riscontrato
Postcondizioni: L’utente visualizza una barra in alto con la descrizione dell’errore.10 CAPITOLO 3. ANALISI DEI REQUISITI
UC3: Logout
Attori Principali: Utente Autenticato.
Precondizioni: L’utente ha acceduto alla piattaforma e si trova in una qualsiasi
schermata dell’applicazione.
Descrizione: L’utente vuole effettuare il logout dall’applicazione.
Scenario principale:
1. L’utente clicca sul pulsante "Logout"
2. L’utente viene reindirizzato alla schermata di login
Postcondizioni: L’utente visualizza la schermata di login.
UC4: Visualizzazione menu personale
Attori Principali: Utente base.
Precondizioni: L’utente è nella schermata di selezione del proprio menu del giorno.
Descrizione: L’utente vuole visualizzare il menu da lui selezionato.
Scenario principale:
1. L’utente seleziona la giornata di inserimento
2. Viene visualizzato a schermo il menu precedentemente selezionato
Postcondizioni: L’utente visualizza il menu precedentemente selezionato.3.1. CASI D’USO 11
Figura 3.4: UC5: Inserimento prenotazione
UC5: Selezione menu personale
Attori Principali: Utente base.
Precondizioni: L’utente è nella schermata di selezione del proprio menu del giorno.
Descrizione: L’utente vuole inserire la propria prenotazione all’interno del sistema.
Scenario principale:
1. L’utente seleziona la giornata di inserimento
2. L’utente seleziona se prenotare il pranzo o la cena
3. L’utente seleziona tra i piatti proposti il primo, il secondo, il contorno e il dolce
desiderati
4. L’utente conferma le proprie preferenze cliccando sul tasto "Prenota"12 CAPITOLO 3. ANALISI DEI REQUISITI
Postcondizioni: L’utente visualizza una conferma della prenotazione oppure un
messaggio di errore di inserimento.
Figura 3.5: UC6: Visualizzazione prenotazioni
UC6: Visualizzazione prenotazioni
Attori Principali: Utente amministratore autenticato.
Precondizioni: L’amministratore ha cliccato sul link per vedere le prenotazioni di
un dato giorno del calendario .
Descrizione: L’utente amministratore desidera vedere le prenotazioni dei pasti per
una certa giornata.
Scenario principale:
1. L’amministratore accede alla pagina delle prenotazioni;
2. L’amministratore sceglie se visualizzare le prenotazioni per persona o per pasto;
3. Nel caso della visualizzazione per pasto l’amministratore clicca sulla singola
pietanza per vedere le persone che hanno prenotato il pasto e in che orario.
Postcondizioni: L’amministratore visualizza la prenotazione eseguita.
Estensioni:
1. L’utente visualizza un errore di caricamento dei dati.3.1. CASI D’USO 13
Figura 3.6: UC7: Inserimento prenotazione
UC7: Inserimento prenotazione
Attori Principali: Utente amministratore.
Precondizioni: L’amministratore è nella schermata di presentazione delle prenotazio-
ni.
Descrizione: L’amministratore desidera inserire una prenotazione per conto di un
utente.14 CAPITOLO 3. ANALISI DEI REQUISITI
Scenario principale:
1. L’amministratore seleziona la giornata di inserimento
2. L’amministratore seleziona l’utente per cui effettuare la prenotazione
3. L’amministratore seleziona se prenotare il pranzo o la cena
4. L’amministratore seleziona tra i piatti proposti il primo, il secondo, il contorno e
il dolce desiderati
5. L’amministratore conferma le proprie preferenze cliccando sul tasto "Prenota"
Postcondizioni: Il sistema riceve la prenotazione oppure visualizza un errore nell’invio
dei dati.
Figura 3.7: UC8: Selezione menu del giorno
UC8: Selezione menu del giorno
Attori Principali: Utente amministratore.
Precondizioni: L’utente sta visualizzando la lista di piatti nel menù del giorno.
Descrizione: L’utente amministratore vuole scegliere o modificare il menù da rende-
re disponibile una giornata, specificando le pietanze proposte per il pranzo e per la cena.3.1. CASI D’USO 15
Scenario principale:
1. L’utente sceglie un pasto per portata che desidera rendere disponibile selezionan-
dolo o deselezionandolo con un click;
2. Preme il pulsante Conferma;
3. L’utente visualizza il messaggio di conferma dell’avvenuto salvataggio.
Postcondizioni: Il sistema ha salvato il menù per quel giorno.
Estensioni:
1. L’utente visualizza un errore.
Figura 3.8: UC9: Visualizzazione pietanze
UC9: Visualizzazione pietanze
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha cliccato sul link del menu Inserimento piatti.
Descrizione: L’utente vuole visualizzare la lista di tutti i piatti che sono salvati nel
sistema.16 CAPITOLO 3. ANALISI DEI REQUISITI
Scenario principale:
1. L’utente attende il caricamento dei piatti;
2. L’utente visualizza la lista di piatti.
Postcondizioni: Il sistema visualizza la lista di piatti.
Estensioni:
1. L’utente filtra i piatti per tipo;
2. Visualizzazione di un messaggio d’errore di caricamento dei piatti.
Figura 3.9: UC10: Inserimento nuova pietanza
UC10: Inserimento nuova pietanza
Attori Principali: Utente amministratore autenticato.
Precondizioni: L’utente sta visualizzando la lista di piatti nella pagina Gestione
piatti.
Descrizione: L’utente vuole aggiungere un nuovo piatto alla lista.3.1. CASI D’USO 17
Scenario principale:
1. L’utente preme il pulsante di aggiunta posto nella barra sopra la lista;
2. Viene visualizzato un pannello modale con il form di inserimento;
3. L’utente compila il form inserendo nome, tipologia e descrizione del piatto;
4. L’utente preme il pulsante Aggiungi;
5. Il piatto viene aggiunto alla lista presente nella pagina.
Postcondizioni: Il sistema ha correttamente aggiunto il nuovo piatto.
Estensioni:
1. Visualizzazione di un messaggio d’errore se l’aggiunta non è andata a buon fine.
UC11: Rimozione pietanza
Attori Principali: Utente amministratore autenticato.
Precondizioni: L’utente sta visualizzando la lista di piatti nella pagina Gestione
piatti.
Descrizione: L’utente vuole rimuovere un piatto dalla lista.
Scenario principale:
1. L’utente preme il pulsante di eliminazione posizionato sotto il nome del piatto
da eliminare;
2. Viene visualizzata una richiesta di conferma;
3. L’utente da il proprio assenso;
4. L’utente attende l’elaborazione della sua richiesta;
5. La lista viene aggiornata.
Postcondizioni: È stato correttamente eliminato un piatto.
Estensioni:
1. Visualizzazione di un messaggio d’errore nel caso non sia possibile completare la
cancellazione;18 CAPITOLO 3. ANALISI DEI REQUISITI
3.2 Tracciamento dei requisiti
In seguito ad un’attenta analisi dei requisiti e degli use case effettuata sul progetto
con il supporto del tutor aziendale è stata stilata la tabella che traccia i requisiti in
rapporto agli use case.
Per poterli distinguere in modo preciso è stata usata la classificazione qui riportata:
R(Importanza)(Tipologia)(Codice)
Ad ogni parte corrisponde:
∗ Importanza: può assumere i seguenti valori:
O : indica un requisito obbligatorio
D : indica un requisito desiderabile
F : indica un requisito facoltativo (opzionale)
∗ Tipologia: può assumere i seguenti valori:
F : indica un requisito funzionale. Rappresenta le funzionalità che il prodotto
deve fornire.
Q : indica un requisito qualitativo. Rappresenta gli elementi per aumentare la
qualità del prodotto finale
P : indica un requisito prestazionale. Rappresenta un valore misurabile delle
performance raggiunte dal prodotto terminato.
V : indica un requisito di vincolo. Rappresenta le limitazioni che il prodotto
deve rispettare.
∗ Codice: codice numerico che identifica il requisito; deve essere univoco ed indicato
in forma gerarchica, da sinistra a destra, nella notazione X.Y.Z.
Nelle tabelle 3.1, 3.2, 3.3 e 3.4 sono riassunti i requisiti e il loro tracciamento con gli
use case delineati in fase di analisi.3.2. TRACCIAMENTO DEI REQUISITI 19
Tabella 3.1: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
ROF-1 L’utente deve poter accedere all’applicazione web UC1
ROF-2 L’utente deve poter effettuare il logout dalla piattaforma UC1
ROF-3 L’utente base deve poter inserire una prenotazione UC4
ROF-3.1 L’utente base deve poter visualizzare tutti i primi piatti UC4
disponibili, compresi i pasti alternativi
ROF-3.2 L’utente base deve poter visualizzare tutti i secondi piatti UC4
disponibili, compresi i pasti alternativi
ROF-3.3 L’utente base deve poter visualizzare tutti i contorni UC4
disponibili
ROF-3.4 L’utente base deve poter visualizzare tutti i dolci UC4
disponibili
ROF-3.5 L’utente base deve poter selezionare la prenotazione per UC4
pranzo o per cena
ROF-3.6 L’utente base deve poter selezionare il giorno della UC4
prenotazione
RDF-3.7 L’utente base deve poter esprimere una preferenza di UC4
orario della prenotazione
ROF-4 L’amministratore deve poter visualizzare le prenotazioni UC5
ROF-4.1 L’amministratore deve poter visualizzare le prenotazioni UC5
divise per pasti
ROF-4 L’amministratore deve poter visualizzare le prenotazioni UC5
divise per persone
ROF-5 L’amministratore deve poter inserire una prenotazione UC6
di un utente
ROF-5.1 L’amministratore deve poter visualizzare tutti i primi UC6
piatti disponibili, compresi i pasti alternativi
ROF-5.2 L’amministratore deve poter visualizzare tutti i secondi UC6
piatti disponibili, compresi i pasti alternativi
ROF-5.3 L’amministratore deve poter visualizzare tutti i contorni UC6
disponibili
ROF-5.4 L’amministratore deve poter visualizzare tutti i dolci UC6
disponibili
ROF-5.5 L’amministratore deve poter selezionare la prenotazione UC6
per pranzo o per cena
ROF-5.6 L’amministratore deve poter selezionare il giorno della UC6
prenotazione
RDF-5.7 L’amministratore deve poter esprimere una preferenza UC6
di orario della prenotazione
ROF-5.8 L’amministratore deve poter selezionare la persona per UC6
cui effettuare la prenotazione20 CAPITOLO 3. ANALISI DEI REQUISITI
Requisito Descrizione Use Case
ROF-6 L’amministratore deve poter modificare il menu del UC7
giorno selezionando tramite click i piatti da rendere
disponibili, uno per ogni portata
ROF-6.1 L’amministratore deve poter selezionare il primo piatto UC7
proposto per la giornata
ROF-6.2 L’amministratore deve poter selezionare il secondo piatto UC7
proposto per la giornata
ROF-6.3 L’amministratore deve poter selezionare il contorno UC7
proposto per la giornata
ROF-6.4 L’amministratore deve poter selezionare il dolce proposto UC7
per la giornata
ROF-7 L’amministratore deve poter inserire una nuova pietanza UC9
ROF-7.1 L’amministratore deve poter inserire il nome della nuova UC9
pietanza
ROF-7.2 L’amministratore deve poter inserire la portata a cui si UC9
riferisce la nuova pietanza
ROF-7.3 L’amministratore deve poter inserire la descrizione della UC9
nuova pietanza
ROF-8 L’amministratore deve poter rimuovere una pietanza UC10
presente nella piattaforma
RFF-9 La procedura di inserimento della prenotazione di un UC4
utente base deve poter essere interrotta da un certo orario
in avanti della giornata stessa della prenotazione
RFF-10 Il sistema deve rilevare la mancata prenotazione del pasto -
e suggerire all’utente di procedere alla prenotazione3.2. TRACCIAMENTO DEI REQUISITI 21
Tabella 3.2: Tabella del tracciamento dei requisiti qualitativi
Requisito Descrizione Use Case
ROQ-1 Il sistema deve garantire la sicurezza nella trasmissione -
dei dati
RDQ-1.1 Il sistema deve usare il sistema di autenticazione dei dati -
tramite token
RDQ-2 L’applicazione deve essere fruibile con ogni browser -
disponibile
RFQ-3 L’applicazione va testata in un contesto di reale utilizzo -
Tabella 3.3: Tabella del tracciamento dei requisiti prestazionali
Requisito Descrizione Use Case
ROP-1 L’accesso al sito deve avvenire senza difficoltà presta- -
zionali su un dispositivo mobile dotato di connessione a
internet attiva
ROP-1.1 Il sito deve essere utilizzabile senza difficoltà prestazionali -
su un browser di un dispositivo android
ROP-1.2 Il sito deve essere utilizzabile senza difficoltà prestazionali -
su un browser di un dispositivo iOS
Tabella 3.4: Tabella del tracciamento dei requisiti di vincolo
Requisito Descrizione Use Case
ROV-1 L’applicazione va sviluppata con il framework Angular -
ROV-2 L’applicazione va sviluppata utilizzando la libreria -
Bootstrap (versione 4.4)
ROV-3 L’applicazione va testata tramite JSON-server -
ROV-4 L’applicazione deve fare utilizzo di un database esterno UC1
per effettuare l’autenticazioneCapitolo 4
Progettazione e codifica
4.1 Tecnologie e strumenti
Di seguito viene data una panoramica delle tecnologie e strumenti utilizzati.
4.1.1 Il framework Angular
Introduzione
Il framework Angular è un insieme di strumenti di sviluppo assemblati tra di loro
con i quali è possibile sviluppare un’applicazione web in modo rapido e semplificato,
garantendo delle funzionalità moderne e richieste non precedentemente presenti in altri
framework come AngularJS.
Tra le principali funzionalità rese disponibili troviamo:
∗ il supporto nativo ad eventi touch e gesture tipiche degli schermi dei dispositivi
mobile;
∗ la compatibilità con le ultime funzionalità dei linguaggi basati su ECMAScript
2015 come ad esempio Javascript;
∗ una curva di apprendimento ridotta rispetto al predecessore AngularJS;
∗ una compatibilità migliorata con le librerie esterne basate su Javascript e un
peso complessivo delle applicazioni ridotto.
Per poter ottenere questi risultati Angular ha dovuto perdere la compatibilità con il
proprio antecessore, dovuta principalmente alla integrazione delle direttive all’interno
dei nuovi elementi cardine del framework: i componenti.
I componenti
Un componente è un elemento fondamentale per la costruzione di applicazioni Angular,
al quale viene affidato il controllo di una porzione dello schermo, acquisendo la respon-
sabilità di visualizzare i dati ricevuti e gestirne l’interazione con l’utente secondo il
concetto di view.
Una moderna applicazione Angular è sintetizzabile in un insieme di componenti ordina-
te in modo gerarchico con le quali vengono fornite le funzionalità con cui far interagire
2324 CAPITOLO 4. PROGETTAZIONE E CODIFICA
l’utente.
Tra i principali motivi che rendono davvero vantaggioso questo modello di program-
mazione vi è il fatto di poter assemblare applicazioni diverse utilizzando un insieme
comune di componenti, favorendo quindi il riutilizzo del codice; al contempo la struttu-
ra definita dell’applicazione ne favorisce la suddivisione in moduli e la leggibilità del
codice scritto.
La scelta di Typescript
Il framework angular permette di utilizzare come linguaggi di programmazione Java-
script, Dart oppure Typescript, il quale è maggiormente consigliato dagli sviluppatori.
La scelta del Typescript come linguaggio principale è dovuta a vari fattori, come per
esempio:
∗ la compatibilità con il linguaggio javascript;
∗ il supporto alle novità di ECMAScript 2015;
∗ una sintassi più compatta del linguaggio Javascript;
∗ l fatto di avere il controllo statico dei tipi di dato.
I servizi e la dependency injection
L’incarico di fornitura dei dati in Angular viene spesso assunto dai servizi, ovvero delle
classi tipicamente addette alla gestione delle transazioni tra i servizi e un qualsiasi
componente dell’interfaccia, anche se questo è un ulteriore servizio. In essi possono
essere implementati dei meccanismi di gestione degli errori e impostazioni di timeout
nelle richieste verso un servizio, rendendo ottimale la gestione del comportamento
asincrono delle transazioni ed evitando dei fastidiosi errori runtime che potrebbero
causare delle interruzioni nell’esecuzione dell’applicazione.
Una volta ricevuti i dati da un servizio Angular si occupa di risolvere le dipendenze
precedentemente dichiarate all’interno del componente secondo il meccanismo della
dependency injection, lasciando al programmatore la scelta di collegare il modello dei
dati con l’interfaccia tramite one-way data binding oppure il glstwo-way data binding.
Vengono in questo modo privilegiate la gestione evoluta delle dipendenze e la testabilità
degli elementi di un’applicazione, poiché da un lato viene delegato al sistema l’incarico
di creare e fornire le istanze necessarie degli oggetti richiesti, dall’altro vengono slegati
i dati richiesti dall’applicazione lasciando la possibilità di testare un componente
utilizzando dei dati di prova.
Gli strumenti di Angular
Per consentire il caricamento dinamico dei moduli in base alla navigazione dell’utente
e al flusso di elaborazione dell’applicazione vengono messi a disposizione dei loader
quali ad esempio webpack, grazie ai quali vengono ridotti i tempi di caricamento
dell’applicazione e vengono ottimizzate le risorse disponibili.
A corredo di questo framework è stato reso disponibile uno strumento da riga di
comando con il quale effettuare in modo totalmente automatizzato la prima configu-
razione dell’applicazione, rendendo quindi disponibili sin da subito allo sviluppatore4.1. TECNOLOGIE E STRUMENTI 25 strumenti di configurazione quali ad esempio TSLint, un code checker per TypeScript, oppure Karma, il test runner di Angular. Vantaggi e svantaggi del framework rispetto ai rivali Angular grazie al proprio successo viene spesso affiancato ai vari framework javascript che col tempo sono stati creati e proposti ai programmatori; rispetto ad essi però vi sono alcune differenze essenziali che distinguono il prodotto di Google rispetto alla concorrenza. Come già precedentemente citato Angular si basa su Typescript, un linguaggio di programmazione che differisce da Javascript e che offre numerose funzionalità aggiuntive come ad esempio la presenza di tipi statici. Grazie a questa feature possono essere implementati numerosi tool per supportare meglio i programmatori e ridurre i bug nelle applicazioni. Altra differenza importante è la presenza di numerose funzionalità aggiuntive molto apprezzate come ad esempio RxJS o la presenza stessa di un modello dei dati consistente integrato grazie al linguaggio Typescript, elemento assente ad esempio nel framework rivale React. Al contempo l’onere di avere molte funzionalità integrate comporta un peso maggiore in termini di spazio di archiviazione in seguito alla prima installazione, mentre in altri concorrenti il peso effettivo del framework è decisamente inferiore, risultando migliori per applicazioni meno complesse o che necessitano di meno funzionalità di quelle proposte da Angular. Infine va rilevata una ridotta flessibilità del framework di Google rispetto ai rivali, con tutti i vantaggi e gli svantaggi derivanti da questa scelta soprattutto a livello progettuale. Un programmatore che sceglie Angular desidera una progettazione meno impegnativa e approva tutte le scelte che il framework ha preso al posto suo; un programmatore di un altro framework desidera invece fare delle scelte personalizzate, dettate dalle proprie necessità progettuali, assumendosi poi però la responsabilità di mantenere aggiornate tutte le dipendenze inserite all’interno della propria applicazione. 4.1.2 Bootstrap La libreria Bootstrap è una raccolta di strumenti liberi per la creazione di siti e applicazioni per il web. Essa contiene modelli di progettazione basati sui linguaggi HTML e CSS sia per la tipografia che per le varie componenti dell’interfaccia, quali ad esempio i moduli, i pulsanti di navigazione ed alcune estensioni opzionali di Javascript. Tra le principali caratteristiche di questa libreria troviamo la piena compatibilità con tutte le ultime versioni di tutti i principali browser utilizzati, il supporto al responsive web design, l’adozione di una filosofia mobile-first per quanto riguarda il design oltre che un’ottima documentazione a corredo della libreria per rendere più facile la sua diffusione. 4.1.3 Typescript L’utilizzo del framework Angular ha portato con sé la necessità di utilizzare il lin- guaggio di programmazione consigliato dai suoi sviluppatori per l’utilizzo delle piene funzionalità. Typescript è un linguaggio di programmazione open-source sviluppato e mantenuto da Microsoft. Esso risulta essere un sovrainsieme di JavaScript, a cui aggiunge tra le altre cose la tipizzazione statica degli oggetti.
26 CAPITOLO 4. PROGETTAZIONE E CODIFICA Tale linguaggio è stato progettato per lo sviluppo di grandi applicazioni e la loro traduzione in fase di compilazione in JavaScript. Poiché TypeScript integra al proprio interno le funzionalità di JavaScript i programmi scritti in quest’ultimo linguaggio sono totalmente funzionanti anche nel secondo. TypeScript può essere utilizzato per sviluppare applicazioni JavaScript eseguibili sia lato client che lato server. 4.1.4 Npm Data la necessità di completare in modo rapido il progetto si è dovuto fare affidamento ad alcuni componenti prefabbricati da terze parti. Il package manager Npm è una raccolta di pacchetti gratuiti o a pagamento utilizzabili sul proprio progetto di sito web, come nel nostro caso. Utilizzabile al seguito dell’installazione di Node.js viene messo a disposizione come strumento da linea di comando con il quale scaricare moduli JavaScript poi disponibili all’interno del proprio progetto. Viene data ovviamente la possibilità all’utilizzatore di caricare dei moduli che vengono successivamente messi a disposizione della community. 4.1.5 JSON Server Data la necessità di sviluppare l’interfaccia in modo totalmente separato dai servizi back-end si è reso rapidamente necessario utilizzare degli strumenti capaci di simulare degli end-point per delle chiamate REST a cui chiedere l’acquisizione di dati similmente a come dovrebbe avvenire nel prodotto finale. Per poter esporre un web server locale alla macchina dello sviluppatore è sufficiente, oltre all’installazione dello strumento, un file .json sul quale vengono inseriti i dati che verranno restituiti durante le chiamate REST; infine è possibile supportare operazioni di tipo GET, POST, DELETE e PUT similmente a come potrebbero fare dei servizi back-end. In questo senso JSON Server è risultato essere uno strumento essenziale, data la sua possibilità di creare un servizio back-end in modo più rapido di quanto sia possibile fare con delle suite più complete ma più complesse da configurare. 4.1.6 Git Git è un software di controllo versione distribuito utilizzabile da interfaccia a riga di comando. Pensato per mantenere un grande progetto di sviluppo distribuito, Git supporta fortemente lo sviluppo non lineare del software. Tramite strumenti appositi è possibile creare più diramazioni di sviluppo del software con la garanzia di poter mantenere in locale la cronologia di sviluppo completa. 4.1.7 Visual Studio Code Visual Studio Code è un editor di codice sorgente sviluppato da Microsoft con supporto multipiattaforma. Il programma integra al suo interno il sistema di versionamento Git, syntax highlighting per vari linguaggi di programmazione, il sistema di completamento automatico IntelliSense, applicativi per il refactoring del codice e uno store ricco di estensioni utili per lo sviluppo delle applicazioni.
Capitolo 5
Progettazione e sviluppo
5.1 I design pattern utilizzati
Il framework Angular presenta già al suo interno numerosi design pattern il cui utilizzo
dà un grande valore aggiunto a tutti i prodotti che si possono creare con esso. La
maggior parte dei pattern che verranno adesso elencati sono stati per gran parte
utilizzati proprio grazie alla loro implementazione all’interno del framework.
5.1.1 Composite
Senza dubbio il design pattern più sfruttato di Angular è il composite, il quale può
essere immediatamente riconosciuto nei più complessi, ovvero quelli formati da più
component figli ma che utilizzano i medesimi dati presenti nel component padre.
Tale pattern permette di trattare un gruppo di oggetti come se fossero l’istanza di un
oggetto singolo. Gli oggetti vengono organizzati in una struttura ad albero, nella quale
i nodi sono delle composizioni e le foglie sono oggetti semplici.
Questo design pattern dovrebbe essere utilizzato quando i client ignorano la differenza
tra composizioni di oggetti e oggetti individuali. Poiché in Angular non è raro che
più oggetti possano essere utilizzati allo stesso modo, addirittura con lo stesso codice,
allora il composite è una buona scelta, permettendo di trattare oggetti compositi o
semplici in modo omogeneo.
Nel progetto questo design pattern è visibile soprattutto nella pagina dei pasti o delle
prenotazioni, dove più component figli modificano la visualizzazione degli stessi dati
presenti nel component padre (una selezione del tipo di pietanza o l’inserimento di una
prenotazione).
5.1.2 Observer
Il design pattern Observer permette di risolvere la problematica delle numerose di-
pendenze da soddisfare tra più oggetti senza che essi siano strettamente accoppiati;
permette inoltre di aggiornare tutte le dipendenze collegate ad un oggetto alla modifica
del suo stato.
Data la necessità di modificare l’interfaccia in base alle interazioni dell’utente il pattern
observer è stato ampiamente utilizzato con questo fine. In tutte le schermate dell’ap-
plicazione tale pattern rende possibile modificare la schermata visualizzata, facendo
2728 CAPITOLO 5. PROGETTAZIONE E SVILUPPO
visualizzare o nascondendo i dati dei componenti che vengono visualizzati.
All’atto pratico gli eventi Angular sono l’esempio applicativo più comune del pattern
observer, consentendo al programmatore di collegare azioni come il click su un pulsante
ad una funzione che modifichi la schermata visualizzata. Al contempo i dati presenti
all’interno dei singoli component vengono aggiornati in modo totalmente automatico
grazie all’adozione di questo pattern nel framework Angular.
5.1.3 Dependency Injection
La dependency injection è una tecnica dove un oggetto (o un metodo statico) fornisce
le dipendenze ad un altro oggetto. L’intento della dependency injection è quello di
disaccoppiare gli oggetti dalle loro estensioni in modo che in nessuna situazione il
codice debba essere cambiato per favorire la modifica di un oggetto da cui esso dipende.
Ciò che distingue questo design pattern è la “injection”, ossia il passaggio di una
dipendenza ad un oggetto che necessita di essa per il proprio funzionamento. Il client
quindi delega a un componente separato (definito come injector) la responsabilità
di approvvigionare le dipendenze di cui esso necessita; il client non chiama in modo
esplicito l’injector, bensì è l’injector che si occupa della costruzione degli oggetti e
guida il client nella ricezione delle proprie dipendenze.
Un servizio Angular svolge questo incarico in ogni sua parte, fornendo quindi ai com-
ponent i dati di cui essi hanno bisogno per un corretto funzionamento. Questo sistema
ha il vantaggio di rendere completamente testabile qualsiasi component tramite la
creazione di un file mock che simuli i modelli dei dati e i servizi.
Rispetto al predecessore Angular utilizza principalmente la dependency injection attra-
verso i costruttori disponibili in typescript.
5.2 Architetture software e paradigmi utilizzati
5.2.1 Reactive programming
Un’applicazione Angular è di per sé un sistema reactive. Quando un utente clicca un
bottone l’applicazione reagisce a questo evento e aggiorna il modello. All’aggiornamento
del modello l’applicazione propaga i cambiamenti attraverso l’albero dei component.
Il flusso di queste informazioni è però insitamente asincrono, comportando una pro-
pagazione meno controllata ma al contempo più libera dai ritmi di funzionamento
dell’applicazione.
In Angular è quindi centrale l’utilizzo di librerie come ad esempio RxJS a cui viene
affidata la gestione di tutte quelle transazioni con il database.
5.2.2 REST
Lo stile architetturale REST prescrive che lo stato in un’applicazione e le sue funzionalità
siano interpretate come risorse web univoche e accessibili solitamente tramite un URL
e un protocollo HTTP. L’approccio architetturale REST è definito dai seguenti vincoli
applicati ad un’architettura:
∗ Client-server: un insieme di interfacce uniformi separa il client dal server in
modo da ridurre l’accoppiamento tra le componenti del sistema. In questo modo,
ad esempio, il client non deve occuparsi della persistenza dei dati e il server
dell’interfaccia grafica;5.2. ARCHITETTURE SOFTWARE E PARADIGMI UTILIZZATI 29
∗ Stateless: la comunicazione client-server è ulteriormente vincolata in modo
che nessun contesto client venga memorizzato sul server tra le richieste. Ogni
richiesta da ogni client contiene tutte le informazioni necessarie per richiedere il
servizio, e lo stato della sessione è contenuto sul client.
∗ Cacheable: i client possono fare caching delle risposte;
∗ Layered system: i client non sono tenuti a conoscere quali livello del sistema
server stanno interrogando.
Tale architettura oltre ad essere molto diffusa nelle applicazioni web, è semplice e
riduce notevolmente l’accoppiamento tra client e server.Capitolo 6
Conclusioni
6.1 Considerazioni riguardo agli obiettivi raggiunti
Figura 6.1: Pagina di login del sito
Non è stato possibile completare nella sua totalità l’applicazione web poiché il tempo
avuto a disposizione ha consentito il completamento della sola parte amministrativa
del sito a discapito di quella disponibile per l’utente.
Si è quindi arrivati ad avere un funzionamento completo delle seguenti funzionalità:
∗ visualizzazione prenotazioni;
∗ inserimento prenotazione;
∗ modifica del menu di una data giornata;
∗ visualizzazione di tutte le pietanze disponibili nel portale;
∗ inserimento delle pietanze all’interno del portale;
∗ eliminazione delle pietanze all’interno del portale.
3132 CAPITOLO 6. CONCLUSIONI
Figura 6.2: Calendario per la selezione della giornata all’interno del sito
Si è utilizzato un calendario per poter accedere ad ogni schermata con la data
già scelta e il conseguente caricamento più rapido delle informazioni. Si è scelto di
utilizzare un calendario con il formato delle date inglese poiché non vi erano delle
alternative altrettanto piacevoli dal punto di vista grafico e non si è voluto utilizzare
dei datepicker di dimensione ridotta ma con un formato delle date corretto per lo
standard italiano.
Figura 6.3: Pagina di inserimento e rimozione delle pietanze presenti dentro alla piattaforma
La sezione utente è stata parzialmente sviluppata con l’intenzione di sfruttare le stesse
operazioni di lettura e scrittura delle prenotazioni utilizzate per la parte amministratore.
Si sono riscontrati invece alcuni problemi durante il salvataggio di un file .xlsx con
all’interno i dati complessivi delle prenotazioni del mese, in particolare il prelievo del
file è risultato complicato da gestire lato front-end a causa del formato inconsueto del
file.6.2. L’ACCESSIBILITÀ DEL SITO 33 6.2 L’accessibilità del sito Avendo fatto utilizzo delle librerie bootstrap 4 e in alcune situazioni anche delle librerie W3CSS dal punto di vista della visualizzazione viene garantito lo standard WCAG 2.0 almeno di livello A (anche se tramite appositi strumenti è stato rilevato un livello anche maggiore in molte delle pagine create). Dal punto di vista della correttezza del codice vi è stata una difficoltà maggiore del previsto nella ricerca di errori di programmazione, dovuto principalmente al fatto che il codice html della pagina visualizzata non comprende il codice dei component, rendendo quindi impossibile per uno strumento di validazione come W3C validator il controllo degli errori presenti nella pagina. Sopperire a questa carenza attuale del framework è al momento assai complicato, poiché l’unico strumento realmente efficace per il controllo della correttezza del proprio lavoro sono i test automatici dell’interfaccia. Risulta comunque impossibile controllare la correttezza del codice html di ogni com- ponente, il quale deve ricevere un test di validazione dedicato e sfortunatamente non automatizzato. 6.3 Considerazioni riguardo il framework Angular 6.3.1 L’esperienza in sintesi Il framework Angular si è dimostrato essere un framework molto completo e comodo da utilizzare per lo sviluppo dell’interfaccia web desiderata. In particolare è stata molto utile l’integrazione di numerose funzionalità quali ad esempio la libreria RxJS per la gestione delle chiamate REST oppure i router per la gestione delle transizioni da una pagina ad un’altra. 6.3.2 I vantaggi Grazie anche al continuo confronto con degli altri stagisti si è potuto vedere in modo chiaro come altri framework come ad esempio React mostrino delle carenze nelle funzionalità e costringano lo sviluppatore all’utilizzo di pacchetti spesso poco testati e affidabili; inoltre i continui rilasci e aggiornamenti del framework garantiscono un continuo miglioramento che altri rivali non possono promettere con il passare del tempo. Oltre a queste caratteristiche uno dei cavalli di battaglia di Angular v2.x.x è la maggiore velocità di apprendimento rispetto ad AngularJs, grazie soprattutto ad una documen- tazione abbastanza esaustiva e al grande sostegno delle community di sviluppatori, la quale non risente eccessivamente della relativamente giovane età del framework. 6.3.3 Gli svantaggi Lo studio di Angular ha fatto affiorare anche qualche difetto congenito di questo framework, dovuto principalmente al fatto che è stato rilasciato da poco tempo e quindi presenta ancora qualche elemento da migliorare. Studiare Angular è sicuramente facilitato dalla documentazione, con però alcune riserve riguardanti alcune spiegazioni ancora troppo poco dettagliate, con degli esempi troppo
34 CAPITOLO 6. CONCLUSIONI semplificati per mostrare una situazione di utilizzo reale. Sfortunatamente la completezza del framework data dall’incolusione di numerosi pacchetti e funzionalità non copre tutte le necessità di uno sviluppatore, costringendo comunque in molte situazioni all’utilizzo di librerie poco testate e dallo sviluppo incerto negli anni futuri. Inoltre la relativa gioventù del framework porta con sé delle difficoltà nel reperire pacchetti npm appositamente creati per tale framework, rendendo complicato trovare il componente che faccia esattamente al proprio caso. 6.4 Risvolti futuri dell’applicazione Anche se ancora in completamento l’applicazione mostra numerosi elementi tali da renderla una ottima base da cui partire per un eventuale sviluppo della stessa in un ambiente diverso da quello preso in esame da questo stage. Tra i principali punti di forza dell’applicazione creata ci sono sicuramente la possibilità di utilizzare database già esistenti che contengano le credenziali degli utenti agevolando gli stessi nell’accesso alla piattaforma, l’apparato di sicurezza basato sul protocollo JWT token tramite il quale viene regolamentato l’accesso alle informazioni oltre che il tempo massimo di connessione dopo cui richiedere un nuovo login ed infine il design responsive al quale viene dato il merito di far girare senza problemi l’applicazione su ogni tipo di dispositivo. Non è stato ancora possibile testare l’applicazione in un contesto di utilizzo reale ma non è escluso che in futuro tale operazione venga effettuata al fine di limare gli eventuali difetti riscontrati.
Glossario
Active Directory In informatica Active Directory è un insieme di servizi di rete,
meglio noti come directory service, adottati dai sistemi operativi Microsoft a
partire da Windows 2000 Server e gestiti da un domain controller. 4, 35
Angular Angular 2 (o semplicemente Angular) è una piattaforma open source per lo
sviluppo di applicazioni web con licenza MIT. 3, 35
back-end parte dell’applicazione che fornisce i dati utili al suo funzionamento. 3, 35
design pattern in informatica si definisce design pattern una soluzione progettuale
generale ad un problema ricorrente. 27, 35
dipendenze Sono oggetti che possono essere utilizzati da uno o più oggetti (o nel
nostro caso componenti). Definiscono il grado con cui ciascuna componente di
un software dipende dalle altre componenti. 35
ECMAScript ECMAScript (o ES) è un linguaggio di programmazione standardizzato
e mantenuto da Ecma International nell’ECMA-262 ed ISO/IEC 16262. Le
implementazioni più conosciute di questo linguaggio (spesso definite come dialetti)
sono JavaScript, JScript e ActionScript che sono entrati largamente in uso,
inizialmente, come linguaggi lato client nello sviluppo web. 23, 35
endpoint Un endpoint di comunicazione (communication endpoint) è un tipo di
nodo per la comunicazione in rete. È un’interfaccia esposta tramite una parte
comunicativa o tramite una canale di comunicazione.
Gli endpoint favoriscono uno strato di astrazione programmabile per cui sistemi
software e/o sottosistemi possono comunicare tra di loro, inoltre i mezzi di
comunicazione sono disaccoppiati dai sottosistemi di comunicazione. 4, 35
framework Insieme integrato di componenti software prefabbricate, grazie alle quali
si forma una ottima base facilmente riusabile di diverse appllicazioni entro un
dato dominio. 3, 35
front-end parte dell’applicazione con cui l’utente ha la possibilità di interagire. 3, 35
mobile first strategia di progettazione dei un’interfaccia affinchè l’uso da smartphone
riceva più attenzione nello sviluppo rispetto alla controparte desktop. 3, 35
35Puoi anche leggere
