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
Studio e implementazione del front-end di
un’applicazione web mediante il framework
Angular
Tesi di laurea triennale
Relatore
Prof. Lamberto Ballan
Laureanda
Bianca Andreea Ciuche
1122193
Anno Accademico 2018-2019
Bianca Andreea Ciuche: Studio e implementazione del front-end di un’applicazione web mediante il framework Angular, Tesi di laurea triennale, c 26 Settembre 2019.
Dedicato alla mia famiglia.
Sommario
Il presente documento ha lo scopo di riassumere il lavoro svolto durante il periodo di
stage accademico della laureanda Ciuche Bianca Andreea presso l’azienda Sync Lab
s.r.l. nel periodo tra il 27 maggio 2019 e 19 luglio 2019 della durata di circa 320 ore.
L’obiettivo dello stage è sviluppare un front-end attraverso l’utilizzo del framework
Angular per un’applicazione web riguardante scheduler per la ricerca di annunci
lavorativi.
Durante i due mesi di tirocinio, in primo luogo c’è stato l’apprendimento delle tecnologie
necessarie per poter iniziare l’implementazione del progetto con approfondimenti sul
framework Angular, in secondo luogo si è svolto lo sviluppo del front-end.
vRingraziamenti
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 profondo affetto la mia famiglia per aver creduto in me, per
il grande supporto e per essermi stata vicina in ogni momento durante gli anni di studio.
Infine ringrazio tutti i miei amici: quelli di quartiere, dell’infanzia, del liceo e dell’uni-
versità.
Padova, 26 Settembre 2019 Bianca Andreea Ciuche
viiIndice
1 Introduzione 1
1.1 Convenzioni tipografiche . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Profilo aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 Settori d’impiego . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Descrizione dello stage 3
2.1 Il progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Lo stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1 Pianificazione delle settimane . . . . . . . . . . . . . . . . . . 5
2.4.2 Pianificazione delle ore . . . . . . . . . . . . . . . . . . . . . . . 6
3 Analisi dei requisiti 7
3.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 UC0: Scenario iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 UC1: Configurazione scheduler . . . . . . . . . . . . . . . . . . . . . . 9
3.4 UC2:Visualizzazione risultati scheduler . . . . . . . . . . . . . . . . . . 13
3.5 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 Requisiti di Vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8 Requisiti di Qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Tecnologie e strumenti utilizzati 21
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Strumenti di versionamento . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Linguaggi e framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.1 Il framework Angular . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.2 Panoramica dell’architettura Angular . . . . . . . . . . . . . . 24
4.4.3 Alternative ad Angular . . . . . . . . . . . . . . . . . . . . . . 27
4.4.4 Typescript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.5 Npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.6 JSON Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.7 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ixx INDICE
5 Progettazione 31
5.1 Struttura delle classi di Sync Lav . . . . . . . . . . . . . . . . . . . . . 31
5.2 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Approfondimenti user experience e user interface . . . . . . . . . . . . 35
6 Conclusioni 37
6.1 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 37
6.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Glossary 39
Acronyms 41
Bibliografia 43Elenco delle figure
1.1 Logo Sync Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.1 Scenario principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 UC1 configurazione scheduler . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Visualizzazione risultati scheduler . . . . . . . . . . . . . . . . . . . . . 13
4.1 Logo Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Logo Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Architettura ad alto livello di Angular . . . . . . . . . . . . . . . . . . 24
4.5 AppModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 AppComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Esempio del meccanismo two-way data binding . . . . . . . . . . . . . 26
4.8 Logo TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.9 Logo Npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.10 Logo Json Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11 Logo Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Diagramma delle classi . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Heat Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Elenco delle tabelle
3.1 Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
xixii ELENCO DELLE TABELLE
3.2 Requisiti di Vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Requisiti di Qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Capitolo 1
Introduzione
Questo capitolo consiste in una presentazione dell’azienda ospitente, Synclab, e in una
descrizione di alcune norme tipografiche usate per la stesura del documento.
1.1 Convenzioni tipografiche
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
∗ Gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzionati
vengono definiti nel glossario, situato alla fine del presente documento;
∗ I termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati con
il carattere corsivo.
1.2 L’azienda
Figura 1.1: Logo Sync Lab
1.2.1 Profilo aziendale
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 Information and Communication Technology (ICT), consolidando i rapporti
con clienti e partner, raggiungendo 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
12 CAPITOLO 1. INTRODUZIONE
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 adattativo e diversificato al mercato.
1.2.2 Servizi
Sync Lab s.r.l. è un’azienda leader nella consulenza tecnologica, impegnata in un
processo continuo d’identificazione e messa in opera di soluzioni per i clienti finalizzate
alla creazione di valore. L’azienda supporta le esigenze d’innovazione di tutte le
organizzazioni ed in ogni settore di mercato nell’ambito Information Technology (IT),
con servizi in ambito
∗ Business Consultancy;
∗ Project Financing;
∗ IT Consultancy;
Sync Lab 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 l’expertise e il 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 Sistema di supporti al
business (BSS), per sistemi d’integrazione (EAI/SOA) o per sistemi di monitoraggio
applicativo/territoriale. Il laboratorio RD (Ricerca e Sviluppo) dell’azienda è sempre
al passo con i nuovi paradigmi tecnologici e di comunicazione, ad esempio Big Data,
Cloud Computing, Internet of Things (IoT), 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 hanno permesso di acquisire una profonda
conoscenza degli strumenti di finanza agevolata fruendone direttamente e 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).
1.2.3 Settori d’impiego
Sync Lab si sta sempre più specializzando in vari settori d’impiego: dal mondo banking
all’assurance 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 generale.Capitolo 2
Descrizione dello stage
Questo capitolo presenta la descrizione del progetto di stage e la stesura del piano di
lavoro stipulato assieme al relatore aziendale e revisionato dal relatore interno.
2.1 Il progetto
Il progetto di stage, denominato Sync Lav, consiste nell’implementazione di un’applicazione
web, la quale si occupa della gestione di scheduler per la ricerca di annunci lavorativi.
Attraverso l’applicazione è possibile configurare, in base alle proprie necessità e prefe-
renze, uno scheduler personalizzato e visualizzarne i risultati in una tabella, dove sono
specificati il nome dell’annuncio, la data di pubblicazione, l’azienda proponente, il link
della pagina d’origine dell’annuncio ed un testo di descrizione dell’annuncio. All’in-
terno del progetto l’obiettivo della stagista è sviluppare il front-end dell’applicazione
mediante il framework Angular, la parte di back-end è assegnata ad un altro membro
del progetto. In alcune fasi del progetto c’è la collaborazione tra i membri del gruppo
per far sì che le due parti, front-end e back-end, possano integrarsi senza problemi.
2.2 Lo stage
Lo stage si è svolto nella sede di Padova dell’azienda ospitante, Sync Lab, nell’arco
delle otte settimane previste nel piano di lavoro.
Nella prima parte dello stage è richiesto alla tirocinante di apprendere le tecnologie
necessarie per poter affrontare le fasi di analisi, progettazione e implementazione del
progetto. Le tematiche da acquisire sono le seguenti:
∗ Angular;
∗ JavaScript;
∗ TypeScript;
∗ Architettura MVVM/MVC;
∗ Studio di alcuni concetti relativi le tematiche di User/Customer Experience e
User Interface tra cui:
– Storytelling;
34 CAPITOLO 2. DESCRIZIONE DELLO STAGE
– User Centered Design, User Journey, Empathy Map;
– User Flow ;
– Analisi dei competitor e delle Persone;
– Mouse Tracking;
– Heat Map;
– Click Map;
– Responsive Web Design e Adaptive Web Design.
La seconda parte dello stage consiste nello sviluppo effettivo della parte di front-end
per il progetto SyncLav, quindi nella sua progettazione e implementazione.
2.3 Obiettivi
Al termine del tirocinio la stagista dovrà aver prodotto un front-end tramite il framework
Angular, cercando di applicare i principi di User experience dove possibile.
Notazione
Si farà riferimento ai requisiti secondo le seguenti notazioni:
∗ O per i requisiti obbligatori, vincolanti in quanto obiettivo primario richiesto dal
committente;
∗ D per i requisiti desiderabili, non vincolanti o strettamente necessari, ma dal
riconoscibile valore aggiunto;
∗ F per i requisiti facoltativi, rappresentanti valore aggiunto non strettamente
competitivo.
Le sigle precedentemente indicate saranno seguite da una coppia sequenziale di
numeri, identificativo del requisito.
Obiettivi fissati
Il progetto si è posto come obiettivo l’adempimento dei seguenti requisiti:
∗ Requisiti obbligatori:
– O01: Acquisizione competenze previste dal programma;
– O02: Capacità di raggiungere gli obiettivi richiesti in autonomia seguendo
il crono programma;
– O03: Portare a termine le modifiche richieste con una percentuale di
superamento degli item di collaudo pari al 50%;
∗ Requisiti desiderabili:
– D01: Portare a temine le modifiche richieste dal cliente con una percentuale
di superamento degli item pari all’80%;
∗ Requisiti facoltativi:
– F01: Acquisizione competenze sulla libreria Hot-jar ed eventuale utilizzo;2.4. PIANIFICAZIONE 5
2.4 Pianificazione
In questa sezione viene mostrata la pianificazione delle settimane e delle ore, per ogni
attività concordata con il relatore aziendale e il relatore interno.
2.4.1 Pianificazione delle settimane
∗ Prima Settima
– Presentazione strumenti di lavoro per la condivisione del materiale di studio
e per la gestione dell’avanzamento del percorso(Slack, Trello, ecc.);
– Condivisione scaletta di argomenti;
– Veloce panoramica su metodologie Agile/Scrum;
∗ Seconda Settima
– Studio di JavaScript e TypeScript;
∗ Terza Settima
– Studio teoretico dell’Architettura MVVM e di Angular;
∗ Quarta Settima
– Studio di alcuni concetti relativi di User/Customer Experience e User
Interface tra cui:
∗ Storytelling;
∗ User Center Design, User Journey, Empathy Map;
∗ User Flow ;
∗ Analisi dei competitor e delle Persone;
∗ Mouse Tracking;
∗ Heat Map;
∗ Responsive Web Design e Adaptive Web Design;
∗ Quinta, Sesta e Settima
– Implementazione front-end tramite il framework Angular del progetto Sync
Lav;
∗ Ottava Settima
– Conclusione implemetazione front-end del progetto Sync Lav, collaudo e
installazione in esercizio;6 CAPITOLO 2. DESCRIZIONE DELLO STAGE
2.4.2 Pianificazione delle ore
Durata in ore Descrizione dell’attività
40 Formazione sulle tecnologie
38 Studio di JavaScript/TypeScript
38 Studio teorico dell’Architettura MVVM Angular e di
Angular
38 Studio delle tematiche relative all’ User/Customer
Experience e User Interface
110 Implementazione Font-End del progetto "SinglePageA-
pllication"
12 Analisi del problema e del dominio applicativo
10 Applicazione dei concetti User/Customer Experience e User
Interface
38 Collaudo Finale
30 Collaudo
5 Stesura documentazione finale
3 Consegna codice
Totale ore 302Capitolo 3
Analisi dei requisiti
Il presente capitolo ha come scopo la descrizione completa e precisa di tutti i casi d’uso
riguardanti il progetto Sync Lav. Tali informazioni sono state estrapolate dai colloqui
con il relatore aziendale.
3.1 Casi d’uso
Per lo studio dei casi d’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 con il sistema stesso. L’attore per
tutti i casi d’uso è sempre l’utente generale.
78 CAPITOLO 3. ANALISI DEI REQUISITI
3.2 UC0: Scenario iniziale
Figura 3.1: Scenario principale
∗ Attori: Utente generale;
∗ Descrizione: Attraverso la pagina iniziale l’utente generale può accedere alla
pagina di configurazione scheduler oppure alla pagina di visualizzazione dei
risultati scheduler cliccando i rispettivi pulsanti;
∗ Precondizione: L’utente si trova nella pagina iniziale dell’applicazione;
∗ Postcondizione:L’utente visualizza la pagina rispettiva al pulsante cliccato;
∗ Scenario principale:
1. Configurazione scheduler (UC1);
2. Visualizza risultati scheduler (UC2);3.3. UC1: CONFIGURAZIONE SCHEDULER 9
3.3 UC1: Configurazione scheduler
Figura 3.2: UC1 configurazione scheduler
∗ Attori: Utente generale;
∗ Descrizione: L’utente generale può impostare una nuova configurazione dello
scheduler di ricerca oppure visualizzare l’ultima configurazione dello scheduler
impostata.
∗ Precondizione: L’utente si trova nella pagina di configurazione dello scheduler.
∗ Postcondizione: L’applicazione ha ricevuto le informazioni dall’utente in base
all’operazione che vuole eseguire.
∗ Scenario principale:
1. Inserimento chiave (UC1.1);
2. Inserimento città (UC1.3);10 CAPITOLO 3. ANALISI DEI REQUISITI
3. Inserimento regione(UC1.5);
4. Inserimento orario (UC1.7);
5. Selezione data di inizio scheduler(UC1.9);
6. Selezione ripetibilità(UC1.11);
7. Salvataggio configurazione(UC1.12);
8. Tornare indietro(UC1.14);
9. Visualizzazione ultima configurazione(UC1.15);
UC1.1: Inserimento chiave
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la chiave.
∗ Precondizione: Il campo form riguardante la chiave è pronto per la configura-
zione.
∗ Postcondizione: L’utente ha inserito la chiave.
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della chiave;
2. L’utente inserisce il valore desiderato nel campo form della chiave;
∗ Estensioni:
1. UC1.2 Visualizzazione messaggio d’errore;
UC1.3: Inserimento città
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la chiave.
∗ Precondizione:Il campo form riguardante la città è pronto per la configurazione.
∗ Postcondizione: L’utente ha inserito la città.
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della città;
2. L’utente inserisce il valore desiderato nel campo form della città;
∗ Estensioni:
1. UC1.4 Visualizzazione messaggio d’errore;3.3. UC1: CONFIGURAZIONE SCHEDULER 11
UC1.5: Inserimento regione
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la regione.
∗ Precondizione: Il campo form riguardante la regione è pronto per la configura-
zione.
∗ Postcondizione: L’utente ha inserito la regione.
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della regione;
2. L’utente inserisce il valore desiderato nel campo form della regione;
∗ Estensioni:
1. UC1.6 Visualizzazione messaggio d’errore;
UC1.7: Inserimento orario
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire l’ora.
∗ Precondizione: Il campo form riguardante l’ora è pronto per la configurazione.
∗ Postcondizione: L’utente ha inserito l’ora.
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento dell’ora;
2. L’utente inserisce il valore desiderato nel campo form dell’ora;
∗ Estensioni:
1. UC1.8 Visualizzazione messaggio d’errore;
UC1.9:Selezione data di inizio scheduler
∗ Attori: Utente generale;
∗ Descrizione: L’utente generale può inserire la data.
∗ Precondizione: Il campo form riguardante la data è pronto per la configurazio-
ne.
∗ Postcondizione: L’utente ha inserito la data.
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della data;
2. L’utente inserisce il valore desiderato nel campo form della data;
∗ Estensioni:
1. UC1.10 Visualizzazione messaggio d’errore;12 CAPITOLO 3. ANALISI DEI REQUISITI
UC1.11: Selezione ripetibilità
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può selezionare la ripetibilità desiderata.
∗ Precondizione: il campo form riguardante la ripetibilità è pronto per la
configurazione.
∗ Postcondizione: L’utente ha selezionato la ripetibilità.
UC1.12: Salva configurazione
∗ Attori: Utente generale;
∗ Descrizione: Il sistema deve salvare la configurazione dello scheduler ricevuta.
∗ Precondizione: L’utente è nella pagina di configurazione scheduler e vuole
salvare la configurazione inserita.
∗ Postcondizione: Il sistema ha salvato con successo la configurazione inserita.
∗ Estensioni:
1. UC1.12 Visualizzazione messaggio d’errore;
UC1.14: Tornare indietro
∗ Attori: Utente generale;
∗ Descrizione:L’utente attraverso il rispettivo pulsante torna alla pagina iniziale.
∗ Precondizione: L’applicazione è pronta per tornare alla pagina iniziale.
∗ Postcondizione: L’utente generale si trova nella pagina iniziale.
UC1.15: Visualizzazione ultima configurazione
∗ Attori: Utente generale;
∗ Descrizione: L’applicazione deve mostrare l’ultima configurazione impostata
dall’utente.
∗ Precondizione: L’utente ha già configurato almeno una volta lo scheduler.
∗ Postcondizione: L’utente visualizza l’ultima configurazione.3.4. UC2:VISUALIZZAZIONE RISULTATI SCHEDULER 13
3.4 UC2:Visualizzazione risultati scheduler
Figura 3.3: Visualizzazione risultati scheduler
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale imposta i filtri per la ricerca dello scheduler e ne
visualizza i risultati in tabella.
∗ Postcondizione: L’applicazione ha ricevuto tutte le informazione e mostra in
tabella i risultati dello scheduler.
∗ Scenario principale:
1. Inserimento chiave (UC2.1);
2. Inserimento città (UC2.3);
3. Inserimento data di inizio(UC2.5);
4. Inserimento data di fine (UC2.7);
5. Visualizzazione risultati in tabella (UC2.9);
6. Tornare indietro(UC2.10);
UC2.1: Inserimento chiave
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la chiave nella sezione riguardante i
filtri:14 CAPITOLO 3. ANALISI DEI REQUISITI
∗ Precondizione:Il campo form riguardante la chiave è pronto per la configura-
zione.
∗ Postcondizione: L’utente ha inserito la chiave nella sezione riguardante i filtri.
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della chiave;
2. L’utente inserisce il valore desiderato nel campo form della chiave;
∗ Estensioni:
1. UC2.2 Visualizzazione messaggio d’errore;
UC2.3: Inserimento città
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la città nella sezione riguardante i
filtri;
∗ Precondizione:Il campo form riguardante la città è pronto per la configurazione.
∗ Postcondizione: L’utente ha inserito la città nella sezione riguardante i filtri;
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della città;
2. L’utente inserisce il valore desiderato nel campo form della città;
∗ Estensioni:
1. UC2.4 Visualizzazione messaggio d’errore;
UC2.5: Inserimento data inizio
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la data di inizio nella sezione riguar-
dante i filtri;
∗ Precondizione: Il campo form riguardante la data è pronto per la configurazio-
ne.
∗ Postcondizione: L’utente ha inserito la data di inizio nella sezione riguardante
i filtri;
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della data di inizio;
2. L’utente inserisce il valore desiderato nel campo form della data;
∗ Estensioni:
1. UC2.6 Visualizzazione messaggio d’errore;3.4. UC2:VISUALIZZAZIONE RISULTATI SCHEDULER 15
UC2.7: Inserimento data fine
∗ Attori: Utente generale;
∗ Descrizione:L’utente generale può inserire la data di fine nella sezione riguar-
dante i filtri;
∗ Precondizione: Il campo form riguardante la data è pronto per la configurazio-
ne.
∗ Postcondizione: L’utente ha inserito la data di fine nella sezione riguardante i
filtri;
∗ Scenario principale:
1. L’utente ha selezionato il form per l’inserimento della data;
2. L’utente inserisce il valore desiderato nel campo form della data;
∗ Estensioni:
1. UC1.10 Visualizzazione messaggio d’errore;
UC2.9: Visualizzazione risultati in tabella
∗ Attori: Utente generale;
∗ Descrizione:il sistema mostra i risultati in base ai filtri impostati dall’utente.
∗ Precondizione: Il sistema è pronto per mostrare i risultati in tabella.
∗ Postcondizione: L’utente visualizza i risultati in base ai filtri inseriti.
∗ Scenario principale:
1. Visualizzazione annuncio in tabella(UC2.9.1);
UC2.10: Tornare indietro
∗ Attori: Utente generale;
∗ Descrizione: L’utente attraverso il rispettivo pulsante torna alla pagina iniziale.
∗ Precondizione: L’applicazione è pronta per tornare alla pagina iniziale.
∗ Postcondizione: L’utente generale si trova nella pagina iniziale.
UC2.9.1: Visualizzazione annuncio in tabella
∗ Attori: Utente generale;
∗ Descrizione: L’utente visualizza le informazione riguardanti l’annuncio d’inte-
resse.
∗ Precondizione: Il sistema è pronto per mostrare le informazioni.16 CAPITOLO 3. ANALISI DEI REQUISITI
∗ Postcondizione: L’utente ha visualizzato le informazioni d’interesse.
∗ Scenario principale:
1. L’utente visualizza la data di pubblicazione dell’annuncio;
2. L’utente visualizza il titolo dell’annuncio;
3. L’utente visualizza il luogo di lavoro riguardante l’annuncio;
4. L’utente visualizza il testo riguardante l’annuncio;
5. L’utente visualizza il sito web riguardante l’annuncio;
3.5 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 seguente nomenclatura
n on on on o
R A B XX . YY
dove:
∗ A: corrisponde a uno dei seguenti requisiti:
– F: funzionale;
– Q: di qualità;
– P: di prestazione;
– V: di vincolo.
∗ B: corrisponde a uno dei seguenti requisiti:
– O: obbligatorio;
– F: facoltativo;
– D: desiderabile.
∗ XX: numero che identifica i requisiti;
∗ YY: numero progressivo che identifica i sottocasi, esso può, a sua volta, includere
altri sottocasi.
Nelle tabelle dei requisiti funzionali, di vincolo e di qualità, sono riassunti i requisiti
e il loro tracciamento con gli use case delineati in fase di analisi.3.6. REQUISITI FUNZIONALI 17
3.6 Requisiti Funzionali
Id
Descrizione Use Case
Requisito
L’applicazione deve permettere all’utente generale di poter
RFO1 UC0
accedere alla pagina iniziale
L’applicazione deve permettere all’utente generale di poter
RFO2 UC0
accedere alla pagina di configurazione dello scheduler
L’applicazione deve permettere all’utente generale di
RFO3 UC1
configurare lo scheduler
L’applicazione deve permettere all’utente generale di
RFO4 UC1.1
inserire la chiave per la configurazione dello scheduler
Il sistema deve permettere all’utente generale di inserire
RFO5 UC1.3
la città per la configurazione dello scheduler
Il sistema deve permettere all’utente generale di inserire
RFO6 UC1.5
la regione per la configurazione dello scheduler
L’applicazione deve permettere all’utente generale di
RFO7 UC1.7
configurare l’ora per la configurazione dello scheduler
L’applicazione deve permettere all’utente generale di
RFO8 UC1.9
selezionare la data per la configurazione dello scheduler
L’applicazione deve permettere all’utente generale di se-
RFO9 lezionare la ripetibilità dello scheduler in base alla data UC1.11
impostata
L’applicazione deve permettere all’utente generale di
RFO10 UC1.12
salvare la configurazione dello scheduler
L’applicazione deve permettere all’utente generale di
RFO11 UC1.14
tornare alla pagina iniziale
L’applicazione deve mostrare all’utente l’ultima configura-
RFF12 UC.15
zione impostata, se esistente
L’utente deve visualizzare i messaggi degli errori che si
UC1.2 UC1.4 UC1.6
RFD13 verificano durante la compilazione della configurazione
UC1.8 UC1.10 UC1.13
dello scheduler
L’applicazione deve permettere all’utente generale di vi-
RFO14 sualizzare i risultati della configurazione dello scheduler in UC2
una tabella
L’applicazione deve permettere all’utente generale di
RFO15 UC2
inserire i filtri per la visualizzazione dei risultati in tabella
L’applicazione deve permettere all’utente generale di
RFO16 inserire la chiave nella sezione filtri della pagina di UC2.1
visualizzazione dei risultati
L’applicazione deve permettere all’utente generale di inseri-
RFO17 re la città nella sezione filtri della pagina di visualizzazione UC2.3
dei risultati
L’applicazione deve permettere all’utente generale di in-
RFO18 serire la data di inizio nella sezione filtri della pagina di UC2.5
visualizzazione dei risultati18 CAPITOLO 3. ANALISI DEI REQUISITI
Id
Descrizione Use Case
Requisito
L’applicazione deve permettere all’utente generale di in-
RFO19 serire la data di fine nella sezione filtri della pagina di UC2.7
visualizzazione dei risultati
L’applicazione deve permettere all’utente generale, nella
RFO20 pagina di visualizzazione dei risultati dello scheduler, di UC2.9
visualizzare i risultati in una tabella
L’applicazione deve permettere all’utente generale, nella
RFO21 pagina di visualizzazione dei risultati dello scheduler, di UC2.9.1
visualizzare il titolo dell’annuncio
L’applicazione deve permettere all’utente generale, nella
RFO22 pagina di visualizzazione dei risultati dello scheduler, di UC2.9.1
visualizzare la data di pubblicazione dell’annuncio
L’applicazione deve permettere all’utente generale, nella
RFO23 pagina di visualizzazione dei risultati dello scheduler, di UC2.9.1
visualizzare il luogo di lavoro
L’applicazione deve permettere all’utente generale, nella
RFO24 pagina di visualizzazione dei risultati dello scheduler, di UC2.9.1
visualizzare l’azienda che ha proposto l’annuncio di lavoro
L’applicazione deve permettere all’utente generale, nella
RFO25 pagina di visualizzazione dei risultati dello scheduler, di UC2.9.1
visualizzare il sito web riguardante l’annuncio di lavoro
L’applicazione deve permettere all’utente generale, nella
RFO26 pagina di visualizzazione dei risultati dello schedule,r di UC2.9.1
visualizzare il testo che riassume l’annuncio di lavoro
L’applicazione deve permettere all’utente generale, nella
pagina di visualizzazione dei risultati dello scheduler, di vi- UC2.2 UC2.4 UC2.6
RFD27
sualizzare gli eventuali errori commessi nella compilazione UC2.8
dei form nella sezione dei filtri
Tabella 3.1: Requisiti Funzionali3.7. REQUISITI DI VINCOLO 19
3.7 Requisiti di Vincolo
Id
Descrizione
Requisito
L’applicazione deve essere sviluppata utilizzando il
RVO1
framework Angular
RVO2 L’applicazione va testata tramite Json-server
L’applicazione va sviluppata utilizzando la libreria
RVF3
Bootstrap
RVF4 L’editor di riferimento è Visual Studio Code
L’applicazione deve essere sviluppata utilizzando il
RVO5
linguaggio di programmazione TypeScript
Tabella 3.2: Requisiti di Vincolo20 CAPITOLO 3. ANALISI DEI REQUISITI
3.8 Requisiti di Qualità
Id
Descrizione
Requisito
L’interfaccia grafica deve rispettare le indicazioni suggerite
RQO1
dall’azienda
La stagista deve rispettare i tempi fissati nel piano di
RQO2
lavoro
RQD3 Il sito deve favorire la User Interface e la User Experience
Lo sviluppo del front-end deve permettere una facile
RQD4
integrazione con la parte di back-end
Tabella 3.3: Requisiti di QualitàCapitolo 4
Tecnologie e strumenti utilizzati
In questo capitolo vengono presentate le tecnologie e gli strumenti utilizzati durante la
progettazione e lo sviluppo del front-end.
4.1 Introduzione
La maggior parte del progetto è focalizzata sul framework Angular, usato assieme
all’editor di codice Visual Studio Code. La scelta di utilizzare Angular per sviluppare
un’applicazione web è stata effettuata dal tutor aziendale invece la scelta delle altre
tecnologie sono state a carico della stagista.
L’utilizzo del framework Angular ha reso obbligatorio l’utilizzo di alcune tecnologie
integrate in esso come ad esempio il linguaggio di programmazione TypeScript e la
tecnologia NPM.
Di seguito è riportata una descrizione delle principali tecnologie e degli strumenti
utilizzati durante durante il periodo di stage.
4.2 Ambiente di sviluppo
Il percorso di stage è stato sviluppato su un sitema operativo Mac.
4.2.1 Visual Studio Code
Figura 4.1: Logo Visual Studio Code
2122 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
Visual Studio Code è un editor di codice sorgente sviluppato da Microsoft per Windows,
Linux e macOS. Esso include supporto per il debugging, un controllo per Git integrato,
Syntax highlighting, IntelliSense, Snippet e refactoring del codice. Visual Studio Code
è basato su Electron, un framework con cui è possibile sviluppare applicazioni Node.js.
Durante il periodo di stage la stagista ha deciso di utilizzare come IDE Visual Studio
Code perchè:
∗ Supporta totalmente il framework Angular, facilitandone l’utilizzo;
∗ È completamente gratuito;
∗ È utilizzato nella maggior parte dei tutorial che sono stati seguiti per l’apprendi-
mento.
Valide alternative a Visual Studio Code sono:
∗ Web Storm, ottimo editor per Angular attraverso il quale è possibile compilare
il codice TypeScript in JavaScript senza fare affidamento a plug-in esterni, però
presenta lo svantaggio di essere a pagamento.
∗ Atom, è un editor di testo gratuito, sviluppato da GitHub che permette tutte le
funzionalità degli altri editor di testo oltre ad un ambiente di sviluppo altamente
personalizzabile.
4.3 Strumenti di versionamento
Git
Figura 4.2: Logo Git
Il versionamento del codice del progetto Sync Lav è avvenuto attraverso l’utilizzato
di una repository privata, versionata tramite il Version Control System (VCS) Git.
Il Version Control System (VCS) Git ha permesso a entrambi i sviluppatori di col-
laborare sullo stesso progetto mantenendo il codice in un unico posto e di gestire
un progetto mantenendo il controllo del codice sorgente e della sua storia. Per non
creare una situazione di confusione durante i merge è stato molto utile il servizio
Git Flow offerto da Git. Il Git Flow permette di avere un flusso organizzativo dei
branch, dei loro scopi e delle loro funzioni. Attraverso il Git Flow il ramo Master,4.4. LINGUAGGI E FRAMEWORK 23
che rappresenta il codice attualmente in produzione, non viene mai modificato ma-
nualmente da nessuno. Pure il ramo Develop che rappresenta il ramo di sviluppo
non viene mai modificato. Le modifiche vengono inserite attraverso la creazione di
un Feature branch. Il Feature branch è un ramo che parte da Develop ed in esso
viene riunificato al termine della modifica dul codice. La particolarità dei Feature
branch è che, una volta chiusi, essi si andranno a riunire automaticamente sia in
Develop che in Master. Seguendo questo schema di sviluppo si evitano la maggior
parte delle complicazioni dovute ai merge e si mantiene un flusso sufficientemente solido.
4.4 Linguaggi e framework
4.4.1 Il framework Angular
Figura 4.3: Logo Angular
Per lo sviluppo del front-end è stato utilizzato Angular, uno dei framework più uti-
lizzati nella creazione di applicazioni web open source. Il linguaggio di programmazione
di Angular è TypeScript mentre per la versione precedente, AngularJS, è JavaScript.
Le applicazioni sviluppate in Angular vengono eseguite interamente dal web browser
dopo essere state scaricate dal web server. Questo comporta il risparmio di dover
spedire indietro la pagina web al web server ogni volta che c’è una richiesta di azione
da parte dell’utente.
Il codice generato da Angular gira su tutti i principali web browser moderni quali
Chrome, Miscrosoft Edge, Opera, Firefox, Safari ed altri. Angular è stato progetta-
to per fornire uno strumento facile e veloce, per sviluppare applicazioni che girano
su qualunque piattaforma inclusi smartphone e tablet, infatti le applicazioni web in
Angular in compilazione con il toolkit open sourse Bootstrap diventano responsive,
ossia il design del sito web si adatta in funzione alle dimensioni del dispositivo utilizzato.
La creazione dell’ambiente di sviluppo per la realizzazione di un nuovo progetto
è un’operazione che potrebbe risultare complicata a causa della quantità di pachetti
software da integrare e per la definizione di diversi aspetti che potrebbero cambiare
nel tempo. Perciò per semplificare l’attività di setup iniziale dell’ambiente di sviluppo,
il team di Angular ha sviluppato Angular CLI, un ambiente a riga di comando per
creare la stuttura di un’applicazione Angular già configurata.24 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
4.4.2 Panoramica dell’architettura Angular
Angular è composto da diversi elementi che messi insieme formano un’applicazione, di
questi i principali sono i moduli, i componenti e i servizi.
Figura 4.4: Architettura ad alto livello di Angular
Moduli
I moduli possono essere considerati come i mattoni di un’applicazione Angular che
forniscono un’ambiente di compilazione per i componenti. Ogni applicazione contiene
un modulo radice, considerato il punto di partenza dell’applicazione, che caricandosi
permette l’avvio di tutti i componenti dell’applicazione.
Ciascun modulo può importare funzionalità di altri moduli ed esportare le proprie
funzionalità. L’organizzazione del codice in moduli aiuta nella gestione di codice
complesso e favorisce la riusabilità.
Per riuscire a comprendere meglio il concetto di modulo viene riportato il codice
dell’AppModule generato da Angular CLI.
Figura 4.5: AppModule4.4. LINGUAGGI E FRAMEWORK 25
Come si può osservare un modulo è una classe identificata da un decoratore
@NgModule, che specifica diverse proprietà:
∗ declaration: specifica i componenti che appartengono al modulo;
∗ imports: contiene i moduli necessari per i componenti dichiarati;
∗ providers: dichiara tutti i servizi per renderli accessibili in tutte le parti dell’ap-
plicazione;
∗ bootstrap: specifica la vista principale dell’applicazione;
Componenti
I componenti definiscono le viste della nostra applicazione, un insieme di elementi
schermo tra i quali Angular sceglie durante l’esecuzione e modifica in base al codice e
alla logica del programma. In un’applicazione Angular esiste sempre un componente
radice che contiene la struttura base del sito e che per convenzione prende il nome
di AppComponent. Ogni componente definisce una classe che contiene i dati e la
logica dell’applicazione ed è associato a un modello HTML che definisce una vista da
visualizzare. Per riuscire a comprendere meglio il concetto di modulo viene riportato il
codice dell’AppComponent generato da Angular CLI.
Figura 4.6: AppComponent
Anche la classe component contiene un decoratore, @Component, che la identifica e
di cui specifica le seguenti proprioetà:
∗ selector : selettore che comunica ad Angular la creazione e l’inserimento di
un’istanza di questo componente ovunque trovi il tag corrispondente nel file
HTML;
∗ templateUrl : percorso relativo al modulo del file HTML di questo componente;
∗ styleUrls: percorso relativo al modulo del file CSS di questo componente.26 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
Two-way data binding
Figura 4.7: Esempio del meccanismo two-way data binding
Nell’immagine riportata si può notare un meccanismo molto importante supportato
da Angular, il two-way data binding, utilizzato per far comunicare un componente con
il proprio template. Il two-way data binding è composto da:
∗ Event binding: aggiornamento dei dati applicativi in seguito ad azioni di input
dell’utente;
∗ Property binding: interpolazione dei dati di un componente visualizzabili nella
view.
Servizi
I componenti usano i servizi, i quali forniscono specifiche funzionalità che non sono
direttamente collegate con le viste come ad esempio la gestione della comunicazione
con i server e il recupero dei dati da esso. Tali servizi vengono iniettati nei componenti
come delle dipendenze, rendendo il codice modulare, riutilizzabile ed efficiente. Ogni
servizio utilizza il decoratore @Injectable che permette ai componenti di includere il
servizio per poterlo utilizzare.
Dependency injection
Il meccanismo di dependency injection è un Design pattern della Programmazione
orientata agli oggetti il cui scopo è quello di semplificare lo sviluppo e migliorare la
testabilità di software di grandi dimensioni.
Angular include un suo meccanismo di dependency injection davvero solido e molto
flessibile, il cui utilizzo si riassume in tre semplici passi: si crea il servizio, si definisce
un injector e si inietta la dipendenza dove necessario. Le dipendenze vengono iniettate
definendole nei parametri del costruttore di un componente, queste dipendenze vengono
poi fornite al componente solamante quando la classe viene istanziata.
Vantaggi e svantaggi
Ho trovato molto utile l’utilizzo del framework Angular principalmente perchè impone
una logica chiara nell’organizzazione del codice, quindi c’è un rischio meno elevato
di andare in contro a codice confusionario e disordinato. È supportato dalla maggior
parte dei browser e comprende un grande numero di funzionalità aggiuntive utili che
possono essere integrate facilmente.
Uno svantaggio è presente nell’esperienza iniziale di utilizzo più complessa: per lanciare
un’applicazione è necessario installare la CLI, ed impostare un insieme di parametri.
Come detto in precedenza Angular è stato scritto utilizzando TypeScript, quindi è
necessario anche l’apprendimento di questo linguaggio. Nel complesso il framework
Angular fa utilizzo di molti elementi che ne facilitano l’utilizzo ma che rallentano la4.4. LINGUAGGI E FRAMEWORK 27
comprensione iniziale. Per evitare questo sforzo di apprendimento iniziale una libreria
molto diffusa nello lo sviluppo di applicazioni web è React.
4.4.3 Alternative ad Angular
Una delle principali e più diffuse tecnologie per lo sviluppo di web application è React.
React è una libreria JavaScript, open source sviluppata da Facebook nel 2013. React
consiste in un apprendimento più veloce e semplice e la principale differenza rispetto ad
Angular è che, essendo una libreria e non framework, oltre al core dobbiamo aggiungere
librerie di terze parti per realizzare specifiche parti delle nostre applicazioni.
Un’altra importante alternativa ad Angular è Vue.js, framework JavaScript opensource.
Vue.js è il più immediato da capire e il più facile da apprendere, persenta il vantaggio
di avere pagine web che si aggirano sui 2MB, sono le più leggere contro i 100Kb di
React e 500Kb di Angular. Ulteriore vantaggio è il passaggio da una versione alla
successiva il quale non crea pesanti problemi di compatibilità al contrario Angular.
Il principale svantaggio di Vue.js è che essendo così semplice da scrivere ed avendo
un’architettura poco complessa è più difficile da testarlo in modo automatico.
4.4.4 Typescript
Figura 4.8: Logo TypeScript
Essendo Angular scritto in TypeScript, per poter scrivere il codice dell’applicazione è
stato necessario l’apprendimento di questo nuovo linguaggio. TypeScript è un linguaggio
di programmazione open source sviluppato da Microsoft, che mira a facilitare lo sviluppo
di applicazioni su larga scala scritte in JavaScript. TypeScript rispetto a JavaScript
aggiunge i concetti di classi, moduli, interfacce, generics e la tipizzazione statica
opzionale. È un superset di JavaScript: tutto il codice JavaScript è codice TypeScript
valido quindi può essere aggiunto facilmente a qualsiasi progetto. Il codice TypeScript
sviluppato viene successivamente ricompilato in JavaScript per poter essere interpretato
da browser o app.28 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
4.4.5 Npm
Figura 4.9: Logo Npm
Node Package Manager (NPM) è il principale software utilizzato per gestire i moduli
di Node.js e consente di condividere il codice per problemi tipici tra gli sviluppatori
JavaScript. La filosofia alla base di NPM è quella che se un problema è stato già
risolto da altri programmatori non ha senso doverlo sviluppare per conto proprio, è
possibile utilizzare la soluzione condivisa messa a disposizione di tutti. NPM oltre
a consentire il riuso del codice, consente di tenerlo costantemente sotto controllo in
modo da aggiornarlo se dovesse essere migliorato. NPM suddivide il codice in package
o moduli. Un package è una directory che contiene uno o più file messi insieme ad un
file chiamato package.json, che contiene dei dati relativi al pacchetto. In generale una
tipica applicazione è costituita da decine o migliaia di package.
Npm è utilizzato dal framework Angular nello sviluppo di Angular CLI, la quale
permette di avere un’applicazione Angular già configurata.
4.4.6 JSON Server
Figura 4.10: Logo Json Server
Nella prima fase della progettazione per non rallentare o bloccare lo sviluppo del
front-end a causa della mancanza di un back-end è stato necessario creare una fake api
rest con Json Server. L’utilizzo di Json server è stato consigliato dal tutor aziendale e
attraverso questo si sono simulate le chiamate GET e POST necessarie.
Json server è risultato uno strumento che ha facilitato l’esecuzione del lavoro inoltre è
configurabile in maniera veloce e chiara ed è facile da usare.4.4. LINGUAGGI E FRAMEWORK 29
4.4.7 Bootstrap
Figura 4.11: Logo Bootstrap
Bootstrap è il framework più famoso per lo sviluppo di siti web responsive e applicazioni
mobile. Esso contiene modelli di progettazione basati su HTML, CSS e JavaScript.
Inoltre è molto vantaggioso scegliere Bootstrap sin dall’inizio in quanto permette di
creare molto velocemente la struttara base del front-end.
In seguito all’indicazione da parte del tutor aziendale sull’utilizzo di questo framework,
la configurazione e l’utilizzo sono risultati molto semplici, inoltre è un buon punto di
riferimento quando non si sa bene come configurare un determinato elemento.
Bootstrap è molto più leggero degli altri framework e ha un design originale e semplice.
Attraverso l’utilizzo di Bootstrap si ha un responsive design, cioè un design che si
adatta dinamicamente a qualsiasi dispositivo e ciò è di fondamentale importanza per
questa fase storica che vede gli utenti navigare sul web da dispositivi molto diversi,
che vanno dal computer di casa allo smartphone di ultima generazione, passando per i
vari tablets. Infatti il responsive design è diventato praticamente obbligatorio.
Importanti alternative a Bootstrap sono i framework Foundation e Semantic UI.
∗ Foundation è un css framework open source molto stabile e leggero, il più cono-
sciuto a seguire di Bootstrap, esso è uno strumento adatto per la realizzazione
di layout responsive. Uno dei suoi vantaggi è la versatilità: esso è ottimo per la
realizzazione di template per email, web app mobile first e siti web.
∗ Semantic UI, come suggerisce il nome, è un framework che ha lo scopo di
rendere il processo di creazione dei siti Web più semantico. La sua principale
caratteristica è quindi di avere un codice molto leggibile chiamato human friendly
HTML. Semantic UI presenta, a differenza di Bootstrap, una struttura dei
componenti molto più complessa a causa della molteplicità dei stili che mette a
disposizione e che può creare confusione.Capitolo 5
Progettazione
In questo capitolo viene presentata la struttura delle classi creata durante la fase di
progettazione e viene dato un riassunto dei concetti appresi, utili per il design dell’in-
terfaccia grafica.
5.1 Struttura delle classi di Sync Lav
Dopo uno studio approffondito di Angular e le indicazioni ricevute dal tutor interno è
iniziata la progettazione delle classi, durante la quale, in alcuni momenti , c’è stato un
confronto con l’altro membro del progetto sugli aspetti di comune interesse.
Infine si è giunti al seguente diagramma che rappresenta la stuttura principale delle
classi del front-end.
Figura 5.1: Diagramma delle classi
3132 CAPITOLO 5. PROGETTAZIONE
Come si può osservare dalla figura la classe AppModule è composta principalmete
da tre classi che rappresentano tre componenti:
∗ La classe PaginaIniziale la quale si occupa di permettere l’accesso alle altre
due pagine del sito;
∗ La classe ConfigurazioneScheduler la quale, come si può intuire dal nome, si
occuppa della configurazione dello scheduler, quindi della compilazione dei campi
form neccessari e successivamente gestisce il salvataggio della configurazione
impostata. Il salvataggio e l’invio dei dati al server avviene attraverso l’iniez-
zione della classe servizio SchedulerService mediante l’utilizzo della depencency
injection;
∗ La classe RisultatiScheduler è composta da una sezione di configurazione dei
filtri da applicare a una tabella sottostante che mostra i risultati dello scheduler.
La classe si occupa dell’invio della configurazione dei filtri allo server, e della
ricezione degli annunci da mostrare in tabella. La comunicazio con il server
avviene attraverso l’utilizzo dalla classe servizio AnnunciServer, anche questa
iniettata nella classe RisultatiScheduler mediante l’utilizzo della dependency
injection.
5.2 User Experience
Figura 5.2: User Experience
Con il termine User Experience (esperienza d’uso) s’intende ciò che una persona
prova durante l’utilizzo di un sito web, un insieme complesso tra esperienza, emozioni
e sensazioni che si percepiscono durante la navigazione in un sito web.
A determinare la User Experience concorrono diversi fattori: l’usabilità del sito web, il
design e la grafica, l’accessibilità, la strategia di comunicazione, i contenuti ed anche
la Search Engine Optimization (SEO), indispensabile per far sì che il sito web sia
rintracciabile sui motori di ricerca.
L’obiettivo finale che si cerca di raggiungere attraverso la User Experience è quello di5.2. USER EXPERIENCE 33
migliorare l’esperienza dell’utente fornendogli esattamente ciò che desidera in modo
rapido senza correre il rischio di andare in contro a complicazioni che potrebbero
generare frustrazione nell’utente e successivo abbandono del sito.
Un sito web capace di assicurare una User Experience positiva deve possedere delle
caratteristiche ben precise. In particolare, il sito web deve essere:
∗ Usabile: L’utente deve riuscire a navigare con facilità, raggiungendo i suoi
obiettivi senza difficoltà.
∗ Accessibile: Il sito deve essere comprensibile a tutte le categorie di utenti in
ogni punto della sua struttura e in qualsiasi momento.
∗ Funzionale: Sia lo sviluppatore sia l’utente deve essere in grado, attraverso il
sito, di raggiungere i proprio obiettivi.
∗ Attraente: L’estetica del sito deve essere bella e piacevole alla vista dell’utente.
Un sito che possiede tutte le caratteristiche necessarie per regalare un’ottima
esperienza d’utente ma non è attrante, nei maggiori dei casi, non trasmette
sensazioni positive all’utente.
∗ Utile: L’utente attraverso la navigazione nel sito deve ottenere un ricavo,
qualcosa di concreto e utile altrimenti è improbabile il ritorno sullo stesso sito.
∗ Completo: Un sito incompleto crea disorientamento, quindi la struttura del
sito e tutte le informazioni che vengono offerte devono essere complete ottenendo
così la fiducia di chi lo utilizza.
∗ Chiaro: L’utente deve impiegare poco tempo per comprendere dove si trova,
l’utilità del sito e cosa questo gli può offrire.
∗ Rintracciabile: Per essere rintracciabile il nostro sito deve comparire tra i primi
10 risultati di una ricerca sul browser, la quale contiene le parole chiave del sito.
∗ Interattivo: Un sito web per riuscire a trasmettere una buona user experience
deve riuscire a diminuire le distanze tra lo sviluppatore e l’utente, cercando ad
esempio di consentire un dialogo per risolvere velocemente eventuali difficoltà o
richieste.
5.2.1 Target
Per riuscire a offrire una buona user exerience lo sviluppatore ha il fondamentale
compito di indentificare la categoria di utenti(target) che andranno ad utilizzare il suo
sito. Questo aspetto è importante per riuscire a soddisfare tutti i bisogni e le richieste
dell’utente e rispondere a tutte le domande che ci si può porre durante la progettazione
come ad esempio: Di cosa ha bisogno? Cosa desidera? Cosa si aspetta di trovare sul
sito web? E cosa no? Come si può soddisfarlo? E come si può sorprendere? In poche
parole l’utente è il soggetto del sito web e tutto ruota attorno ad esso.Puoi anche leggere
