Università degli Studi di Padova - SIAGAS

Pagina creata da Matteo De Marco
 
CONTINUA A LEGGERE
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova
    Dipartimento di Matematica ‘Tullio Levi-Civita’

             Corso di Laurea in Informatica
              Anno accademico 2017/2018

Standard Prototype InfoCert: un framework per
      la produzione di software di qualità

 Studente             Todescato Matteo, matricola 1121857
 Relatore             Dott. Vardanega Tullio
 Azienda ospitante    InfoCert S.P.A.
 Tutor aziendale      Menegon Federico
Università degli Studi di Padova - SIAGAS
Matteo Todescato, 18 settembre 2018
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova - SIAGAS
Dedicato alla mia famiglia
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova - SIAGAS
Sommario

Il presente documento descrive il lavoro svolto durante il periodo di stage, della
durata di trecentoventi ore, dal laureando Matteo Todescato presso l’azienda
InfoCert S.P.A. Gli obiettivi da raggiungere erano molteplici.
In primo luogo il progetto ha previsto lo sviluppo di una web application che
utilizzasse i nuovi framework aziendali per sviluppo. In secondo luogo il progetto
ha previsto un rilascio di questa applicazione, con la creazione di un ambiente di
sviluppo. Tutto questo corredato da documentazione, necessaria per distribuire
l’applicazione internamente all’azienda come esempio del nuovo standard.

                                        v
Università degli Studi di Padova - SIAGAS
INDICE

Indice

1 L’Azienda                                                                                                  1
  1.1 Profilo aziendale . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    1
  1.2 Modello di sviluppo . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .    2
  1.3 Organizzazione . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
  1.4 Tecnologie utilizzate e processi aziendali    .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
  1.5 InfoCert e l’innovazione . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .    7

2 Perché questo stage?                                                                                       9
  2.1 Il problema . . . . . . . . . . . . . . . . . . . .           .   .   .   .   .   .   .   .   .   .    9
  2.2 La strategia di InfoCert . . . . . . . . . . . . .            .   .   .   .   .   .   .   .   .   .    9
  2.3 Motivazioni della scelta dello stage . . . . . . .            .   .   .   .   .   .   .   .   .   .   10
  2.4 Obiettivi e vincoli dello stage . . . . . . . . . .           .   .   .   .   .   .   .   .   .   .   10
  2.5 Pianificazione dello sviluppo . . . . . . . . . . .           .   .   .   .   .   .   .   .   .   .   11
      2.5.1 Milestone . . . . . . . . . . . . . . . . .             .   .   .   .   .   .   .   .   .   .   13
  2.6 Vincoli tecnologici e metodologici . . . . . . . .            .   .   .   .   .   .   .   .   .   .   13
      2.6.1 Metodo di sviluppo . . . . . . . . . . . .              .   .   .   .   .   .   .   .   .   .   13
      2.6.2 Gherkin e Cucumber . . . . . . . . . . .                .   .   .   .   .   .   .   .   .   .   14
      2.6.3 BECON . . . . . . . . . . . . . . . . . .               .   .   .   .   .   .   .   .   .   .   15
      2.6.4 FECON . . . . . . . . . . . . . . . . . .               .   .   .   .   .   .   .   .   .   .   16
              2.6.4.1 Redux . . . . . . . . . . . . . .             .   .   .   .   .   .   .   .   .   .   17
      2.6.5 Creazione degli ambienti per lo sviluppo                .   .   .   .   .   .   .   .   .   .   19
      2.6.6 Confluence . . . . . . . . . . . . . . . .              .   .   .   .   .   .   .   .   .   .   22

3 Lo Sviluppo di SPICe                                                                                      23
  3.1 Metodo di lavoro e tecnologie aggiuntive . . . . . . .                    .   .   .   .   .   .   .   23
      3.1.1 Test-driven development . . . . . . . . . . . .                     .   .   .   .   .   .   .   23
      3.1.2 Versionamento e gestione delle configurazioni                       .   .   .   .   .   .   .   24
             3.1.2.1 GitFlow . . . . . . . . . . . . . . . .                    .   .   .   .   .   .   .   24
      3.1.3 Stile di codifica . . . . . . . . . . . . . . . . .                 .   .   .   .   .   .   .   27
      3.1.4 Diagrammi UML . . . . . . . . . . . . . . . .                       .   .   .   .   .   .   .   28
  3.2 Sviluppo di SPICe . . . . . . . . . . . . . . . . . . .                   .   .   .   .   .   .   .   29
      3.2.1 Analisi dei requisiti . . . . . . . . . . . . . . .                 .   .   .   .   .   .   .   29
      3.2.2 Progettazione . . . . . . . . . . . . . . . . . .                   .   .   .   .   .   .   .   30
      3.2.3 Codifica . . . . . . . . . . . . . . . . . . . . .                  .   .   .   .   .   .   .   34
      3.2.4 Verifica . . . . . . . . . . . . . . . . . . . . .                  .   .   .   .   .   .   .   35
      3.2.5 Deployment . . . . . . . . . . . . . . . . . . .                    .   .   .   .   .   .   .   36
      3.2.6 Validazione . . . . . . . . . . . . . . . . . . .                   .   .   .   .   .   .   .   38
  3.3 Risultati raggiunti . . . . . . . . . . . . . . . . . . .                 .   .   .   .   .   .   .   39

                                       vii
INDICE

4 Valutazione retrospettiva                                                                  41
  4.1 Raggiungimento degli obiettivi di stage . . . . . . . .    .   .   .   .   .   .   .   41
      4.1.1 Raggiungimento obiettivi formativi . . . . . .       .   .   .   .   .   .   .   42
  4.2 Competenze richieste per lo svolgimento del progetto       .   .   .   .   .   .   .   42
  4.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   43

Glossario                                                                                    45

Acronimi                                                                                     49

                                     viii
ELENCO DELLE FIGURE

Elenco delle figure

 1.1   Modello di sviluppo Scrum, fonte: DTU apppm wiki, [Voc16] . .                 2
 1.2   Confronto tra lo sviluppo agile con un metodo tradizionale a ca-
       scata nella struttura dei rilasci, fonte: Wikipedia Commons, [Lit09]          4
 1.3   Fasi dello sviluppo DevOps, fonte: Wikipedia Commons, [Kha16]                 4
 1.4   Schema di una applicazione API REST-based, fonte: Microsoft
       Developer Network, [Kea15] . . . . . . . . . . . . . . . . . . . . .          6
 1.5   Immagine rappresentante la toolchain DevOps utilizzata in InfoCert            7

 2.1   Diagramma di Gantt rappresentate la pianificazione della tabel-
       la 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   13
 2.2   Diagramma delle classi di un servizio Representational State Trans-
       fer (REST) sviluppato con BECON . . . . . . . . . . . . . . . .              16
 2.3   interfaccia grafica di esempio . . . . . . . . . . . . . . . . . . . .       17
 2.4   Esempio del flusso di passaggio dei dati nelle architetture tradi-
       zionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    18
 2.5   Esempio del flusso di passaggio dei dati con Redux . . . . . . . .           19
 2.6   Architettura del sistema di integrazione . . . . . . . . . . . . . .         21

 3.1   Diagramma del ciclo di sviluppo test-driven, fonte: Hanselt.com, [Bog16] 23
 3.2   Esempio di repository strutturata con l’utilizzo di GitFlow, fonte:
       nvie.com, [Dri10] . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
 3.3   Esempio di ciclo di vita di un branch per l’aggiunta di una nuova
       funzionalità, fonte: nvie.com, [Dri10] . . . . . . . . . . . . . . . . 26
 3.4   Diagramma delle classi del servizio REST di Standard Prototype
       InfoCErt (SPICe) . . . . . . . . . . . . . . . . . . . . . . . . . . 31
 3.5   Aggiornamento della configurazione di Puppet su GitLab . . . . . 37
 3.6   Aggiornamento della configurazione della macchina tramite Puppet 38

                                        ix
