Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica ”Tullio Levi-Civita”
Corso di Laurea in Informatica
Analisi e confronto dei paradigmi di progettazione delle
API web
Tesi di laurea
Relatore Laureando
Prof. Tullio Vardanega Mauro Fasolo
Anno Accademico 2019-2020
Mauro Fasolo: Analisi e confronto dei paradigmi di progettazione delle API web, Tesi di laurea triennale, ©Aprile 2020.
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage dal laureando Mauro
Fasolo presso l’azienda Diana E-Commerce Corporation S.r.l. di Torreglia (PD). Ho svolto lo
stage alla conclusione del percorso di studi della Laurea Triennale in Informatica per una du-
rata totale di 303 ore. Gli obiettivi da raggiungere rispondono alla necessità aziendale di con-
durre un’analisi comparativa dei paradigmi di design delle API web, sugli stili architetturali e
sulle pratiche utilizzate per svilupparle renderle sicure. Il primo capitolo presenta il contesto
organizzativo e produttivo dell’azienda ospitante. Il secondo capitolo discute quali problemi
l’organizzazione ha inteso affrontare con lo stage. Il terzo capitolo documenta lo svolgimento
dello stage, presentando le attività svolte per punti salienti ed eventuali difficoltà incontrate. Il
quarto ed ultimo capitolo contiene una valutazione retrospettiva dello svolgimento dello stage
rispetto agli obiettivi iniziali e alle conoscenze acquisite.
iii
Indice
1 L’ azienda 1
1.1 La missione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Caratteristiche dell’azienda . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Mercato di riferimento . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Visione agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Organizzazione dell’azienda . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Lo sviluppo software . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 La manutenzione del software . . . . . . . . . . . . . . . . . . . . . 6
1.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Il PoC per diffondere il know-how 9
2.1 La scelta dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Perché ho scelto Diana Corp . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Documentare con un PoC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Un portale per la pubblicazione della documentazione . . . . . . . . . 10
2.2.2 Rendere la conoscenza accessibile . . . . . . . . . . . . . . . . . . . 12
2.2.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Impatto del PoC nel breve periodo . . . . . . . . . . . . . . . . . . . 14
2.3 Lo stage in un’azienda agile . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Documentare per il team di sviluppo . . . . . . . . . . . . . . . . . . 15
2.3.2 Il software funzionante più che la documentazione esaustiva . . . . . 16
2.3.3 L’importanza di scrivere il codice di buona qualità . . . . . . . . . . . 17
2.3.4 Obiettivi dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.5 Utilità del PoC nel lungo periodo . . . . . . . . . . . . . . . . . . . 18
2.4 Vincoli di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Strategie per il riutilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1 Il PoC e la dimostrabilità . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Fonti affidabili per il Copy&Paste . . . . . . . . . . . . . . . . . . . 19
2.5.3 La documentazione come strumento di riuso . . . . . . . . . . . . . 20
3 Lo sviluppo del PoC 21
3.1 Il metodo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Pianificazione delle attività . . . . . . . . . . . . . . . . . . . . . . . 21
iv
3.1.2 Revisioni di progresso . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.3 Analisi e tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . 23
3.2 Sviluppo del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Programmazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.4 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.5 Rilascio del prodotto su Heroku . . . . . . . . . . . . . . . . . . . . 38
3.3 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1 Copertura dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2 Copertura dei test . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.3 Linee di codice e documenti prodotti . . . . . . . . . . . . . . . . . 42
3.4 Scenario d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Valutazione retrospettiva 47
4.1 Valutazione rispetto agli obiettivi fissati . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Obiettivi fissati dallo stage . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Obiettivi raggiunti a fine stage . . . . . . . . . . . . . . . . . . . . . 48
4.1.3 Valutazione dell’organizzazione ospitante . . . . . . . . . . . . . . . . 48
4.1.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Valutazione generale dell’esperienza . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Conoscenze e abilità maturate . . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Valutazione rispetto alle competenze richieste . . . . . . . . . . . . . . . . . 50
4.3.1 Competenze utilizzate durante lo stage . . . . . . . . . . . . . . . . . 50
4.3.2 Competenze mancanti . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.3 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . 50
Glossario 53
Bibliografia 61
v
Elenco delle figure
1.1 La catena del valore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 I servizi del commercio elettronico in rete . . . . . . . . . . . . . . . . . . . . . 3
1.3 Lo sviluppo con Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 L’orchestrazione dei sottosistemi del commercio in rete . . . . . . . . . . . . . . 7
2.1 Il risultato dell’analisi dei paradigmi di progettazione . . . . . . . . . . . . . . . 11
2.2 Architettura di integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Il codice interattivo per interagire con le WebAPI . . . . . . . . . . . . . . . . . 16
3.1 Pianificazione delle attività di progetto . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Casi d’uso del sistema web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Casi d’uso per le WebAPI Request-Response nel sistema web . . . . . . . . . . . 25
3.4 Casi d’uso per i protocolli e per le WebAPI Event-Driven nel sistema web . . . . . 25
3.5 Il software design pattern MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Il dialogo tra client e server per il paradigma Event-Driven . . . . . . . . . . . . . 31
3.7 Architettura di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 Architettura headless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Scenario di integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Elenco delle tabelle
3.2 Pianificazione degli Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Test di unità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 Test di integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.12 Copertura dei requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.14 Copertura dei requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.16 Risultato dei test di unità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.18 Rapporto sui prodotti del tirocinio . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Obiettivi fissati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Conoscenze e abilità maturate . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Competenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
vi
1 L’ azienda
1.1 La missione
1.1.1 Caratteristiche dell’azienda
Diana E-Commerce Corporation, da ora in poi Diana Corp, è un’agenzia internazionale con
sede a Padova, Milano e New York, specializzata nella creazione, gestione e promozione di siti
per il commercio in rete nell’ambito della moda.
L’attuale CEO Stefano Mocellini e la CCO Margherita Silvestri operano nel campo della
moda e della vendita in rete dal 2004. L’azienda Diana Corp nasce nel 2007, in seguito alla
realizzazione del sito di commercio elettronico per Gas Jeans [1].
La nuova azienda progetta e realizza un flagship store in rete per i marchi di moda. Questo
punto di vendita al dettaglio è sviluppato con tecnologie pensate per la vendita online, in questo
modo, l’azienda offre ai clienti un sistema di commercio in rete. Attraverso la condivisione
dell’istanza del portale, Diana Corp utilizza un solo strumento per gestire le richieste di più
clienti.
Diana Corp offre servizi per il commercio elettronico, sia a quelli che preferiscono una
soluzione pronta all’uso, sia a quelli che hanno un maggiore grado di autonomia nel mondo
del commercio elettronico e che sono alla ricerca di un’offerta personalizzata.
1.1.2 Mercato di riferimento
I servizi offerti da Diana Corp costituiscono i bulding blocks che ricorrono nelle organizzazioni
appartenenti al settore manifatturiero [2]. Organizzando i processi secondo il modello di catena
del valore, l’azienda offre linee di impresa distinte. Con la separazione dei processi l’azienda può
gestire: progetti che accompagnano i clienti nell’uso della piattaforma e progetti che richiedono
l’affiancamento del cliente nel suo processo di trasformazione digitale.
12 CAPITOLO 1. L’ AZIENDA
Figura 1.1: La catena del valore
https://it.wikipedia.org/wiki/Catena_del_valore
I servizi offerti da Diana Corp sono i seguenti: supporto IT, gestione del negozio in rete,
gestione dell’immagine del marchio, photoshooting, supporto clienti, logistica e gestione del mag-
azzino.
I servizi offerti dall’azienda possono essere classificati in due tipologie:
• i servizi gestiti, sono rivolti ai clienti che non hanno l’interesse o le competenze necessarie
ad internalizzare le funzioni offerte da Diana Corp;
• i servizi professionali, sono rivolti ai clienti che richiedono l’affiancamento del personale
Diana Corp nel percorso di trasformazione digitale.
Attraverso queste due linee di impresa, l’azienda modula l’offerta per le diverse tipologie di
cliente.
Il cliente promuove e consegna il proprio bene attraverso il commercio elettronico in rete,
svolgendo le attività definite dai processi aziendali Diana Corp. Questi processi aziendali pos-
sono essere adottati dal cliente, sfruttando la piattaforma. L’azienda prevede l’adozione parziale
dei servizi con progetti personalizzati, quando il cliente ha maggiore autonomia e quando il suo
processo di trasformazione digitale è in corso.
Il flagship store Diana Corp è il prodotto che meglio rappresenta il core business dell’azienda.
Con questo prodotto, l’azienda offre i servizi per la prima linea d’impresa. La pila software del
portale è realizzata con tecnologie che sono gestite da figure IT con professionalità specifiche. I
clienti che ancora non consegnano i propri beni, utilizzando il commercio elettronico, possono
intrecciare il proprio modello di impresa con la catena del valore Diana Corp e proporre le stesse1.2. VISIONE AGILE 3
tipologie di servizio agli utenti finali. Il flagship store Diana Corp prevede la multitenancy, per
questa ragione un’attenta attività di analisi deve essere svolta per pianificare la corretta condivi-
sione delle risorse disponibili. Ogni servizio Diana Corp mette a disposizione le proprie risorse
per personalizzare la piattaforma.
I servizi professionali Diana Corp rappresentano la seconda linea di impresa per i quali mette
a disposizione figure professionali specializzate. Queste figure affiancano il cliente trasmettendo
il loro know-how. Con le competenze acquisite il cliente completa la propria catena del valore e
consegna i beni attraverso il commercio elettronico in rete.
Il cliente può richiedere una combinazione di servizi delle due linee di impresa e completare
la propria catena del valore.
Figura 1.2: I servizi del commercio elettronico in rete
https://ayaatechnologies.com/ecommerce-development/
1.2 Visione agile
Nella sezione a seguire, ho descritto l’organizzazione aziendale del reparto software. Diana Corp
adotta metodologie per la gestione dei progetti come Waterfall, Kanban e Scrum. Durante il
periodo di tirocinio, ho notato una forte relazione tra l’identità aziendale e l’impiego dei metodi
agili. I principi del manifesto Agile rispecchiano ,infatti, il modo di lavorare dell’azienda che
promuove: interazione tra gli individui, collaborazione e reattività al cambiamento.4 CAPITOLO 1. L’ AZIENDA
1.2.1 Organizzazione dell’azienda
Ad ognuno dei servizi offerti da Diana Corp è associato un reparto. Le istanze di processo gener-
ate all’interno dei reparti, rappresentano gli anelli della catena del valore alla base dell’organizzazione
aziendale. Grazie al basso grado di accoppiamento dei reparti e dei servizi, Diana Corp rivende
i servizi delle due linee di impresa. Ad esempio, l’azienda può rivendere sevizi di photoshooting
senza richiedere l’intervento degli altri reparti.
Il reparto IT progetta e realizza le funzionalità software della piattaforma, collaborando con
le figure professionali messe a disposizione dagli altri reparti Diana Corp. Il reparto IT è suddi-
viso in team:
• il team di sviluppo effettua manutenzioni evolutive e correttive sui servizi con il quale
l’utente finale interagisce;
• il team di integrazione gestisce e definisce il dialogo applicativo tra i sottosistemi che com-
pongono il sistema di commercio elettronico;
• il team di rilascio installa le nuove versioni dei prodotti negli ambienti previsti dal ciclo di
vita;
• il team degli amministratori intercetta errori di sistema e problemi di performance. Gli
amministratori segnalano errori e problemi di performance al team di sviluppo. Il team di
sviluppo interviene sul prodotto e migliora la qualità del servizio;
• il team sicurezza indica le pratiche da adottare per sviluppare i prodotti in modo sicuro.
Il team segnala anche i problemi di sicurezza per i prodotti già rilasciati.
Per coordinare le attività di progetto, i responsabili di progetto sono collocati in modo trasver-
sale rispetto ai reparti. Ai responsabili di progetto é demandato il controllo del Product Back-
log. Adottando i metodi agili, i responsabili pianificano le attività giorno per giorno, in questo
modo, l’azienda reagisce velocemente alle richieste dei clienti. La metodologia Agile, adottata
dal reparto IT, rende frequente e conviviale la comunicazione tra i membri del gruppo e, allo
stesso tempo, l’adozione della metodologia garantisce formalità nel processo di gestione.
1.2.2 Lo sviluppo software
Di seguito, illustro il processo di gestione di una commessa per un cliente che richiede l’erogazione
dei servizi gestiti attraverso il flagship store.
Alla nuova commessa segue la creazione di un’istanza di progetto nello strumento di ges-
tione dei progetti. Le richieste effettuate dal cliente, vengono analizzate dai responsabili e dai
membri di progetto del reparto IT. Le attività definite per rispondere alle richieste del cliente,
vengono scomposte e inserite nel Product backlog. I membri del reparto IT tracciano gli at-1.2. VISIONE AGILE 5
tributi delle attività come: la data di inizio, la data di fine, l’assegnatario e la priorità. Utilizzando
queste informazioni, i responsabili di progetto ne adattano la strategia di conduzione durante
uno Sprint.
Figura 1.3: Lo sviluppo con Scrum
https://it.wikipedia.org/wiki/Scrum_(informatica)
Ambienti di sviluppo, collaudo e staging vengono preparati per accogliere la codebase del
nuovo tenant. Il team di rilascio si occupa di gestire il dislocamento della codebase, nei vari am-
bienti, quando vengono prodotti incrementi funzionali significativi.
Nelle fasi iniziali di sviluppo del progetto, vengono coinvolte risorse dai team di sviluppo
e di integrazione. Le regole di usabilità, per soddisfare il cliente, sono individuate dal team di
sviluppo. Il team di integrazione, invece, scompone i flussi dati che regolano ordine, pagamento
e consegna del bene.
Durante lo svolgimento del progetto vengono utilizzate tutte le cerimonie dello Scrum frame-
work.
Gli Sprint vengono pianificati, tipicamente, con durata bisettimanale. All’inizio di ogni
giornata, i responsabili di progetto guidano gli incontri di progetto utilizzando gli strumenti
per la gestione delle attività. Le risorse partecipano agli incontri per il progetto al quale sono
state assegnate. Durante la giornata, i membri dei team IT coinvolti nel progetto portano a
termine le attività assegnate. Tutti i membri del reparto IT coinvolti nel progetto, utilizzano gli
strumenti di gestione per tracciare i progressi ottenuti durante lo svolgimento dei compiti. Al
termine della settimana, durante gli incontri di retrospettiva e di revisione, vengono effettuate
valutazioni sull’andamento del progetto. In quel momento, i membri di progetto propongono
soluzioni per migliorare l’efficienza degli Sprint successivi.6 CAPITOLO 1. L’ AZIENDA
1.2.3 La manutenzione del software
La metodologia Agile viene utilizzata anche durante il processo di manutenzione. Sprint e stru-
menti per la gestione di progetto, vengono utilizzati per gestire le attività di manutenzione. Il
processo di manutenzione adotta una combinazione di Scrum e Kanban, per aumentare la reat-
tività nei confronti delle richieste del cliente.
Il modello combinato prevede la presenza di una scrivania Kanban. Gli sviluppatori utiliz-
zano un modello di tipo pull per perdere in carico la richiesta. In questo modo, si semplifica
l’attività di pianificazione delle manutenzioni e vengono ridotti i tempi di risposta.
La suddivisione del ciclo di vita dei prodotti software nelle varie fasi, aiuta a mitigare il ris-
chio di fallimento durante il rilascio di nuove funzionalità e di correzioni. Le funzionalità e le
correttive rilasciate dal reparto IT, attraversano sempre tutte le fasi del ciclo di vita. I clienti dei
progetti, affiancati dai responsabili di progetto, collaborano attivamente al processo di sviluppo
e rilascio. Dopo la fase di collaudo, i feeback del cliente vengono filtrati, valutati e lavorati dai
responsabili di progetto e dagli sviluppatori. Verifica e validazione vengono effettuate, insieme
al cliente, per stabilire cosa deve essere rilasciato negli ambienti di produzione.
1.3 Tecnologie utilizzate
Nel sistema sviluppato per offrire i servizi gestiti, i rivenditori e i gestori del magazzino trac-
ciano informazioni e dettagli su ordini, prezzi, livelli multipli di inventario, carrelli della spesa
abbandonati, posizioni di stoccaggio dei prodotti, tempi e costi di consegna. Alcune di queste
informazioni sono rilevanti per i consumatori che si aspettano di poterle trovare in uno spazio
dedicato come “i miei ordini” (almeno sul web o sul dispositivo mobile).
Per offrire tutte le funzioni sopra descritte è quindi necessario disporre di un sistema di ges-
tione degli ordini. Il sistema di gestione degli ordini dell’azienda orchestra diversi sottosistemi.
Ogni sottosistema, a sua volta, è incaricato della risoluzione e della gestione di una parte dei
servizi offerti dall’intero sistema. Ad esempio, il sottosistema di spedizione della merce prende
in carico gli ordini di spedizione e traccia il percorso del bene fino alla consegna.
L’azienda usa strumenti di integrazione, coinvolgendo i sottosistemi del commercio elettron-
ico, per completare l’evasione degli ordini. Ogni sottosistema espone API che possono essere
utilizzate per attivare le funzioni dello specifico sottodominio. Ad esempio, al momento del
pagamento della merce in carrello, possono essere invocate le API di un sottosistema come Pay-
Pal per gestire la transazione con la carta di credito.1.3. TECNOLOGIE UTILIZZATE 7
Il sistema di integrazione può prelevare tutti i pagamenti effettuati con PayPal per confer-
mare quali ordini devono essere trasferiti al sottosistema di gestione e consegna della merce.
Figura 1.4: L’orchestrazione dei sottosistemi del commercio in rete
https:
//blog.clever-age.com/en/2018/04/30/oms-a-key-enabler-of-omni-channel-commerce/
L’adozione della metodologia Agile e lo sviluppo di prodotti di alto profilo hanno spinto Di-
ana Corp ad utilizzare soluzioni software commerciali specificamente progettate per il mercato
di riferimento, concentrando quindi le proprie energie sulla qualità del prodotto da consegnare
al cliente.
Diana Corp utilizza gli ambienti in cloud e i framework messi a disposizione da compagnie
come Salesforce, Atalassian e Dell, riducendo i costi associati alla gestione dell’hardware.
Con riferimento alle numerose tecnologie utilizzate dall’azienda, è sembrato importante ri-
portare quelle che vengono maggiormente impiegate nei progetti per la gestione del commercio
in rete.
Jira
Jira è un software appartenente alla suite Atlassian. Il sistema viene utilizzato dalle aziende
che, prevalentemente, adottano la metodologia di sviluppo Agile per organizzare i progetti e
dividere le attività in compiti assegnati ad ogni membro del progetto. In questa applicazione
il responsabile di progetto registra le attività da svolgere e le assegna ai membri del gruppo di8 CAPITOLO 1. L’ AZIENDA
sviluppo. L’assegnatario ritroverà nella propria bacheca personale le varie attività da svolgere,
con tutte le informazioni di dettaglio come: descrizione, creatore, priorità, utenti assegnati, data
di conclusione, stato del compito (da fare, in corso, completato, da rivedere, ecc..), allegati e
commenti.
L’applicazione viene utilizzata dai reparti che dialogano con il reparto IT, per tracciare l’andamento
dei progetti e per coordinare le attività e i compiti assegnati alle risorse.
Boomi
Boomi è una piattaforma di integrazione cloud per il collegamento di applicazioni e dati
cloud e locali. Acquistata da Dell nel 2010, la piattaforma consente la progettazione di processi
di integrazione basati su cloud e il trasferimento dati tra applicazioni cloud e locali. Le API es-
poste dai sottosistemi, consentono a Boomi di definire oggetti sorgente e oggetti destinazione
per trasformare e trasferire le informazioni.
La piattaforma viene utilizzata dall’azienda , per realizzare il dialogo tra i sottosistemi che
partecipano al flusso di commercio elettronico.
Salesforce
Salesforce fornisce un servizio di gestione delle relazioni con i clienti (CRM). Salesforce pro-
pone, inoltre, una suite di applicazioni aziendali incentrate sul servizio clienti, sull’automazione
del marketing, sull’analisi e sullo sviluppo di applicazioni.
B2C Commerce è un’applicazione, appartenente alla suite, che fornisce le risorse per lo sviluppo
dei siti di commercio elettronico in rete. L’applicazione, mette a disposizione librerie per l’integrazione
con sistemi terze parti e un ambiente cloud dove è possibile gestire il ciclo di vita dei prodotti.
B2C Commerce è il framework utilizzato dal team di sviluppo Diana Corp, per realizzare le
vetrine dei clienti.
NetSuite
NetSuite Inc. è una società americana di cloud computing che fornisce software e servizi per
la gestione: delle finanze aziendali, delle operazioni e delle relazioni con i clienti. I suoi software
e servizi sono personalizzati per le piccole, medie e grandi aziende con moduli per ERP , CRM,
e commercio elettronico.
Diana Corp utilizza prodotti appartenenti alla suite, per gestire le risorse utilizzate dal com-
mercio elettronico.Il PoC per diffondere il know-how
2
2.1 La scelta dell’azienda
2.1.1 Obiettivi personali
Ho intrapreso il percorso di studi come studente lavoratore e concluderò questa esperienza du-
rante lo svolgimento dell’attività lavorativa. Attualmente mi occupo di sviluppo di applicazioni
web. Le motivazioni che mi hanno portato a svolgere il tirocinio, provengono dall’esperienza
lavorativa e dalla carriera di studente del corso di laurea.
Durante la mia carriera di studente, ho sperimentato un metodo di apprendimento diverso
da quello acquisito con l’esperienza lavorativa. Il corso di laurea, mi ha insegnato ad essere più
consapevole dell’attività che svolgo. Nel percorso formativo mi sono stati presentati concetti
che applicherò nel mondo del lavoro e pertanto, voglio sfruttare lo stage per mettere in pratica
queste conoscenze e valutarne l’efficacia.
Dall’esperienza lavorativa ho appreso che i concetti proposti dal corso di laurea, non sono
adottatati da tutte le aziende del settore informatico. Gli strumenti acquisiti durante il percorso
di studio mi hanno fornito gli strumenti per valutare le aziende tenendo conto di alcuni fattori,
tra cui il raggiungimento degli obiettivi e l’adeguamento ai metodi di lavoro riconosciuti dalla
comunità accademica. Indipendentemente dalla realtà lavorativa nella quale sarò impiegato,
confido che questi strumenti potranno essermi di aiuto nello scegliere le future opportunità di
lavoro e nel gestire i nuovi progetti che mi aspettano.
Molte delle aspettative del tirocinio sono legate a quanto sopra descritto. La scelta dell’azienda
in cui svolgere il tirocinio doveva rispondere ai seguenti criteri:
• lo svolgimento del tirocinio doveva condizionare in misura minima lo svolgimento dell’attuale
attività lavorativa;
• le tecnologie impiegate dall’azienda dovevano essere all’avanguardia;
• i rapporti con il personale dovevano essere possibilmente conviviali per rendere l’esperienza
di stage piacevole, oltre che professionale;
910 CAPITOLO 2. IL POC PER DIFFONDERE IL KNOW-HOW
• il personale con il quale avrei interagito doveva dimostrarsi qualificato per scambiare opin-
ioni e per poter ricevere consiglio in caso di difficoltà;
• i metodi e le pratiche dell’azienda dovevano essere molto vicine ai metodi e alle pratiche
apprese durante il percorso di studio;
• con il progetto di tirocinio volevo esplorare temi innovativi per aumentare le mie abilità;
• l’esperienza di tirocinio doveva essere un’opportunità per far conoscere le mie abilità all’azienda,
anche nella prospettiva di una possibile collaborazione;
• infine, l’adozione dei metodi agili da parte dell’azienda avrebbe rappresentato un valore
aggiunto.
2.1.2 Perché ho scelto Diana Corp
Per individuare l’azienda che mi avrebbe ospitato durante il tirocinio, ho portato a termine una
ricerca esplorativa. I candidati, scelti dal roster di aziende presenti a stage.it 2019, sono stati se-
lezionati e valutati utilizzando gli obiettivi personali. Alcune delle aziende presenti nella lista
sono state consigliate anche da ex colleghi di studio. Ho orientato la scelta del progetto su argo-
menti che avrei voluto approfondire nel mondo del lavoro.
Ho valutato positivamente il colloquio conoscitivo con il tutor di Diana Corp poichè la pro-
posta del progetto di tirocinio era in linea con le mie competenze e consentiva l’approfondimento
di temi che ritenevo interessanti, dal punto di vista professionale.
In conclusione, ho scelto Diana Corp, perché le caratteristiche dell’azienda e il progetto di
tirocinio, proposto dal tutor, erano in linea con le mie aspettative.
2.2 Documentare con un PoC
2.2.1 Un portale per la pubblicazione della documentazione
Come descritto nel capitolo §1, Diana Corp è un’azienda che crede nell’adozione dei metodi agili.
Il principio del manifesto Agile, “Working software over comprehensive documentation”, ispira la
strategia di gestione del progetto. Il Proof of concept (PoC), è la realizzazione di un certo metodo
o idea, al fine di dimostrarne la fattibilità o una dimostrazione in linea di principio. L’obiettivo
del PoC, è verificare che alcuni concetti o teorie, abbiano un potenziale pratico [3]. Il progetto
di stage è quindi un PoC.
Durante lo svolgimento del tirocinio, ho pubblicato nel web il risultato del mio lavoro. Il
prodotto da me realizzato non consiste unicamente in una blackbox utilizzabile dagli utenti fi-
nali. Ho rilasciato il codice sorgente del prodotto, con licenza MIT, all’interno della piattaforma2.2. DOCUMENTARE CON UN POC 11
GitHub. In questo modo, il codice sorgente del prodotto può essere consultato liberamente da
tutti.
L’argomento del progetto di stage risponde a necessità dell’azienda ospitante. Il flagship
store dell’azienda, può essere classificato come SaaS e il basso grado di accoppiamento delle com-
ponenti del sistema, è ottenuto attraverso l’esposizione di interfacce applicative dette WebAPI.
Gli sviluppatori software che operano sulla piattaforma devono scegliere WebAPI appropriate
per realizzare il dialogo tra le varie componenti poiché l’efficienza e l’efficacia delle funzionalità
sviluppate dipende dal corretto impiego delle stesse.
Il prodotto da me realizzato, fornisce un’analisi e un confronto dei paradigmi di proget-
tazione delle WebAPI. L’ho concepito per aiutare gli sviluppatori a scegliere il paradigma di
progettazione, durante lo sviluppo della piattaforma. Request-Respose ed Event-Driven sono le
tipologie di paradigma da me presentate.
Figura 2.1: Il risultato dell’analisi dei paradigmi di progettazione
https://webapi-analysis.herokuapp.com/
Il prodotto non è rivolto unicamente agli sviluppatori del flagship store Diana Corp ma an-
che a sviluppatori che intendono integrare servizi terze parti. Il portale Microsoft Azure è un
esempio di prodotto terze parti utilizzato dall’azienda. Il portale Microsoft mette a disposizione
WebAPI per dialogare con i servizi del prodotto Office 365 che utilizza lo stile architetturale
REST per accedere agli eventi di calendario e ai messaggi di posta elettronica .
Un altro argomento che ho affrontato con il PoC è la sicurezza delle WebAPI. In molti casi
gli sviluppatori devono progettare e costruire interfacce applicative per esporre i dati aziendali su
Internet. Ciò significa che, software esterni possono consultare i dati rilasciati da Diana Corp. In12 CAPITOLO 2. IL POC PER DIFFONDERE IL KNOW-HOW
questo scenario, è necessario progettare le WebAPI in modo sicuro per proibire l’accesso alle
applicazioni non autorizzate. Nel prodotto sono documentate le pratiche da utilizzare per rag-
giungere questo obiettivo.
2.2.2 Rendere la conoscenza accessibile
La forma scelta, per presentare il risultato finale dello stage, è quella del sito web. Nella postazione
di lavoro degli sviluppatori è presente un calcolatore. Il sito web che ho costruito consiste in
una documentazione interattiva che può essere consultata dallo sviluppatore, durante lo svolgi-
mento dei propri compiti.
Ho reso il sito web responsivo, in modo che gli sviluppatori possano consultare la documen-
tazione, anche dai dispositivi mobili. Questa caratteristica è vantaggiosa quando lo sviluppatore
è fuori sede e deve utilizzare strumenti diversi da quelli presenti nella postazione di lavoro.
2.2.3 Tecnologie utilizzate
Per il PoC ho impiegato le tecnologie utilizzate dagli sviluppatori Diana Corp. Ho adottato
un’architettura a microservizi. Adottando questo pattern, ho isolato le componenti della pila
software e ho semplificato la scrittura del codice.
Figura 2.2: Architettura di integrazione2.2. DOCUMENTARE CON UN POC 13
Presento di seguito l’elenco delle tecnologie impiegate durante la realizzazione del PoC. Per
brevità, riporto unicamente gli elementi principali della pila software e ometto le librerie utiliz-
zate e i servizi di terze parti come Google Dialogflow.
Docker
Docker è uno strumento progettato per semplificare la creazione, la distribuzione e l’esecuzione
di applicazioni con contenitori. I contenitori, isolano gli ambienti dei microservizi e le compo-
nenti, in questo modo, le componenti software possono essere raggruppate in un’unica appli-
cazione. Utilizzando i contenitori ho potuto trasportare la pila software su sistemi operativi
diversi.
Laravel, Express.js, Docusaurus e PostgreSQL fanno parte dei contenitori che compongono
la pila software.
Laravel
Laravel è un framework web PHP, gratuito e open source, per lo sviluppo di applicazioni
web con MVC. Elenco alcune delle caratteristiche di Laravel: un sistema di packaging modulare
con un gestore delle dipendenze dedicato, diverse modalità per accedere ai database relazion-
ali, orientamento verso lo zucchero sintattico; utilità che aiutano a distribuire e manutenere le
applicazioni.
Ho utilizzato Laravel per progettare e implementare gli stili architetturali che ricorrono nel
paradigma di progettazione Request-Response.
Express.js
Express.js è un framework per sviluppare applicazioni Javascript per l’interprete Node.js. Il
framework è open source e viene rilasciato con licenza MIT. È progettato per costruire appli-
cazioni web e WebAPI.
Ho utilizzato Express per progettare e implementare gli stili architetturali che ricorrono nel
paradigma di progettazione Event-Driven.
Docusaurus
Docusaurus è uno strumento per la pubblicazione di documentazione web, realizzato dalla
comunità open source di Facebook. Lo strumento è pronto all’uso e lo sviluppatore non deve
progettare e implementare l’infrastruttura per pubblicare i documenti. I prerequisiti per rilas-
ciare la documentazione sono: documenti scritti in markdown, una home page scritta in React
e alcune modifiche alla configurazione dello strumento.14 CAPITOLO 2. IL POC PER DIFFONDERE IL KNOW-HOW
Ho utilizzato Docusaurus, per pubblicare i contenuti statici risultato dell’analisi. Ho uti-
lizzato il supporto nativo React, per realizzare l’interazione tra l’interfaccia grafica web e le We-
bAPI.
PostgreSQL
PostgreSQL è un potente database relazionale open source che utilizza ed estende il linguag-
gio SQL. PostgreSQL ha guadagnato una solida reputazione per: affidabilità, integrità dei dati,
solido set di funzionalità, estensibilità e dedizione della comunità open source.
Ho utilizzato questo database relazione per supportare tutte le operazioni di lettura e scrit-
tura dalle WebAPI. Heroku metteva a disposizione un’ istanza del database relazionale senza
quindi essere obbligato ad installare il microservizio. In questo modo, si sono semplificate le
operazioni di dislocamento nell’ambiente di produzione.
Visual Studio Code
Visual Studio Code è un editor di codice sorgente, sviluppato da Microsoft, per Windows,
Linux e macOS. Include il supporto per: debugging, controllo per Git, Syntax highlighting,
Snippet e refactoring del codice.
Ho utilizzato questo IDE per scrivere il codice sorgente del sistema e per l’analisi statica.
2.2.4 Impatto del PoC nel breve periodo
Per consegnare il prodotto entro i tempi stabiliti ho dovuto fare delle scelte. La mappa dei tra-
guardi è stata suddivisa per separare quelli raggiunti da quelli raggiungibili dopo la data di con-
segna del prodotto.
Traguardi raggiunti
Riporto l’elenco dei traguardi raggiunti al momento della consegna del prodotto
• Progettazione e realizzazione dell’impianto di base e dell’architettura del sistema;
• Analisi e realizzazione delle WebAPI per gli stili architetturali: REST, RPC, GraphQL e
Webhook;
• Analisi del protocollo WebSocket.
Traguardi futuri
Riporto l’elenco dei traguardi che possono essere raggiunti nel breve periodo2.3. LO STAGE IN UN’AZIENDA AGILE 15
• Progettazione e implementazione di un microservizio GraphQL per il supporto delle op-
erazioni di tipo subscriptions;
• Analisi e realizzazione delle WebAPI per lo stile architetturale gRPC;
• Analisi del protocollo HTTP/2.
2.3 Lo stage in un’azienda agile
2.3.1 Documentare per il team di sviluppo
La condivisione della conoscenza aziendale è importante per consentire l’intercambiabilità dei
membri del gruppo. L’argomento del PoC è di interesse per l’azienda, perché molte delle at-
tività ruotano intorno allo sviluppo e all’utilizzo delle WebAPI. I team, che curano lo sviluppo
delle interfacce grafiche del sistema, utilizzano servizi che espongono i dati attraverso le WebAPI.
Strumenti come Del Boomi, vengono utilizzati dall’azienda per prelevare e trasformare i dati
provenienti dai servizi in rete.
Il codice sorgente che ho rilasciato, può essere consultato dai programmatori per osservare
il dialogo tra client e server. In questo modo, viene fornita documentazione: ai programmatori
che utilizzano le WebAPI; ai programmatori che progettano e sviluppano nuove WebAPI.
1 /* ** GitHub
2 il frammento di codice dimostra come definire
3 un 'endopoint Webhook . La WebAPI prevede l'utilizzo
4 di HMAC per autorizzare la richiesta del client .
5 */
6 app . p o s t ( '/ webhook ' ,
7 hmac ( c o n f i g . hmac . s e c r e t , {
8 a l g o r i t h m : 'sha512 ' ,
9 i d e n t i f i e r : 'HMAC ' ,
10 h e a d e r : 'authorization ' ,
11 m a x I n t e r v a l : c o n f i g . hmac . m a x I n t e r v a l
12 }) ,
13 ( r e q , r e s ) => {
14 wc . t o ( r e q . q u e r y . a p i _ k e y ) . e m i t ( 'message .sent ' , r e q . body . m e s s a g e ) ;
15 r e t u r n r e s . j s o n ( { " message " : "Great !" } ) ;
16 }) ;
Frammento 2.1: Frammento di codice sorgente del prodotto16 CAPITOLO 2. IL POC PER DIFFONDERE IL KNOW-HOW
L’adozione di nuovi paradigmi e stili architetturali può motivare la revisione dei contenuti
dell’analisi. Il prodotto è concepito per essere estensibile, nuovi documenti e funzionalità pos-
sono essere aggiunte per migliorare l’analisi.
2.3.2 Il software funzionante più che la documentazione esaustiva
Ogni progetto informatico è sicuramente incompleto fino a quando non viene corredato da una
documentazione esauriente. In un progetto informatico la documentazione è presente in tutte
le fasi del ciclo di vita. Nello sviluppo Agile non esiste una vera definizione di documentazione.
Dalla prospettiva di sviluppo, il codice deve essere ben documentato per facilitare l’evoluzione
del prodotto. Per gli utenti finali, è preferibile predisporre una documentazione orientata all’uso
del sistema [4].
Il prodotto documenta il risultato dell’analisi e per questa ragione soddisfa sviluppatori e
utenti finali. L’usabilità del sito web soddisfa la richiesta dell’utente finale riproponendo paradigmi
di navigazione noti.
Figura 2.3: Il codice interattivo per interagire con le WebAPI
https://webapi-analysis.herokuapp.com/docs/request-response/rest#
how-to-create-a-resource
Le componenti interattive e il codice sorgente pubblicato su GitHub sono invece desti-
nate agli sviluppatori. Rilasciando il codice sorgente e inserendo componenti interattive nel2.3. LO STAGE IN UN’AZIENDA AGILE 17
prodotto, posso convincere gli sviluppatori dell’affidabilità dei concetti esposti.
2.3.3 L’importanza di scrivere il codice di buona qualità
Il reparto IT di Diana Corp, gestisce molte tipologie di prodotto diverse. Con buona proba-
bilità, il prodotto da me rilasciato, verrà gestito da membri dei team dell’azienda. Per questa
ragione, ho concepito il prodotto perché sia facile da manutenere.
Per raggiungere questo obiettivo ho progettato il sistema utilizzando un’architettura a mi-
croservizi. L’adozione di questo pattern mi permette di ottenere questi vantaggi:
• è meno probabile il manifestarsi di un problema che produca un blocco dell’intero sis-
tema;
• il sistema è facile da orchestrare nei diversi ambienti;
• il codice sorgente è molto semplice e le operazioni di riscrittura sono meno rischiose;
• il sistema è scalabile perché ognuno dei container Docker può essere dislocato su mac-
chine diverse;
• i diversi stili architetturali delle WebAPI sono localizzati in ambienti con linguaggi di pro-
grammazione adatti alla gestione del paradigma di riferimento.
I vantaggi ereditati dall’adozione di questa architettura interessano i team di sviluppo, gli
amministratori e i system integrator. Per sviluppare il prodotto, ho utilizzato dei framework di
tipo OOP. In questo modo, il prodotto eredita le caratteristiche e i principi di questo paradigma.
Grazie alle caratteristiche ereditate si semplificano le attività di manutenzione e di evoluzione.
Ho utilizzato Visual Code per effettuare l’analisi statica del codice sorgente e assicurarmi dell’assenza
di errori nel codice dovuti alla presenza di rami inutilizzati o a formalismi che rendono il pro-
cesso di interpretazione meno efficiente.
2.3.4 Obiettivi dello stage
Gli obiettivi fissati all’inizio dello stage hanno subìto delle correzioni in corso d’opera. In seguito
alla presentazione dell’analisi sui paradigmi Request-Response, il tutor ha suggerito l’approfondimento
dello stile architetturale GraphQL. Di seguito, riporto la versione aggiornata degli obiettivi dello
lo stage:
1. Implementazione dell’impianto base di un PoC per presentare l’analisi dei paradigmi di
progettazione delle WebAPI;
2. Presentazione dei risultati dell’analisi sulle pratiche di sicurezza usate WebAPI;
3. Presentazione dei risultati dell’analisi per il paradigma Request-Response;18 CAPITOLO 2. IL POC PER DIFFONDERE IL KNOW-HOW
4. Presentazione dei risultati dell’analisi, per il paradigma Event-Driven;
5. Approfondimento dello stile architetturale GraphQL.
2.3.5 Utilità del PoC nel lungo periodo
Ho realizzato il prodotto per raggiungere gli obiettivi fissati dal progetto. Ho utilizzato compo-
nenti software che permettono l’estensione, non solo per il dominio di riferimento, ma anche
per un dominio più ampio.
Se il dominio di riferimento del prodotto è la “documentazione dell’analisi sulle WebAPI in
modo interattivo”, posso dire che il prodotto può essere esteso nel dominio “documentazione
interattiva”. L’utilizzo del componente Docusaurus, semplifica la pubblicazione di un qualsiasi
documento scritto in markdown.
Di seguito riporto alcuni possibili traguardi:
• Pubblicazione di nuove tipologie di paradigma di progettazione;
• Pubblicazione di nuovi stili architetturali;
• Pubblicazione di documenti di analisi, per argomenti diversi dal dominio corrente.
2.4 Vincoli di stage
2.4.1 Vincoli temporali
L’Università ha fissato le date di inizio e di fine dello stage. Le ore totali di stage sono comprese
tra 300 e 320. L’azienda ospitante ha imposto altri vincoli temporali. Diana Corp prevedeva la
presenza nelle fasce orarie 9:00-13:00 e 14:00-18:00. Oltre a questo, il piano di lavoro preparato
dal tutor aziendale, pianificava le attività da portare a termine e le scadenze temporali.
L’attuale datore di lavoro ha imposto l’ultimo vincolo temporale: lo svolgimento del tirocinio
non doveva condizionare le attività lavorative già pianificate. Per raggiungere questo obiettivo il
datore di lavoro ha concesso lunedì, mercoledì e venerdì come giornate da dedicare al tirocinio.
Per questa ragione, le ore di tirocinio sono state distribuite su un arco temporale di circa tre
mesi.
2.4.2 Vincoli tecnologici
L’azienda mi ha affidato un calcolatore con preinstallato il sistema operativo MacOS 10.7 e per-
tanto le attività di sviluppo venivano svolte su questa piattaforma. Il prodotto doveva essere un2.5. STRATEGIE PER IL RIUTILIZZO 19
sito web installato sulla piattaforma Heroku. Era quindi vincolante sviluppare un software web
utilizzabile dai maggiori browser.
Oltre a questo, il dispiegamento del prodotto sulla piattaforma Heroku introduceva vincoli
a cascata. Heroku consentiva l’installazione di contenitori Docker e l’uso di Docker ha lo scopo
di semplificare lo sviluppo di sistemi a microservizi.
2.5 Strategie per il riutilizzo
2.5.1 Il PoC e la dimostrabilità
La scelta di implementare un prodotto consultabile in modo interattivo, rispetto alla tradizionale
documentazione “statica”, offre diversi vantaggi. L’adozione del PoC favorisce l’approfondimento
della teoria attraverso l’applicazione. A volte, la scelta del metodo per la risoluzione di un pro-
blema è guidata da vincoli temporali che possono obbligare lo sviluppatore ad adottare soluzioni
che hanno dimostrato di funzionare, rispetto a soluzioni più appropriate dal punto di vista
teorico. L’affiancamento di teorica e applicazione risolve questa criticità.
2.5.2 Fonti affidabili per il Copy&Paste
Il copia e incolla è un meccanismo efficace per il riutilizzo del codice. Il programmatore ottiene
parti di codice, utilizzando varie fonti e verifica se è corretto, efficiente, estensibile e personaliz-
zabile. Le fonti sono importanti per garantire la qualità e l’efficacia del risultato.
Durante il periodo di tirocinio ho osservato che l’adozione dei metodi agili, porta gli svilup-
patori Diana Corp a comunicare con frequenza, condividendo informazioni a voce, via email
o con strumenti per la messaggistica istantanea. Frammenti di codice vengono trasmessi, uti-
lizzando questi canali, per esibire codice funzionante e riutilizzabile. Nella maggior parte dei
casi, il codice trasmesso non è pronto all’uso e deve essere verificato e personalizzato. Il metodo
di lavoro del gruppo di sviluppo, motiva la realizzazione di un sito di riferimento per tutti gli
sviluppatori.
Ho inserito nel prodotto esempi di codice interattivo che possono essere modificati e verifi-
cati. Il codice interattivo realizza una comunicazione di tipo client server tra browser e WebAPI e
può essere modificato per simulare l’impatto di una modifica sul sorgente. La possibilità di mod-
ificare e verificare il risultato delle operazioni effettuate dal client aumenta la fiducia sull’utilità
della fonte.
Ho inoltre sfruttato l’utility di sistema cURL per consentire un dialogo da terminale con le
WebAPI.20 CAPITOLO 2. IL POC PER DIFFONDERE IL KNOW-HOW
1 # Esempio di codice
2 # il codice può essere il copiato e incollato nel terminale
3 # per controllare la risposta delle REST WebAPI
4 c u r l −− i n s e c u r e −X POST \
5 'https :// webapi - analysis . herokuapp .com/api/rest/ movies ?' \
6 'identifier = $identifier ' \
7 '&title=Conan %20 the %20 barbarian ' \
8 '&year =1982& duration =2h%209 min ' \
9 '& director =John %20 Milius '
10 −H 'Authorization : Bearer $( JWT_TOKEN )' \
11 −H 'Accept : text/json ' \
12 −H 'Content -Type: application /x-www -form - urlencoded '
Frammento 2.2: Utilizzo delle WebAPI con cURL
La scelta è ricaduta su cURL per le ragioni che riporto di seguito:
• nelle postazioni di sviluppo Diana Corp è installato MacOS e l’utility cURL è presente
tra le utility di base sistema operativo;
• l’utilizzo di un comando da terminale semplifica l’utilizzo della funziona copia e incolla
fornita dal sistema operativo;
• il comando da terminale permette di osservare il risultato dell’operazione senza nessun
tipo di formattazione, questa caratteristica permette allo sviluppatore di osservare il dato
grezzo;
• il comando cURL simula una comunicazione client-server minimale, è quindi utile nella
progettazione from scratch.
2.5.3 La documentazione come strumento di riuso
Il riuso del codice permette di risparmiare tempo durante la scrittura del sorgente. Le attività
di programmazione sono semplificate e viene migliorata la leggibilità del codice che diventa più
corto e sintetico.
Portali come Stackoverflow e php.org rilasciano porzioni di codice riutilizzabile che devono
essere personalizzate del programmatore. Inoltre, rilasciare frammenti di codice specifico per la
propria piattaforma semplifica le operazioni di personalizzazione.
Il prodotto rilasciato a Diana Corp è modificabile e pertanto è possibile inserire all’interno
della piattaforma frammenti di codice pronto all’uso per le piattaforme di riferimento. In questo
modo potrebbero essere semplificate le attività di sviluppo per le piattaforme gestite da Diana
Corp.Lo sviluppo del PoC
3
3.1 Il metodo di lavoro
In questa sezione ho descritto la pratiche utilizzate per lo sviluppo del prodotto. Il piano di la-
voro, preparato dal tutor aziendale, elencava le attività che dovevano essere portate a termine per
rilasciare il prodotto. Trattandosi di un PoC erano previste: attività di approfondimento sugli
argomenti trattati, attività per lo sviluppo delle funzionalità e attività di revisione dei prodotti
rilasciati.
Ho deciso di approfittare dell’esperienza di stage per sperimentare i metodi agili. In molte
occasioni, ho chiesto consigli al personale del reparto IT sulle pratiche da adottare per organiz-
zare la attività in modo efficiente.
3.1.1 Pianificazione delle attività
Il piano di progetto, preparato dal tutor, ha semplificato l’organizzazione delle attività e dei com-
piti che dovevo svolgere. Nel piano di lavoro erano riportate le attività che avrei dovuto portare
a termine.
Ho adottato il metodo Scrum per gestire il progetto. Utilizzando il piano di progetto ho rag-
gruppato le attività in Sprint. Ho definito la date di conclusione degli Sprint per farle coincidere
con le date di revisione di progetto. In questo modo, ho potuto mostrare al tutor gli incrementi
raggiunti durante le sessioni di revisione.
ID Nome sprint Conclusione
Studio e formazione sui paradigmi di progettazione delle
S1 29 Novembre 2019
WebAPI [5]
S2 Architettura del sistema e funzioni di base 6 Dicembre 2019
2122 CAPITOLO 3. LO SVILUPPO DEL POC
ID Nome sprint Conclusione
S3 Analisi paradigma Request-Reponse e stili WebAPI 24 Dicembre 2019
S4 Analisi paradigma Event-Driven e stili WebAPI 24 Gennaio 2020
S5 Approfondimenti, rilascio del prodotto e consegna finale 07 Febbraio 2020
Tabella 3.2: Pianificazione degli Sprint
Ho trascritto le attività dal piano di progetto nello strumento di gestione e le ho organizzate
in Sprint. Ho considerato più impegnative le attività che richiedevano l’impiego di tecnologie
che non avevo mai sperimentato. Ho provveduto quindi a classificare gli Sprint tenendo conto
di questa caratteristica ed infine ho assegnato dei punteggi ad ogni Sprint sulla base delle quattro
categorie qui riportate:
• UX - progettazione dell’esperienza utente
• Design - progettazione e definizione delle immagini, dei colori, delle forme e della ti-
pografia per migliorare l’usabilità e migliorare l’esperienza dell’utente
• Front - sviluppo delle interazioni per l’interfaccia utente
• Back - sviluppo componenti di accesso ai dati e logiche di business
Con questo sistema di categorizzazione, ho assegnato punteggi più alti alle componenti
che richiedevano l’interazione con l’utente finale. Il dialogo bidirezionale, tra client e server,
prevedeva la definizione di nuovi componenti sviluppati con la libreria React per questa ragione
gli Sprint di sviluppo delle WebAPI Event-Driven avevano un peso maggiore, se paragonati agli
Sprint delle WebAPI Request-Response.
Figura 3.1: Pianificazione delle attività di progetto3.2. SVILUPPO DEL PRODOTTO 23
3.1.2 Revisioni di progresso
Durante l’intero svolgimento del tirocinio, il tutor ha periodicamente preso visione del lavoro
svolto e ha fornito suggerimenti di natura tecnica. Nel piano di lavoro redatto prima dell’inizio
dello stage, erano riportati i momenti in cui si sarebbero svolte le revisioni di progresso.
Grazie a queste, ho potuto definire meglio i punteggi per le categorie UX e Design. Durante
tutta la durata del progetto, il tutor ha fornito molti suggerimenti che mi hanno aiutato a miglio-
rare la qualità del prodotto. Ho riprogettato il prodotto in più occasioni, perché incoraggiato a
trovare soluzioni sempre più efficaci ed eleganti.
Con cadenza regolare, il tutor chiedeva una rapporto sullo stato di avanzamento dei lavori e
valutava il grado di raggiungimento degli obiettivi fissati.
Le revisioni di progresso sono risultate fondamentali per migliorare la qualità del prodotto
e per risolvere problemi di natura tecnica.
3.1.3 Analisi e tracciamento dei requisiti
Ho derivato i requisiti dal piano di progetto e dalle interviste con il tutor. Il piano di progetto
è la fonte principale dei requisiti funzionali. Le interviste con il tutor sono la fonte dei requisiti
di vincolo.
Ho utilizzato i requisiti per definire i test di verifica e di validazione del sistema. Ho definito
le date di inizio e di fine degli Sprint, utilizzando i requisiti. Il piano di lavoro indicava quali
incrementi funzionali avrei dovuto mostrare al tutor, durante le revisioni di progresso.
Ho distribuito i requisiti individuati negli Sprint per valutare il grado di conformità del
prodotto e il raggiungimento degli obiettivi fissati. Durante ogni incontro di revisione, ho val-
idato il prodotto mostrando i requisiti soddisfatti, in questo modo, ad ogni revisione il tutor ha
potuto valutare il grado di completamento dell’intero prodotto.
3.2 Sviluppo del prodotto
3.2.1 Analisi
Ho derivato le interazioni degli utenti con il sistema dal piano di lavoro e dalle interviste con il
tutor. Di seguito riporto le funzionalità del sistema utilizzando i diagrammi dei casi d’uso.
Durante le interviste il tutor ha proposto nuove funzionalità per migliorare l’esperienza utente.
Le pagine web del sito sono interattive e l’utente finale può simulare il funzionamento delle di-
verse WebAPI, utilizzando frammenti di codice. Per questa ragione il sistema mette a dispo-24 CAPITOLO 3. LO SVILUPPO DEL POC
sizione dell’utente due tipologie di interazione con le WebAPI. La piattaforma web rende in-
oltre disponibili tutte le funzioni offerte dal sistema. L’utente può inoltre utilizzare un insieme
ridotto delle funzioni, con l’utility cURL.
Casi d’uso del sistema web
Riporto di seguito i casi d’uso per il sistema web.
Figura 3.2: Casi d’uso del sistema web3.2. SVILUPPO DEL PRODOTTO 25
Request-Response
Di seguito ho rappresentato i casi d’uso del sistema web, dove l’utente interagisce con le
WebAPI di tipo Request-Response.
Figura 3.3: Casi d’uso per le WebAPI Request-Response nel sistema web
Event-Driven
Di seguito ho rappresentato i casi d’uso del sistema web, dove l’utente interagisce con le
WebAPI e i protocolli di tipo Event-Driven.
Figura 3.4: Casi d’uso per i protocolli e per le WebAPI Event-Driven nel sistema web26 CAPITOLO 3. LO SVILUPPO DEL POC
Casi d’uso per l’interfaccia da terminale
L’interfaccia da terminale prevede tutti i casi d’uso già presentati per le WebAPI di tipo
Request-Respose. A questi casi d’uso si aggiunge il caso d’uso UC8.2 che permette l’invio dei
messaggi al componente chat per le WebAPI di tipo Webhook.
Requisiti
I casi d’uso sono serviti per definire meglio i requisiti di sistema. Di seguito riporto i requi-
siti e le fonti utilizzate per derivarli. Ho classificato i requisiti con la notazione qui riportata. Il
codice utilizzato per classificare i requisiti è composto da un prefisso e da un numero che iden-
tifica, a sua volta, il requisito in modo univoco.
Il prefisso è composto da due caratteri. Il tipo di requisito viene indicato con:
• F il requisito è funzionale;
• V il requisito è di vincolo.
Il livello di obbligatorietà del requisito è identificato da:
• O il requisito definito anche nel piano di progetto è obbligatorio per il committente;
• D il requisito non è necessario ma rappresenta un valore aggiunto riconoscibile.
Requisiti f unzionali
ID Descrizione Fonte
Il sistema deve consentire la consultazione del documento Piano di progetto,
FO1
che riassume l’analisi sullo studio di cos’è una WebAPI UC1
Il sistema deve consentire la consultazione del documento
Piano di progetto,
FO2 che riassume l’analisi sui possibili business cases per le
UC2
WebAPI
Il sistema deve consentire la consultazione del documento
Piano di progetto,
FO3 che riassume l’analisi sullo studio dei paradigmi di
UC3
progettazione per le WebAPI
Il sistema deve consentire la consultazione del documento
FO4 che riassume l’analisi sulle pratiche da adottare per rendere Interviste, UC4
le WebAPI sicurePuoi anche leggere
