Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita" Corso di Laurea in Informatica
Applicazione web per la gestione automatica degli Objectives & Key Results nei processi aziendali
Tesi di laurea triennale
Relatore Prof. Armir Bujari
Laureando Nicolò Tartaggia
Anno Accademico 2018-2019 Nicolò Tartaggia: Applicazione web per la gestione automatica degli Objectives & Key Results nei processi aziendali, Tesi di laurea triennale, c Settembre 2019. Dedicato alla mia famiglia, che mi supporta da sempre.
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata di 330 ore, dal laureando Nicolò Tartaggia presso l’azienda Uqido Srl di Padova. Il progetto di stage prevedeva l’analisi, la progettazione e lo sviluppo di una piattaforma web per la gestione automatica e la visualizzazione dello stato di avanzamento degli OKR (Objectives & Key Results) aziendali. L’applicazione è stata pensata per un uso interno. Di conseguenza, solo i membri dell’azienda possono avere accesso a quest’ultima. Nello specifico, il prodotto è composto da due componenti principali: (i) modulo di back-end, struttura a microservizi per effettuare tutte le operazioni di interazione con il database, e (ii) modulo di front-end, applicazione Angular che utilizza le API REST esposte dal back-end per la modifica e l’aggiornamento degli OKR.
v
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Armir Bujari per la fiducia accordatami accettando il ruolo di relatore della mia tesi e per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
In seguito, desidero ringraziare tutto il team Uqido per la disponibilità dimostrata e per avermi dato la possibilità di vivere questa esperienza formativa.
Desidero ringraziare di cuore i miei genitori per il sostegno, il grande aiuto e per avermi permesso di raggiungere questo ambito traguardo. Consegno a loro virtualmente questo diploma di laurea, in segno di riconoscimento per gli sforzi sostenuti, non solo finanziari.
Infine desidero ringraziare i miei amici, su cui so di poter sempre contare, per le esperienze vissute insieme che hanno reso più piacevoli questi anni di studio.
Padova, Settembre 2019 Nicolò Tartaggia
vii
Indice
1 Introduzione 1 1.1 L’azienda ...... 1 1.2 Proposta di stage ...... 2 1.3 Metodo di lavoro ...... 2 1.3.1 Scrum ...... 2 1.3.2 Ciclo Scrum ...... 3 1.3.3 Pull Request and review ...... 4 1.4 Organizzazione del documento ...... 5 1.5 Convenzioni tipografiche ...... 6
2 Il progetto 7 2.1 Objectives & Keys Results ...... 7 2.2 Piattaforma per la gestione automatica degli OKR ...... 7 2.2.1 Caratteristiche degli utenti ...... 8 2.2.2 Moduli ...... 8 2.2.3 Funzionalità ...... 8 2.3 Requisiti ...... 9 2.3.1 Notazione ...... 9 2.3.2 Obiettivi fissati ...... 9
3 Tecnologie, strumenti di supporto e linguaggi 11 3.1 Tecnologie ...... 11 3.1.1 NodeJS ...... 11 3.1.2 Firebase ...... 14 3.1.3 Angular ...... 16 3.1.4 RxJS ...... 18 3.2 Strumenti di supporto ...... 18 3.2.1 Git ...... 19 3.2.2 GitHub ...... 19 3.2.3 Postman ...... 20 3.2.4 Trello ...... 20 3.2.5 Clockify ...... 21 3.2.6 Slack ...... 21 3.2.7 WebStorm ...... 21 3.3 Linguaggi per la codifica ...... 22 3.3.1 TypeScript ...... 22 3.3.2 HTML5 ...... 23 3.3.3 SCSS ...... 23
ix x INDICE
4 Analisi dei requisiti 25 4.1 Casi d’uso ...... 25 4.1.1 Attori ...... 25 4.1.2 Struttura ...... 25 4.1.3 Operazioni permesse ad un utente non autenticato ...... 26 4.1.4 Caso d’uso generale UCG1: gestione degli OKR ...... 28 4.2 Tracciamento dei requisiti ...... 47 4.2.1 Requisiti funzionali ...... 48 4.2.2 Requisiti di qualità ...... 50 4.2.3 Requisiti di vincolo ...... 51 4.3 Tracciamento requisiti - casi d’uso ...... 51
5 Progettazione architetturale 55 5.1 Back-end ...... 55 5.1.1 Struttura dei servizi ...... 58 5.1.2 I servizi ...... 58 5.1.3 Il database ...... 60 5.2 Front-end ...... 62 5.2.1 Struttura Angular ...... 63 5.2.2 I moduli ...... 63 5.2.3 I componenti ...... 64 5.2.4 I servizi ...... 65 5.2.5 I modelli ...... 65
6 Codifica 67 6.1 Back-end ...... 67 6.1.1 Elenco API REST esposte dal back-end ...... 67 6.1.2 Esempi di JSON ritornati dalle API ...... 69 6.2 Front-end ...... 70 6.2.1 Struttura dei modelli ...... 70 6.2.2 Servizi ...... 71 6.2.3 Screenshot dell’applicazione ...... 73 6.3 Verifica e validazione ...... 76 6.3.1 Verifica ...... 76 6.3.2 Analisi statica ...... 76 6.3.3 Analisi dinamica ...... 76 6.3.4 Validazione ...... 77
7 Conclusioni 79 7.1 Consuntivo finale ...... 79 7.2 Raggiungimento degli obiettivi ...... 80 7.3 Conoscenze acquisite e valutazione personale ...... 81 7.4 Sviluppi futuri ...... 81
Glossario 83
Bibliografia 87 Elenco delle figure
1.1 Logo di Uqido ...... 1 1.2 Ruoli di Scrum ...... 4 1.3 Ciclo Scrum ...... 4 1.4 Pull Request ...... 5
2.1 Obiettivi suddivisi per tipologia ...... 10
3.1 Logo Node.js ...... 11 3.2 Interazione client-server ...... 12 3.3 Flusso di una richiesta CORS ...... 14 3.4 Logo di Firebase ...... 14 3.5 Logo di Angular ...... 16 3.6 Logo di RxJS ...... 18 3.7 Logo di Git ...... 19 3.8 Logo di GitHub ...... 19 3.9 Logo di Postman ...... 20 3.10 Logo di Trello ...... 20 3.11 Logo di Clockify ...... 21 3.12 Logo di Slack ...... 21 3.13 Logo di WebStorm ...... 21 3.14 Logo di TypeScript ...... 22 3.15 Logo di HTML5 ...... 23 3.16 Logo di Sass ...... 23
4.1 Operazioni permesse ad un utente non autenticato ...... 26 4.2 UC1 - Autenticazione ...... 26 4.3 UCG1 - Operazioni per la gestione degli OKR ...... 29 4.4 UC3 - Operazioni per la gestione del quarter ...... 30 4.5 UC3.1 - Creazione di un quarter ...... 31 4.6 UC3.2 - Visualizzazione lista dei quarter disponibili ...... 32 4.7 UC3.2.1 - Visualizzazione di un quarter specifico ...... 33 4.8 UC4 - Operazioni per la gestione degli obiettivi ...... 35 4.9 UC4.1 - Inserimento di un nuovo obiettivo ...... 36 4.10 UC4.3 - Visualizzazione lista degli obiettivi ...... 37 4.11 UC4.3.1 - Visualizzazione obiettivo specifico ...... 37 4.12 UC5 - Operazioni per la gestione dei risultati chiave ...... 38 4.13 UC5.1 - Creazione di un risultato chiave ...... 39 4.14 UC5.3 - Visualizzazione lista dei risultati chiave ...... 40
xi 4.15 UC5.3.1 - Visualizzazione di un risultato chiave specifico ...... 41 4.16 UC6 - Operazioni per la gestione delle metriche ...... 42 4.17 UC6.1 - Inserimento di una nuova metrica ...... 43 4.18 UC6.3 - Visualizzazione di una lista di metriche ...... 45 4.19 UC6.3.1 - Visualizzazione metrica specifica ...... 45 4.20 UC7 - Logout ...... 47
5.1 Struttura generale a layer dell’applicazione ...... 55 5.2 Architettura monolitica vs architettura a microservizi ...... 57 5.3 Architettura del modulo di back-end ...... 58 5.4 Struttura delle collezioni del database ...... 60 5.5 Architettura di un’applicazione Angular ...... 62 5.6 Architettura del modulo di front-end ...... 63
6.1 Pagina di autenticazione ...... 73 6.2 Pagina principale quarter ...... 74 6.3 Sidenav laterale ...... 74 6.4 Dialog aggiunta risultato chiave ...... 75 6.5 Pagina delle metriche ...... 75
Elenco delle tabelle
4.1 Tabella del tracciamento dei requisti funzionali ...... 50 4.2 Tabella del tracciamento dei requisti di qualità ...... 50 4.3 Tabella del tracciamento dei requisti di vincolo ...... 51
5.1 Tabella delle operazioni CRUD ...... 57 5.2 Tabella dei servizi esposti dal back-end ...... 59 5.3 Tabella dei campi dato di ogni documento ...... 61
6.1 API REST esposte dai microservizi ...... 69 6.2 Metodi esposti dal servizio StateService ...... 73
7.1 Tabella degli obiettivi obbligatori ...... 80 7.2 Tabella degli obiettivi desiderabili ...... 80 7.3 Tabella degli obiettivi facoltativi ...... 81
xii ELENCO DELLE TABELLE xiii
Capitolo 1
Introduzione
L’attività di stage si è svolta presso l’azienda Uqido Srl di Padova. Nata nel 2010, essa è una software house B2Bg operante nel settore ICTg e delle new technologies, all’avanguardia nell’impiegare tutte le tecnologie disponibili sul mercato, o ad inventarne di nuove, per creare soluzioni semplici ed efficaci. Di seguito una breve descrizione del contesto aziendale e del progetto affrontato durante questo periodo di stage. Alla fine del capitolo è presente una piccola digressione sull’organizzazione del documento.
1.1 L’azienda
Figura 1.1: Logo di Uqido
Le macro aree in cui Uqido opera sono:
∗ Sviluppo software gestionali ad hoc;
∗ Campagne di digital marketing;
∗ Sviluppo e gestione applicazioni per iOS, Android e Windows Phone;
∗ Ricerca e sviluppo settore biomedicale;
∗ Sviluppo VRg e ARg. Il team di Uqido è composto da circa 35 persone. Il carattere aziendale e di ognuno dei suoi componenti è dinamico ed intraprendente e grazie agli importanti know-how tecnici sedimentati nel proprio staff e alle numerose esperienze maturate in questi anni di attività, Uqido garantisce prodotti di elevata qualità ed affidabilità. Il team di Uqido può essere suddiviso in diversi gruppi in base all’area tematica che
1 2 CAPITOLO 1. INTRODUZIONE ognuno ricopre: team sviluppo, che comprende sia sviluppatori web che mobile; team XRg, che comprende sviluppatori che si occupano di realtà aumentata e realtà virtuale attraverso il motore 3D Unity; team design, che comprende grafici, web designer e UI/UX designer; e team marketing e comunicazioni. La costante cooperazione tra i diversi team è garantita dalla supervisione dei fondatori e dei vari project manager.
1.2 Proposta di stage
Uqido ha inserito degli obiettivi aziendali da raggiungere con lo scopo di migliorare le conoscenze interne, l’impatto nel territorio e la qualità del lavoro svolto, quantificabili con metriche. L’insieme di obiettivi e metriche è identificato con l’acronimo OKR (Objectives & Key Results). La proposto di stage prevede la progettazione e lo sviluppo di un’applicazione web attraverso il frameworkg Angular che permetta di consultare tali metriche e di poterle aggiornare qualora non vi sia un sistema automatico che possa farlo in modo autonomo. Inoltre, è richiesta l’implementazione di microservizi, con lo scopo di fornire il back-endg per l’applicazione web e di automatizzare la registrazione delle metriche che si prestano a tale operazione.
1.3 Metodo di lavoro
In Uqido viene adottato il modello di ciclo di vita agile1, attuato attraverso la metodologia Scrum. Questo processo presenta caratteristiche che sposano ottimamente la dinamicità con cui l’intero team opera. Scrum è, a tutti gli effetti, un framework agileg che fornisce le linee guida per lo sviluppo e il sostegno di progetti complessi. Le persone vengono divise in team, in cui ognuno ha ruoli e capacità differenti ma tutti concorrono per raggiungere gli stessi obiettivi.
1.3.1 Scrum Scrum2 si basa sulla teoria del controllo empirico dei processi, o empirismo. L’empirismo afferma che la conoscenza deriva dall’esperienza e che le decisioni si basano su ciò che si conosce. Scrum utilizza un approccio iterativo ed incrementale per ottimizzare la prevedibilità ed il controllo del rischio. Scrum abbraccia i concetti chiave dello sviluppo agile:
∗ Persone e interazioni più che processi e strumenti;
∗ Software funzionante più che documentazione ampia;
∗ Collaborazione con il cliente più che negoziazione del contratto;
∗ Risposta al cambiamento più che seguire un piano.
1Metodologia agile. url: https://medium.com/geekandjob- blog/scrum- cos%C3%A8- e- come- funziona-metodologia-agile-7c8988feec01. 2Metodologia Scrum. url: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum- Guide-Italian.pdf. 1.3. METODO DI LAVORO 3
I tre pilastri su cui Scrum si basa sono:
∗ Trasparenza: i responsabili dell’esito del processo devono essere sempre aggiornati sui risultati significativi ottenuti. La trasparenza richiede che tali aspetti siano definiti da uno standard comune in modo che gli osservatori condividano una comune comprensione di ciò che viene visto (ad esempio linguaggio comune per una conoscenza condivisa);
∗ Ispezione: chi utilizza Scrum deve ispezionare frequentemente gli artefatti prodotti con lo scopo di rilevare deviazioni indesiderate. Tali ispezioni devono essere programmate, in modo tale da non intralciare il lavoro stesso. Esse, infatti, mostrano la loro utilità quando vengono eseguite diligentemente da chi ha l’abilità e la competenza necessaria per effettuarle rispetto ad un particolare stadio del lavoro;
∗ Adattamento: il responsabile delle ispezioni verifica gli aspetti di un processo. Se questi risultano al di fuori dei limiti accettabili allora il processo o il materiale processato devono essere adattati il più rapidamente possibile, per ridurre al minimo un’ulteriore deviazione.
Lo Scrum team è formato da product owner, team di sviluppo (development team) e scrum master. Questo modello si è rivelato nel tempo molto efficace per garantire flessibilità, creatività e produttività.
∗ Product Owner: singola persona che ha il compito di coordinare il team di sviluppo per massimizzare il valore del prodotto risultante dal lavoro di quest’ultimo. Il product owner raccoglie la voce degli stakeholdersg (clienti, management e chiunque abbia un interesse nel prodotto), le necessità dell’utente finale, i requisiti del mercato e sulla base di questi elementi stabilisce le priorità di sviluppo per il development team;
∗ Scrum Master: leader a servizio (servant-leader) del development team. Colui che ricopre questo ruolo possiede una conoscenza approfondita della metodologia Scrum e si assicura che il team comprenda e segua le caratteristiche che la caratterizzano;
∗ Team di sviluppo: squadra composta da un numero contenuto di professionisti che portano concretamente a termine uno Sprint. Il gruppo è autogestito, perché decide in autonomia come sviluppare le funzionalità individuate dal product owner, e cross-funzionale, perché contiene al proprio interno tutte le competenze e le funzioni necessarie per portare a termine i task.
1.3.2 Ciclo Scrum Scrum ruota attorno a cosiddetto sprint, un periodo di 2-4 settimane in cui viene realizzato un incremento di prodotto potenzialmente rilasciabile. Il product owner studia e crea una lista di funzionalità, chiamata product backlog, che rappresenta tutte le features desiderate dal cliente. Questi costituiscono i requisti di uno sprint. Lo Scrum team, all’inizio di ogni sprint, sceglie dalla lista un certo numero di funzionalità da implementare. Questo evento è detto sprint planning. Esso è limitato temporalmente (time-boxed) ad un massimo di otto ore per uno sprint di un mese. Lo Scrum master si assicura che ogni membro rispetti i tempi previsti. Inoltre, quotidianamente di svolge 4 CAPITOLO 1. INTRODUZIONE
Figura 1.2: Ruoli di Scrum (http://ns2.cooltest.info/scrum-roles/scrum-roles-5) una breve riunione di circa 15 minuti (daily Scrum) per valutare i progressi fatti e, di conseguenza, pianificare il lavoro da svolgere successivamente. Alla fine dello sprint si tiene lo sprint review, un incontro informale per ispezionare l’incremento e adattare, se necessario, il product backlog. Durante lo sprint review, Scrum master, Scrum team e stakeholders collaborano su ciò che è stato fatto durante lo sprint. Il risultato dello sprint review è un product backlog revisionato che definisce gli elementi selezionati per il prossimo sprint. Dopo lo sprint review si tiene lo sprint retrospective, una riunione formale in cui lo Scrum team analizza lo sprint appena concluso, individua possibili miglioramenti che possono essere fatti e pianifica il modo in cui implementarli nello sprint successivo, sotto la supervisione dello Scrum master. Alla fine di questa ultima riunione, si ricomincia da capo con un nuovo sprint planning, finché il progetto non è concluso.
Figura 1.3: Ciclo Scrum (https://www.knowledgehut.com/blog/agile/from-creation-to-execution-how-sprint- backlog-helps-scrum-teams)
1.3.3 Pull Request and review
Uqido utilizza Git come sistema di versionamento (VCSg) e GitHub e GitLab come servizi di hostingg per i progetti software. 1.4. ORGANIZZAZIONE DEL DOCUMENTO 5
Git presenta diverse caratteristiche, tra le quali spicca quella del branching3. Molte volte è necessario eseguire degli sviluppi paralleli su un progetto. In questo modo si riesce ad avere un maggior controllo sullo sviluppo di nuove funzionalità che devono essere testate prima di entrare in produzione. La versione stabile del prodotto viene mantenuta tale e verrà aggiornata solo quando le nuove features saranno completate. Per far sì che le nuove modifiche vengano accorpate definitivamente, per ognuna di esse deve essere creata una pull request. Questa è una richiesta di revisione, da parte dell’autore della nuova feature, di tutti i cambiamenti apportati al codice sorgente. Un membro del team di sviluppo di cui fa parte l’autore, si prende carico della richiesta. Se non vengono riscontrati problemi, il branch viene unito al ramo principale, altrimenti la pull request viene respinta segnalando i punti critici da risolvere.
Figura 1.4: Pull Request (https://kenya-tech.com/2019/01/07/pull-request-on-git-and-github-for-beginners- part-iii-tutorial)
1.4 Organizzazione del documento
Il primo capitolo fornisce una panoramica generale sullo scenario aziendale all’interno del quale si è svolto il progetto di stage.
Il secondo capitolo descrive il progetto affrontato durante il periodo di stage, sottolineandone le caratteristiche principali.
Il terzo capitolo descrive tecnologie, strumenti di supporto e linguaggi di codifica utilizzati per lo sviluppo del progetto.
Il quarto capitolo presenta l’analisi dei requisiti.
Il quinto capitolo descrive la fase di progettazione architetturale, durante la quale è stata progettata l’architettura completa dell’applicazione.
Il sesto capitolo descrive la fase di codifica, durante la quale sono state implementate le funzionalità individuate attraverso l’analisi dei requisiti, e le attività di verifica e validazione.
3Branching. url: https://git-scm.com/book/it/v1/Diramazioni-in-Git-Cos-%C3%A8-un- Ramo. 6 CAPITOLO 1. INTRODUZIONE
Il settimo capitolo vengono riportate le considerazioni finali in merito al prodotto realizzato e all’attività di stage.
1.5 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; ∗ Per la prima occorrenza dei termini riportati nel glossario viene utilizzata la seguente nomenclatura: parolag; ∗ I nomi di funzioni e costrutti di un linguaggio di programmazione sono evidenziati con il carattere macchina da scrivere; ∗ i termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati con il carattere corsivo. Capitolo 2
Il progetto
2.1 Objectives & Keys Results
L’acronimo OKR (Objectives & Key Results) identifica un metodo per la definizione e la pianificazione di obiettivi e dei loro risultati, utilizzato da aziende di fama mondiale come Google, Intel, Linkedin e Amazon. I suoi elementi essenziali sono:
∗ Obiettivo: il traguardo da raggiungere da parte dell’azienda entro un periodo di tempo prestabilito. Esso deve essere ambizioso;
∗ Risultati chiave: le metriche che permettono di quantificare e di monitorare il raggiungimento di un determinato obiettivo. Esse devono essere SMART: Specifiche (Specific), Misurabili (Measurable), Raggiungibili (Achievable), Realistiche (Realistic) e con scadenza (Time-bound);
∗ Allineamento: una volta definiti obiettivi e risultati chiave, può diventare più facile per gli individui collegare i loro progetti con gli obiettivi organizzativi;
∗ Trasparenza: gli OKR sono pubblici a tutti i livelli aziendali. In altre parole, tutti hanno accesso agli OKR di tutti gli altri.
Gli OKR sono l’approccio ideale per le aziende che lavorano con le metodologie agili. Per loro natura, gli OKR consentono un ciclo di definizione di obiettivi più rapido, in genere ogni trimestre, detto quarter, in modo tale da adattarsi dinamicamente ai contesti e alle priorità dell’azienda. Ogni obiettivo contiene dai 3 ai 5 risultati chiave. L’utilizzo degli OKR si differenzia dalle classiche tecniche aziendali di definizione di obiettivi poiché lo scopo principale è quello di fissare traguardi molto ambiziosi. In questo modo, ogni membro di un team può testare la sue capacità per vedere quali sono i suoi limiti e per cercare di dare il meglio di sè, in molti casi andando oltre le sue aspettative.
2.2 Piattaforma per la gestione automatica degli OKR
Il progetto di stage nasce con lo scopo di creare una piattaforma per la gestione automatica degli Objectives & Keys Results. L’applicazione permette ad ogni membro di controllare lo stato di avanzamento di ogni obiettivo e di aggiornare i relativi risultati chiave. Inoltre è possibile effettuare operazioni di creazione, eliminazione o modifica di
7 8 CAPITOLO 2. IL PROGETTO obiettivi e chiavi. La piattaforma realizzata si pone come punto di riferimento dell’azienda per la gestione degli OKR, attuabile in qualsiasi momento e con qualsiasi dispositivo. Oltre al quarter corrente, è possibile analizzare periodi precedenti per vedere quali obiettivi sono stati raggiunti e quali sono rimasti incompleti. Questo permette di evidenziare sia i punti di forza dell’azienda, per i quali possono essere definiti obiettivi più complessi, sia i punti deboli, i quali obiettivi devono essere coerenti con le capacità del team aziendale.
2.2.1 Caratteristiche degli utenti Il prodotto si rivolge ad un utente generico e non ad uno nello specifico, in quanto qualunque membro dell’azienda può usufruire dei servizi offerti dalla piattaforma. In fase di analisi si è deciso di non avere alcuna gerarchia di utenti, o utenti con privilegi differenziati. Pertanto il prodotto prevede una sola tipologia di utente, ovvero l’utilizzatore finale.
2.2.2 Moduli L’architettura di base della piattaforma è composta da due moduli principali. L’interazione tra le due parti garantisce che ogni operazione effettuata non comporti errori:
∗ Back-end: espone i servizi RESTg che ricevono, elaborano e inviano dati in base alle richieste e aggiornano in automatico i dati memorizzati nel database;
∗ Front-endg: costituisce l’interfaccia della piattaforma, sviluppata attraverso il framework Angular. Essa utilizza le APIg REST esposte del back-end per effettuare tutte le operazioni di gestione degli OKR in seguito ad eventi scatenati dall’utente.
2.2.3 Funzionalità La realizzazione dei due moduli appena descritti ha portato allo sviluppo delle seguenti funzionalità esposte dell’applicazione:
∗ Gestione utenti:
– autenticazione tramite account Google aziendale. L’autenticazione di Firebaseg espone un SDKg per l’implementazione di questa funzionalità in modo semplice e veloce.
∗ Gestione quarter:
– creazione di un nuovo quarter; – visualizzazione lista di quarters fino ad ora creati; – selezione di un quarter; – visualizzazione grafico a torta con la percentuale di completamento di ogni obiettivo.
∗ Gestione obiettivi:
– creazione di un nuovo obiettivo; – eliminazione di un obiettivo; 2.3. REQUISITI 9
– visualizzazione lista di obiettivi di uno specifico quarter.
∗ Gestione risultati chiave:
– creazione di un nuovo risultato chiave; – eliminazione risultato chiave; – visualizzazione stato di avanzamento di un risultato chiave tramite progress bar; – visualizzazione lista di risultati chiave di uno specifico obiettivo.
∗ Gestione metriche di un risultato chiave:
– creazione di una nuova metrica; – eliminazione di una metrica; – visualizzazione lista di metriche di uno specifico risultato chiave.
2.3 Requisiti
Durante la stesura del piano di lavoro sono stati individuati una serie di obiettivi da soddisfare durante il periodo di stage.
2.3.1 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.
2.3.2 Obiettivi fissati Si è previsto lo svolgimento dei seguenti obiettivi:
∗ Obbligatori
– O01: implementazione funzionalità di base dell’applicazione tramite operazioni CRUD; – O02: studio, apprendimento e utilizzo del framework Angular per lo sviluppo dell’interfaccia dell’applicazione.
∗ Desiderabili
– D01: implementazione ulteriori funzionalità dell’applicazione sfruttando API di servizi esterni (ad esempio Github o Clockify); 10 CAPITOLO 2. IL PROGETTO
– D02: suite di test completo per il codice prodotto; – D03: documentazione completa.
∗ Facoltativi – F01: ulteriori modifiche all’applicazione.
Figura 2.1: Obiettivi suddivisi per tipologia Capitolo 3
Tecnologie, strumenti di supporto e linguaggi
Questo capitolo ha lo scopo di descrivere le tecnologie, gli strumenti di supporto e linguaggi utilizzati durante lo sviluppo. La scelta di includere determinati componenti da una lista di possibili opzioni deriva da diversi fattori: obblighi del progetto, analisi preventiva dei requisiti, curiosità di provare strumenti nuovi. Ad esempio, Angular è stata utilizzata in quanto prevista nel piano di lavoro per lo sviluppo dell’interfaccia mentre la piattaforma Firebase è stata scelta, dopo un confronto con altre tecnologie simili, per i numerosi servizi offerti e perché si presentava come possibilità di ampliare le proprie conoscenze personali. Invece, tutti i linguaggi impiegati non sono stati oggetto di confronto con altri in quanto dipendenti dalla scelta delle tecnologie per lo sviluppo di entrambi i moduli: sia Firebase sia Angular prevedono l’utilizzo di JavaScript o, come in questo caso, di TypeScript.
3.1 Tecnologie
La seguente sezione elenca e descrive le tecnologie utilizzate durante il periodo di stage. Per ognuna sono fornite una descrizione generale e una breve motivazione sull’utilizzo nel progetto.
3.1.1 NodeJS
Figura 3.1: Logo Node.js (https://nodejs.org/it/)
11 12 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
Node.js1, spesso chiamato Node, è una piattaforma di sviluppo open source per l’esecuzione di codice JavaScript lato server, costruita sul motore JavaScript V8 di Google Chrome. Node.js è utile per lo sviluppo di applicazioni che richiedono una connessione persistente dal browser al server ed è spesso utilizzato per applicazioni in tempo reale come chat e news feed. Lo sviluppo web può essere suddiviso in due categorie:
∗ Lato client (front-end): tutto ciò che viene tradotto in qualcosa che l’utente vede attraverso il browser;
∗ Lato server (back-end): tutto ciò che viene utilizzato per la logica dell’applicazione, dall’organizzazione al salvataggio nel database dei dati.
In figura 3.2 si può vedere un esempio di interazione client-serverg. Il client rappresenta il browser attraverso il quale l’utente visualizza l’applicazione. Il client effettua richieste, specificando quali dati desidera inviare o ricevere, al server. Quest’ultimo permette l’esecuzione dell’applicazione, gestisce tutti i dati inoltrati dall’utente ed è responsabile di inviare risposte alle richieste, per esempio caricando una pagina o inviando semplicemente dati.
Figura 3.2: Interazione client-server (https://www.mufin.com/products/audioid-server)
La particolarità di Node.js è quella di operare su un ciclo di eventi utilizzando un unico threadg. Generalmente, un thread ha il compito di gestire un singolo taskg, dall’inizio fino al suo completamento; di conseguenza, più tasks vengono eseguiti simultaneamente, maggiore sarà il numero di threads necessari. Nella maggior parte dei software, tasks multipli vengono gestiti attraverso un certo numero di threads che il computer può offrire nello stesso tempo (concorrenza). Node.js, invece, gestisce un task per volta e utilizza più threads per tutti quelli che il thread principale non riesce a sostenere.
La filosofia di Node.js si basa sui seguenti concetti:
∗ Programmazione ad eventi (Event Driven Programming): paradigma di programmazione nel quale il controllo del flusso del programma è determinato dal verificarsi di uno o più eventi. Essi sono monitorati da un event listenerg, il quale esegue un event handlerg per ogni occorrenza rilevata;
1Node.js. url: https://nodejs.org/it/about; Node.js - Concetti base. url: https://medium. com/@LindaVivah/the- beginners- guide- understanding- node- js- express- js- fundamentals- e15493462be1. 3.1. TECNOLOGIE 13
∗ I/O non bloccante o asincrono: nei tradizionali sistemi di I/O, una richiesta può essere inviata solo quando la risposta della richiesta precedente è giunta a destinazione. In Node.js ciò non accade: se una risposta tarda ad arrivare, la relativa richiesta entra nel cosiddetto event loop permettendo di eseguire le successive richieste pendenti nello stack;
∗ Callbacks: Node.js utilizza le callbacks, cioè della funzioni che vengono chiamate quando un task è completato. In questo modo si evita che il programma si blocchi mentre attende che una richiesta venga completata;
∗ Moduli: funzionalità più o meno complessa organizzata in uno o più file JavaScript che possono essere riutilizzati in qualsiasi punto dell’applicazione. Essi vengono gestiti attraverso il gestore dei pacchetti Node NPM (Node Package Manager).
3.1.1.1 HTTPS Il modulo HTTPS2 di Node.js permette creare un server HTTP e di eseguire le tradizionali richieste GET, POST, DELETE e PUT. In questo progetto di stage questo modulo viene utilizzato per trasferire dati attraverso il protocollo HTTPS (Hyper Text Transfer Protocol over TLS/SSL).
const https= require(’https’) const options={ hostname:’whatever.com’, port: 443, path:’/todos’, method:’GET’ }
const req= https.request(options, res =>{ console.log(‘statusCode: ${res.statusCode}‘)
let responseData; res.on(’data’, chunk =>{ responseData += chunk; });
res.on(’end’, chunk =>{ console.log(responseData); }) })
req.on(’error’, error =>{ console.error(error) })
req.end()
Esempio di richiesta GET con il modulo HTTPS ¥
2Modulo HTTPS in Node.js. url: https://nodejs.org/api/https.html. 14 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
3.1.1.2 CORS Il modulo CORS3 (Cross-Origin Resource Sharing) permette al client di effettuare richieste HTTP verso origini differenti (cross-origin) rispetto a quella del client stesso. L’utilizzo di questo modulo si è rivelato necessario fin da subito, in quanto la politica restrittiva same-origin del browser, generalmente, impedisce questo tipo di richieste. I benefici di CORS sono molteplici:
∗ Permette di esporre le API ad un pubblico più ampio;
∗ Permette opzioni di configurazione flessibili;
∗ Facilita l’utilizzo da parte degli sviluppatori;
∗ Facilita la manutenzione.
L’applicazione sviluppata ha richiesto l’utilizzo di questo modulo in quanto utilizza API di varie piattaforme, come Clockify o WordPress.
Figura 3.3: Flusso di una richiesta CORS (https://medium.com/@buddhiv/what-is-cors-or-cross-origin-resource-sharing- eccbfacaaa30)
3.1.2 Firebase
Figura 3.4: Logo di Firebase (https://firebase.google.com)
3Monsur Hossain. CORS in Action: Creating and consuming cross-origin APIs. Manning Publications, 2014. 3.1. TECNOLOGIE 15
Firebase è una piattaforma per lo sviluppo di applicazioni web e mobile, nata nel 2011 e sviluppata originariamente da Firebase, Inc. Nel 2014 è stata acquistata da Google e tutt’ora dispone di 18 prodotti utilizzabili dagli sviluppatori. In questo progetto di stage sono stati utilizzati i seguenti servizi: Cloud Firestore, Cloud Functions e Firebase Hosting.
3.1.2.1 Cloud Firestore
Cloud Firestore4 è un database non relazionale (NoSQL), altamente scalabile e cloud- hostedg utilizzato per archiviare, sincronizzare e interrogare i dati dell’applicazione. La struttura del database è composta da collezioni (simili a tabelle in SQL) che contengono documenti (simili a righe). Ogni documento contiene i dati effettivi sottoforma di campi.
3.1.2.2 Cloud Functions
L’applicazione web richiede del codice back-end per l’esecuzione delle sue funzionalità. Essendo di natura serverless, il servizio Cloud Functions5 permette di, una volta eseguito il deploymentg delle funzioni, ospitare ed eseguire il codice back-end nel cloud. In questo modo si ottengono diversi vantaggi:
∗ Non è necessario eseguire e mantenere il proprio server;
∗ Il codice back-end è isolato per rispondere ad eventi;
∗ Scalabilità automatica.
3.1.2.3 Firebase Hosting
Firebase Hosting6 è uno strumento che permette di distribuire facilmente l’applicazione all’utente. Come nel caso di Cloud Functions, una volta eseguito il deploy del prodotto, il servizio Google fornisce un modo per ospitare tutti i suoi contenuti. Attraverso questo servizio all’interno di firebaseapp.com viene creato per noi un sottodominio al quale i nostri utenti possono accedere per interagire con l’applicazione. Inoltre, a differenza di altre piattaforme gratuite, Firebase Hosting assicura una connessione sicura, configurando automaticamente un certificato SSL (Secure Sockets Layer) per ogni sito implementato.
4Cloud Firestore. url: https://firebase.google.com/products/firestore/. 5Cloud Functions. url: https://firebase.google.com/products/functions/; Microservizi tramite Cloud Functions. url: https : / / medium . com / billie - finanzratgeber / writing - microservices-with-google-cloud-functions-231205d1a94. 6Firebase Hosting. url: https://firebase.google.com/products/hosting/. 16 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
3.1.3 Angular
Figura 3.5: Logo di Angular (https://angular.io)
Angular7 (comunemente indicato come Angular 2+) è un framework JavaScript open source per lo sviluppo di Single Page Applications (SPAs) prodotto da Google. Angular sostituisce il suo precedessore, AngularJS, e presenta nuove caratteristiche che permettono di costruire applicazioni web complesse, al passo con l’evoluzione che hanno subito in questi ultimi anni. Angular fornisce diversi vantaggi significativi e una struttura comune per gli sviluppatori. I suoi aspetti principali sono: ∗ Componenti personalizzati: Angular permette di costruire i propri componenti riutilizzabili che contengono le funzionalità insieme alla sua logica; ∗ Data binding: Angular permette di gestire senza problemi i dati dal codice JavaScript di base alla vista e reagire agli eventi provenienti della vista stessa; ∗ Dependency Injection: Angular permette di scrivere servizi modulari e fornisce la possibilità iniettare questi ultimi ovunque siano necessari. Questo migliora notevolmente la testabilità e il riuso degli stessi; ∗ Test: Angular considera i test come componente primario nello sviluppo delle applicazioni. L’ambiente fornito dal framework facilita la scrittura di test attraverso strumenti come Karma e Protractor; ∗ Completo: Angular è un framework completo e fornisce soluzioni pronte all’uso per la comunicazione con i server, il routing all’interno dell’applicazione e molto altro ancora.
3.1.3.1 Angular CLI Prima di poter iniziare a sviluppare l’applicazione Angular sono necessari alcuni passi di configurazione. Per facilitare le operazioni preliminari, il team di Angular mette a disposizione uno strumento di interfaccia a riga di comando (Command Line Interface - CLI), il quale espone una serie di comandi utili per inizializzare, strutturare, sviluppare e mantenere l’applicazione. Vista la mia prima esperienza con questa tecnologia, ho scelto di appoggiarmi a questo servizio, soprattutto nella prima fase di sviluppo. In un secondo momento ho unito Angular CLI con una gestione più manuale del progetto. 7Pablo Deeleman e Christoffer Noring. Learning Angular - Second Edition. Packt Publishing, 2017. 3.1. TECNOLOGIE 17
3.1.3.2 AngularFire AngularFire8 è la libreria ufficiale Angular che collega il framework a Firebase. AngularFire fornisce connessioni ai seguenti servizi della piattaforma Google: ∗ Autenticazione; ∗ Archiviazione dei file; ∗ Cloud Firestore. In questo progetto di stage mi sono appoggiato a questa libreria per la gestione dell’autenticazione tramite Google degli utenti, attraverso il modulo AngularFireAuthModule.
3.1.3.3 Reactive Forms Le Reactive Forms9 di Angular utilizzano un approccio esplicito e immutabile per gestire lo stato di una form in uno specifico momento. Ogni cambiamento allo stato di una form restituisce un nuovo stato, che mantiene l’integrità dei dati del modello. Le Reactive Forms sono costruite intorno a stream di Observables, dove gli input provenienti dall’utente sono forniti come un flusso di valori, ai quali si può accedere in modo sincrono. Le Reactive Forms, inoltre, semplificano il testing, perché si ha la certezza che i dati siano integri e prevedibili quando vengono richiesti. In questo progetto di stage ho utilizzato le Reactive Forms di Angular poiché l’utente interagisce frequentemente con l’applicazione; di conseguenza si è reso necessario avere un controllo solido sui dati inseriti.
3.1.3.4 Routing Il Routing10 di Angular è un meccanismo che consente la navigazione da una vista di un componente all’altra mentre l’utente interagisce con l’applicazione. Il modello di riferimento a cui si ispira è la navigazione tradizionale che avviene attraverso un browser:
∗ Inserendo un URLg nella barra degli indirizzi è possibile navigare verso la pagina corrispondente; ∗ Cliccando su un link è possibile navigare verso la pagina a cui il link fa riferimento; ∗ Cliccando sui pulsanti avanti e indietro del browser è possibile navigare attraverso la cronologia delle pagine visitate. Il Routing può interpretare un URL del browser come un’istruzione per navigare verso una vista di un componente specifico. Oppure può passare al componente parametri opzionali che permettono di identificare il contenuto da presentare. Inoltre è possibile navigare quando l’utente clicca su un pulsante, seleziona da un menu a tendina, o in risposta ad un evento da qualsiasi fonte. In questo progetto di stage ho utilizzato il Routing per creare schemi di navigazione precisi tra le varie viste dei componenti. Dovendo gestire anche l’autenticazione, questo approccio mi ha fornito strumenti utili per mostrare sia i contenuti accessibili da un utente non autenticato sia quelli da uno riconosciuto.
8Autenticazione con AngularFire. url: https : / / angularfirebase . com / lessons / angular - firebase-authentication-tutorial-oauth/. 9Angular - Reactive Forms. url: https://angular.io/guide/reactive-forms. 10Angular - Routing. url: https://angular.io/guide/router. 18 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
3.1.3.5 Angular Material
Angular Material11 è una libreria di componenti UI (User Interface) utilizzabile per costruire pagine e applicazioni web attraenti, coerenti e funzionali, aderendo ai principi del web design moderno. Si ispira al Material Design di Google. Angular Material fornisce diversi tipi di elementi integrabili in ogni tipo di vista, come form, bottoni, slider, checkbox, modali, tabelle, menù e molto altro. Non avendo mai sperimentato l’utilizzo di questa libreria, ho colto l’occasione di utilizzarla in questo progetto per analizzarne le potenzialità e confrontarla con altre librerie che ricoprono la stessa area, in primo luogo Bootstrap.
3.1.4 RxJS
Figura 3.6: Logo di RxJS (https://rxjs-dev.firebaseapp.com)
RxJS (Reactive Extensions for JavaScript) è una libreria molto valida per lo sviluppo di applicazioni che rispettano il paradigma della Reactive Programming. Questo tipo di programmazione ruota intorno al concetto di flussi di dati asincroni (asynchronous streams of data) e la libreria adottata fornisce gli strumenti per la gestione e la manipolazione di un particolare tipo di dati chiamato Observable. A differenza di altre librerie JavaScript, tuttavia, l’utilizzo di RxJS comporta un approccio diverso: la risoluzione di un problema non si traduce come una somma dell’insieme di stati manipolati da metodi di una o più classi, ma come una sequenza di dati che viaggia continuamente dai produttori (producers) ai consumatori (consumers), attraverso un insieme di operatori che implementano le funzionalità desiderate. In questo progetto, dovendo effettuare diverse chiamate HTTP ad API esterne o per interrogare il database, l’utilizzo di questa libreria si è rivelato di vitale importanza per gestire i flussi di dati provenienti da ogni risposta e per garantire che i dati dell’applicazione siano sempre integri, in modo da evitare malfunzionamenti durante l’esecuzione.
3.2 Strumenti di supporto
In questa sezione vengono descritti gli strumenti utili al supporto dello sviluppo e dell’organizzazione del lavoro utilizzati durante il periodo di stage.
11Agular Material. url: https://material.angular.io. 3.2. STRUMENTI DI SUPPORTO 19
3.2.1 Git
Figura 3.7: Logo di Git (https://git-scm.com)
Git12 è un sistema di controllo di versione distribuito gratuito e open source progettato per gestire con velocità ed efficienza qualsiasi tipo di progetto. Le sue caratteristiche principali sono:
∗ Braching and merging: possibilità di creare rami (branch) di sviluppo parallelli al ramo principale per la creazione o la sperimentazione di nuove funzionalità. Quando il lavoro è completo è possibile unire (merge) le nuove caratteristiche alla linea principale;
∗ Velocità e robustezza: tutte le operazioni sono eseguite localmente; ciò rende Git un sistema estremamente veloce, a differenza di altri sistemi di versionamento non distribuiti, e adatto per progetti di grandi dimensioni. Quando si ritiene opportuno è possibile caricare le nuove modifiche nel repositoryg remoto; ∗ Sviluppo distribuito: ogni utente ha un backup completo dell’ultima versione presente nel server principale. Ogni aggiornamento è possibile solo se la copia locale del progetto è in linea con la versione remota;
∗ Sicurezza dei dati: il modello di dati utilizzato da Git garantisce integrità per ogni commitg eseguito. Ogni commit è, infatti, identificato da un ID univoco.
3.2.2 GitHub
Figura 3.8: Logo di GitHub (https://github.com/)
GitHub è un servizio di hosting per progetti software. Il nome deriva dal fatto che esso è una implementazione dello strumento di controllo di versione distribuito
12Git. url: https://git-scm.com/about. 20 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
Git. GitHub permette di creare un account gratuito, grazie al quale inizializzare un numero illimitato di repositories pubbliche o private, nel caso sia stato sottoscritto un piano a pagamento. Gli sviluppatori possono caricare il codice sorgente dei loro programmi e renderlo scaricabile dagli altri utenti. Questi ultimi possono interagire con lo sviluppatore tramite un sistema di issue tracking, pull request e commenti che permette di individuare possibili bug o di aggiornare le funzionalità.
3.2.3 Postman
Figura 3.9: Logo di Postman (https://www.getpostman.com)
Postman è un strumento per l’utilizzo e il testing di API REST sviluppate da noi stessi o da terzi. Esso è disponibile sia come plug-in di Google Chrome sia come applicazione per i moderni sistemi operativi. Oltre alla possibilità di eseguire richieste ad uno specifico endpoint, Postman permette di salvare in modo permanente una richiesta e le sue variabili in modo da poter utilizzarla in qualsiasi momento.
3.2.4 Trello
Figura 3.10: Logo di Trello (https://trello.com)
Trello è strumento collaborativo online per gestione dei progetti. Possiamo immaginare Trello come una lavagna bianca sulla quale vengono disegnate delle liste (ad esempio "To Do", "Doing", "Done" del metodo Kanban). Ogni lista contiene le cosiddette cards, simili a dei post-it che specificano l’attività da portare a termine. Le caratteristiche principali di Trello sono: ∗ Ad ogni card può essere assegnata una label di un certo colore, in modo tale da facilitarne l’identificazione; ∗ Per ogni card è possibile assegnare una data di scadenza, aggiungere commenti e aggiornamenti e invitare gli utenti a partecipare; ∗ Ogni card può essere spostata o copiata in un’altra board tramite gli appositi comandi o con il meccanismo drag and drop e archiviata una volta completata. 3.2. STRUMENTI DI SUPPORTO 21
3.2.5 Clockify
Figura 3.11: Logo di Clockify (https://clockify.me)
Clockify è un software di monitoraggio del tempo. Esso permette ad un team di tracciare il tempo impiegato per il completamento di una determinata attività e di migliorare la produttività. In generale, Clockify aiuta a tenere traccia delle ore di lavoro dei dipendenti, delle ore fatturabili e del tempo di completamento di un progetto.
3.2.6 Slack
Figura 3.12: Logo di Slack (https://slack.com)
Slack è una piattaforma di messaggistica attraverso la quale un team può comunicare e collaborare per lo sviluppo di un progetto. Il punto centrale di Slack è il canale di comunicazione. Ogni canale può basarsi su team, progetti, luoghi ecc. Come nel caso di Uqido, un’azienda può creare uno o più workspace, ossia un centro condiviso composto da un certo numero di canali. Tutti i membri appartenenti ad un workspace hanno accesso a tutti i canali in esso contenuti. L’utilizzo di Slack come sistema di riferimento permette una comunicazione interna al team istantanea, garantendo maggiore efficienza e produttività.
3.2.7 WebStorm
Figura 3.13: Logo di WebStorm (https://www.jetbrains.com/webstorm) 22 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
WebStorm è un IDEg potente e intelligente che offre assistenza alla codifica per JavaScript, TypeScript, HTML e CSS e una vasta gamma di moderne tecnologie web. Prodotto dall’azienda JetBrains, WebStorm è attrezzato per lo sviluppo sia lato client sia lato server con Node.js. L’IDE fornisce diversi servizi come interpretazione intelligente del codice, autocompletamento, funzioni di refactoring, prevenzione degli errori on-the-fly e molto altro ancora. Insieme al supporto per i framework più diffusi come Angular e agli strumenti integrati per il testing, il debugging, l’analisi del codice e l’integrazione con vari VCS, WebStorm è uno strumento adatto per migliorare la produttività e per creare un ambiente di sviluppo in grado di supportare progetti complessi.
3.3 Linguaggi per la codifica
In questa sezione vengono descritte le principali caratteristiche dei linguaggi di programmazione utilizzati in durante il periodo di stage.
3.3.1 TypeScript
Figura 3.14: Logo di TypeScript (https://www.typescriptlang.org)
TypeScript13 è un linguaggio open-source orientato agli oggetti e superset di JavaScript. Quest’ultimo è un linguaggio multipiattaforma versatile utilizzato per sviluppare moderne applicazioni web, sia per quanto riguarda la parte client di un’applicazione, con framework come Angular o React.js, sia per la parte server, con framework come Node.js. Tuttavia JavaScript presenta alcune limitazioni, in primis la mancanza di controlli statici sui tipi di dato e la conversione implicita tra i tipi. Al contrario, TypeScript fornisce un sistema per la gestione del tipo di una variabile o di un parametro di funzione, aumentando la qualità del codice e la leggibilità, facilitando la manutenzione e il refactoring e rendendo scalabile il codice di applicazioni complesse. In questo modo, inoltre, gli errori possono essere rilevati durante la compilazione piuttosto che durante l’esecuzione. TypeScript viene transpilato in JavaScript standard, eseguibile da qualsiasi browser o motore JavaScript.
13TypeScript. url: https://www.typescriptlang.org/. 3.3. LINGUAGGI PER LA CODIFICA 23
3.3.2 HTML5
Figura 3.15: Logo di HTML5 (https://www.w3schools.com/html)
L’HyperText Markup Language (HTML) è un linguaggio di markup di tipo descrittivo, nato per la formattazione e impaginazione di documenti ipertestuali. Il componente principale è l’elemento, una struttura di base che ha la funzione di formattare i dati o indicare al browser delle informazioni. Ogni elemento è racchiuso all’interno di una marcatura, ovvero una annotazione del suo contenuto. A sua volta, la marcatura prevede l’uso di etichette, dette TAG (
3.3.3 SCSS
Figura 3.16: Logo di Sass (https://sass-lang.com/)
Il CSS (Cascading Style Sheet) è un linguaggio utilizzato per formattare il layout delle pagine Web, come stili di testo, dimensioni delle tabelle e altri aspetti che prima potevano essere definiti solo tramite l’HTML di una pagina. Il codice CSS viene specificato in un documento .css chiamato foglio di stile. Esso contiene tutte le informazioni per la rappresentazione degli elementi in una pagina web. Una volta che lo stile è stato definito nel foglio corrispondente, può essere utilizzato in qualsiasi punto della pagina, favorendo il riuso del codice e il disaccoppiamento tra logica e rappresentazione. 24 CAPITOLO 3. TECNOLOGIE, STRUMENTI DI SUPPORTO E LINGUAGGI
SCSS (Sassy CSS) è una sintassi del linguaggio di scripting Sass (Syntactically awesome style sheets) che permette di creare documenti di stile con estensione .scss interpretati e compilati in file .css. Questo tipo di linguaggio fornisce strumenti che estendono classico CSS, come variabili, annidamento del codice, cicli ed ereditarietà dei selettori, tipici dei tradizionali linguaggi di programmazione orientati agli oggetti. Capitolo 4
Analisi dei requisiti
4.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 UMLg dedicati alla descrizione delle funzioni o servizi offerti da un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. Essendo il progetto finalizzato alla creazione di una piattaforma per la gestione automatica degli OKR, le interazioni da parte dell’utilizzatore sono strettamente legate alle operazioni di modifica o aggiornamento di un obiettivo o di un risultato chiave e alla visualizzazione dello stato di avanzamento di un particolare quarter.
4.1.1 Attori ∗ Utente non autenticato: si fa riferimento ad un utente che deve effettuare l’autenticazione per usufruire dei servizi esposti dell’applicazione;
∗ Utente autenticato: identifica l’utente principale dell’applicazione, il quale può usufruire di tutti i servizi esposti;
∗ Firebase Authentication: servizio esposto da Firebase per gestire l’autenticazione.
4.1.2 Struttura Ogni caso d’uso è descritto dalla seguente struttura:
∗ Codice identificativo:
UC {codice_padre}.{codice_figlio}
– UC specifica che si tratta di un caso d’uso; – Codice_padre identifica univocamente i casi d’uso; – Codice_figlio è un numero progressivo che identifica i sottocasi.
∗ Titolo;
∗ Diagramma UML;
25 26 CAPITOLO 4. ANALISI DEI REQUISITI
∗ Attori;
∗ Attori secondari (se presenti);
∗ Scopo e descrizione;
∗ Precondizioni;
∗ Scenario principale;
∗ Postcondizioni;
∗ Inclusioni (se presenti);
∗ Estensioni (se presenti).
4.1.3 Operazioni permesse ad un utente non autenticato
Figura 4.1: Operazioni permesse ad un utente non autenticato
4.1.3.1 UC1: Autenticazione
Figura 4.2: UC1 - Autenticazione 4.1. CASI D’USO 27
Attori: Utente non autenticato. Attori secondari: Firebase Authentication. Scopo e descrizione: l’attore vuole eseguire l’autenticazione. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina di autenticazione. Scenario Principale:
∗ L’attore avvia il servizio di autenticazione attraverso l’apposito bottone;
∗ L’attore inserisce l’email aziendale (UC1.1)
∗ L’attore inserisce la password associata all’email aziendale (UC1.2)
Postcondizioni: L’Utente non autenticato viene autenticato e reindirizzato alla pagina principale dell’applicazione. Estensioni: L’Utente non autenticato visualizza un messaggio di errore poiché le credenziali inserite non sono corrette.
4.1.3.2 UC1.1: Inserimento email
Attori: Utente non autenticato. Attori secondari: Firebase Authentication. Scopo e descrizione: l’attore vuole inserire l’email aziendale per eseguire l’autenticazione.
Precondizioni: il sistema di autenticazione fornito da Firebase Authentication si è avviato correttamente. Scenario Principale: l’attore inserisce l’email aziendale nell’apposita form. Postcondizioni: l’attore ha inserito l’email aziendale senza errori.
4.1.3.3 UC1.2: Inserimento password
Attori: Utente non autenticato. Attori secondari: Firebase Authentication. Scopo e descrizione: l’attore vuole inserire la password per eseguire l’autenticazione.
Precondizioni: il sistema di autenticazione fornito da Firebase Authentication si è avviato correttamente. Scenario Principale: l’attore inserisce la password associata all’email aziendale nell’apposita form Postcondizioni: l’attore ha inserito la password senza errori. 28 CAPITOLO 4. ANALISI DEI REQUISITI
4.1.3.4 UC2: Visualizzazione errore credenziali di accesso
Attori: Utente non autenticato. Attori secondari: Firebase Authentication. Scopo e descrizione: l’attore vuole eseguire l’autenticazione. Precondizioni: il servizio di autenticazione esposto da Firebase Authentication contiene, nelle apposite form, l’email aziendale e la password dell’Utente non autenticato.
Scenario Principale:
∗ L’attore conferma la richiesta di autenticazione attraverso l’apposito bottone;
∗ L’attore attende che la richiesta di autenticazione venga processata;
∗ L’attore visualizza un messaggio d’errore relativo all’inserimento di credenziali non corrette.
Postcondizioni: L’Utente non autenticato rimane nella pagina di autenticazione dopo che la sua richiesta è stata rigettata..
4.1.4 Caso d’uso generale UCG1: gestione degli OKR
Poiché la maggior parte delle funzionalità possono essere sfruttate da un utente autenticato, i casi d’uso relativi ad esse vengono riassunti in un caso d’uso generale (UCG1) la cui nomenclatura non segue quella riportata nella sottosezione 4.1.2. Esso rappresenta i casi d’uso più ad alto livello, ognuno dei quali viene approfondito nelle sezioni successive. 4.1. CASI D’USO 29
Figura 4.3: UCG1 - Operazioni per la gestione degli OKR
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire operazioni per la gestione degli OKR. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale:
∗ L’attore gestisce e visualizza le informazioni di un quarter (UC3);
∗ L’attore gestisce e visualizza le informazioni degli obiettivi di un quarter (UC4);
∗ L’attore gestisce e visualizza le informazioni dei risultati chiave di un obiettivo (UC5);
∗ L’attore gestisce e visualizza le informazioni delle metriche di un risultato chiave (UC6);
∗ L’attore effettua l’operazione di logout (UC7).
Postcondizioni: L’Utente autenticato ha eseguito operazioni per la gestione degli OKR con successo. 30 CAPITOLO 4. ANALISI DEI REQUISITI
4.1.4.1 UC3: Gestione quarter
Figura 4.4: UC3 - Operazioni per la gestione del quarter
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire operazioni per la gestione di un quarter.
Precondizioni: l’applicazione si è avviata correttamente e l’attore visualizza le informazioni di un quarter. Scenario Principale: ∗ L’attore crea uno o più quarter (UC3.1); ∗ L’attore visualizza la lista di quarter disponibili (UC3.2); ∗ L’attore seleziona un quarter dalla lista (UC3.3); ∗ L’attore visualizza grafico a torta che descrive lo stato di avanzamento di ogni obiettivo (UC3.4); 4.1. CASI D’USO 31
∗ L’attore avvia il comando di gestione della modalità di modifica (UC3.5).
Postcondizioni: L’utente autenticato ha eseguito operazioni per la gestione di un quarter con successo.
4.1.4.2 UC3.1: Creazione nuovo quarter
Figura 4.5: UC3.1 - Creazione di un quarter
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire l’operazione di creazione di un nuovo quarter. Precondizioni: l’attore indica all’applicazione di voler creare un nuovo quarter dopo aver avviato la procedura tramite l’apposito bottone. Scenario Principale: ∗ L’attore inserisce la data di inizio del nuovo quarter (UC3.1.1); ∗ L’attore inserisce la data di fine del nuovo quarter (UC3.1.2).
Postcondizioni: la creazione di un nuovo quarter è stata completata con successo.
4.1.4.3 UC3.1.1: Inserimento data di inizio
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole inserire la data di inizio del nuovo quarter. Precondizioni: la procedura di creazione di un nuovo quarter si è avviata correttamente.
Scenario Principale: l’attore seleziona la data di inizio del nuovo quarter attraverso l’apposito datepicker. Postcondizioni: l’inserimento della data di inizio del quarter è stato completato con successo. 32 CAPITOLO 4. ANALISI DEI REQUISITI
4.1.4.4 UC3.1.2: Inserimento data di fine
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole inserire la data di fine del nuovo quarter. Precondizioni: la procedura di creazione di un nuovo quarter si è avviata correttamente.
Scenario Principale: l’attore seleziona la data di fine del nuovo quarter attraverso l’apposito datepicker. Postcondizioni: l’inserimento della data di fine del quarter è stato completato con successo.
4.1.4.5 UC3.2: Visualizzazione lista quarter disponibili
Figura 4.6: UC3.2 - Visualizzazione lista dei quarter disponibili
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la lista di quarter disponibili. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale: l’attore visualizza un quarter specifico (UC3.2.1). Postcondizioni: l’attore ha visualizzato la lista di quarter con successo. 4.1. CASI D’USO 33
4.1.4.6 UC3.2.1: Visualizzazione quarter specifico
Figura 4.7: UC3.2.1 - Visualizzazione di un quarter specifico
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare le informazioni di un quarter specifico della lista. Precondizioni: la lista di quarter disponibili si è caricata correttamente e l’attore visualizza un quarter specifico. Scenario Principale: ∗ L’attore visualizza la data di inizio del quarter (UC3.2.1.1); ∗ L’attore visualizza la data di fine del quarter (UC3.2.1.2).
Postcondizioni: l’attore ha visualizzato le informazioni di un quarter specifico con successo.
4.1.4.7 UC3.2.1.1: Visualizzazione data di inizio
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la data di inizio di un quarter specifico. Precondizioni: l’attore visualizza correttamente un quarter specifico della lista. Scenario Principale: l’attore visualizza la data di inizio di un quarter specifico. Postcondizioni: l’attore ha visualizzato la data di inizio di un quarter specifico con successo.
4.1.4.8 UC3.2.1.2: Visualizzazione data di fine
Attori: Utente autenticato. 34 CAPITOLO 4. ANALISI DEI REQUISITI
Scopo e descrizione: l’attore vuole visualizzare la data di fine di un quarter specifico.
Precondizioni: l’attore visualizza correttamente un quarter specifico della lista. Scenario Principale: l’attore visualizza la data di fine di un quarter specifico. Postcondizioni: l’attore ha visualizzato la data di fine di un quarter specifico con successo.
4.1.4.9 UC3.3 - Selezione quarter
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole selezionare un quarter diverso da quello presente nella pagina principale. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale: l’attore visualizza la lista di quarter disponibili. Postcondizioni: l’attore ha selezionato un quarter dalla lista di quarter disponibili con successo.
4.1.4.10 UC3.4 - Visualizzazione grafico a torta
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare il grafico a torta che contiene lo stato di avanzamento di ogni obiettivo. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale: l’attore visualizza il grafico a torta nel quale ogni obiettivo è contrassegnato da un colore. Postcondizioni: l’attore ha visualizzato il grafico a torta con successo.
4.1.4.11 UC3.5 - Gestione modalità di modifica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire operazioni di gestione della modalità di modifica. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale: l’attore esegue operazioni per la gestione della modalità di modifica. Postcondizioni: l’attore ha eseguito operazioni per la gestione della modalità di modifica con successo. 4.1. CASI D’USO 35
4.1.4.12 UC3.6 - Attivazione modalità di modifica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole attivare la modalità di modifica. Precondizioni: la procedura di gestione della modalità di modifica si è avviata correttamente. Scenario Principale: l’attore seleziona l’attivazione della modalità di modifica. Postcondizioni: l’attore ha attivato la modalità di modifica con successo.
4.1.4.13 UC3.7 - Disattivazione modalità di modifica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole disattivare la modalità di modifica. Precondizioni: la procedura di gestione della modalità di modifica si è avviata correttamente. Scenario Principale: l’attore deseleziona l’attivazione della modalità di modifica. Postcondizioni: l’attore ha disattivato la modalità di modifica con successo.
4.1.4.14 UC4: Gestione obiettivi
Figura 4.8: UC4 - Operazioni per la gestione degli obiettivi
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire operazioni per la gestione degli obiettivi.
Precondizioni: l’applicazione si è avviata correttamente e l’attore visualizza le 36 CAPITOLO 4. ANALISI DEI REQUISITI informazioni degli obiettivi. Scenario Principale:
∗ L’attore crea un nuovo obiettivo (UC4.1);
∗ L’attore elimina un obiettivo (UC4.2);
∗ L’attore visualizza la lista di obiettivi relativi ad un quarter (UC4.3).
Postcondizioni: l’attore ha eseguito operazioni per la gestione degli obiettivi.
4.1.4.15 UC4.1: Inserimento nuovo obiettivo
Figura 4.9: UC4.1 - Inserimento di un nuovo obiettivo
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire l’operazione di inserimento di un nuovo obiettivo. Precondizioni: l’attore indica all’applicazione di voler creare un nuovo obiettivo dopo aver avviato la procedura tramite l’apposito bottone. Scenario Principale: L’attore inserisce la descrizione del nuovo obiettivo (UC4.1.1).
Postcondizioni: la creazione di un nuovo obiettivo è stata completata con successo.
4.1.4.16 UC4.1.1: Inserimento descrizione obiettivo
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole inserire la descrizione del nuovo obiettivo. Precondizioni: la procedura di creazione di un nuovo obiettivo si è avviata correttamente.
Scenario Principale: l’attore inserisce la descrizione del nuovo obiettivo attraverso l’apposita form. Postcondizioni: l’attore ha inserito la descrizione del nuovo obiettivo con successo. 4.1. CASI D’USO 37
4.1.4.17 UC4.2: Eliminazione obiettivo
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eliminare un obiettivo dalla lista. Precondizioni: l’attore indica all’applicazione di voler eliminare un obiettivo dopo aver avviato la procedura tramite l’apposito bottone. Scenario Principale: l’attore conferma l’eliminazione dell’obiettivo. Postcondizioni: l’attore ha eliminato un obiettivo dalla lista con successo.
4.1.4.18 UC4.3: Visualizzazione lista obiettivi
Figura 4.10: UC4.3 - Visualizzazione lista degli obiettivi
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la lista di obiettivi disponibili. Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale: l’attore visualizza un obiettivo specifico (UC4.3.1). Postcondizioni: l’attore ha visualizzato la lista di obiettivi disponibili con successo.
4.1.4.19 UC4.3.1: Visualizzazione obiettivo specifico
Figura 4.11: UC4.3.1 - Visualizzazione obiettivo specifico 38 CAPITOLO 4. ANALISI DEI REQUISITI
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare le informazioni di un obiettivo specifico. Precondizioni: la lista di obiettivi disponibili si è caricata correttamente e l’attore visualizza un obiettivo specifico. Scenario Principale: L’attore visualizza la descrizione dell’obiettivo (UC4.3.1.1). Postcondizioni: l’attore ha visualizzato le informazioni di un obiettivo specifico con successo.
4.1.4.20 UC4.3.1.1: Visualizzazione descrizione obiettivo
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la descrizione di un obiettivo specifico.
Precondizioni: l’attore visualizza correttamente un obiettivo specifico della lista. Scenario Principale: l’attore visualizza la descrizione dell’obiettivo specifico. Postcondizioni: l’attore ha visualizzato la descrizione di un obiettivo specifico con successo.
4.1.4.21 UC5: Gestione risultati chiave
Figura 4.12: UC5 - Operazioni per la gestione dei risultati chiave
Attori: Utente autenticato. 4.1. CASI D’USO 39
Scopo e descrizione: l’attore vuole eseguire operazioni per la gestione dei risultati chiave. Precondizioni: la lista di obiettivi si è caricata correttamente e l’attore visualizza le informazioni dei risultati chiave per ogni obiettivo. Scenario Principale: ∗ L’attore crea un nuovo risultato chiave (UC5.1); ∗ L’attore elimina un risultato chiave (UC5.2); ∗ L’attore visualizza la lista di risultati chiave di un obiettivo (UC5.3).
Postcondizioni: l’attore ha eseguito operazioni per la gestione dei risultati chiave.
4.1.4.22 UC5.1: Creazione risultato chiave
Figura 4.13: UC5.1 - Creazione di un risultato chiave
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire l’operazione di creazione di un nuovo risultato chiave. Precondizioni: la procedura di creazione di un nuovo risultato chiave si è avviata correttamente. Scenario Principale: ∗ L’attore inserisce la descrizione del nuovo risultato chiave attraverso l’apposita form (UC5.1.1); ∗ L’attore inserisce il tipo del nuovo risultato chiave attraverso l’apposito menu (UC5.1.2).
Postcondizioni: la creazione di un nuovo risultato chiave è stata completata con successo. 40 CAPITOLO 4. ANALISI DEI REQUISITI
4.1.4.23 UC5.1.1: Inserimento descrizione risultato chiave
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole inserire la descrizione del nuovo risultato chiave.
Precondizioni: la procedura di creazione di un nuovo risultato chiave si è avviata correttamente. Scenario Principale: l’attore inserisce la descrizione del nuovo risultato chiave. Postcondizioni: l’attore ha inserito la descrizione del nuovo risultato chiave con successo.
4.1.4.24 UC5.1.2: Inserimento tipo risultato chiave
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole inserire il tipo del nuovo risultato chiave. Precondizioni: la procedura di creazione di un nuovo risultato chiave si è avviata correttamente. Scenario Principale: l’attore inserisce il tipo del nuovo risultato chiave. Postcondizioni: l’attore ha inserito il tipo del nuovo risultato chiave con successo.
4.1.4.25 UC5.2: Eliminazione risultato chiave
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eliminare un risultato chiave dalla lista. Precondizioni: l’attore indica all’applicazione di voler eliminare un risultato chiave dopo aver avviato la procedura tramite l’apposito bottone. Scenario Principale: l’attore conferma l’eliminazione del risultato chiave. Postcondizioni: l’attore ha eliminato un risultato chiave dalla lista con successo.
4.1.4.26 UC5.3: Visualizzazione lista risultati chiave
Figura 4.14: UC5.3 - Visualizzazione lista dei risultati chiave 4.1. CASI D’USO 41
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la lista di risultati chiave disponibili.
Precondizioni: la lista di obiettivi si è caricata correttamente e l’attore visualizza le informazioni dei risultati chiave per ogni obiettivo. Scenario Principale: l’attore visualizza un risultato chiave specifico (UC5.3.1) Postcondizioni: l’attore ha visualizzato la lista di risultati chiave disponibili con successo.
4.1.4.27 UC5.3.1: Visualizzazione risultato chiave specifico
Figura 4.15: UC5.3.1 - Visualizzazione di un risultato chiave specifico
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare le informazioni di un risultato chiave specifico. Precondizioni: la lista di risultati chiave disponibili si è caricata correttamente e l’attore visualizza un risultato chiave specifico. Scenario Principale:
∗ L’attore visualizza la descrizione del risultato chiave specifico (UC5.3.1.1);
∗ L’attore visualizza la progress bar del risultato chiave specifico (UC5.3.1.2).
Postcondizioni: l’attore ha visualizzato le informazioni di un risultato chiave specifico con successo. 42 CAPITOLO 4. ANALISI DEI REQUISITI
4.1.4.28 UC5.3.1.1: Visualizzazione descrizione risultato chiave
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la descrizione di un risultato chiave specifico. Precondizioni: l’attore visualizza correttamente un risultato chiave specifico della lista. Scenario Principale: l’attore visualizza la descrizione del risultato chiave specifico. Postcondizioni: l’attore ha visualizzato la descrizione di un risultato chiave specifico con successo.
4.1.4.29 UC5.3.1.2: Visualizzazione progress bar risultato chiave
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la progress bar di un risultato chiave specifico. Precondizioni: l’attore visualizza correttamente un risultato chiave specifico della lista. Scenario Principale: l’attore visualizza la progress bar del risultato chiave specifico.
Postcondizioni: l’attore ha visualizzato la progress bar di un risultato chiave specifico con successo.
4.1.4.30 UC6: Gestione metriche
Figura 4.16: UC6 - Operazioni per la gestione delle metriche 4.1. CASI D’USO 43
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire operazioni per la gestione delle metriche.
Precondizioni: la pagina relativa alla metriche si è caricata correttamente e l’attore visualizza le informazioni delle metriche. Scenario Principale: ∗ L’attore inserisce una nuova metrica (UC6.1); ∗ L’attore elimina una metrica (UC6.2); ∗ L’attore visualizza la lista di metriche di un risultato chiave (UC6.3).
Postcondizioni: l’attore ha eseguito operazioni per la gestione delle metriche.
4.1.4.31 UC6.1: Inserimento nuova metrica
Figura 4.17: UC6.1 - Inserimento di una nuova metrica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eseguire l’operazione di creazione di una nuova metrica. Precondizioni: la procedura di creazione di una nuova metrica si è avviata correttamente.
Scenario Principale: ∗ L’attore inserisce la descrizione della nuova metrica; ∗ L’attore seleziona la data di inserimento della nuova metrica attraverso l’apposito datepicker. 44 CAPITOLO 4. ANALISI DEI REQUISITI
Postcondizioni: la creazione di una nuova metrica è stata completata con successo.
4.1.4.32 UC6.1.1: Inserimento descrizione metrica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole inserire la descrizione della nuova metrica. Precondizioni: la procedura di creazione di una metrica si è avviata correttamente. Scenario Principale: l’attore inserisce la descrizione della nuova metrica. Postcondizioni: l’attore ha inserito la descrizione della metrica con successo.
4.1.4.33 UC6.1.2: Selezione data di inserimento
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole selezionare la data di inserimento della nuova metrica. Precondizioni: la procedura di creazione di una metrica si è avviata correttamente. Scenario Principale: l’attore seleziona la data di inserimento della nuova metrica attraverso l’apposito datepicker. Postcondizioni: l’attore ha selezionato la data di inserimento della metrica con successo.
4.1.4.34 UC6.2: Eliminazione metrica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole eliminare una metrica dalla lista. Precondizioni: l’attore indica all’applicazione di voler eliminare una metrica dopo aver avviato la procedura tramite l’apposito bottone. Scenario Principale: l’attore conferma l’eliminazione della metrica. Postcondizioni: l’attore ha eliminato una metrica dalla lista con successo. 4.1. CASI D’USO 45
4.1.4.35 UC6.3: Visualizzazione lista metriche
Figura 4.18: UC6.3 - Visualizzazione di una lista di metriche
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la lista di metriche disponibili. Precondizioni: la pagina relativa alla metriche si è caricata correttamente e l’attore visualizza le informazioni delle metriche di un risultato chiave. Scenario Principale: l’attore visualizza una metrica specifica (UC6.3.1) Postcondizioni: l’attore ha visualizzato la lista di metriche disponibili con successo.
4.1.4.36 UC6.3.1: Visualizzazione metrica specifica
Figura 4.19: UC6.3.1 - Visualizzazione metrica specifica
Attori: Utente autenticato. 46 CAPITOLO 4. ANALISI DEI REQUISITI
Scopo e descrizione: l’attore vuole visualizzare le informazioni di una metrica specifica. Precondizioni: la lista di metriche disponibili si è caricata correttamente e l’attore visualizza una metrica specifica. Scenario Principale:
∗ L’attore visualizza la descrizione della metrica specifica (UC6.3.1.1);
∗ L’attore visualizza l’autore della metrica specifica (UC6.3.1.2);
∗ L’attore visualizza la data di inserimento della metrica specifica (UC6.3.1.3);
Postcondizioni: l’attore ha visualizzato le informazioni di una metrica specifica con successo.
4.1.4.37 UC6.3.1.1: Visualizzazione descrizione metrica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la descrizione di una metrica specifica.
Precondizioni: l’attore visualizza correttamente una metrica specifica della lista. Scenario Principale: l’attore visualizza la descrizione della metrica specifica. Postcondizioni: l’attore ha visualizzato la descrizione di una metrica specifica con successo.
4.1.4.38 UC6.3.1.2: Visualizzazione autore metrica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare l’autore di una metrica specifica. Precondizioni: l’attore visualizza correttamente una metrica specifica della lista. Scenario Principale: l’attore visualizza l’autore della metrica specifica. Postcondizioni: l’attore ha visualizzato l’autore di una metrica specifica con successo.
4.1.4.39 UC6.3.1.3: Visualizzazione data inserimento metrica
Attori: Utente autenticato. Scopo e descrizione: l’attore vuole visualizzare la data di inserimento di una metrica specifica. Precondizioni: l’attore visualizza correttamente una metrica specifica della lista. Scenario Principale: l’attore visualizza la data di inserimento della metrica specifica. 4.2. TRACCIAMENTO DEI REQUISITI 47
Postcondizioni: l’attore ha visualizzato la data di inserimento di una metrica specifica con successo.
4.1.4.40 UC7 - Logout
Figura 4.20: UC7 - Logout
Attori: Utente autenticato. Attori secondari: Firebase Authentication. Scopo e descrizione: l’attore vuole effettuare l’operazione di logout dall’applicazione.
Precondizioni: l’applicazione si è avviata correttamente e l’attore si trova nella pagina principale. Scenario Principale: l’attore avvia il servizio di logout attraverso l’apposito bottone.
Postcondizioni: l’operazione di logout viene completata con successo e l’attore viene reindirizzato alla pagina di login dell’applicazione.
4.2 Tracciamento dei requisiti
Da un’attenta analisi dei requisiti effettuata sul progetto è stata stilata la tabella che traccia i requisiti in rapporto ai casi d’uso. Per distinguere i diversi tipi di requisiti individuati si utilizza il seguente codice identificativo: [R][tipo][identificativo]
∗ R = requisito;
∗ tipo distingue se si tratta di un requisito funzionale (F), di qualità (Q) o di vincolo (V);
∗ identificativo è un numero progressivo che identifica i sottocasi.
Nelle tabelle 4.1, 4.2 e 4.3 sono riassunti i requisiti e il loro tracciamento con i casi d’uso delineati in fase di analisi. 48 CAPITOLO 4. ANALISI DEI REQUISITI
4.2.1 Requisiti funzionali
Id requisito Descrizione
RF1 L’utente non autenticato effettua il login
L’utente non autenticato inserisce la propria RF1.1 email aziendale
L’utente non autenticato inserisce la password RF1.2 relativa all’email aziendale
L’utente visualizza un messaggio di errore nel RF1.3 caso le credenziali inserite non siano esatte
L’utente visualizza la pagina principale con il RF2 quarter corrente
L’utente visualizza il grafico a torta che RF3 mostra lo stato di avanzamento di ogni obiettivo
L’utente visualizza la lista di quarter RF4 disponibili
RF4.1 L’utente visualizza un quarter specifico
L’utente visualizza data di inizio e di fine del RF4.1.1 quarter
L’utente seleziona un quarter diverso da quello RF5 attualmente presente nella pagina principale
L’utente avvia la procedura di creazione di un RF6 nuovo quarter
L’utente inserisce la data di inizio e di fine del RF6.1 nuovo quarter
L’utente seleziona l’opzione di modalità di RF7 modifica
RF7.1 L’utente attiva la modalità di modifica
RF7.2 L’utente disattiva la modalità di modifica
L’utente visualizza la pagina principale con RF8 lista di obiettivi del quarter 4.2. TRACCIAMENTO DEI REQUISITI 49
Id requisito Descrizione
L’utente visualizza la lista di obiettivi del RF9 quarter
RF9.1 L’utente visualizza un obiettivo specifico
RF9.1.1 L’utente visualizza la descrizione dell’obiettivo
RF10 L’utente crea un nuovo obiettivo
L’utente inserisce la descrizione del nuovo RF10.1 obiettivo
RF11 L’utente elimina un obiettivo
L’utente visualizza la pagina principale con la RF12 lista di risultati chiave associati ad un obiettivo
L’utente visualizza la lista di risultati chiave RF13 associati ad un obiettivo
L’utente visualizza un risultato chiave RF13.1 specifico
L’utente visualizza la descrizione del risultato RF13.1.1 chiave
L’utente visualizza la progress bar del RF13.1.2 risultato chiave
RF14 L’utente crea un nuovo risultato chiave
L’utente inserisce la descrizione del nuovo RF14.1 risultato chiave
L’utente seleziona il tipo del nuovo risultato RF14.2 chiave
RF15 L’utente elimina un risultato chiave
L’utente visualizza la pagina con la lista di RF16 metriche di un risultato chiave
L’utente visualizza la lista di metriche di un RF17 risultato chiave 50 CAPITOLO 4. ANALISI DEI REQUISITI
Id requisito Descrizione
RF17.1 L’utente visualizza una metrica specifica
RF17.1.1 L’utente visualizza la descrizione della metrica
RF17.1.2 L’utente visualizza l’autore della metrica
L’utente visualizza la data di inserimento RF17.1.3 della metrica
RF18 L’utente crea una nuova metrica
L’utente inserisce descrizione della nuova RF18.1 metrica
L’utente selezione la data di inserimento della RF18.2 metrica
RF19 L’utente elimina una metrica
RF20 L’utente effettua il logout dall’applicazione
Tabella 4.1: Tabella del tracciamento dei requisti funzionali
4.2.2 Requisiti di qualità
Id requisito Descrizione
Il progetto deve utilizzare un sistema di RQ1 versionamento del codice
Ogni componente sviluppato deve essere sottoposto all’approvazione del tutor aziendale RQ2 o di un altro membro del team di sviluppo tramite il meccanismo di pull request & review
Il codice deve essere salvato in un repository remoto pubblico, in modo che sia sempre RQ3 accessibile e che sia visibile la storia di ogni modifica effettuata
I nomi delle variabili e dei metodi devono seguire la notazione camelCase, mentre i nomi RQ4 delle classi devono seguire la notazione PascalCase
Tabella 4.2: Tabella del tracciamento dei requisti di qualità 4.3. TRACCIAMENTO REQUISITI - CASI D’USO 51
4.2.3 Requisiti di vincolo
Id requisito Descrizione
Il linguaggio utilizzato per lo sviluppo dei RV1 moduli dell’applicazione deve essere TypeScript
L’interfaccia dell’applicazione deve essere RV2 sviluppata attraverso il framework Angular
L’architettura del back-end dell’applicazione RV3 deve essere basata su microservizi
L’autenticazione deve essere implementata attraverso gli strumenti messi a disposizione RV4 da Firebase Authentication, il quale segue lo standard OAuth2.0
Tabella 4.3: Tabella del tracciamento dei requisti di vincolo
4.3 Tracciamento requisiti - casi d’uso
Id requisito Id caso d’uso
RF1 UC1
RF1.1 UC1.1
RF1.2 UC1.2
RF1.3 UC2
RF2 UC3
RF3 UC3.4
RF4 UC3.2
RF4.1 UC3.2.1 52 CAPITOLO 4. ANALISI DEI REQUISITI
UC3.2.1.1 RF4.1.1 UC3.2.1.2
RF5 UC3.3
RF6 UC3.1
UC3.1.1 RF6.1 UC3.1.2
RF7 UC3.5
RF7.1 UC3.6
RF7.2 UC3.7
RF8 UC4
RF9 UC4.3
RF9.1 UC4.3.1
RF9.1.1 UC4.3.1.1
RF10 UC4.1
RF10.1 UC4.1.1
RF11 UC4.2
RF12 UC5
RF13 UC5.3
RF13.1 UC5.3.1
RF13.1.1 UC5.3.1.1
RF13.1.2 UC5.3.1.2 4.3. TRACCIAMENTO REQUISITI - CASI D’USO 53
RF14 UC5.1
RF14.1 UC5.1.1
RF14.2 UC5.1.2
RF15 UC5.2
RF16 UC6
RF17 UC6.3
RF17.1 UC6.3.1
RF17.1.1 UC6.3.1.1
RF17.1.2 UC6.3.1.2
RF17.1.3 UC6.3.1.3
RF18 UC6.1
RF18.1 UC6.1.1
RF18.2 UC6.1.2
RF19 UC6.2
RF20 UC7
Tabella 4.4: Tabella del tracciamento dei requisti - casi d’uso
Capitolo 5
Progettazione architetturale
Figura 5.1: Struttura generale a layer dell’applicazione
Come già introdotto nella sottosezione 2.2.2, l’applicazione è composta da due moduli principali: back-end e front-end. Ogni modulo opera in modo indipendente dall’altro: il modulo di front-end comunica con il modulo di back-end esclusivamente attraverso le API REST esposte da quest’ultimo. La figura 5.1 descrive ad alto livello la struttura dell’applicazione utilizzando un sistema a layer: l’interfaccia utente comunica con i vari componenti, i quali, appoggiandosi ai servizi Angular, interagiscono con la logica del back-end. Ogni operazione può comportare una o più modifiche al database.
5.1 Back-end
L’architettura del back-end della piattaforma si basa su microservizi1. Secondo questo approccio un software è progettato e realizzato attraverso dei servizi di piccole
1Microservizi. url: https://aws.amazon.com/it/microservices.
55 56 CAPITOLO 5. PROGETTAZIONE ARCHITETTURALE dimensioni indipendenti l’uno dall’altro che comunicano tra loro tramite API. Questi componenti rappresentano ciascuno una funzionalità ben precisa. Poiché eseguito in modo separato, ogni servizio può essere aggiornato, modificato, distribuito e ridimensionato per adattarsi al comportamento richiesto della funzione specifica che ricopre. Le caratteristiche chiave dei microservizi sono:
∗ Autonomia: ciascun servizio può essere sviluppato, distribuito, eseguito e ridimensionato senza influenzare il funzionamento degli altri componenti. Il codice di un servizio non è condiviso ed è specializzato per realizzare la funzionalità relativa al servizio. Inoltre, qualsiasi comunicazione tra i componenti individuali avviene attraverso API ben definite;
∗ Specializzazione: ciascun servizio è fornisce una serie di capacità e si concentra sulla risoluzione di un problema specifico. Se, nel tempo, un servizio viene esteso attraverso del codice aggiuntivo dagli sviluppatori rendendolo più complesso, il servizio può essere scomposto in servizi più piccoli.
I microservizi offrono dei vantaggi che hanno permesso loro di diventare un punto di riferimento nello sviluppo di architetture software, a discapito delle architetture monolitiche dove tutti i processi sono strettamente legati fra loro e vengono eseguiti come un unico servizio:
∗ Agilità: ogni servizio viene sviluppato indipendentemente dagli altri, permettendo al team di operare in contesti ridotti e definiti. Ciò favorisce una riduzione del ciclo di sviluppo e una conseguente rapidità di rilascio del servizio;
∗ Scalabilità e flessibilità: ogni servizio è modellato in base alla richiesta che deve soddisfare. L’autonomia di ciascuno permette al team di applicare modifiche in modo facile, veloce e sicuro, garantendo costi ridotti di sviluppo;
∗ Semplicità di distribuzione: poiché un servizio è autosufficiente, esso supporta l’integrazione e la distribuzione continua. In altri termini, ogni servizio è potenzialmente rilasciabile in ogni momento ed eventuali errori non influiscono sull’integrità degli altri componenti;
∗ Libertà tecnologica: il team ha la libertà di scegliere gli strumenti e le tecnologie migliori per risolvere ogni tipo di problema;
∗ Codice riutilizzabile: il codice di un servizio scritto per implementare una certa funzione può essere utilizzato come base di partenza per un’altra funzionalità. Ciò permette la creazione di un template che viene in seguito specializzato per le necessità della nuova funzionalità, senza dover scrivere del codice da zero;
∗ Resilienza: l’indipendenza dei servizi aumenta la resilienza di un’applicazione, permettendo un gestione più solida in caso di errori. In un’architettura monolitica, un errore qualsiasi potrebbe avere ripercussioni sull’intera applicazione. Al contrario, con i microservizi, le applicazioni possono isolare completamente gli errori di un servizio senza bloccare l’intera applicazione. 5.1. BACK-END 57
Figura 5.2: Architettura monolitica vs architettura a microservizi (https://www.redhat.com/it/topics/microservices/what-are-microservices)
Il back-end si basa su uno stile REST-like2:
∗ ogni risorsa è unica e indirizzabile attraverso un URIg; ∗ metodi HTTP standard per il trasferimento di dati tra client e risorse (ad esempio GET, POST, PUT, DELETE).
In REST la risorsa, intesa come aggregato di dati con un nome e una rappresentazione interna, occupa una posizione di rilievo. Su di essa è possibile eseguire le operazioni CRUD (Create, Read, Update e Delete).
Operazione Descrizione Procedura
GET Read Restituisce una risorsa
PUT Update Aggiorna una risorsa
POST Create Crea una nuova risorsa
DELETE Delete Elimina una risorsa
Tabella 5.1: Tabella delle operazioni CRUD
I dati di una risorsa sono rappresentati seguendo lo standard JSON (JavaScript Object Notation) visto lo stretto legame con le tecnologie utilizzate. La struttura JSON è chiara, flessibile e si adatta molto bene al dominio dell’applicazione e permette l’indipendenza completa tra i moduli.
2REST. url: https://en.wikipedia.org/wiki/Representational_state_transfer. 58 CAPITOLO 5. PROGETTAZIONE ARCHITETTURALE
5.1.1 Struttura dei servizi
Figura 5.3: Architettura del modulo di back-end
5.1.2 I servizi I servizi che il modulo di back-end espone sono riportati nella seguente tabella: 5.1. BACK-END 59
Servizio Funzionalità Descrizione
Funzionalità che restituisce tutti i quarter Okrs service okrs disponibili
okrCreate funzionalità che crea un nuovo quarter
Funzionalità che restituisce tutti gli Objectives service objectives obiettivi di un quarter
objectivesCreate Funzionalità che crea un nuovo obiettivo
objectivesDelete Funzionalità che elimina un obiettivo
Funzionalità che restituisce tutti i risultati Keys service keys chiave di un obiettivo
Funzionalità che crea un nuovo risultato keysCreate chiave
Funzionalità che aggiorna un risultato keysUpdate chiave
keysDelete Funzionalità che elimina un risultato chiave
Funzionalità che restituisce tutte le Metrics service metrics metriche di un risultato chiave
metricsCreate Funzionalità che crea una nuova metrica
metricsUpdate Funzionalità che aggiorna una metrica
metricsDelete Funzionalità che elimina una metrica
Funzionalità che restituisce tutte le time Clockify service clockify entries degli utenti del workspace Uqido che rispettano il periodo di validità del quarter
Funzionalità che restituisce tutte gli articoli presenti sul blog https://tech.uqido.com, TechArticles service techArticles caricati durante il periodo di validità del quarter
Funzionalità che restituisce il numero di GitHub service gitHub pull request eseguite dai membri di Uqido durante il periodo di validità del quarter
Tabella 5.2: Tabella dei servizi esposti dal back-end 60 CAPITOLO 5. PROGETTAZIONE ARCHITETTURALE
Ogni funzionalità esposta comunica con Cloud Firestore in modo da mantenere aggiornati in tempo reale i dati relativi ad un quarter su cui sono in corso operazioni di gestione. Inoltre le funzionalità clockify, techArticles e gitHub utilizzano le API esposte rispettivamente da Clockify, WordPress e GitHub per ottenere le informazioni necessarie.
5.1.3 Il database Il database fornito da Firebase è di tipo non relazionale. La progettazione della sua struttura ha dovuto scontrarsi con questa sua caratteristica. Infatti, al contrario di un database relazionale, per reperire un dato memorizzato in Cloud Firestore occorre navigare tra le sue collezioni, giungendo fino al documento interessato. Per evitare che la struttura risultasse troppo innestata, rendendo le chiamate lunghe e verbose, lo scheletro del database è stato linearizzato il più possibile:
Figura 5.4: Struttura delle collezioni del database
Ogni collezione contiene un certo numero di documenti nei quali sono contenuti i veri e propri dati. I campi dato di ogni documento sono i seguenti:
Collezione di Campi dato Descrizione riferimento
okrs id:string Identifica l’id del documento 5.1. BACK-END 61
startingAt:string Identifica la data di inizio del quarter
endingAt:string Identifica la data di fine del quarter
Identifica l’id del quarter di riferimento; objectives okrId:string combacia con l’id di un documento della collezione okrs
description:string Identifica la descrizione dell’obiettivo
Identifica l’id dell’obiettivo di riferimento; keys objectiveId:string combacia con l’id di un documento della collezione objectives
description:string Identifica la descrizione del risultato chiave
evaluationType:string Identifica il tipo del risultato chiave
Identifica un valore limite per completare il risultato chiave; presente solo nei limit:number documenti il cui evaluationType == limit
Identifica l’id del risultato chiave di metrics keyId:string riferimento; combacia con l’id di un documento della collezione keys
author:string Identifica l’autore della metrica
Identifica la data di inserimento della createdAt:string metrica
description:string Identifica la descrizione della metrica
Identifica se la metrica è stata completata o no; presente solo nei documenti il cui checked:boolean risultato chiave di riferimento ha il campo evaluationType == check
users displayName:string Identifica il nome dell’utente
email:string Identifica l’email dell’utente
Identifica l’URL dell’immagine di profilo photoURL:string dell’account Google dell’utente
uid:string Identifica l’id Google dell’utente
Tabella 5.3: Tabella dei campi dato di ogni documento
I campi dato okrId, objectiveId e keyId rappresentano delle sorte di chiavi esterne. 62 CAPITOLO 5. PROGETTAZIONE ARCHITETTURALE
In questo modo è possibile reperire, ad esempio, tutti gli obiettivi di un quarter confrontando il suo campo id con il campo okrId degli obiettivi. Gli endpoint esposti attraverso questa struttura risultano più corti e leggibili. Nel sezione di codifica è possibile vedere alcuni esempi.
5.2 Front-end
Il front-end dell’applicazione è stato sviluppato attraverso il framework Angular. La struttura dell’interfaccia segue di conseguenza le sue regole costruttive. Le fondamenta3 di un’applicazione Angular sono i moduli (NgModules), che forniscono un ambiente per la compilazione dei componenti. In genere, in un sistema complesso, i moduli sono molteplici in modo da facilitare la gestione dello sviluppo e la riusabilità. I componenti Angular definiscono delle classi che contengono i dati e la logica dell’applicazione, a ciascuno dei quali è associato un template HTML che definisce la vista relativa al componente. Infine, Angular fornisce la possibilità di creare dei servizi (services). Essi sono delle vere e proprie classi che implementano una o più funzionalità utilizzabili dai componenti. Ogni servizio è iniettabile (injectable) come dipendenza nei vari componenti, rendendo il codice modulare, riutilizzabile e efficiente. I servizi aderiscono al design pattern creazionale singleton. In questo modo si ha la certezza che, per un determinato servizio, durante l’esecuzione dell’applicazione venga creata una e una sola un’istanza.
Figura 5.5: Architettura di un’applicazione Angular (https://angular.io/guide/architecture)
Il modulo di front-end segue le regole strutturali di Angular. Tutti i componenti e le relative viste gestiscono una parte dell’applicazione e si appoggiano ai servizi disponibili.
3Architettura Angular. url: https://angular.io/guide/architecture. 5.2. FRONT-END 63
5.2.1 Struttura Angular
Figura 5.6: Architettura del modulo di front-end
5.2.2 I moduli I moduli Angular permettono di raggruppare tra loro componenti, direttive e tutte le librerie Angular di cui l’applicazione ha bisogno. La definizione di un modulo avviene attraverso il decoratore @NgModule. In questa applicazione sono presenti 7 moduli: ∗ AppModule: rappresenta il modulo di base dell’applicazione; ∗ AppRoutingModule: rappresenta il modulo per la gestione del routing all’avvio dell’applicazione; ∗ AuthModule: rappresenta il modulo per la gestione dell’autenticazione; ∗ MaterialModule: rappresenta il modulo per la gestione di tutti i componenti di Angular Material utilizzati; ∗ OkrsRoutingModule: rappresenta il modulo per la gestione del routing dopo che l’utente ha effettuato l’autenticazione; ∗ OkrsModule: rappresenta il modulo per la gestione generale del quarter, dagli obiettivi fino alle metriche; ∗ SharedModule: rappresenta il modulo per la gestione delle librerie Angular utilizzate da più componenti. 64 CAPITOLO 5. PROGETTAZIONE ARCHITETTURALE
In fase di progettazione, la decisione di utilizzare più moduli, in particolare i moduli di routing, è strettamente legata al concetto lazy loading di Angular. Come impostazione predefinita, i moduli dell’applicazione vengono caricati nello stesso momento del caricamento dell’applicazione stessa. Ciò comporta un costo molto elevato in termini di risorse, soprattutto se l’applicazione è di grandi dimensioni e presenta un numero elevato di componenti, perché vengono caricati tutti i contenuti disponibili, anche quelli di cui non abbiamo immediatamente bisogno. Al contrario, il lazy loading fornisce uno schema di progettazione rivolto all’ottimizzazione dell’applicazione, permettendo il caricamento della pagina in "pezzi" e non come un unico pacchetto. Una volta definiti i vari moduli, il routing permette di associare un componente ad un indirizzo, dando la possibilità di navigare in sezioni specifiche dell’applicazione. In questo modo, solo quando è richiesto il contenuto di quel particolare componente, vengono caricati tutti i moduli ad esso associati nel modulo di routing. Per fare un esempio pratico pensiamo alla piattaforma in esame: al primo accesso essa naviga alla pagina di autenticazione. Finché l’utente non esegue l’accesso, il modulo OkrsModule, che rappresenta il modulo principale, non viene caricato. In questo modo si garantiscono ottime prestazioni e un consumo ridotto di risorse.
5.2.3 I componenti L’applicazione è costituita dai seguenti componenti:
∗ AppComponent: componente di base dell’applicazione utilizzato per gestire il routing;
∗ OkrsComponent: componente utilizzato per la visualizzazione e la gestione del quarter;
∗ CurrentOkrComponent: componente "di passaggio" per invocare il componente degli obiettivi relativi al quarter corrente;
∗ ObjectivesComponent: componente utilizzato per la visualizzazione e la gestione degli obiettivi;
∗ KeysComponent: componente utilizzato per la visualizzazione dei risultati chiave;
∗ KeyComponent: componente utilizzato per la gestione di un singolo risultato chiave;
∗ MetricsComponent: componente utilizzato per la visualizzazione e la gestione delle metriche;
∗ AuthComponent: componente utilizzato per la gestione dell’autenticazione e la visualizzazione della pagina di login;
∗ QuarterDialogComponent: componente utilizzato per la visualizzazione del dialog che permette la creazione di un nuovo quarter;
∗ ObjectiveDialogComponent: componente utilizzato per la visualizzazione del dialog che permette la creazione di un nuovo obiettivo;
∗ KeyDialogComponent: componente utilizzato per la visualizzazione del dialog che permette la creazione di un nuovo risultato chiave; 5.2. FRONT-END 65
∗ MetricDialogComponent: componente utilizzato per la visualizzazione del dialog che permette la creazione di una nuova metrica da aggiungere alla lista di quelle già presenti;
∗ ConfirmDialogComponent: componente utilizzato per la visualizzazione del dialog che permette di confermare l’eliminazione di obiettivo, di un risultato chiave o di una metrica. Questo tipo di dialog è stato progettato per essere riutilizzabile per qualsiasi operazione di eliminazione;
∗ LimitDialogComponent: componente utilizzato per la visualizzazione del dialog che permette inserire una nuova metrica relativa ad un risultato chiave con evaluationType == "limit";
∗ CheckDialogComponent: componente utilizzato per la visualizzazione del dialog che permette inserire una nuova metrica relativa ad un risultato chiave con evaluationType == "check";
∗ PieChartComponent: componente utilizzato per la gestione dei dati visualizzati attraverso il grafico a torta.
5.2.4 I servizi I componenti si appoggiano ai seguenti servizi:
∗ AuthService: servizio utilizzato per gestire il login e il logout, basandosi sugli strumenti forniti da Firebase Authentication;
∗ UiService: servizio di piccole dimensioni utilizzato per amministrare lo stato degli spinner. Essi sono degli strumenti molto utili per gestire il caricamento del contenuto contenuto di un pagina o il completamento di un’operazione, creando un ambiente user-friendly;
∗ StateService: servizio principale utilizzato per gestire l’intero stato dell’applicazione. Esso coordina le chiamate alle API esposte del back-end e mantiene costantemente aggiornati i dati dell’applicazione che vengono mostrati all’utente.
5.2.5 I modelli Per il modulo di front-end sono stati utilizzati i cosiddetti modelli. Un modello non appartiene al mondo Angular ma rappresenta uno strumento di appoggio per gestire i dati ricevuti dopo aver interrogato le API esposte dal back-end. Essi sono degli oggetti i cui campi dati sono associati ai campi dato del JSON ritornato da una specifica API. Ognuno di questi oggetti può essere istanziato in qualsiasi componente e le sue proprietà possono essere mostrate attraverso template HTML. Tramite i modelli vengono introdotti nell’applicazione dei tipi definiti dall’utente, favorendo di conseguenza la tipizzazione del codice. Nella sezione di codifica è possibile osservare alcuni esempi di modelli.
∗ OkrModel: modello che rappresenta un quarter;
∗ ObjectiveModel: modello che rappresenta un obiettivo;
∗ KeyModel: modello che rappresenta un risultato chiave; 66 CAPITOLO 5. PROGETTAZIONE ARCHITETTURALE
∗ MetricModel: modello che rappresenta una metrica;
∗ UserModel: modello che rappresenta un utente; ∗ ArticleModel: modello che rappresenta un articolo del blog di Uqido; ∗ EntryModel: modello che rappresenta le time entries di Clockify di un utente.
5.2.5.1 Guardia dell’autenticazione Per rendere l’autenticazione più solida possibile, il modulo di routing presenta un meccanismo di controllo molto importante: la guardia dell’autenticazione. La classe AuthGuard implementa l’interfaccia CanActivate di Angular ed esegue tutti i controlli necessari per garantire che le credenziali dell’utente siano corrette. Il modulo di routing permette la navigazione solo se il controllo effettuato dalla guardia ha esito positivo. Capitolo 6
Codifica
Il seguente capitolo presenta le caratteristiche generali dell’applicazione sviluppati durante la fase di codifica, ad esempio la descrizione dei vari endpoint esposti dalle API, la struttura delle risorse in formato JSON, i metodi forniti dal servizio Angular per la gestione dello stato e alcuni screenshot dell’interfaccia. Tramite l’ultima sezione vengono presentate la verifica e la validazione del prodotto.
6.1 Back-end
Lo scopo di questa sezione è quello di fornire un esempio di codifica degli aspetti significativi del modulo di back-end.
6.1.1 Elenco API REST esposte dal back-end
Metodo Endpoint Descrizione
Endpoint utilizzato per recuperare la lista [GET] /okrs di quarter disponibili
Endpoint utilizzato per aggiungere un [POST] /okrCreate nuovo quarter alla lista di quarter disponibili
Endpoint utilizzato per recuperare la lista [GET] /objectives?{okrId} di tutti gli obiettivi relativi all’okrId passato come parametro
Endpoint utilizzato per aggiungere un [POST] /objectivesCreate nuovo obiettivo alla lista di obiettivi di un quarter
Endpoint utilizzato per eliminare un [DELETE] /objectivesDelete/objectiveId obiettivo
67 68 CAPITOLO 6. CODIFICA
Endpoint utilizzato per recuperare la [GET] /keys?{objectiveId} lista di tutti i risultati chiave relativi all’objectiveId passato come parametro
Endpoint utilizzato per aggiungere un [POST] /keysCreate nuovo risultato chiave alla lista di risultati chiave di un obiettivo
Endpoint utilizzato per aggiornare le [PUT] /keysUpdate informazioni di un risultato chiave
Endpoint utilizzato per eliminare un [DELETE] /keysDelete/{keyId} risultato chiave
Endpoint utilizzato per recuperare la lista [GET] /metrics?{keyId} di tutti le metriche relative al keyId passato come parametro
Endpoint utilizzato per aggiungere una [POST] /metricsCreate nuova metrica alla lista di metriche di un risultato chiave
Endpoint utilizzato per aggiornare le [PUT] /metricsUpdate/metricId informazioni di una metrica
Endpoint utilizzato per eliminare una [DELETE] /metricsDelete/{metricId} metrica
Endpoint utilizzato per recuperare le time entries di Clockify di un utente che hanno [GET] /clockify?{startedAt} una data di inizio uguale o superiore alla data di inizio del quarter specificata dal parametro startedAt
Endpoint utilizzato per recuperare le informazioni degli articoli pubblicati sul [GET] /articles/{keyId} blog di Uqido; nel documento associato al parametro keyId vengono successivamente scritti i dati ottenuti dalla chiamata
Endpoint utilizzato per recuperare le informazioni sulle pull request di GitHub effettuate dai membri di Uqido che hanno [GET] /github?{startedAt} una data di inizio uguale o superiore alla data di inizio del quarter specificata dal parametro startedAt 6.1. BACK-END 69
Tabella 6.1: API REST esposte dai microservizi
6.1.2 Esempi di JSON ritornati dalle API 6.1.2.1 Obiettivi
[ { id:"abcd", description:"Obiettivo 1", okrId:"wxyz" }, { id:"efgh", description:"Obiettivo 2", okrId:"wxyz" }, { id:"ijkl", description:"Obiettivo 3", okrId:"wxyz" } ]
JSON contenente le informazioni sugli obiettivi di un quarter ¥
6.1.2.2 Metriche
[ { author:"Mario Rossi", createdAt: "2019-08-29T12:18:23.470Z", description:"Angular Day", keyId:"mnop", id:"qrst" }, { author:"Giorgio Bianchi", createdAt: "2019-08-20T12:10:20.500Z", description:"Google Developer Day", keyId:"mnop", id:"jklm" } ]
JSON contenente le informazioni sulle metriche di un risultato chiave ¥ 70 CAPITOLO 6. CODIFICA
6.1.2.3 Articoli del blog
[ { author":"Sara Verdi", createdAt": "2019-09-02T12:59:16", postId": 2350, description":"Articolo 1", keyId":"abcdef" }, { author:"Umberto Rossi", createdAt: "2019-08-30T09:20:17", postId: 2373, description:"Articolo 2", keyId:"abcdef" } ] JSON contenente le informazioni sugli articoli del blog di Uqido ¥
6.2 Front-end
Lo scopo di questa sezione è quello di fornire un esempio di codifica degli aspetti significativi del modulo di front-end.
6.2.1 Struttura dei modelli Di seguito viene riportata solamente la struttura del modello OkrModel in quanto contiene le caratteristiche significative comuni a tutti i modelli dell’applicazione. import * as firebase from’firebase’; import Timestamp= firebase.firestore.Timestamp; export interface OkrJSON{ id: string; startingAt: Timestamp; endingAt: Timestamp; } export class Okr{ id: string; startingAt: Date; endingAt: Date;
constructor(object?: any){ if (object){ this .id= object.id; this .startingAt= object.startingAt&& new Date(object. startingAt.seconds * 1000); this .endingAt= object.endingAt&& new Date(object.endingAt .seconds * 1000); } } 6.2. FRONT-END 71
static fromJSON(json?: OkrJSON): Okr{ return new Okr(json); } }
Modello Okr ¥ L’oggetto Okr contiene le informazioni riguardanti un quarter specifico, in particolare data di inizio, data di fine e il suo codice identificativo. Come possiamo notare, ogni oggetto Okr viene costruito a partire da un altro tipo di oggetto, in questo caso OkrJSON. I campi dato di quest’ultimo combaciano con il JSON ritornato dalla chiamata API. Quando invocato, il metodo fromJSON(json?: OkrJSON) ritorna un nuovo Okr richiamando il suo costruttore. Utilizzando questo modello è possibile adattare le informazioni ottenute attraverso le API del back-end in modo che siano sempre leggibili dall’applicazione Angular. Il campo dati startingAt così come endingAt inizialmente sono di tipo Timestamp, un formato utilizzato da Firebase e non riconosciuto dalla piattaforma. Attraverso il costruttore, gli omonimi campi dati dell’oggetto Okr sono istanziati come oggetti di tipo Date, estrapolando le informazioni necessarie dal Timestamp di partenza e garantendo perfetta compatibilità con l’applicazione.
6.2.2 Servizi Di seguito vengono descritti i metodi esposti dal servizio StateService, essendo lo strumento principale di gestione dello stato dell’applicazione.
Metodo Descrizione
Esegue la chiamata API per recuperare la getOkrs() lista di quarter disponibili
Calcola il quarter corrente confrontando la isCurrentOkr(okr:Okr) data di inizio e la data di fine del parametro okr con la data corrente
Aggiorna la lista di quarter updateCurrentOkr(okr:Okr) dell’applicazione dopo un’operazione di creazione
Esegue la chiamata API per recuperare la setObjectives(okrId:string) lista di obiettivi del quarter associato al parametro okrId
Aggiorna la lista di obiettivi del quarter updateObjective(objective:Objective) dell’applicazione dopo un’operazione di creazione
Aggiorna la lista di obiettivi del quarter downdateObjective(objectiveId:string) dell’applicazione dopo un’operazione di eliminazione 72 CAPITOLO 6. CODIFICA
Esegue la chiamata API per recuperare getKeyWithObjectiveId(objectiveId:string) la lista di risultati chiave di un obiettivo associato al parametro objectiveId
Aggiorna la lista di risultati chiave updateKey(key:Key) di un obiettivo dell’applicazione dopo un’operazione di creazione
Aggiorna la lista di risultati chiave downdateKey(keyId:string) di un obiettivo dell’applicazione dopo un’operazione di eliminazione
Esegue la chiamata API per recuperare getMetricsWithKeyId(keyId:string) la lista di metriche di un risultato chiave associato al parametro keyId
Aggiorna la lista di metriche di un risultato updateMetric(metric:Metric) chiave dell’applicazione dopo un’operazione di creazione
Aggiorna la lista di metriche di un risultato downdateMetric(metricId:string) chiave dell’applicazione dopo un’operazione di eliminazione
Aggiorna il numero di metriche totali updateLimitMetricCount(keyId:string) relative ad un risultato chiave di tipo limit individuato dal parametro keyId
Aggiorna il numero di metriche totali updateCheckMetricCount(metric:Metric) relative ad un risultato chiave di tipo check individuato dal parametro keyId
Aggiorna il numero di metriche totali relative ad un risultato chiave individuato downdateMetricCount(keyId:string) dal parametro keyId dopo un’operazione di eliminazione
Esegue la chiamata API per recuperare le time entries di Clockify di ogni utente che getClockifyTimeEntries(startedAt:Date) hanno una data di inizio uguale o superiore alla data di inizio del quarter specificata dal parametro startedAt
Esegue la chiamata API per recuperare gli getTechArticles(keyId:string) articoli pubblicati sul blog Uqido 6.2. FRONT-END 73
Esegue la chiamata API per recuperare le pull request di GitHub di ogni utente getPullRequest(startedAt:Date) che sono state eseguite dopo la data di inizio del quarter specificata dal parametro startedAt
Permette di attivare o disattivare la changeOption() modalità di modifica
Tabella 6.2: Metodi esposti dal servizio StateService
6.2.3 Screenshot dell’applicazione
Figura 6.1: Pagina di autenticazione 74 CAPITOLO 6. CODIFICA
Figura 6.2: Pagina principale quarter
Figura 6.3: Sidenav laterale 6.2. FRONT-END 75
Figura 6.4: Dialog aggiunta risultato chiave
Figura 6.5: Pagina delle metriche 76 CAPITOLO 6. CODIFICA
6.3 Verifica e validazione 6.3.1 Verifica Con il termine verifica si intende il processo che ha il compito di accertare che durante lo sviluppo di una funzionalità non siano stati introdotti errori. La verifica risponde alla domanda "Did I build the system right?". Per effettuare una verifica accurata e di qualità, il software è stato analizzato utilizzando due tecniche: ∗ Analisi statica; ∗ Analisi dinamica. Inoltre, per raggiungere un grado di correttezza adeguato, è stata adottata la metodologia correctness by construction che prevede la definizione di regole e strategie per la stesura di codice facile da verificare durante lo sviluppo.
6.3.2 Analisi statica L’analisi statica è un tecnica di verifica del codice che non prevede la sua esecuzione. WebStorm, l’IDE utilizzato per lo sviluppo di entrambi i moduli dell’applicazione, fornisce di default diversi tool per eseguire attività di analisi statica, evidenziando bug, incongruenze, ridondanze e violazioni delle specifiche di codifica proprio mentre si sta scrivendo. Questi possibili errori sono molteplici: variabili dichiarate e mai inizializzate, variabili scritte e mai lette, conversioni automatiche, variabili costanti ridefinite, duplicazione del codice, metodi mai invocati ecc.
6.3.3 Analisi dinamica L’analisi dinamica del codice è il metodo di analisi di un programma durante la sua esecuzione. Il processo di analisi dinamica può essere suddiviso in diverse fasi: preparazione dei dati di input, esecuzione di un programma di test e raccolta dei parametri necessari e analisi dei dati di output. Eseguire attività di verifica tramite analisi statica può solo dimostrare la presenza di bug ma mai la loro assenza. Pertanto è necessario sviluppare una serie di test che mirino ad azzerare il numero di difetti dell’applicazione. L’oggetto di verifica di un test può variare: un singolo modulo, un gruppo di moduli collegati tra loro per uso, struttura, scopo o comportamento) o l’intero sistema. Esistono perciò diversi tipi di test: ∗ Test di unità: verificano l’unità, il più piccolo sottosistema possibile (per esempio una classe o un metodo) che può essere testato separatamente. Sono veloci da eseguire e indipendenti tra loro; ∗ Test di integrazione: verificano l’integrazione tra più sotto-sistemi. Sono più lenti da configurare e da eseguire; ∗ Test di sistema: verificano il comportamento dell’intero sistema. Lo scopo principale di questo tipo di test è la verifica rispetto alle specifiche tecniche; ∗ Test di accettazione: anche conosciuti come UAT (User Acceptance Testing), verificano tutto il sistema confrontando i casi d’uso e i requisiti concordati con l’utente finale; 6.3. VERIFICA E VALIDAZIONE 77
∗ Test di regressione: riutilizzo di vecchi test di unità per verificare che durante lo sviluppo di nuove funzionalità non siano stati introdotti errori in parti del sistema già testate. L’efficacia dei test si manifesta nel tempo. In altre parole, i test devono essere ripetibili: l’ambiente e le condizioni di svolgimento devono essere sempre uguali, in modo da poter confrontare i risultati ottenuti più volte e in momenti diversi. Inoltre l’esecuzione dei test deve essere automatizzata. Durante il periodo di stage sono stati testati i vari componenti dell’applicazione Angular attraverso gli strumenti forniti da Angular CLI. Quest’ultimo genera per ogni componente un file di test (component.spec.ts) che permette di eseguire test di unità adottando il framework JavaScript Jasmine. Questo framework utilizza Karma come test runner. Inoltre sono stati eseguiti test di accettazione in presenza del tutor aziendale, dei project manager e del team leader, dando esito positivo e riscontrando il pieno soddisfacimento dei requisiti richiesti.
6.3.4 Validazione Con il termine validazione si intende il processo che ha il compito di accertare, attraverso prove e misurazioni oggettive, che le specifiche del software siano adeguate ai bisogni dell’utente. La validazione risponde alla domanda "Did I build the right system?". La piattaforma sviluppata rispetta tutti i requisiti definiti in fase di progettazione e ha soddisfatto tutte le aspettative. Essa è già entrata in funzione all’interno dell’azienda, permettendo di definire e tracciare gli obiettivi di ogni quarter.
Capitolo 7
Conclusioni
7.1 Consuntivo finale
Il progetto di stage svolto presso Uqido ha avuto una durata di 330 ore, a fronte delle 320 ore previste dal piano di lavoro suddivise in otto settimane. L’aumento è dovuto al fatto che, per motivi di salute e di impegni universitari, è stato necessario prorogare di una settimana il termine dello stage in modo da coprire il monte ore pianificato. Sebbene alcune tecnologie abbiano richiesto uno studio preliminare, in primis Angular, il tempo a disposizione è stato sufficiente per completare tutti gli obiettivi. Di seguito è possibile osservare il consuntivo finale delle attività svolte durante il periodo di stage: ∗ Studio di fattibilità (40 ore): questa fase ha richiesto diverse ore per lo studio delle varie tecnologie utilizzate, alcune di queste completamente nuove. La difficoltà maggiore è stata individuare i punti di contatto tra le varie tecnologie. Tutti membri del team di sviluppo hanno dato il loro contributo per aiutarmi ad avere una visione d’insieme precisa; ∗ Analisi dei requisiti (50 ore): questa fase si è rivelata in linea con i tempi preventivati. Dopo uno studio approfondito è risultato più semplice svolgere un’analisi dei requisiti del sistema che fosse più chiara possibile; ∗ Progettazione architetturale (60 ore): questa fase ha richiesto un monte ore superiore a quanto preventivato. In particolare, la strutturazione iniziale del database si è rivelata inadatta per sviluppare successivamente i servizi del modulo di back-end. Di conseguenza, la progettazione del database ha subito delle modifiche che sono state molto utili in fase di codifica ma che hanno richiesto delle ore extra; ∗ Codifica (150 ore): questa fase ha richiesto circa 20 ore aggiuntive rispetto a quanto preventivato. Le difficoltà incontrate riguardano entrambi i moduli: – per quanto riguarda il modulo di back-end, la codifica dei servizi che utilizzano API esterne, ad esempio le API di GitHub o di Clockify, ha dovuto scontrarsi con i dati ritornati dalle API stesse. Le informazioni contenute nei JSON andavano continuamente adattate e filtrate per soddisfare le richieste del front-end. Allo stesso modo tutte le operazioni CRUD hanno richiesto una codifica specifica, in modo che ogni interazione con il database ritornasse informazioni complete e chiare;
79 80 CAPITOLO 7. CONCLUSIONI
– per quanto riguarda il modulo di front-end, la difficoltà maggiore è legata alla gestione dei flussi di dati asincroni derivanti dal modulo di back-end. Questo tipo di dati ha richiesto un codifica specifica attraverso la libreria RxJS, la quale ha permesso di creare un’applicazione consistente e reattiva ad ogni interazione con l’utente.
∗ Verifica e validazione (20 ore): questa fase è in linea con quanto preventivato. I processi di testing sono stati realizzati sia durante la fase codifica sia alla fine di quest’ultima;
∗ Documentazione (10 ore): questa fase non ha richiesto conoscenze o strumenti particolari e le ore richieste sono in linea con quanto preventivato.
7.2 Raggiungimento degli obiettivi
In questa sezione vengono elencati gli obiettivi pianificati, come riportato in sezione 2.3.2, e il relativo stato di completamento.
Obiettivi obbligatori Stato
Implementazione funzionalità di base Completato dell’applicazione tramite operazioni CRUD
Studio, apprendimento e utilizzo del framework Angular per lo sviluppo dell’interfaccia Completato dell’applicazione
Tabella 7.1: Tabella degli obiettivi obbligatori
Obiettivi desiderabili Stato
Implementazione ulteriori funzionalità dell’applicazione sfruttando API di servizi Completato esterni (ad esempio Github o Clockify)
Suite di test completo per il codice prodotto Completato
Documentazione completa Completato
Tabella 7.2: Tabella degli obiettivi desiderabili 7.3. CONOSCENZE ACQUISITE E VALUTAZIONE PERSONALE 81
Obiettivi facoltativi Stato
Ulteriori modifiche all’applicazione Completato
Tabella 7.3: Tabella degli obiettivi facoltativi
7.3 Conoscenze acquisite e valutazione personale
Questo progetto di stage è stato estremamente utile e fortemente formativo. La realtà di Uqido racchiude un team giovane, coeso e intraprendente. Poter interagire con un personale disponibile e lavorare seguendo le metodologie agili mi ha permesso di mantenere una comunicazione chiara con tutti i membri e di risolvere problemi che, prima di iniziare, non pensavo sarei stato in grado di risolvere. L’applicazione è stata presentata a tutto lo staff durante una riunione generale e tutti ne sono rimasti entusiasti, complimentandosi per il lavoro svolto. Le conoscenze acquisite sono molte. Ho toccato con mano il mondo dello sviluppo web, lavorando con software e strumenti moderni. Ho approfondito il linguaggio di programmazione JavaScript, osservando i suoi pregi e i suoi difetti. Ho imparato ad utilizzare il framework Angular per lo sviluppo di Single Page Application e ho integrato i servizi offerti da Google tramite la piattaforma Firebase. Questa esperienza ha alimentato la mia passione nei confronti dell’informatica e della tecnologia, confermando che è possibile progettare e sviluppare soluzioni a problematiche di qualsiasi tipo. Inoltre mi ha permesso di crescere sia a livello personale sia a livello lavorativo, grazie alle relazioni stabilite in azienda.
7.4 Sviluppi futuri
La versione attuale dell’applicazione soddisfa tutti i requisiti previsti per questo progetto di stage. La gestione degli OKR è di fatto automatica e permette, quindi, all’utente di eseguire qualsiasi tipo di operazione. I dati memorizzati nel database vengono aggiornati costantemente e non necessitano di un controllo frequente da parte di un responsabile. Tutto ciò non significa che la piattaforma sia definitiva; essa può essere considerata un buon prototipo di partenza per l’azienda per costruire un sistema più stabile e con un design di interfaccia migliore. I miglioramenti e gli sviluppi previsti per il futuro sono i seguenti:
∗ Creazione di nuovi servizi del modulo di back-end: gli OKR sono, a tutti gli effetti, uno strumento per migliorare il modo di lavorare dell’azienda ma anche del singolo. Per questo motivo, si prevede che vengano istituiti traguardi sempre più ambiziosi, gestibili attraverso la piattaforma;
∗ Suddivisione dei servizi Angular: i servizi attuali, soprattutto il servizio di gestione dello stato dell’applicazione, presentano numerose funzionalità. Per permettere un maggiore controllo sull’aggiornamento dei dati che l’utente visualizza, si prevede una ripartizione delle funzionalità offerte, raggruppate per scopo. In questo modo si fornisce, inoltre, una struttura adatta all’aggiornamento delle funzionalità stesse; 82 CAPITOLO 7. CONCLUSIONI
∗ Estensione dell’architettura Angular: tutti i componenti Angular sono stati realizzati cercando di specializzarli il più possibile in relazione al loro scopo. In questo modo si garantisce che l’aggiunta di nuovi componenti non richieda l’adattamento della logica di componenti preesistenti; ∗ Miglioramento del design dell’interfaccia: tutte le viste di ogni componente sono state sviluppate con l’aiuto di Angular Material. Visti i numeri strumenti offerti dal servizio, si prevede che l’interfaccia venga migliorata sotto vari punti di vista, ad esempio lo stile della lista di obiettivi e della lista di metriche, il menù di gestione del quarter e gli spinner per il caricamento dei contenuti della pagina. Glossario
Agile Nell’ingegneria del software, l’espressione metodologia agile si riferisce a un insieme di metodi di sviluppo del software, tra i quali la formazione di team di sviluppo piccoli, poli-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva, e il coinvolgimento diretto e continuo del cliente. 2, 83 API Application Programming Interface è un termine utilizzato per indicare ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l’espletamento di un determinato compito all’interno di un certo programma. 8, 83 AR Augmented Reality, in italiano realtà aumentata, è un termine utilizzato per indicare la rappresentazione di una realtà alterata in cui, alla normale realtà percepita dai nostri sensi, vengono sovrapposte informazioni artificiali e virtuali. 1, 83
B2B Business To Business, in italiano commercio interaziendale, è una locuzione utilizzata per descrivere le transazioni commerciali elettroniche tra imprese. 1, 83 Back-end Parte di un software con la quale l’utente interagisce indirettamente, di solito attraverso l’utilizzo di un’interfaccia. 2, 83
Client-server Architettura di rete nella quale genericamente un computer o un terminale si connette ad un server per la fruizione di un certo servizio. 12, 83 Cloud-hosting Infrastruttura che fornisce una serie di servizi remoti/virtuali. 15, 83 Commit Insieme di modifiche che sono state esplicitamente validate. Esso produce una nuova versione del codice sorgente. 19, 83
Deployment Termine inglese, letteralmente lo spiegamento, che indica il rilascio di un’applicazione con relativa messa in funzione. 15, 83
Event handler Procedura o funzione che opera in modo asincrono e gestisce gli input generati dal verificarsi di un evento. 12, 83 Event listener Procedura o funzione di un programma che attende che si verifichi un evento, ad esempio il click del mouse o un’attività di rete. 12, 83
Firebase Piattaforma per lo sviluppo di applicazioni web e mobili di proprietà di Google. 8, 83
83 84 Glossario
Framework In informatica, è un’architettura logica di supporto su cui un software può essere progettato e realizzato, spesso facilitandone lo sviluppo da parte del programmatore. 2, 84
Front-end Parte di un software visibile all’utente e con cui egli può interagire, tipicamente una interfaccia utente. 8, 84
Hosting Servizio di rete che consiste nell’allocare su un server i contenuti di un sito o di un’applicazione web, rendendolo così accessibile dalla rete Internet e ai suoi utenti. 4, 84
ICT Information and Communication Technology, tecnologia che deriva dall’uso contemporaneo dell’informatica e della telematica. 1, 84
IDE Integrated Development Environment, programma che racchiude gli strumenti di base necessari agli sviluppatori per scrivere e testare il software. In genere, contiene un editor, un compilatore ed un debugger che lo sviluppatore accede attraverso una singola interfaccia grafica. 22, 84
Repository Termine inglese che significa deposito, ripostiglio. In ambito informatico viene usato per indicare una struttura dati in cui vengono gestiti i metadati per un insieme di file, come ad esempio lo storico dei cambiamenti avvenuti o l’insieme delle modifiche effettuate. 19, 84
REST Representational State Transfer, stile architetturale per sistemi distribuiti attraverso il quale è possibile trasmettere dati su HTTP senza ulteriori livelli. 8, 84
SDK Software Development Kit , è un termine utilizzato per indicare un insieme di strumenti per lo sviluppo e la documentazione di un software. 8, 84
Stakeholders letteralmente portatore di interesse, è un soggetto o un gruppo che ha influenza nei confronti di un’iniziativa economica o un progetto. 3, 84
Task Compito assegnato ad un segmento temporale. 12, 84
Thread Flusso di esecuzione indipendente all’interno ad un processo, utilizzato per svolgere un’attività specifica del processo stesso. 12, 84
UML in ingegneria del software UML, Unified Modeling Language (ing. linguaggio di modellazione unificato) è un linguaggio di modellazione e specifica basato sul paradigma object-oriented. L’UML svolge un’importantissima funzione di “lingua franca” nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa tale linguaggio per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. 25, 84
URI Uniform Resource Identifier, termine utilizzato per indicare una sequenza di caratteri che identifica universalmente ed univocamente una risorsa, ad esempio un indirizzo web. 57, 84 Glossario 85
URL Uniform Resource Locator, termine utilizzato per indicare una sequenza di caratteri che identifica univocamente l’indirizzo di una risorsa. 17, 85
VCS Version Control System, in italiano sistema di controllo versione, è un termine utilizzato per indicare un software che permette di organizzare e gestire le versioni di vari tipi di file. 4, 85 VR Virtual Reality, in italiano realtà virtuale, è un termine utilizzato per indicare una realtà simulata, costruita attraverso l’uso del computer. 1, 85
XR Extended Reality, in italiano realtà estesa, è un termine utilizzato per indicare tutte le combinazioni di ambienti reali e virtuali e alle interazioni uomo-macchina generate dalla tecnologia informatica. L’acronimo è un termine generale che racchiude sia realtà virtuale sia realtà aumentata. 2, 85
Bibliografia
Riferimenti bibliografici
Deeleman, Pablo e Christoffer Noring. Learning Angular - Second Edition. Packt Publishing, 2017 (cit. a p. 16). Hossain, Monsur. CORS in Action: Creating and consuming cross-origin APIs. Manning Publications, 2014 (cit. a p. 14).
Siti web consultati
Agular Material. url: https://material.angular.io (cit. a p. 18). Angular - Reactive Forms. url: https://angular.io/guide/reactive-forms (cit. a p. 17). Angular - Routing. url: https://angular.io/guide/router (cit. a p. 17). Architettura Angular. url: https://angular.io/guide/architecture (cit. a p. 62). Autenticazione con AngularFire. url: https://angularfirebase.com/lessons/ angular-firebase-authentication-tutorial-oauth/ (cit. a p. 17). Branching. url: https://git-scm.com/book/it/v1/Diramazioni-in-Git-Cos- %C3%A8-un-Ramo (cit. a p. 5). Cloud Firestore. url: https://firebase.google.com/products/firestore/ (cit. a p. 15). Cloud Functions. url: https://firebase.google.com/products/functions/ (cit. a p. 15). Firebase Hosting. url: https://firebase.google.com/products/hosting/ (cit. a p. 15). Git. url: https://git-scm.com/about (cit. a p. 19). Metodologia agile. url: https://medium.com/geekandjob-blog/scrum-cos%C3%A8- e-come-funziona-metodologia-agile-7c8988feec01 (cit. a p. 2). Metodologia Scrum. url: https://www.scrumguides.org/docs/scrumguide/v2017/ 2017-Scrum-Guide-Italian.pdf (cit. a p. 2). Microservizi. url: https://aws.amazon.com/it/microservices (cit. a p. 55).
87 88 BIBLIOGRAFIA
Microservizi tramite Cloud Functions. url: https://medium.com/billie-finanzratgeber/ writing-microservices-with-google-cloud-functions-231205d1a94 (cit. a p. 15). Modulo HTTPS in Node.js. url: https://nodejs.org/api/https.html (cit. a p. 13). Node.js. url: https://nodejs.org/it/about (cit. a p. 12). Node.js - Concetti base. url: https://medium.com/@LindaVivah/the-beginners- guide- understanding- node- js- express- js- fundamentals- e15493462be1 (cit. a p. 12). REST. url: https://en.wikipedia.org/wiki/Representational_state_transfer (cit. a p. 57). TypeScript. url: https://www.typescriptlang.org/ (cit. a p. 22).