ELENCO DELLE TABELLE

Elenco delle tabelle

 2.1   Pianificazione della quantità di ore . . . . . . . . . . . . . . . . .                                              12

 3.1   Riepilogo   requisiti . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
 3.2   Riepilogo   del codice prodotto     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   35
 3.3   Riepilogo   test di unità . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   36
 3.4   Riepilogo   test di validazione .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   39

 4.1   Tabella degli obiettivi di stage soddisfatti . . . . . . . . . . . . .                                              41

                                       xi
LISTINGS

Listings

 2.1   Esempio di un requisito scritto in Gherkin . . . . . . . . . . . . .      14
 2.2   Esempio di implementazione di un test di validazione . . . . . . .        15
 3.1   Esempio di codice JavaScript scritto seguendo delle style guide .         28
 3.2   Esempio di codifica dei requisti in modo scorretto . . . . . . . . .      29
 3.3   Esempio di codifica di un requisito in modo corretto . . . . . . .        30
 3.4   Esempio di classe processata da Immutables.org per la creazione
       di oggetti immutabili . . . . . . . . . . . . . . . . . . . . . . . . .   34
 3.5   Funzione presente nei test di esempio . . . . . . . . . . . . . . . .     35

                                      xiii
CAPITOLO 1. L’AZIENDA

1. L’Azienda

1.1     Profilo aziendale
InfoCert è leader del mercato italiano nei servizi di digitalizzazione e demateria-
lizzazione nonché una delle principali Certification Authority a livello europeo
per i servizi
   • Posta Elettronica Certificata. Tipologia particolare di posta elettronica,
     con in più alcune caratteristiche di sicurezza e di certificazione della tra-
     smissione. Consente infatti di inviare e ricevere messaggi di testo e allegati
     con lo stesso valore legale di una raccomandata con avviso di ricevimento.
   • Firma Digitale. È l’equivalente informatico di una firma posta su carta.
     La sua funzione è quella di attestare la validità, la veridicità e la paternità
     di un file di dati.
   • Conservazione digitale. È un Processo che permette, nei casi previsti dalla
     legge, di distruggere l’originale cartaceo o di non procedere con la sua
     stampa. Serve a garantire autenticità, integrità, affidabilità, leggibilità e
     reperibilità dei documenti.
Da dicembre 2015 InfoCert è anche gestore accreditato AgID dell’identità di-
gitale di cittadini e imprese, in conformità ai requisiti regolamentari e tecnici
dello SPID (Sistema Pubblico per la gestione dell’Identità Digitale).
InfoCert e di proprietà del gruppo Tecnoinvestimenti SPA che è tra gli operatori
leader in Italia nelle tre aree di business:
   • Digital Trust
   • Credit Information & Management
   • Sales & Marketing Solutions
La Business Unit Digital Trust eroga, attraverso le società InfoCert, Sixtema
e Visura, prodotti e servizi per la digitalizzazione documentale, la fatturazione
elettronica, la posta elettronica certificata (PEC) e la firma digitale.
La società progetta e sviluppa soluzioni informatiche ad alto valore tecnologico
di dematerializzazione dei processi documentali. I clienti, siano essi imprese
o professionisti, vengono accompagnati nella scelta di servizi e soluzioni pie-
namente rispondenti alle esigenze organizzative, così come ai vincoli normativi
generali e specifici di settore.
InfoCert rivolge la propria offerta di prodotti sia ad Ordini Professionali e Profes-
sionisti sia ad piccole e grandi imprese, pubbliche e private operanti in numerosi
settori, InfoCert ha clienti anche di rilevanza internazionale nei settori:

                                         1
CAPITOLO 1. L’AZIENDA

   • Bancario
   • Assicurativo
   • Farmaceutico
   • Manifatturiero
   • Energy
   • Utilities
   • Distribuzione Commerciale
   • Ambiente
   • Qualità
   • Sicurezza
   • Sanità
   • Pubblica Amministrazione
Le certificazioni di qualità ISO 9001, 27001 e 20000 testimoniano l’impegno
di InfoCert ai massimi livelli nell’erogazione dei servizi e nella gestione del-
la sicurezza con attenzione ai temi di sostenibilità ambientale (certificazione
ISO14001). Inoltre il Sistema di Gestione della Sicurezza delle Informazioni
InfoCert è certificato ISO/IEC 27001:2013 per le attività EA:33–35.

1.2     Modello di sviluppo
InfoCert negli ultimi anni ha scelto di abbandonare un classico modello di svi-
luppo a cascata e di adottare lo Scrum.
Lo Scrum è un framework di sviluppo agile G per la gestione del ciclo di sviluppo
del software, iterativo ed incrementale, concepito per gestire progetti e prodotti
software o applicazioni di sviluppo. La figura 1.1 illustra la struttura di questo
modello di sviluppo.

  Figura 1.1: Modello di sviluppo Scrum, fonte: DTU apppm wiki, [Voc16]

                                        2
CAPITOLO 1. L’AZIENDA

    In InfoCert i team di sviluppo hanno una dimensione che va dai 5 ai 9
componenti, questi team sono composti dagli sviluppatori, uno ScrumMaster G
che si occupa di facilitare al team il raggiungimento degli obiettivi, ed un Product
Owner G che rappresenta il cliente ed è responsabile nell’assicurare che il team
fornisca valore al business.
Gli sprint hanno una durata di quindici giorni e sono preceduti dallo sprint
planning durante il quale il team affronta le seguenti tematiche:
   • definizione degli obiettivi dello sprint e l’insieme di funzionalità su cui
     impegnarsi
   • stima del tempo e pianificazione per lo sprint

Gli stand-up G , brevi riunioni che il team svolge giornalmente, scandiscono il
corso dello sprint e tengono informato il team degli avanzamenti ed eventuali
criticità.
Al termine dell due settimane il team svolge uno sprint review, riunione che
conclude ogni sprint, all’interno del quale il team tratta dei seguenti argomenti:

   • il Product Owner identifica ciò che è stato “Fatto” e ciò che non è stato
     “Fatto”
   • il team di sviluppo discute su cosa è andato bene durante lo sprint, i
     problemi riscontrati e come sono stati risolti o si pensa di risolverli
   • il team illustra il lavoro svolto e risponde a domande sull’incremento

Gli sprint retrospective vengono svolti dal team tra la sprint review e lo sprint
planning, e sono riunioni dedicate al controllo sulla qualità degli sprint. Così il
team può valutare lo svolgimento dello sprint dal punto di vista delle persone,
relazioni, processi e strumenti, così da poter identificare un piano per il loro
miglioramento.
InfoCert ha recentemente ristrutturato l’organizzazione interna dei team e delle
divisioni di sviluppo ed operation G per la gestione del ciclo di vita del software,
adottando il modello DevOps, la cui caratteristica principale è l’estesa automa-
zione e monitoraggio per tutte le fasi del ciclo di vita del software, che vanno
dallo sviluppo fino al rilascio e alla gestione dell’infrastruttura. Il DevOps pun-
ta ad ottenere cicli di sviluppo corti, con rilasci frequenti, più affidabili e meno
onerosi, come illustrato nella seguente figura.

                                         3
CAPITOLO 1. L’AZIENDA

Figura 1.2: Confronto tra lo sviluppo agile con un metodo tradizionale a cascata
nella struttura dei rilasci, fonte: Wikipedia Commons, [Lit09]

    A differenza della struttura classica che faceva si di separare in modo netto
i team che si occupano dello sviluppo e quelli di operation, in questo modello i
team si occupano sia dello sviluppo che del lato operation durante tutto il ciclo
di vita del software, creando un ciclo continuo, come quello rappresentato nella
figura 1.3.

 Figura 1.3: Fasi dello sviluppo DevOps, fonte: Wikipedia Commons, [Kha16]

    Questo modello permette ai team di sviluppo di rilasciare il software più
frequentemente e di essere più rapidi nell’affrontare problemi nel software di-
stribuito, questo avviene perché chi scrive il codice si occupa anche del moni-

                                       4
CAPITOLO 1. L’AZIENDA

toraggio del software rilasciato e riceve i feedback dai clienti e dagli utenti in
modo diretto.

1.3     Organizzazione
InfoCert ha sedi a Roma, Milano e Padova, presenta un modello organizzativo
organizzativo strutturato su più livelli. Nella sede di Padova dove ho svolto lo
stage ci si occupa principalmente dello sviluppo software, è però anche presente
un’area dedita al supporto clienti ed una che si occupa della gestione delle reti
e dei sistemi aziendali.
Non descriverò l’intera organizzazione, ma mi limiterò alla struttura dell’area
che si dedicata allo sviluppo e alla struttura dei team, visto che non ho interagito
in modo esteso con le altre aree dell’azienda.
L’area dedita allo sviluppo e organizzata in software lab, questi sono formati da
uno o più team DevOps che si occupano in modo diretto dello sviluppo. I team,
come scritto nella sezione precedente, sono formati da gruppi con un numero di
componenti compreso tra 5 e 9, all’interno dei quali ci sono gli sviluppatori, uno
ScrumMaster, e un Product Owner. Vista la presenza di più sedi spesso alcuni
componenti del team lavorano in remoto da casa o da altre sedi, raramente tutti
i componenti di un team DevOps lavorano presso la stessa sede dell’azienda.

1.4     Tecnologie utilizzate e processi aziendali
All’interno dell’ufficio di Padova quasi tutti i team si dedicano nello sviluppo
legato alla creazione, manutenzione ed estensione di prodotti software. Tutti i
team a parte uno sono impiegati nello sviluppo di applicazioni web principal-
mente basate sulle tecnologie:
   • Java EE G

   • AngularJS G
   • Oracle SQL
Principalmente infatti l’azienda sviluppa applicativi web con un’architettura
API REST-based, rappresentata nella seguente immagine:

                                         5
CAPITOLO 1. L’AZIENDA

Figura 1.4: Schema di una applicazione API REST-based, fonte: Microsoft
Developer Network, [Kea15]

    Lo sviluppo di applicazioni con questo tipo di architettura richiede la crea-
zione di due moduli separati:
   • Server. Espone delle Application Programming Interface (API) REST
     con le quali i client possono interagire. In InfoCert per la creazione dei
     server e delle API REST si utilizza Java Enterprise Edition.

   • Client. Possono essere presenti uno o più client, per quanto riguarda le
     applicazioni aziendali solitamente è una web application, sviluppata in An-
     gularJS, che fornisce un’interfaccia user friendly per usufruire dei servizi
     offerti da un server che espone delle API REST .
Questa architettura permette di sviluppare in modo semplice su più piattaforme,
ogni applicazione utilizza la stessa API per ottenere, aggiornare e manipolare
i dati. Tutte le applicazioni hanno le stesse feature e nel caso fossero necessari
dei cambiamenti è sufficiente modificare una sola componente, in linea con il
principio di programmazione Don’t Repeat Yourself (DRY). Le applicazioni non
sono altro che un’interfaccia grafica relativamente leggera, che permettono l’in-
terazione in modo semplice ai servizi REST . Alcuni team hanno recentemente
sviluppato anche delle applicazioni per smartphone e permettere ai clienti di
InfoCert di accedere ai propri servizi anche tramite dispositivi mobili.
Esiste un team che si occupa dello sviluppo dell’applicativo desktop per la firma
digitale, questo e sviluppato con l’utilizzo dei linguaggi C, C++ e un interfaccia
creata tramite le librerie Qt G . Come ho scritto nella sezione 1.2 l’azienda uti-
lizza il modello DevOps, di conseguenza ha adottato un gran numero tecnologie
costruendo una toolchain a supporto di questo modello. Nell’Immagine seguen-
te sono rappresentate le tecnologie utilizzate corredate dal loro compito della
toolchain.

                                        6
CAPITOLO 1. L’AZIENDA

Figura 1.5: Immagine rappresentante la toolchain DevOps utilizzata in InfoCert

1.5     InfoCert e l’innovazione
InfoCert pone una certa attenzione nello restare al passo con la conoscenza di
nuove tecnologie e con l’innovazione, per quanto riguarda l’ultima, l’azienda col-
labora con alcuni tra i maggiori poli universitari e centri di ricerca del nostro
paese.
Tuttavia InfoCert non è particolarmente veloce nell’adottare nuove tecnologie,
questo in parte è dovuto all’ambiente in cui si trova ad operare, per il quale
l’utilizzo delle tecnologie più moderne sul mercato non è considerato un obiet-
tivo da perseguire a discapito dell’affidabilità degli applicativi. Una seconda
motivazione è dovuta alla dimensione dell’azienda che scoraggia cambi continui
di tecnologie, in quanto sarebbe oneroso formare il personale.
L’azienda è invece particolarmente attenta all’innovazione e alla ricerca del mi-
glioramento per quanto riguarda i suoi processi interni. È stato riformato da
InfoCert il modello di sviluppo utilizzato all’interno dell’azienda e applicato lo
Scrum, negli ultimi anni è stato inoltre riformato la struttura interna dell’azien-
da passando da uno lo stile tradizionale dove ci sono gli sviluppatori e gli ops,
che si occupavano della fase di operation delle applicazioni rilasciate, ad una più
moderna organizzazione in stile DevOps.

                                        7
CAPITOLO 2. PERCHÉ QUESTO STAGE?

2. Perché questo stage?

2.1     Il problema
I team di sviluppo non riescono a seguire lo sviluppo di tutto il software di cui
InfoCert ha bisogno, di conseguenza, l’azienda non di rado si avvale dell’utilizzo
di fornitori esterni a cui appalta lo sviluppo.
L’utilizzo di fornitori esterni per sviluppare dei prodotti può essere utile nel caso
non si disponga del personale necessario o che non ha le competenze necessarie
per provvedere allo sviluppo.
Purtroppo appaltare lo sviluppo non è una cosa semplice da fare, in quanto la
scelta e la gestione dei rapporti con i fornitori non è sempre semplice. Le azien-
de che concorrono, hanno competenze abilità ed esperienza differenti, risulta
perciò non sempre facile scegliere la proposta migliore e risulta spesso difficile
gestire la qualità del software prodotto e garantire che il codice sia ben scritto,
manutenibile e con una documentazione esaustiva.
Per InfoCert possedere codice con questo tipo di difetti è un grande problema,
visto che l’azienda poi manterrà quel codice per anni, comportando dei costi
notevoli nell’eseguire normali operazioni di manutenzione ed estensione.

2.2     La strategia di InfoCert
Per far fronte al problema posto nella sezione 2.1, InfoCert negli ultimi due
anni ha condotto un percorso volto a trovare un metodo per ridurre i problemi
derivanti dall’appalto all’esterno della produzione del software al fine di ridurne
i costi e semplificare le attività di gestione.
Questo percorso ha portato alla creazione di due template per lo sviluppo del-
le web application aziendali, Back-End CONtainer (BECON) per il back-end e
Front-End CONtainer (FECON) per il front-end, pensati per dare ai fornitori
dei progetti di base all’interno dei quali sviluppare, ciò che gli è stato commis-
sionato, spingendoli a produrre del codice di buona qualità e con una struttura
nota.
InfoCert ha inoltre adottato numerosi strumenti e tecnologie che hanno l’obiet-
tivo di standardizzare i processi e gli strumenti per fare in modo che il software
prodotto dai fornitori sia il più possibile simile al quello sviluppato dai team
interni all’azienda, agevolando così la manutenzione e l’estensione del software
nel corso degli anni.
È sorto perciò il bisogno che qualcuno che qualcuno provasse ad integrare tutte
queste tecnologie, tramite al creazione di un progetto che ne facesse uso. L’o-
biettivo principale che ho avuto durante lo svolgimento dello stage è stato di

                                         9
CAPITOLO 2. PERCHÉ QUESTO STAGE?

creare un’applicazione che utilizzasse tutte le tecnologie e gli strumenti, per fare
in modo di evidenziare eventuali problemi tramite la creazione di una web ap-
plication. Il secondo obiettivo è stato sviluppare l’applicazione in modo tale che
potesse essere utilizzata come un progetto di esempio, da distribuire all’interno
dell’azienda e ed ai fornitori.
Questo perché l’azienda vuole far si che la conoscenza delle tecnologie, che for-
mano il nuovo standard per lo sviluppo dei prodotti software, venga appreso
in modo rapido all’interno dell’azienda e dai fornitori, così da poter iniziare ad
utilizzarlo il prima possibile.

2.3     Motivazioni della scelta dello stage
Le motivazioni che mi hanno portato a scegliere questa proposta di stage sono
state molteplici le principali sono state:
   • un progetto di stage definito e chiaro
   • la presenza di una strategia aziendale costruita attorno al progetto
   • l’utilizzo di tecnologie ritenute più utili per il futuro
Gli altri stage per il quale ero stato contattato invece mancavano di questo, al-
cuni non erano chiari su cosa si dovesse produrre durante lo stage e con l’utilizzo
di quali tecnologie, mentre altri non avevano una strategia e un vero e proprio
obiettivo da raggiungere con lo stage.
Questo era principale dovuto al fatto che erano progetti di ricerca e sviluppo per
i quali l’azienda ospitante non aveva grandi competenze e quindi non sapevano
cosa aspettarsi e se aspettarsi risultati utilizzabili dallo stage.
Un altro fattore determinate nella mia scelta dello stage sono state le tecnologie
che avrei dovuto apprendere ed utilizzare. Ho ritenuto che le tecnologie che avrei
appreso durante questo stage mi sarebbero state più utili a livello professionale,
mentre negli altri stage avrei utilizzato tecnologie più di nicchia.
Da menzionare anche se meno rilevante, è il fatto che alcuni degli stage proposti
era i luoghi irraggiungibili per una persona sprovvista di un veicolo di proprietà
o che non vivesse nelle immediate vicinanze del posto di lavoro.

2.4     Obiettivi e vincoli dello stage
Come scritto nella sezione precedente lo stage consiste nello sviluppo di una web
application che faccia utilizzo di tutte le tecnologie che l’azienda ha deciso di
adottare. I requisiti sono classificati utilizzano le notazioni di seguito riportate:
   • min per i requisiti minimi, vincolanti in quanto obiettivo primario richiesto
     dal committente;
   • max per i requisiti massimi (comprendenti quelli desiderabili e opziona-
     li), non vincolanti o strettamente necessari, ma dal riconoscibile valore
     aggiunto;
   • for per gli obiettivi formativi, rappresentanti valore aggiunto non stretta-
     mente competitivo.

                                         10
CAPITOLO 2. PERCHÉ QUESTO STAGE?

    Le sigle precedentemente indicate sono seguite da una coppia sequenziale di
numeri, creando un codice che identifichi in modo univoco il requisito.
Si prevede lo svolgimento dei seguenti obiettivi:
   • Minimi
        – min01: Realizzazione Web Application basata sul template aziendale
          BECON ;
        – min02: Realizzazione ambiente di sviluppo tramite Puppet e Fore-
          man G ;
        – min03: Suite test automatici di accettazione per componente di back-
          end con Cucumber G + RestAssured G ;
        – min04: Documentazione di Progettazione e Sviluppo dei componenti
          menzionati nei punti precedenti;
   • Massimi
        – max01: Realizzazione componente di front-end basata sul template
          aziendale FECON ;
        – max02: Suite test automatici di navigazione per componente di front-
          end con Cucumber + Selenium G ;
   • Formativi
        – for01: Utilizzo della metodologia agile in ambito aziendale;
        – for02: Collegato a min02. Studio degli strumenti per la continuous
          integration G e continuous delivery G ;
        – for03: Collegato a min03. Studio del linguaggio Gherkin G per la
          definizione dei test automatici;

2.5     Pianificazione dello sviluppo
La pianificazione, in termini di quantità di ore di lavoro, e stata la seguente:

 Settimane                Descrizione dell’attività
 18 Giugno-29 Giugno      1◦ sprint
           16 ore             •    Introduzione alle tecnologie aziendali per lo
                                   sviluppo e test di applicazioni web, crea-
                                   zione repository su GitLab G , predisposizione
                                   ambiente di sviluppo
           20 ore             •    Progettazione web application (stesura do-
                                   cumentazione: progettazione risorse, lista
                                   requisiti sotto forma di scenari (SP, SI, IM))
           4 ore              •    Revisione progettazione
           24 ore             •    Realizzazione ambiente di sviluppo trami-
                                   te Puppet/Foreman, definizione DataBase
                                   (DB), integrazione con servizio di auten-
                                   ticazione Infocert Secure Access Controller
                                   (ISAC)/Infocert Profile and Access Manager
                                   (IPAM)
                                        11
CAPITOLO 2. PERCHÉ QUESTO STAGE?

          16 ore             •    Studio di BECON , scaffolding progetto
                                  di Back End (BE) e aggiunta supporto
                                  Continuous Integration (CI)
 2 Luglio-13 Luglio      2◦ sprint
          32 ore             •    completamento BE
          16 ore             •    review BE + integrazione documentazione
          24 ore             •    realizzazione test interfacce REST (scaffol-
                                  ding progetto di test) e aggiunta supporto
                                  CI
          8 ore              •    studio di FECON , scaffolding progetto di
                                  Front End (FE) e aggiunta supporto CI
 16 Luglio-27 Luglio     3◦ sprint
          16 ore             •    proseguimento studio di FECON , scaffolding
                                  progetto di FE e aggiunta supporto CI
          24 ore             •    completamento sviluppi FE
          16 ore             •    review FE + integrazione documentazione
          24 ore             •    realizzazione test interfaccia web
 30 Luglio-24 Agosto     4◦ sprint
          24 ore             •   realizzazione ambiente di test, produzione e
                                 collaudo
          24 ore            •    sviluppo nuove funzionalità e completamento
                                 lavori
          16 ore            •    review complessiva di tutto il lavoro svolto
          16 ore            •    presentazione del lavoro fatto all’area DevOps
                Tabella 2.1: Pianificazione della quantità di ore

    Nella figura 2.1 è riportata in modo grafico la pianificazione dei giorni di
lavoro per lo sviluppo descritta nella tabella 2.1.

                                      12
CAPITOLO 2. PERCHÉ QUESTO STAGE?

Figura 2.1: Diagramma di Gantt rappresentate la pianificazione della tabella 2.1

2.5.1     Milestone
Di seguito è riportato l’elenco delle milestone G previste nell’arco temporale dello
stage. Ad ogni milestone vengono associate delle baseline G di prodotto che
dovranno essere raggiunte entro ogni corrispondente scadenza. Le milestone
fissate sono le seguenti:
  1. M1: Fine 1◦ sprint, scaffolding applicazione di BE , predisposizione am-
     biente di sviluppo, documentazione.

  2. M2: Fine 2◦ sprint, scaffolding applicazione di FE , test automatici BE .
  3. M3: Fine 3◦ sprint, applicazione di FE e relativi test.
  4. M4: Fine 4◦ sprint, presentazione, documentazione e applicazioni com-
     plete.

2.6     Vincoli tecnologici e metodologici
2.6.1     Metodo di sviluppo
Come modello per lo sviluppo del progetto ho applicato lo Scrum, in quanto
tutti i team all’interno dell’azienda utilizzano questo modello di sviluppo.
Per lo svolgimento dello stage io e il tutor abbiamo adattato il modello classico,
essendo il team formato due componenti, io mi occupavo dello sviluppo e il tutor
aziendale faceva le veci del Product Owner.
Ogni giorno il team svolgeva uno stand-up G nel quale io riportavo e illustravano
i risultati raggiunti nella giornata precedente, esponevo i problemi riscontrati
durante lo sviluppo e assieme al tutor svolgevo la pianificazione per le giornate

                                        13
CAPITOLO 2. PERCHÉ QUESTO STAGE?

     di lavoro successive. Di conseguenza io ed il tutor abbiamo adattato il modello
     con la rimozione degli sprint planning e sprint review, ritenuti non necessari
     visto che la pianificazione che sarebbe avvenuta all’inizio di ogni sprint, e la
     revisione degli avanzamenti trattati durante la sprint review, sarebbero già stati
     trattati durante gli stand-up giornalieri.

     2.6.2     Gherkin e Cucumber
     Con Gherkin e Cucumber si esegue l’individuazione, la codifica e la validazione
     del soddisfacimento dei requisti dell’applicazione.
     Cucumber come linguaggio per la definizione e la codifica dei requisti utilizza
     Gherkin.
     È progettato con lo scopo di essere non tecnico e facilmente comprensibile, il
     suo obiettivo è quello di promuovere il Behavior Driven Development all’interno
     di tutto il team di sviluppo compresi manager e commerciali.
     La semplicità nella comprensione di questo linguaggio è data dalla sua struttura
     che fondamentalmente utilizza cinque keyword :
        • Feature: descrive in modo generico che tipo di funzionalità quel requisito
          richiede ed è formato da uno o più scenari
        • Scenario: descrivono il comportamento dell’applicazione date delle pre-
          condizioni e un azione da parte dell’utente, ed è formata da un blocco:
          Given, When, Then
        • Given: indica le precondizioni dello scenario
        • When: specifica l’azione che scatena l’esecuzione di un azione da parte
          dell’applicazione

        • Then: il risultato che ci si aspetta in risposta
     Come si può notare dal codice riportato a seguito la scrittura dei requisti risulta
     molto naturale e molto comprensibile a chi legge.
1    F e a t u r e : FUN_100 : User can manage h i s t o d o s
2       Logged u s e r can s e e h i s todo l i s t
3       Logged u s e r can add , d e l e t e and e d i t t o d o s from h i s todo l i s t
4
5      S c e n a r i o : FUN_100_1 : User i s shown an empty todo page
6      I f t h e u s e r i s a u t h e n t i c a t e d and has no todo , system w i l l show an
            empty todo l i s t
7
8         Given User has an empty todo l i s t
9         When User r e q u e s t t o s e e h i s t o d o s
10        Then System w i l l show an empty page with a message
                  Listing 2.1: Esempio di un requisito scritto in Gherkin
     Cucumber poi utilizza i requisiti scritti con Gherkin per generare la struttura
     nella quale poi codificare i test di accettazione automatici necessari per la va-
     lidazione del soddisfacimento dei requisiti definiti durane la fase di analisi. Un

                                                 14
CAPITOLO 2. PERCHÉ QUESTO STAGE?

     esempio di come il requisito sopra riportato può essere testato è il seguente:
1    p u b l i c c l a s s ManageTodoStepDef {
2
3      @Given ( "^User has an empty todo l i s t $ " )
4      p u b l i c v o i d userHasAnEmptyTodoList ( ) throws E x c e p t i o n {
5         // mi a s s i c u r o che l ’ u t e n t e non p o s s e g g a n e s s u n todo a l l ’ i n t e n r o
            del sistema
6         DBManager . d e l e t e A l l U s e r T o d o s ( " Example " ) ;
7      }
8
9      @When( "^User r e q u e s t t o s e e h i s t o d o s $ " )
10     p u b l i c v o i d u s e r R e q u e s t T o S e e H i s T o d o s ( ) throws E x c e p t i o n {
11        // e s e g u o una chiamata v e r s o i l s e r v i z i o REST p e r v i s u a l i z z a r e
          l a l i s t a d i todo d e l l ’ u t e n t e c o r r e n t e
12        Rest . c a l l R e s t S e r v i c e ( g e t ( " / t o d o s " ) ) ;
13     }
14
15     @Then ( "^System w i l l show an empty page with a message$ " )
16     p u b l i c v o i d systemWillShowAnEmptyPageWithAMessage ( ) throws
          Exception {
17        // r i c e v o l a r i s p o s t a d a l s e r v i z i o REST e l a immagazzino i n una
          variabile
18        S t r i n g t o d o s = Rest . g e t R e s p o n s e ( ) ;
19        // c o n t r o l l o che l a r i s p o s t a s i a vuota i n quanto l ’ u t e n t e non
          p o s s i e d e todo
20        Matcher . c h e c k T r u e C o n d i t i o n ( t o d o s . e q u a l s ( " [ ] " ) , " " , " " ) ;
21     }
             Listing 2.2: Esempio di implementazione di un test di validazione

     2.6.3      BECON
     Lo sviluppo della componente di back-end dell’applicazione è svolto con l’utilizzo
     dell template aziendale BECON costruito sulle seguenti tecnologie:
        • Java SE 1.8
        • Java EE 6

        • Enterprise JavaBean (EJB) 3.1
        • Contexts and Dependency injection (CDI) 1.0
        • Maven G 3.3.9

        • OpenAPI 2.0
        • JBoss G EAP 6.4
        • ISAC
        • IPAM

     BECON fornisce una base sul quale costruire il back-end dell’applicazione, e
     impone regole di struttura per quanto riguarda l’architettura ed la scrittura del
     codice, con l’obiettivo di ottenere dei servizi REST ben costruiti e facilmente
     manutenibili nel tempo.
     Lo stile architetturale imposto da BECON permette di ridurre il lavoro per

                                                        15
CAPITOLO 2. PERCHÉ QUESTO STAGE?

quanto riguarda la progettazione, questo è dovuto al fatto che con la struttura
imposta dal container porta alla creazione di API con un diagramma delle classi
simile al seguente

Figura 2.2: Diagramma delle classi di un servizio REST sviluppato con BECON

   strutturate su tre livelli che svolgono funzioni specifiche:
   • L’interfaccia contenente la definizione dei servizi e la loro implementazione
     si occupano di esporre all’esterno le funzionalità
   • Le classi contenenti la business logic G si occupano delle elaborazioni
   • La persistance logic assieme alle entity G gestisce tutto quello che riguarda
     la lettura e la modifica del database.
Questo porta ad un’architettura che permette di essere estesa e manutenuta nel
tempo, anche a fonte di cambiamenti tecnologici.
Un ulteriore feature di BECON è quella di integrare in modo nativo il supporto
a ISAC ed IPAM , questo permette di integrare nella applicazione in modo
rapido funzioni di login e controllo dei permessi degli utenti che interagiscono
con l’applicazione.

2.6.4    FECON
Lo sviluppo del componete front-end è svolto utilizzando il template aziendale
FECON basato sulle seguenti tecnologie:
   • AngularJS
   • EcmaScript 6
   • Babel
   • Redux G

                                        16
CAPITOLO 2. PERCHÉ QUESTO STAGE?

   • HTML 5
   • Bootstrap (angular-ui-bootsrap)
   • Sass
   • ui-router
FECON fornisce una struttura all’interno della quale costruire la componen-
te front-end di web application, che spinga il programmatore ad organizzare
le componenti e a codificarle rispettando delle linee guida e buone pratiche di
programmazione, che nel tempo hanno dimostrato di dare buoni risultati nel-
l’ottenere applicazioni facili da manutenere e gestire nel tempo. Una di queste
pratiche è la gestione dello stato in modo centralizzato, per fare questo FECON
utilizza Redux, i cui principi verrano trattati nella successiva sottosezione.

2.6.4.1     Redux
In una applicazione creata con un framework JavaScript come AngularJS G lo
stato interno delle componenti è contenuto all’interno delle componenti stesse
sotto forma di variabili. Questo approccio può creare numerosi problemi a livello
di gestione dello stato, e non è raro trovarsi in situazioni che possono presentare
problematiche di questo tipo, un esempio di questo è quando due componenti
utilizzano gli stessi dati, magari in modo differente, questa situazione avviene
quando si ha una lista di oggetti divisa in due sezioni: una contenete delle
informazioni riassunte e l’altra contente tutti i dettagli ad esempio di un todo
per calare l’esempio in SPICe. Poniamo il caso di avere un interfaccia come
quella delle figura 2.3

                    Figura 2.3: interfaccia grafica di esempio

   Dove è presente una lista sulla sinistra ed una visualizzazione specifica sulla
destra, queste due componeti necessitano degli stessi dati, è da escludere la

                                        17
CAPITOLO 2. PERCHÉ QUESTO STAGE?

duplicazione dei dati in quanto chi sarebbero due source-of-truth situazione da
evitare, la soluzione usata inizialmente era quella di posizionare i dati in una
componente che racchiude le due componeti interessate nella condivisione dei
dati, come illustrato nella figura 2.4.

Figura 2.4: Esempio del flusso di passaggio dei dati nelle architetture tradizionali

    I questo esempio la componete che contiene i dati li passa come argomenti
alle due componenti che necessitano dei dati, questo comporta un flusso dei dati
‘sporco’ che risulta difficile da controllare, nella figura i dati vengono passati dal
componente padre al figlio ma in alcuni casi ci possono essere più passaggi,
questo può portare alla creazione di side-effects G e in caso di errori diventa
complesso risalire a dove siano avvenuti. Per far fronte a questo problema
FECON utilizza Redux come container G , dove conservare e gestire l’interno
stato dell’applicazione. L’utilizzo di questa pratica permette di avere un flusso
dei dati come quello rappresentato nella figura 2.3

                                         18
CAPITOLO 2. PERCHÉ QUESTO STAGE?

        Figura 2.5: Esempio del flusso di passaggio dei dati con Redux

    Come si può notare adesso la gestione dello stato avviene esternamente
alle componenti così da evitare il passaggio dei dati attraverso più strati di
componenti. L’utilizzo di Redux prevede che:
   • Lo stato dell’applicazione è rappresentato tramite oggetti e array
   • I cambiamenti del sistema sono descritti tramite oggetti

   • La logica per gestire i cambiamenti è implementata tramite funzioni pu-
     re G , senza side-effects sui dati
Queste regole permettono di ottenere un’architettura per la gestione del flusso
dei dati all’interno dell’applicazione con le seguenti caratteristiche:

   • con una singola source-of-truth
   • un comportamento consistente, predicibile e idealmente privo di side-
     effects
   • semplicità nella creazione ed esecuzione di test

Queste proprietà hanno portato InfoCert ad utilizzare in FECON questa prati-
ca, che negli ultimi anni è diventato uno standard de facto nello sviluppo web,
per applicazioni di dimensioni non banali e pensate per durare nel tempo.

2.6.5       Creazione degli ambienti per lo sviluppo
In InfoCert ogni applicazione nel corso del suo ciclo di vita esegue su quattro
ambienti:
   • sviluppo

   • test
   • collaudo
   • produzione

                                       19
CAPITOLO 2. PERCHÉ QUESTO STAGE?

La creazione di questi avviene tramite l’utilizzo di tre strumenti:

   • Artifactory
   • Foreman
   • Puppet

che si appoggiano poi sui repository aziendali per reperire le configurazioni.
L’immagine seguente illustra la struttura organizzativa che permette la creazione
e la gestione degli ambienti per lo sviluppo.

                                       20
CAPITOLO 2. PERCHÉ QUESTO STAGE?

              Figura 2.6: Architettura del sistema di integrazione

    Foreman fornisce le funzionalità per la creazione e gestione delle macchine
virtuali all’interno delle quali poi eseguire le applicazioni. Artifactory è il soft-
ware repository G aziendale all’interno del quale vengono pubblicate le release
dei progetti vengono immagazzinate in forma binaria per poter essere installate
sulle macchine su cui effettuare la distribuzione.
Questo permette di avere un unico luogo che contiene tutte le versioni delle
applicazioni attualmente in servizio sia per i clienti che per il testing interno e
fornisce un integrazione rapida con i più comuni metodi di messa in produzione

                                         21
CAPITOLO 2. PERCHÉ QUESTO STAGE?

come Docker, Kubernetes e Puppet.
Puppet è un tool di infrastructure as a code, per la gestione delle configurazioni,
permette all’utente di descrivere le caratteristiche del sistema di cui ha bisogno
indicando dipendenze software e le configurazioni necessarie tramite l’utilizzo
di un linguaggio comprensibile da un calcolatore così da permettere a Puppet di
applicare alla macchina creata con Foreman la configurazione e l’installazione
dei pacchetti necessari all’esecuzione dell’applicazione presente su Artifactory e
di conseguenza ottenere una ambiente nel quale sviluppare, testare o rilasciare
il prodotto in produzione.

2.6.6    Confluence
Per la gestione della documentazione e per reperire la documentazione neces-
saria per l’utilizzo di alcune tecnologie ho utilizzato Confluence, software per
la collaborazione, all’interno del quale è contenuta tutta la documentazione per
progetti e le guide all’utilizzo dei software presenti all’interno dell’azienda.

                                        22
CAPITOLO 3. LO SVILUPPO DI SPICE

3. Lo Sviluppo di SPICe

3.1     Metodo di lavoro e tecnologie aggiuntive
Durante lo sviluppo del progetto ho scelto di adottare delle tecnologie e dei
metodi di lavoro aggiuntivi, in alcuni casi per far fronte a problemi di specifiche
componenti e in altri a supporto dell’interno progetto per facilitare lo sviluppo.

3.1.1     Test-driven development
Per lo sviluppo di alcune parti dell’applicazione, io ed il tutor abbiamo deciso di
utilizzare un modello di sviluppo test-driven. Il test-driven development prevede
la ripetizione di un breve ciclo composto da tre fasi.

Figura 3.1: Diagramma del ciclo di sviluppo test-driven, fonte:                Han-
selt.com, [Bog16]

    Nella ‘fase rossa’, il programmatore scrive i test automatici le nuove funzio-
nalità o funzioni da sviluppare, in questa fase i test falliscono in quando manca il
codice che implementa la funzionalità, da questo è dovuto il nome di fase rossa.
Nella ‘fase verde’, lo sviluppatore scrive il codice necessario a far passare i test.

                                         23
CAPITOLO 3. LO SVILUPPO DI SPICE

Nella terza e ultima fase detta ‘fase grigia’ o di refactoring, lo lo sviluppatore si
concentra sul refactoring del codice, così da adeguarlo agli standard richiesti.

3.1.2      Versionamento e gestione delle configurazioni
Per la gestione delle versioni del progetto ho utilizzato Git G con l’utilizzo di
GitFlow, come modello di branching, questo è utilizzato in InfoCert in modo da
favorire lo sviluppo in parallelo da parte di più persone e o team.

3.1.2.1    GitFlow
GitFlow fa questo imponendo regole e categorizzando i branch all’interno del
repository. Questo modello di branching suddivide i branch in due categorie
principali:
   • master
   • supporto internamente suddivisi in:

          – feature
          – release
          – hotfix
Ognuna di queste categorie di branch svolge un compito specifiche all’interno
del modello, la figura seguente illustra un esempio di come GitFlow spinga ad
organizzare ed utilizzare il repository.

                                         24
CAPITOLO 3. LO SVILUPPO DI SPICE

Figura 3.2: Esempio di repository strutturata con l’utilizzo di GitFlow, fonte:
nvie.com, [Dri10]

    I branch master e develop sono i considerati principali, in quanto hanno una
vita considerata infinita, il gestore del repository li crea all’inizio del progetto e
non vengono mai eliminati.
I branch principali hanno molta rilevanza nello sviluppo, in quanto lo stato
della HEAD, riferimento simbolico all’ultima commit di un branch, di master e
develop rappresentano rispettivamente il codice che è pronto alla produzione o

                                         25
CAPITOLO 3. LO SVILUPPO DI SPICE

è già stato rilasciato e le più nuove funzionalità considerate pronte per essere
inserite nel prodotto finale, develop è un considerato un branch di integrazione
e periodicamente i cambiamenti presenti in questo branch vengono riversati dal
team di sviluppo nel master.
Per riversare i cambiamenti dal branch di sviluppo al master il team utilizza
i release branch. La caratteristica principale dei release branch è che vengono
creati direttamente dal develop e non vengono introdotte nuove feature, il team
di sviluppo in questo branch si focalizza sulla rimozione di bug per poi rilasciare
le modifiche nel master. Per la creazione di nuove feature si utilizzano dei
branch appositamente creati, per ogni nuova funzionalità, il loro ciclo di vita è
rappresentano nella seguente figura.

Figura 3.3: Esempio di ciclo di vita di un branch per l’aggiunta di una nuova
funzionalità, fonte: nvie.com, [Dri10]

    Come si può vedere dall’immagine un branch di feature ha una vita molto più
corta rispetto a quella dei branch principali, in quanto le modifiche apportate
dal team di sviluppo all’interno di questo branch sono finalizzati alla creazione
di nuove funzionalità da aggiungere al develop e poi al prodotto finale.
L’ultimo branch previsto dalla struttura di GitFlow è hotfix, unico branch esclu-
so il develop che viene creato a partire dal master. Lo scopo di questo branch
è quello di eseguire dei fix su gravi bug scoperti nel branch master e di conse-
guenza nel prodotto finale, senza dubbio è il branch che deve avere la vita più
breve, il branch di hotfix si caratterizza ulteriormente per il fatto che è l’unico
le cui modifiche vengono apportate a tutti i branch attualmente attivi.

Ho applicato poi le regole aziendali sulla struttura dei messaggi ed il contenuto,
in breve:
   • separare l’argomento dal corpo della commit con una linea bianca

   • limitare la lunghezza del argomento della commit a 50 caratteri
   • la prima lettera dell’argomento deve essere maiuscola

                                        26
CAPITOLO 3. LO SVILUPPO DI SPICE

   • non terminare l’argomento della commit con il punto

   • scrivere l’argomento della commit in modo imperativo
   • la lunghezza massima delle righe all’interno del corpo della commit è di
     72 caratteri
   • spiegare nel corpo della commit perché la si sta facendo e come risolve il
     problema
Con l’utilizzo di Git ho inoltre gestito il versionamento delle configurazioni
necessarie a Puppet, che verrà trattato nella sottosezione 2.6.5, per eseguire
i deployment e mantenere il progetto all’interno dell’ambiente di sviluppo.

3.1.3    Stile di codifica
Per garantire uno stile uniforme e che rispettasse lo standard aziendale in via di
applicazione per quanto riguarda lo stile della codifica, ho deciso di utilizzare a
supporto dello sviluppo dei verificatori automatici.
Durante lo sviluppo del back-end ho utilizzato Checkstyle, plugin G Maven adi-
bito al controllo dell’aderenza del codice ad una style guide, per la codifica del
codice Java ho applicato la Google Java Style Guide G .
Per quanto riguarda il front-end ho utilizzato ESLint G come analizzatore sta-
tico, con il quale ho assicurato l’aderenza di tutto il codice JavaScript presente
nel progetto alla Google JavaScript Style Guide G . Uniformare lo stile del co-
dice ha lo scopo di facilitare la code review G durante lo sviluppo, migliorare la
manutenibilità e comprensibilità del codice, in quanto comprendere il funziona-
mento di codice scritto utilizzando molti stili differenti è complesso e richiede
tempo. Effettuare un processo come quello della code review su codice che segue
delle regole per uniformane lo stile permette di velocizzare il lavoro, in quanto
il codice che si dovrà analizzare sarà più simile a quello che la persona che sta
eseguendo il controllo scriverebbe.
L’utilizzo di questo tipo di strumenti avviene anche per linguaggi come Java,
come avviene in BECON , questo bisogno si fa però sentire in maniera più forte
con un linguaggio come JavaScript G che permette una grande varietà di stili
come si può vedere dal codice riportato a seguire.

                                        27
CAPITOLO 3. LO SVILUPPO DI SPICE

1    /* No Style Guide */
2
3    var S tr i ng E xa m pl e = " t e s t s t r i n g " ;
4
5    function f o o ( ) {
6      // ...
7    }
8
9    c o n s t f o o = function ( ) {
10       // ...
11   };
12
13
14
15   /* Google JavaCript Style Guide */
16
17   l e t S t r i n g G o o g l e = ’ test String ’ ;
18
19   /* * @return { number } */
20   function h e l p e r F u n c t i o n ( ) {
21        return 4 2 ;
22   }
23
24
25
26   /* AirBnB JavaScript Style Guide */
27
28   l e t s t r i n g A i r B n B = ’ test string ’ ;
29
30   c o n s t s h o r t = function d e s c r i p t i v e F u n c t i o n N a m e ( ) {
31       // ...
32   };
       Listing 3.1: Esempio di codice JavaScript scritto seguendo delle style guide
     Come si può notare nel eseguire due compiti semplici come dichiarate una va-
     riabile contente una stringa e una funzione JavaScript G fornisce numerose pos-
     sibilità, cosa che non avviene in linguaggi come Java o C++, dove le possibili
     opzioni non cambiano radicalmente lo stile, impattando sulla leggibilità del co-
     dice se non si è consueti a quello stile di codifica.

     3.1.4        Diagrammi UML
     Durante lo sviluppo dell’applicazione ho utilizzato i diagrammi UMLG per inte-
     grare la documentazione dell’applicazione in quanto ho ritenuto utile l’aggiunta
     di diagrammi per aiutare la comprensione di come ci si aspetta una applicazio-
     ne con BECON e FECON venga sviluppata, e facilitare la comprensione delle
     interazioni tra le componenti.
     Durante il progetto ho utilizzato:
         • Diagrammi dei package. Un package raggruppa un numero arbitrario
           di elementi UML. I package contengono al loro interno classi, entità che
           descrivono gli oggetti che fanno parte di un sistema, oppure altri package,
           seguendo così una struttura gerarchica.
           I diagrammi dei package permettono di descrivere le dipendenze tra gli
           stessi, fornendo un visione ad alto livello dell’architettura dell’applicazio-
           ne.

                                                          28
CAPITOLO 3. LO SVILUPPO DI SPICE

         • Diagrammi delle classi. Descrivono le entità che compongono il siste-
           ma. Il diagramma delle classi descrive le caratteristiche degli oggetti e le
           loro relazioni. Permette di avere una visione architetturale di dettaglio
           dell’applicativo.
         • Diagrammi di sequenza. Visualizzano lo scambio di messaggi tra le
           entità del sistema nel tempo, descrivendo la loro collaborazione nell’im-
           plementazione di un comportamento.

     3.2       Sviluppo di SPICe
     3.2.1      Analisi dei requisiti
     L’attività di analisi dei requisiti ha avuto come obiettivo quello di identificare
     un insieme di funzionalità sufficienti per dimostrare il funzionamento e l’inte-
     grazione tra le tecnologie in uso nello stage.
     Vista la natura interna del progetto e il fatto che le funzionalità offerte dal-
     l’applicazione non erano importanti per l’azienda, ho potuto sceglierle in modo
     libero e le ho poi discusse con il tutor aziendale.
     Una volta concordate le funzionalità a grandi linee sono passato all’identifica-
     zione e alla codifica dei requisiti con l’utilizzo del linguaggio Gherkin. La chiara
     comprensione di come avrei dovuto codificare i requisiti ha richiesto del tempo e
     degli studi sul linguaggio, nonostante questo sia semplice da apprendere e com-
     prendere, non è banale scrivere degli scenari che sfruttino a pieno le funzionalità
     di Gherkin, ma soprattutto di Cucumber, infatti scrivere in modo scorretto e
     non utilizzando le feature del linguaggio tende a non penalizzare il risultato per
     quello che riguarda l’analisi dei requisiti, porta invece a test difficili da codifica-
     re, complessi, male strutturati e ripetitivi.
     Il seguente blocco di codice riporta un esempio di non corretto utilizzo degli
     strumenti che il linguaggio mette a disposizione.
1    F e a t u r e : FUN_100 : User can l o g i n t h e system
2
3      S c e n a r i o : FUN_100_1 : User l o g i n s u c c e s s
4      The u s e r i s not a u t h e n t i c a t e d
5
6         Given User a c c o u n t c r e d e n t i a l s a r e v a l i d
7         When System r e c i v e s l o g i n r e q u e s t
8         Then System w i l l show l o g i n s u c c e s s page
9
10   S c e n a r i o : FUN_100_2 : User l o g i n f a i l
11      The u s e r i s not a u t h e n t i c a t e d
12
13        Given User a c c o u n t c r e d e n t i a l s a r e i n v a l i d
14        When System r e c i v e s l o g i n r e q u e s t
15        Then System w i l l show l o g i n f a i l page
               Listing 3.2: Esempio di codifica dei requisti in modo scorretto
     Come si può notare i due scenari sono quasi identici, da questi Cucumber creerà
     due test di accettazione separati.
     Dopo lo studio approfondito del linguaggio e alcuni tentativi nella creazione
     dei test, ho compreso il punto di vista dal quale è più conveniente esprimere i
     requisiti.

                                                       29
CAPITOLO 3. LO SVILUPPO DI SPICE

     A mio parere è più efficace scrivere i requisti descrivendoli dal punto di vista del
     sistema software, invece che dell’utente come ho trovato in molti esempi durate
     lo studio del linguaggio, questo perché permette di scrivere requisiti meno con-
     torti a livello logico e permette l’utilizzo in modo più agevole di alcune feature di
     linguaggio come gli Scenario Outline. Questi sono come i template di un classi-
     co linguaggio di programmazione e permettono di evitare la scrittura di feature
     ripetitive, che poi si trasformano in test di accettazione ripetitivi, portando del
     carico di lavoro aggiuntivo. Il seguente codice contenente una soluzione alter-
     nativa che descrive gli stessi requisti presenti nella feature precedente.
1    F e a t u r e : FUN_100 : User can l o g i n t h e system
2
3      S c e n a r i o O u t l i n e : FUN_100_1 : System l o g i n
4      The u s e r i s not a u t h e n t i c a t e d
5         Given User a c c o u n t c r e d e n t i a l s a r e 
6         When System r e c i v e s l o g i n r e q u e s t
7         Then System w i l l show l o g i n  page
8
9         Examples :
10          | V a l i d i t y | Response |
11          | valid           | success  |
12          | invalid         | fail     |
             Listing 3.3: Esempio di codifica di un requisito in modo corretto
     In questo caso però l’utilizzo dello Scenario Outline permette di scrivere un solo
     scenario che Cucumber trasformerà in un unico test di accettazione con due
     parametri. La seguente tabella illustra il numero di requisiti identificati in fase
     di analisi.

                 Tipo                  Obbligatorio         Desiderabile        Facoltativo
                 Funzionale            15                   11                  0
                 Di prodotto           0                    0                   0
                 Organizzativo         0                    0                   0

                                    Tabella 3.1: Riepilogo requisiti

     3.2.2      Progettazione
     Ho svolto la progettazione in modo agile, non andando a progettare le compo-
     nenti nello specifico e puntando ad ottenere velocemente software funzionante.
     La forte struttura imposta dai template aziendali BECON e FECON ha reso
     possibile questo, in quanto la struttura che impongono porta lo sviluppatore
     in modo abbastanza naturale alle creazioni di componenti che seguono lo stile
     architetturale desiderato. È inoltre rafforzato questo da numerosi esempi e dalla
     documentazione che spiega in modo preciso come le componenti vadano orga-
     nizzate, codificate e come queste debbano interagire, inoltre il modo in cui sono
     costruiti i due container fanno si che ogni qual volta si voglia inserire delle nuove
     funzionalità, basta aggiungere un nuovo modulo, questo avrà una struttura in
     tutto e per tutto identica a quella degli altri moduli dell’applicazione, quindi
     sarebbe poco utile produrre un diagramma delle classi per il nuovo modulo,
     in quanto sarebbe come un’istanza generata da un template. L’immagine è un

                                                       30
CAPITOLO 3. LO SVILUPPO DI SPICE

esempio di questo ed illustra il diagramma delle classi ottenuto con lo sviluppo
in BECON di SPICe.

       Figura 3.4: Diagramma delle classi del servizio REST di SPICe

                                      31
CAPITOLO 3. LO SVILUPPO DI SPICE

    La struttura è aderente a quella precedentemente a quella presente nella
figura 2.2 dove:
   • TodosResource: espone i servizi tramite API REST verso l’esterno
   • TodoStorage: si occupa della business logic G
   • TodoRepository: gestisce la lettura e scrittura verso il database
Il diagramma contiene anche delle interfacce e classi astratte non implementate
che non presenti nel modello della figura 2.2. Le classi astratte ed interfacce
   • Todo
   • Comment
   • JsonTodo
   • JsonComment
non appartengono al diagramma di base in quanto non sono obbligatorie da uti-
lizzare e non hanno lo scopo di fornire delle funzionalità ma si il loro obiettivo
è quello di creare oggetti immutabili utilizzati per il trasferimento dei dati al-
l’interno dell’applicazione e vengono generate in modo automatizzato, tratterò
in modo più approfondito nella sottosezione successiva riguardante la codifica.
Ho eseguito la progettazione in modo più approfondito per quanto riguarda
l’interfaccia REST e della sua implementazione TodosResource. Lo svolgimento
della progettazione del interfaccia REST non ha richiesto l’utilizzo di metodi o
strumenti particolari. Questo in quanto mi sono limitato a delineare le risorse
da creare all’interno dell’API in modo riuscire a soddisfare i requisti identificati
nella fase di analisi. Successivamente ho proceduto nell’organizzare la struttura
delle API identificando:
   • la struttura interna del servizio, definendo gli Uniform Resource Locator
     (URL) per ogni risorsa disponibile all’interno dell API , in modo da poter
     identificare e utilizzare le risorse create
   • il tipo di richiesta HyperText Transfer Protocol (HTTP) necessario per
     interagire con i servizi offerti
   • i servizi che non necessitano di autenticazione, ad esempio la risorsa /wel-
     come utilizzata generalmente per verificarne lo stato del sevizio, e sevizi
     che invece necessitano di un autenticazione e o di permessi di accesso alle
     risorse
Per la progettazione dello stato interno dell’applicazione del front-end gestito da
Redux, ho definito in modo accurato la forma che si voleva ottenere dallo stato.
Questo perché la sua forma impatta in modo determinate sulla manutenibilità
e comprensibilità delle operazioni sullo stato.
Ho inizialmente definito le azioni che i reducer poi dovranno gestire, questi sono
paragonabili alla funzione di transizione di un automa a stati, dato in input
uno stato e un azione, in questo caso, producono in uscita il nuovo stato. Ho
utilizzato l’interfaccia REST del servizio di back-end come guida per definire le
azioni, così da fare in modo di utilizzare tutte le funzionalità offerte, in seguito
ho previsto tre varianti:

                                        32
Puoi anche leggere