ECM Tesi di laurea - 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
Integrazione di Google Drive: modifiche
collaborative online e in tempo reale con
ECM
Tesi di laurea
Relatore
Prof. Francesco Ranzato
Laureando
Mirko Gibin
Matricola 1102450
Anno Accademico 2018-2019
Mirko Gibin: Integrazione di Google Drive: modifiche collaborative online e in tempo reale con ECM, Tesi di laurea, c Febbraio 2019.
Sommario
Il presente documento descrive il lavoro svolto durante lo stage del laureando Mirko
Gibin presso l’azienda Sanmarco Informatica S.p.A. sotto la supervisione del tutor
aziendale Stefano Fardin.
Tale attività, svolta al termine della Laurea Triennale in Informatica dal 5 novembre
2018 al 11 gennaio 2019, ha richiesto un impegno di 320 ore.
Lo scopo dello stage era la realizzazione di un nuovo modulo di ECM, software per la
gestione documentale prodotto dall’azienda, per offrire agli utenti dell’applicativo la
possibilità di modificare in modo collaborativo i documenti qui caricati. Ciò è stato
reso possibile sfruttando il servizio Google Drive e la relativa suite per l’ufficio che
comprende Google Documenti, Google Fogli e Google Presentazioni.
Questo documento è così diviso:
• Capitolo 1: presentazione del contesto aziendale in cui si è svolto lo stage;
• Capitolo 2: presentazione del progetto di stage con i relativi obiettivi;
• Capitolo 3: descrizione dello svolgimento dello stage;
• Capitolo 4: valutazione retrospettiva dello stage.
iii
Ringraziamenti
Vorrei ringraziare il Professore Francesco Ranzato, relatore della mia tesi, per l’aiuto e
il supporto fornitomi.
Ringrazio il mio tutor aziendale Stefano Fardin, che mi ha offerto questa opportunità,
e tutto il team, che mi ha accolto e guidato.
Desidero ringraziare di cuore i miei genitori per il loro grande sostegno e la loro infinita
pazienza.
Ringrazio tutti gli amici e i colleghi che mi hanno accompagnato in questo percorso, in
particolar modo Francesco, Giovanni e Federico.
E grazie anche a coloro che erano con me nei momenti di svago, specialmente Gianluca,
Fabio, Valentino e Sara.
Per concludere, uno speciale ringraziamento va a Valentina, sempre al mio fianco sia
nelle situazioni più belle che in quelle più dure. Grazie a te sono riuscito a trovare la
forza per superare tutti gli ostacoli.
Padova, Febbraio 2019 Mirko Gibin
v
Indice
1 Contesto aziendale 1
1.1 L’azienda in generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Il team di Discovery ECM . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Metodologia di sviluppo adottata . . . . . . . . . . . . . . . . . . . . . 2
1.4 Tecnologie di riferimento . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Strumenti per lo sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Sistemi operativi . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.2 Ambienti di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3 Gestione dei progetti software . . . . . . . . . . . . . . . . . . . 5
2 Lo stage nella strategia aziendale 7
2.1 Il progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Discovery ECM per la gestione documentale . . . . . . . . . . . . . . . 7
2.3 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.2 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Realizzazione del progetto 15
3.1 Formazione e ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Progetto, tecnologie e strumenti . . . . . . . . . . . . . . . . . 15
3.1.2 Valutazione delle alternative . . . . . . . . . . . . . . . . . . . 15
3.1.3 Google Drive REST API . . . . . . . . . . . . . . . . . . . . . 16
3.1.4 Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Progettazione dell’architettura . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Visione complessiva . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2.1 Le classi rest . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2.2 Le classi service . . . . . . . . . . . . . . . . . . . . . 20
3.2.2.3 Le classi client . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3.1 La componente view . . . . . . . . . . . . . . . . . . . 23
3.2.3.2 La componente controller . . . . . . . . . . . . . . . . 23
vii
viii INDICE
3.2.3.3 La componente service . . . . . . . . . . . . . . . . . 23
3.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Sviluppo del modulo di autorizzazione . . . . . . . . . . . . . . 24
3.3.1.1 Gestione del codice di autorizzazione . . . . . . . . . 24
3.3.1.2 Gestione dei token . . . . . . . . . . . . . . . . . . . . 24
3.3.1.3 Persistenza delle credenziali . . . . . . . . . . . . . . . 25
3.3.2 Modifica dei documenti . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2.2 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Creazione di un nuovo documento . . . . . . . . . . . . . . . . 26
3.3.4 Altre implementazioni . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.1 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.2 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Valutazione retrospettiva 31
4.1 Riscontro dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Divario tra università e lavoro . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A Protocollo OAuth 2.0 37
A.1 Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2 Ruoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.3 Registrazione del client . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.4 Flusso del protocollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.5 OAuth 2.0 con Google . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B Schermate del prodotto 43
Glossario 47
Bibliografia 51
Elenco delle figure
1.1 Logo di Sanmarco Informatica S.p.A. . . . . . . . . . . . . . . . . . . . 1
1.2 Rappresentazione del framework Scrum . . . . . . . . . . . . . . . . . 2
2.1 Diagramma delle attività - prima metà . . . . . . . . . . . . . . . . . . 14
2.2 Diagramma delle attività - seconda metà . . . . . . . . . . . . . . . . . 14
3.1 Logo di Google Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Scherma di richiesta delle credenziali per l’utilizzo delle API Google . 17
3.3 Progettazione ad alto livello del modulo di integrazione con Google Drive 19
3.4 Diagramma delle classi rest . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Diagramma delle classi service . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Diagramma delle classi client . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 Architettura frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.1 Flusso del protocollo OAuth 2.0 per l’autorizzazione . . . . . . . . . . 39
A.2 Flusso del protocollo OAuth 2.0 per il refresh dei token . . . . . . . . 39
A.3 Flusso del protocollo OAuth 2.0 con Google per un’applicazione web
server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.4 Richiesta autorizzazione da parte dell’applicazione client . . . . . . . . 41
B.1 Sezione per la creazione di un nuovo documento e relativo messaggio di
apertura dell’editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.2 Pulsante di "avvio nuova modifica" presente nei documenti modificabili
e messaggi di conferma annullamento modifiche. . . . . . . . . . . . . 44
B.3 Pulsanti visualizzati quando è in corso una modifica e nome dell’utente
che l’ha avviata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.4 Messaggio che conferma la concessione dell’autorizzazione da parte
dell’utente, con la quale permette ad ECM di modificare i file all’interno
di Drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.5 Pulsanti di gestione di un documento in creazione e messaggio visualiz-
zato prima di confermare l’annullamento. . . . . . . . . . . . . . . . . 45
B.6 Messaggio di errore relativo all’apertura di un link ad un documento la
cui modifica è stata chiusa per annullamento o check-in. . . . . . . . . 45
B.7 Operazione di check-in di un file in modifica. . . . . . . . . . . . . . . 46
ix
x ELENCO DELLE TABELLE
Elenco delle tabelle
2.1 Tabella degli obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Tabella dei rischi individuati . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Tabella delle attività . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Tabella dei rischi riscontrati . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Tabella del raggiungimento degli obiettivi aziendali . . . . . . . . . . . 33Capitolo 1
Contesto aziendale
1.1 L’azienda in generale
Figura 1.1: Logo di Sanmarco Informatica S.p.A.
Fonte: www.sanmarcoinformatica.it
Ho svolto lo stage presso Sanmarco Informatica S.p.A., software house fondata nel
1984 che si occupa della progettazione e della realizzazione di soluzioni applicative a
supporto dei vari processi aziendali.
La sede principale, avente funzione commerciale e amministrativa, e il Centro di Ricerca
e Sviluppo, dove ho svolto lo stage, sono situati a Grisignano di Zocco, provincia di
Vicenza. A Reggio Emilia, Vimercate, provincia di Monza e della Brianza, e Tavagnac-
co, provincia di Udine, sono presenti delle filiali a supporto dei sistemisti. L’azienda
vanta un organico di oltre 400 dipendenti e collaboratori tra cui sistemisti, sviluppatori
software, grafici, addetti al marketing, addetti al personale e alla formazione e figure pro-
fessionali specializzate nell’organizzazione e gestione aziendale. Attualmente Sanmarco
Informatica segue circa 2000 aziende private italiane, europee ed extraeuropee.
1.2 Il team di Discovery ECM
Il team in cui sono stato inserito si occupa dello sviluppo e manutenzione del software
di gestione dei contenuti Discovery ECM (nel presente documento abbreviato in ECM ).
Questo prodotto permette la gestione di tutti i documenti aziendali digitalizzati con
l’obiettivo di abbattere i costi dovuti alla gestione della versione cartacea degli stessi.
È prevista anche l’archiviazione a norma dei contenuti che acquisiscono così valenza
legale e fiscale.
Altro progetto qui seguito è Discovery XChange, servizio che gestisce gli obblighi
12 CAPITOLO 1. CONTESTO AZIENDALE
normativi relativi alla fatturazione elettronica.
Di seguito parlerò degli strumenti, delle metodologie e delle tecnologie utilizzate
all’interno di questo team.
1.3 Metodologia di sviluppo adottata
L’azienda adotta una metodologia Agileg nello sviluppo dei propri prodotti. Al cliente
viene offerta la possibilità di personalizzazione, dunque la stretta collaborazione con
lo stesso diventa indispensabile ed è necessario reagire in modo rapido ed efficace ai
frequenti cambiamenti delle richieste. Nel periodo del mio stage ho avuto modo di
osservare come i requisiti di prodotto cambino velocemente anche a causa degli aggior-
namenti imposti dalle normative: archiviazione digitale dei documenti e fatturazione
elettronica hanno subìto numerose modifiche in ambito legislativo, alle quali l’azienda
ha dovuto adeguarsi in tempi brevi. Un approccio Agile allo sviluppo permette di
concentrare le risorse sulla realizzazione di software funzionante e di adattarsi velo-
cemente ai cambiamenti e alle nuove esigenze del cliente, mettendo in secondo piano
documentazione esaustiva, rigida pianificazione e negoziazione di contratti.
Framework Scrum
Nel team in cui sono stato inserito la metodologia Agile è utilizzata applicando il
frameworkg Scrum, il quale offre un insieme di regole che permettono di ottenere i
vantaggi precedentemente elencati offrendo al contempo una rappresentazione dell’a-
vanzamento generale dei lavori, adattandosi dunque alle necessità di un’azienda di
discrete dimensioni che riunisce le esigenze di numerosi stakeholderg .
Figura 1.2: Rappresentazione del framework Scrum
Fonte: https://www.scrum.org/resources/scrum-framework-poster
Secondo le regole di Scrum lo sviluppo del prodotto è guidato dai seguenti elementi:
• Product backlog: insieme di requisiti e definizione delle caratteristiche del
software di cui si deve occupare il team di Scrum;1.3. METODOLOGIA DI SVILUPPO ADOTTATA 3
• Sprint: un iterazione dello sviluppo della durata da 1 a 4 settimane durante la
quale non è possibile cambiare gli obiettivi. Lo scopo dello Sprint è realizzare un
incremento di prodotto potenzialmente rilasciabile.
• Incremento di prodotto potenzialmente rilasciabile: l’incremento di un
software consegnato alla fine di uno Sprint. Dovrebbe trovarsi in uno stato finito
e non richiedere ulteriore lavoro per essere incorporato nel prodotto finale;
Tipico di questo framework è la presenza dei seguenti ruoli:
• Team di sviluppo: gruppo di sviluppatori con organizzazione autonoma, re-
sponsabili dello sviluppo del software e della produzione della documentazione
essenziale necessaria. L’obiettivo del team è consegnare un incremento di prodotto
potenzialmente rilasciabile alla fine di uno Sprint;
• Product Owner: persona che rappresenta il cliente o uno stakeholder. Ha il
compito di definire i requisiti critici del prodotto assegnando delle priorità e
aggiorna il Product Backlog di conseguenza, accertandosi che il team produca
valore;
• Scrum Master: ha la responsabilità di trasmettere i valori e le regole di Scrum
e di assicurare la corretta esecuzione del processo. Si interfaccia con il Product
Owner per migliorare la gestione del Product Backlog e definire in modo chiaro
gli obiettivi, collabora con il team di Scrum allo scopo di creare prodotti di
valore e rimuovere gli ostacoli e le interferenze esterne non legate allo sviluppo
del prodotto, collabora con gli altri Scrum Masters per migliorare l’efficacia
dell’applicazione del framework a livello aziendale.
Durante lo stage ho avuto la possibilità di partecipare alle riunioni e agli eventi previsti
dal metodo Scrum, i quali sono volti a pianificare, monitorare e valutare l’avanzamento
dello sviluppo. Vengono di seguito elencati:
• Sprint Planning: riunione effettuata all’inizio di ogni Sprint in cui si pianifica
il lavoro da svolgere. Vi partecipa l’intero Scrum team analizzando Product
Backlog per definire quale incremento produrre nel prossimo Sprint;
• Daily Stand-up: riunione giornaliera della durata di 15 minuti circa in cui
ciascun membro del team di sviluppo comunica il lavoro svolto nel giorno lavo-
rativo precedente, gli obiettivi della corrente giornata lavorativa e indica se è
necessario un aiuto da parte di altri componenti. Ciò permette a tutto il team di
tenere traccia degli avanzamenti e di coordinare e organizzare le varie attività,
incentivando la collaborazione;
• Sprint Review: riunione che si svolge al termine di ogni Sprint per monitorare
l’incremento e adattare il Product Backlog. Vi partecipano sia lo Scrum team
che gli stakeholders al fine di valutare l’andamento dello sviluppo. Vengono
dimostrati i risultati ottenuti tramite una dimostrazione del prodotto (detta
Demo), analizzando ciò che è stato fatto o meno, i problemi riscontrati e le
note positive dello Sprint, eventuali cambiamenti di requisiti, budget o altro che
possano influire sullo sviluppo futuro. I risultati della Sprint Review vanno ad
aggiornare il Product Backlog e influiranno di conseguenza sulla successiva Sprint
Planning. Anche in questa riunione la collaborazione gioca un ruolo importante
per adattarsi alle nuove esigenze e cogliere le nuove opportunità;4 CAPITOLO 1. CONTESTO AZIENDALE
• Sprint Retrospective: riunione effettuata successivamente alla Sprint Review
durante la quale lo Scrum team fa un’autoanalisi per evidenziare gli aspetti
positivi e negativi riscontrati durante l’ultimo Sprint. La riunione viene svolta
in un modo informale, abbandonando temporaneamente i propri ruoli al fine
di esporre consigli, criticità o problemi senza doversi preoccupare della propria
posizione. Affrontare i problemi emersi e trovare punti di miglioramento è un
buon modo per cercare di mantenere alti livelli di collaborazione, coesione e
soddisfazione all’interno del team.
Altra attività non strettamente legata alla metodologia Agile a cui ho partecipato è
stata la Code Review, nella quale si è valutato il codice prodotto da ciascun membro
riconoscendo errori, criticità, elementi positivi e migliorie da apportare. Ciò permette a
ciascuno di aumentare il proprio bagaglio conoscitivo e produrre codice più manutenibile
e meno soggetto ad errori e inefficienze negli Sprint successivi.
1.4 Tecnologie di riferimento
1.4.1 Frontend
Come verrà approfondito nella sezione 2.5, per il frontend le tecnologie più utilizzate
sono JavaScript, il framework JavaScript AngularJs, HTML e CSS.
È previsto una nuova versione dell’interfaccia grafica basata sul framework Angular
7. Tale aggiornamento è attualmente in fase realizzazione con la previsione di miglio-
ramenti sia sul fronte della manutenibilità del codice che delle prestazioni e usabilità
dell’applicazione.
1.4.2 Backend
Come verrà approfondito nella sezione 2.5, per il backend la tecnologia più utilizzata è
Java grazie alla sua portabilità e alle sue numerose funzionalità e librerie. Lo sviluppo
in Java viene realizzato con l’ausilio di numerosi framework quali:
• Spring che permette ad esempio l’iniezione delle dipendenze e la gestione dell’au-
tenticazione;
• Jersey per la gestione dei servizi RESTg ;
• MyBatis per la gestione dei dati persistenti;
• JUnit, JMock e Selenium per la realizzazione dei test;
Per la gestione dei documenti viene utilizzato il software Alfresco Community Edition,
mentre i database utilizzati sono MySQL e SQLServer.
È prevista la sostituzione del framework MyBatis a favore di Hibernate per una migliore
gestione dei dati persistenti.
1.5 Strumenti per lo sviluppo
1.5.1 Sistemi operativi
L’azienda non impone vincoli sull’utilizzo dei sistemi operativi, il cui uso dipende dalle
preferenze degli sviluppatori o dalle necessità dei progetti. Nei server utilizzati in1.5. STRUMENTI PER LO SVILUPPO 5
azienda sono installati sia il sistema operativo Windows che Linux in modo da poter
testare i prodotti in entrambe le piattaforme ed essere pronti ad adattarsi quanto
più possibile alle esigenze dei clienti. Per il mio progetto ho utilizzato un computer
aziendale dotato di sistema operativo Windows e interagito principalmente con server
Windows.
1.5.2 Ambienti di sviluppo
Il team in cui sono stato inserito utilizza i seguenti strumenti per lo sviluppo:
• Eclipse: ambiente di sviluppo integrato utilizzato principalmente per la realiz-
zazione del backend di ECM. Per migliorare il lavoro sono stati aggiunti diversi
plugin, tra i quali i principali sono:
– Sonarlint: estensione che aiuta a migliorare la qualità del codice mentre
questo viene scritto. Vengono evidenziati i problemi del codice e poi proposti
la spiegazione del problema ed esempi di soluzioni. Il team si affida a questo
strumento per avere una buona base comune da seguire per scrivere codice
di qualità;
– Spring Tool Suite: estensione che semplifica la gestione di progetti che
utilizzano il framework Spring. Tra gli aiuti forniti vi è la segnalazione di
dipendenze mancanti o non esistenti quando queste vengono definite nei
relativi file XMLg .
• Visual Studio Code: editor di codice sorgente utilizzato nella realizzazione del
frontend di ECM ;
• MySQL Workbench: strumento grafico per la creazione, gestione e manuten-
zione di database MySQL;
1.5.3 Gestione dei progetti software
Apache Maven è uno strumento per la gestione di progetti software. Oltre ad
automatizzare la buildg Maven si occupa anche del soddisfacimento delle dipendenze
del progetto. La struttura di quest’ultimo è rappresentata in un file XML chiamato
POM (Project Object Model), nel quale vengono indicate informazioni come il nome
del progetto, la versione, i file di configurazione richiesti, gli sviluppatori che hanno
partecipato e il loro ruolo, le librerie e le dipendenze. Qualora fosse necessaria una
nuova libreria o una sua versione più aggiornata è sufficiente aggiornare il file XML.
Maven scaricherà in modo automatico le librerie dichiarate e si occuperà di soddisfare
tutte le dipendenze necessarie.Capitolo 2
Lo stage nella strategia
aziendale
2.1 Il progetto
Lo scopo dello stage è stato la realizzazione dell’integrazione con Google Drive del
documentale ECM per offrire agli utenti la possibilità di modifica contemporanea dei
documenti. L’utente che inizia una nuova modifica agisce dall’interfaccia grafica del
documentale e prosegue in Google Drive; al termine degli aggiornamenti può effettuare
il check-ing delle modifiche e creare così una nuova versione del contenuto.
Prima di questa integrazione, per poter effettuare una modifica nel documentale
era necessario scaricare il documento in locale, modificarlo con un opportuno editor
e ricaricarlo come nuova versione. Tale modalità poteva risultare limitativa e non
consente una collaborazione immediata. L’ostacolo maggiore si presentava nel caso di
utilizzo del documentale ECM da parte di terzi, incaricati nella gestione dei contenuti
per conto di altre aziende. In questo caso, alla richiesta di una modifica, le parti erano
costrette a scambiarsi reciprocamente il documento tramite email o altri strumenti.
Grazie all’integrazione con Google Drive, qualora fosse necessario aggiornare dei conte-
nuti, è sufficiente che l’utente incaricato della loro gestione avvii la modifica con Google
Drive e condivida il link del documento con il richiedente. Con solamente un browser e
un account Google è possibile aggiornare i contenuti, anche collaborando in tempo reale
con altre persone, senza dover uscire dal documentale e senza dover utilizzare editor
installati localmente. Una volta concluse le modifiche, tramite il check-in vengono
aggiornati il contenuto e la versione del documento presente all’interno di ECM.
2.2 Discovery ECM per la gestione documentale
Il team in cui sono stato inserito si occupa dello sviluppo e della manutenzione di
Discovery ECM, un’applicazione web dedicata alla gestione dei contenuti aziendali
in formato digitale (come suggerito dall’acronimo ECMg ). I documenti qui salvati
vengono organizzati attraverso le classi documentali, ovvero un insieme di metadati
come la tipologia del documento, la data di creazione, la data di validità, il nome e
l’azienda di appartenenza. Questa gestione permette l’indicizzazione dei documenti e
aumenta la facilità di reperimento dei contenuti desiderati grazie anche alla funzionalità
78 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE spotlight, che ricerca le parole chiave sia tra i metadati che nei dati delle risorse. Essendo un’applicazione web l’accesso avviene tramite browser, quindi da qualsiasi dispositivo che lo supporta. ECM permette la condivisione dei documenti sia all’interno dell’azienda che all’e- sterno, ad esempio verso i clienti e i fornitori, gestendo i permessi di accesso dei vari utenti e le operazioni da loro eseguibili su ogni contenuto. Oltre alla consultazione dei documenti è permessa la loro creazione, modifica, eliminazione e trasmissione, purché la classe documentale di appartenenza lo consenta (ad esempio una fattura ricevuta non può essere modificata). Le modifiche o le revisioni vengono automaticamente tracciate tramite versionamento. L’archiviazione dei documenti riguarda sia il ciclo attivog che il ciclo passivog e la relativa conservazione digitale, supportata sia in house che in outsourcing 1 , viene effettuata attraverso le procedure informatiche previste dalla normativa italiana, le quali aggiungono ai contenuti valenza legale e fiscale. Lo scopo di ECM è quindi quello di garantire l’autenticità, l’integrità e l’affidabi- lità dei documenti digitalizzati offrendo l’opportunità di abbattere i costi legati alla stampa, allo stoccaggio e all’archiviazione. Il modo di organizzare i documenti favorisce inoltre il rapido reperimento dei contenuti necessari e la conseguente riduzione del tempo richiesto per ottenere le informazioni desiderate. 2.3 Obiettivi aziendali L’azienda ha richiesto, nelle 320 ore di stage, un’implementazione funzionante del modulo descritto da utilizzare come base per miglioramenti o estensioni in vista di un futuro rilascio con il prodotto. Per raggiungere un risultato soddisfacente gli obiettivi individuati sono stati suddivisi in obbligatori, desiderabili e facoltativi, come riportato nella tabella 2.1. 1 La conservazione digitale in house avviene tramite l’utilizzo di sistemi propri dell’azienda, mentre in outsourcing viene affidata a enti terzi.
2.3. OBIETTIVI AZIENDALI 9
Obiettivi obbligatori
Studio dell’API Google Drive
Studio di AngularJs
Studio dell’architettura REST
Studio del protocollo OAuth 2.0
Realizzazione modulo autenticazione con Google OAuth 2.0 lato backend
Realizzazione modulo autenticazione con Google OAuth 2.0 lato frontend
Realizzazione modulo modifica documento con Google Drive lato backend
Realizzazione modulo modifica documento con Google Drive lato frontend
Obiettivi desiderabili
Studio del documentale ECM
Studio di MyBatis
Studio di Maven
Studio di Spring Framework
Realizzazione di test con JUnit e JMock
Realizzazione modulo creazione nuovo documento con Google Drive lato backend
Realizzazione modulo creazione nuovo documento con Google Drive lato frontend
Stesura documentazione codice
Obiettivi facoltativi
Studio di Alfresco Community
Stesura test con Selenium
Apprendimento metodologia Scrum
Inserimento lock del documento aperto in modifica
Gestione dei permessi di modifica del documento in base alla classe documentale
Gestione dei permessi di modifica del documento in base all’utente
Tabella 2.1: Tabella degli obiettivi aziendali10 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE
2.4 Obiettivi personali
Il mio obiettivo principale era di poter effettuare questa mia prima esperienza la-
vorativa all’interno di un team in un’azienda di discrete dimensioni e con diversi
anni di esperienza. Cercavo inoltre uno stage che mi desse la possibilità sia di ap-
plicare quanto studiato all’università, sia di acquisire nuove conoscenze e di mettere
alla prova la mia capacità di apprendimento di nuove tecnologie e metodologie di lavoro.
Il progetto di stage di Sanmarco Informatica offriva le opportunità da me deside-
rate insieme ad un argomento che ho trovato molto interessante: l’utilizzo delle APIg
di Google per la realizzazione di una nuova componente di un prodotto già esistente.
Ciò mi avrebbe consentito di analizzare del codice scritto da altri sviluppatori con più
esperienza e di dover adattare la mia soluzione a determinate esigenze e vincoli.
Per una buona riuscita dell’attività mi sono posto i seguenti obiettivi:
• Imparare a lavorare secondo le regole del framework Scrum;
• Individuare le mie lacune e risolverle il prima possibile, studiando prima in
modo autonomo e fissando in seguito i concetti con l’aiuto del team e del tutor
aziendale;
• Essere in grado di rapportarmi con il team al fine di scambiare esperienze,
conoscenze e punti di vista sulle varie tecnologie e sul metodo di lavoro;
• Approfittare di questa esperienza di stage per osservare i problemi che un’azienda
può dover affrontare e le modalità di risoluzione adottate;
• Comprendere l’architettura e la logica di un’applicazione web RESTfulg ;
• Compiere una buona analisi dei requisiti richiesti;
• Dare ampio spazio alla progettazione dell’architettura del software e anticipare
eventuali criticità;
• Realizzare un prodotto funzionante;
• Scrivere del codice comprensibile, ben documentato e semplice da estendere e
manutenere.
2.5 Vincoli tecnologici
Per lo sviluppo del modulo è stato necessario adottare le stesse tecnologie utilizzate
nello sviluppo del documentale.
2.5.1 Backend
L’applicativo è realizzato in linguaggio Java, che viene eseguito su un server Tomcat.
Il framework Jersey si occupa della comunicazione con il client che avviene tramite
chiamate REST. I dati persistenti sono gestiti da un database MySQL o SQLServer a
seconda delle esigenze del cliente e la loro gestione avviene attraverso il framework My-
Batis. Spring Framework è ampiamente utilizzato per la gestione delle dipendenze tra
le varie componenti e Spring Security per la realizzazione del sistema di autenticazione2.5. VINCOLI TECNOLOGICI 11 e controllo di accessi. I test di unità sono realizzati con JUnit e JMock. I test con l’automatizzazione del browser sono realizzati con Selenium. Il motore documentale su cui ECM si appoggia è Alfresco Community Edition. Di seguito il dettaglio delle tecnologie citate. Java : linguaggio di programmazione ad alto livello orientato agli oggetti e a tipizza- zione statica. Viene utilizzato principalmente per la sua indipendenza dalla piattaforma di esecuzione, il che favorisce la semplice realizzazione di applicazioni portabili. Il motto "write once, run everywhere" esprime uno dei principi fondamentali di Java e infatti la compilazione di un sorgente genera del codice chiamato bytecode interpretato dalla Java Virtual Machine (JVM ). Per ogni piattaforma su cui l’applicazione deve essere eseguita il codice sorgente e il relativo bytecode sono gli stessi mentre cambia l’implementazione della JVM, la quale interpreta le istruzioni del codice compilato generando le istruzioni macchina corrette per il dispositivo in cui è in esecuzione. Altri punti di forza sono la presenza di numerose librerie che aggiungono molteplici funzionalità e la sua progettazione volta a garantire sicurezza nell’esecuzione di codice su macchine remote. La versione utilizzata è la 7; Apache Tomcat : server web opensource che implementa le specifiche Java servletg . Ciò lo rende una valida piattaforma su cui eseguire le applicazioni web realizzate in Java; Jersey : framework opensource utilizzato per lo sviluppo di servizi RESTful in Java; Spring Framework : framework opensource per lo sviluppo di applicazioni in Java. Utilizzato principalmente per ridurre l’accoppiamento tra i vari oggetti. Grazie a Spring Framework le classi non hanno più la responsabilità dell’istanziazione e inizia- lizzazione delle proprie dipendenze: seguendo le istruzioni di un file XML, realizzato dal programmatore, gli oggetti vengono creati correttamente da Spring e iniettati dove richiesti; Spring Security : framework utilizzato per la realizzazione di sistemi di autentica- zione e autorizzazione nelle applicazioni Java; MyBatis : framework opensource per la persistenza dei dati nelle applicazioni. Questo framework associa ai metodi di una classe le rispettive operazioni SQLg , le quali sono mappate in appositi file XML, in modo da poterle riutilizzare. Ciò permette il disaccoppiamento tra l’applicazione e le interrogazioni del database; MySql : RDBMSg basato su logica e linguaggio SQL; SQLServer : RDBMS proprietario Microsoft che utilizza Transact-SQL, variante del linguaggio standard SQL; JUnit : framework utilizzato per realizzare i test di unità per il linguaggio Java;
12 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE JMock : libreria che si appoggia a JUnit utile nella definizione di oggetti mockg e del loro comportamento, da iniettare nelle dipendenze solitamente soddisfatte da Spring Framework; Selenium : suite per i test delle applicazioni web nei quali vengono automatizzate le operazioni eseguite dagli utenti; Alfresco Community : software opensource per la gestione di documenti. 2.5.2 Frontend Il client di Discovery ECM è realizzato da pagine HTML che definiscono la struttura, arricchite da apposite direttive interpretate da AngularJs che permettono di rendere la pagina interattiva e di modificarne il contenuto a seconda delle azioni dell’utente e dei dati da visualizzare. L’aspetto dell’applicazione è gestito da fogli di stile CSS mentre la gestione dei dati e l’interazione con il server è responsabilità di script realizzati in JavaScript e organizzati in moduli gestiti dal framework AngularJs. Di seguito vengono descritte in dettaglio le tecnologie citate. Javascript : linguaggio di programmazione ad alto livello interpretato e a tipizza- zione dinamica. È conforme alle direttive ECMAScriptg ed è il linguaggio web più utilizzato insieme ad HTML e CSS. In questo contesto il suo ruolo è quello di gestire il comportamento delle pagine web lato client, pertanto è molto utilizzato per realizzare applicazioni web interattive. La sua flessibilità ne ha permesso la diffusione anche lato server e in programmi desktop o mobile. AngularJs : framework opensource per applicazioni web a singola pagina sviluppato principalmente da Google. AngularJs legge le pagine HTML arricchite con appositi attributi, interpretati come direttive, le quali permettono di collegare la vista con il model rappresentato dalle variabili JavaScript. Alla modifica di queste variabili corrisponde l’aggiornamento dinamico della pagina web, la quale si adatta quindi alle operazioni dell’utente. Il framework supporta l’architettura Model-View-Controllerg , ma la sua flessibilità permette di adattarlo anche ad altri pattern. Con AngularJs l’applicazione può essere divisa in moduli in base alle varie funzionalità offerte. Ogni modulo offre un’interfaccia pubblica e nasconde la complessità interna composta ad esempio da controller e servizi; HTML : HyperText Markup Language è un linguaggio di markup utilizzato per creare pagine e applicazioni web. Il suo scopo è descrivere la struttura semantica di un documento web. La versione utilizzata è la 5; CSS : Cascading Style Sheets è un linguaggio usato per definire la formattazione e l’aspetto dei documenti web scritti con il linguaggio HTML. La versione usata è la 3. 2.6 Analisi dei rischi All’inizio dello stage ho individuato alcuni potenziali rischi che avrebbero potuto influenzare negativamente il progetto, pianificando come intervenire per evitarli o
2.7. PIANIFICAZIONE DEL LAVORO 13
affrontarli.
Nella tabella 2.2 vengono valutati gli impatti (colonna "Imp") che i rischi potreb-
bero produrre sul progetto e la loro probabilità (colonnea "Prob") di verificarsi. Come
indice viene utilizzata una scala suddivisa in: basso, medio, alto, critico.
Descrizione Strategia Imp Prob
Inesperienza relativa- Studio preventivo della documentazione e Alto Alta
mente ad alcuni lin- realizzazione di una prova di progetto per
guaggi capirne il funzionamento.
Inabilità con gli stru- Comprendere fin da subito gli strumenti ne- Basso Media
menti di lavoro. cessari e il loro funzionamento, chiedendo
chiarimenti e consigli ai membri del team.
Mancanza di supporto Pianificare la possibilità di lavori concomitan- Critico Media
da parte del team o del ti evitando lo stagnamento in punti di stallo
tutor a causa di altro che necessitino di supporto o spiegazioni.
lavoro urgente
Gestione del tempo non Effettuare una pianificazione settimanale di Alto Media
ottimale (causata an- massima degli impegni e adattarla giorno
che dai tempi di viag- per giorno in base all’esperienza maturata.
gio per raggiungere il
lavoro)
Inesatta comprensione Analizzare in modo completo il problema, Critico Media
del problema e realizza- studiare la documentazione delle tecnologie
zione di una soluzione ed eventuali esempi, realizzare una Proof of
inefficace Conceptg e progettare in modo preciso con
diagrammi UMLg .
Tabella 2.2: Tabella dei rischi individuati
2.7 Pianificazione del lavoro
In accordo con il tutor aziendale l’attività di stage è stata pianificata suddividendo le
320 ore previste come indicato nella tabella 2.3.14 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE
Attività Ore Descrizione Settimana
Formazione 40 Introduzione al progetto e studio delle 1
relative tecnologie.
Analisi e definizio- 15 Comprensione del problema e delle 2
ne degli obiettivi soluzioni.
Raccolta documen- 25 Ricerca della documentazione necessaria 2
tazione per comprendere come implementare le
soluzioni e raggiungere gli obiettivi.
Implementazione 90 Realizzazione dell’integrazione lato bac- 3-5
backend kend.
Implementazione 60 Realizzazione dell’integrazione lato fron- 6-7
frontend tend.
Sviluppo dei test 90 Esecuzione dei test di unità e di 3-8
integrazione necessari.
Tabella 2.3: Tabella delle attività
Le figure 2.1 e 2.2 rappresentano in un diagramma di Ganttg la suddivisione temporale
delle attività.
Figura 2.1: Diagramma delle attività - prima metà
Figura 2.2: Diagramma delle attività - seconda metàCapitolo 3
Realizzazione del progetto
3.1 Formazione e ricerca
Le prime due settimane, per un totale di 80 ore, sono state dedicate alla formazione e
alla ricerca. Nelle sezioni a seguire è descritto l’approccio utilizzato per il progetto.
3.1.1 Progetto, tecnologie e strumenti
Con la guida del tutor aziendale e del team ho compreso i valori di Scrum e studia-
to la struttura del documentale ECM, analizzando determinate scelte progettuali e
implementative e apprendendo quali componenti sarebbero stati di maggior interesse
nello sviluppo del modulo richiesto. I framework Maven, per la gestione dei progetti, e
Spring Framework per la gestione della dependency injectiong si sono rivelati fin da
subito fondamentali per la buona riuscita del progetto; di conseguenza ho dedicato
particolare attenzione al loro studio, creando dei piccoli progetti indipendenti per
comprenderne l’approccio e il funzionamento. Ho adottato una strategia simile anche
per approfondire le mie conoscenze di AngularJs. Nel realizzare questi esempi ho
utilizzato gli strumenti di sviluppo previsti apprendendone le funzionalità principali.
Il passo successivo è stata la ricerca di informazioni, documentazione ed esempi degli
strumenti e delle librerie utilizzabili per raggiungere il mio obiettivo. Nelle fasi iniziali
ho trovato difficoltà nel reperimento e nella comprensione di informazioni ed esempi in
quanto scarsi in numero, poco completi e ricchi di concetti non spiegati e a me nuovi.
La documentazione di Google si è rivelata, contrariamente alle mie aspettative, poco
strutturata, dispersiva e a volte incompleta o superficiale. Recuperare informazioni al
suo interno spesso si rivelava un’operazione lunga a causa della mancanza di un indice
completo e ciò mi ha spinto a creare dei documenti in cui organizzare le informazioni
ottenute e tenere traccia delle fonti più utili.
3.1.2 Valutazione delle alternative
L’obiettivo del progetto di stage era permettere la modifica dei documenti presenti
all’interno di ECM con la suite per l’ufficio di Google: Documenti, Fogli e Presentazioni.
Ciò poteva essere realizzato sfruttando dei servizi messi a disposizione da Google tramite
apposite API. L’idea di modifica di documenti mi aveva dapprima portato a valutare le
API Docs e Sheets, le quali si sono però rivelate insufficienti per i miei obiettivi. Queste
1516 CAPITOLO 3. REALIZZAZIONE DEL PROGETTO
permettevano l’automatizzazione di alcune operazioni di gestione dei contenuti o la
possibilità di elaborare i dati di un documento, mentre le mie esigenze erano orientate
verso il salvataggio e la condivisione dei documenti, lasciando la gestione del contenuto
all’utente finale.
Ho così individuato Google Drive REST come API da utilizzare: la piattaforma Google
Drive offre le funzionalità di condivisione e collaborazione e uno spazio in cui salvare
i documenti, mentre la relativa API fornisce un insieme di librerie che permettono
l’esecuzione di operazioni CRUDg sugli stessi. L’unica fonte di informazioni è stata la
documentazione ufficiale di Google, la quale fornisce anche esempi di utilizzo specifici
per vari linguaggi. Trovando questa documentazione carente in determinati punti
ho integrato con lo studio di altri progetti e guide disponibili online e, su consiglio
del tutor aziendale, ho analizzato il codice sorgente messo a disposizione da Alfresco
Community che aveva già implementato un’integrazione simile con Google Drive.
Come prima soluzione ho ipotizzato di salvare i documenti all’interno di uno spazio
Drive dell’azienda associato all’applicazione e condividerli con l’utente. Gli svantaggi
principali erano però legati alla quantità di spazio necessario e al trattamento e la
diffusione di dati sensibili. Ho quindi valutato e in seguito adottato una soluzione che
sfruttasse l’utilizzo dello spazio Google Drive dei singoli utenti che avrebbero avviato
una nuova modifica dal documentale. Ciò avrebbe delegato sia il problema dello spazio
di archiviazione che la gestione dei documenti aziendali.
3.1.3 Google Drive REST API
Figura 3.1: Logo di Google Drive
Google Drive REST API è un insieme di procedure che permettono di integrare un’ap-
plicazione con Google Drive. I metodi offerti consentono di effettuare operazioni CRUD
su file all’interno delle cartelle Google Drive degli utenti previa loro autorizzazione.
Ogni operazione viene eseguita tramite una chiamata REST all’API di Google, la quale
deve includere le chiave di autorizzazione e autenticazione fornite da Google secondo il
protocollo OAuth 2.0 descritto nell’appendice A.
Seguendo le direttive della documentazione ufficiale, tramite la sezione di gestione delle
API (Google developers console) ho attivato l’API Google Drive REST e registrato
un nuovo progetto relativo ad ECM, l’applicazione che avrebbe effettuato le chiamate
REST a Google. Questa sezione permette inoltre di monitorare il traffico, gli errori e
altri parametri di utilizzo delle API da parte delle applicazioni registrate.
Per il progetto creato è necessario attivare l’API desiderata e generare le credenziali
per la propria applicazione, come mostrato in figura 3.2. Seguendo il protocollo OAuth
2.0, tra le varie informazioni vengono anche richiesti gli URIg di reindirizzamento
autorizzati.
Terminata la procedura, Google genera un file JSONg contenente il codice identificativo
dell’applicazione client, la relativa password e gli URI da utilizzare per effettuare le
richieste di autenticazione, autorizzazione e ottenimento delle access token. Seguendo3.1. FORMAZIONE E RICERCA 17
Figura 3.2: Scherma di richiesta delle credenziali per l’utilizzo delle API Google
gli esempi presenti nella documentazione ufficiale ho realizzato un primo programma
elementare che richiede il consenso dell’utente per estrarre una lista dei nomi dei primi
dieci file presenti nel suo spazio di archiviazione Drive. Sfruttando questo esempio
come base ho sperimentato altre funzionalità per iniziare a comprendere le possibilità
offerte.
3.1.4 Proof of Concept
Terminate le sperimentazioni e maturate basi sufficienti, ho ritenuto opportuno realiz-
zare una Proof of Concept per dimostrare la fattibilità del progetto con le tecnologie
richieste. Grazie a questa attività ho identificato e valutato due possibilità a prima
vista parimenti fattibili: la realizzazione dell’integrazione interamente nel frontend con
Javascript o completamente nel backend con Java. La prima si è dimostrata presto
insostenibile per la mancanza di documentazione, la difficoltà nella gestione delle chiavi
di accesso e la persistenza delle informazioni necessarie. La seconda possibilità si è
invece rivelata adeguata e ho realizzato così una semplice applicazione che caricava
un file di prova in formato Open Document Spreadsheet, presente nel desktop, sul mio
Drive personale e lo apriva in modifica con l’applicazione Google Fogli.
In seguito alla presentazione della Proof of Concept al tutor aziendale e alla valutazione
di alcune scelte progettuali ho iniziato a definire l’architettura del prodotto.18 CAPITOLO 3. REALIZZAZIONE DEL PROGETTO 3.2 Progettazione dell’architettura In seguito allo studio del problema e della documentazione, dopo la realizzazione della Proof of Concept ho sviluppato una prima struttura generale dell’architettura del modulo. La prima bozza era caratterizzata dalla presenza di alcuni design patterng creazionali quali il Factory Patterng e il Builder Patterng , pensati principalmente per dividere le responsabilità di uso e di creazione delle dipendenze delle classi. In seguito alla revisione da parte del tutor aziendale ho abbandonato l’utilizzo dei pattern precedentemente indicati e ho utilizzato al loro posto la dependency injection in quanto successivamente, a livello implementativo, la creazione e l’iniezione delle dipendenze sarebbero state responsabilità di Spring Framework. Oltre a questo vantaggio, la struttura del modulo sarebbe stata più semplice, comprensibile e coerente con quella degli altri componenti di ECM. Data la mia scarsa esperienza con la progettazione di architetture software ho più volte avuto la necessità di tradurre alcune classi o metodi in pseudo-codice per rendermi effettivamente conto della complessità che il componente avrebbe raggiunto e per evidenziare alcune divisioni di responsabilità da tenere in considerazione. Con questo approccio ho potuto correggere e migliorare tempestivamente l’architettura e arginare il problema di un futuro eccessivo discostamento dell’implementazione. 3.2.1 Visione complessiva La figura 3.3 mostra il diagramma dei packageg e fornisce un’idea della progettazione ad alto livello. Il package docmenu contiene tutto ciò che riguarda il frontend: in linea di massima è strutturato in modo che le interazioni dell’utente con la view inneschino funzioni del controller che utilizza i service per effettuare chiamate REST al server. Il package ecm racchiude tutto ciò che forma il backend. Le richieste REST vengono gestite dalle classi rest che invocano i metodi corretti delle classi service. Queste classi si occupano di gestire tutta la logica sfruttando altri oggetti per delegare alcune responsabilità. Per l’interrogazione con il database vengono utilizzate classi dao, mentre le classi pojo ed entity 1 rappresentano oggetti che vengono elaborati dalle classi service e scambiati con le classi client. Queste ultime hanno la responsabilità di utilizzare i metodi offerti dall’API per effettuare le operazioni necessarie. Mi sono impegnato per realizzare l’architettura in modo da separare i compiti delle varie classi e rispettare il Single Responsability Principleg . Come si potrà vedere meglio in seguito, l’architettura è pensata per rispettare anche l’Interface Segrega- tion Principleg e il Dependency Inversion Principleg , concretizzati dalla preferenza all’utilizzo di molte interfacce specifiche rispetto a poche e generiche e all’adozione della dependency injection come pattern architetturale guidato dall’ottica dell’utilizzo di Spring Framework. Le dipendenze delle classi sono verso interfacce, ad eccezione dell’uso di oggetti util, pojo o entity. Di seguito esporrò gli elementi più interessanti e importanti dell’architettura. 1 Le classi dao (Data Access Object) si occupano dell’interazione con il database, le classi entity e pojo rappresentato un oggetto i cui attributi sono solitamente salvati in una tabella in database e avente unicamente metodi di set e get. Le classi util contengono solamente metodi di utilità.
3.2. PROGETTAZIONE DELL’ARCHITETTURA 19 Figura 3.3: Progettazione ad alto livello del modulo di integrazione con Google Drive
20 CAPITOLO 3. REALIZZAZIONE DEL PROGETTO
3.2.2 Backend
3.2.2.1 Le classi rest
Figura 3.4: Diagramma delle classi rest
Le classi rest utilizzano le annotazioni Jersey per definire il metodo HTTPg della
chiamata REST gestita e l’endpointg a cui sono collegate. Ho identificato due tipolo-
gie di chiamate: quelle inerenti all’autorizzazione dell’applicazione, soddisfatte dalla
classe GoogleConnectionRestService e quelle relative alle operazioni vere e proprie sui
documenti, gestite dalla classe GoogleFileManagerRestService. Queste classi hanno
unicamente lo scopo di fare da ponte tra frontend e backend: invocano il metodo della
classe service collegato alla chiamata REST e restituiscono il risultato dell’operazione.
Ogni altra logica è responsabilità delle implementazioni delle classi service da cui
dipendono.
3.2.2.2 Le classi service
Le classi service si occupano di gestire gran parte della logica di business. Nell’eseguire
le operazioni richieste possono rivolgersi ad altri service e ad oggetti dao, util, pojo o
entity e sfruttare le classi client per operazioni verso l’API.
Nella realizzazione dell’architettura ho individuato quattro necessità alle quali corri-
spondono altrettante interfacce e le relative implementazioni:
• GoogleConnectionService per la gestione del processo di autorizzazione;
• GoogleCredentialPersistenceService per la gestione delle operazioni verso da-
tabase inerenti alla persistenza e al recupero delle credenziali ottenute con
l’autorizzazione;
• GoogleFileManagerService per la gestione della logica operazioni CRUD sui
documenti sia lato Google Drive, sia lato documentale;
• GoogleFilePersistenceService per la gestione delle operazioni verso database
inerenti alla persistenza e al recupero delle informazioni sui documenti la cui
modifica è attiva.3.2. PROGETTAZIONE DELL’ARCHITETTURA 21
Figura 3.5: Diagramma delle classi service
Figura 3.6: Diagramma delle classi client22 CAPITOLO 3. REALIZZAZIONE DEL PROGETTO
3.2.2.3 Le classi client
Le classi client si occupano dell’interazione con l’API Drive REST. Come per le classi
rest e service, ho diviso le responsabilità di connessione da quelle di gestione dei
file. GoogleConnectionClient si occupa delle procedure di autorizzazione, verifica la
validità delle credenziali ed effettua l’aggiornamento delle token quando necessario.
Avvia inoltre la connessione con l’API attraverso la quale possono essere effettuate
le richieste. GoogleFileManagerClient si occupa invece di tutte le operazioni che
riguardano il caricamento di documenti in Drive o l’esportazione del loro contenuto.
La decisione di renderlo dipendente da GoogleConnectionClient è giustificata dalla
possibilità di riuso del codice e dalla semplificazione della sua logica interna. Infatti
tutte le operazioni sui file verso Google Drive necessitano della connessione gestita da
GoogleConnectionClient che si occupa, come già detto, di aggiornare automaticamente
le credenziali in caso di invalidità, senza dover richiedere ulteriori controlli o operazioni.
L’utilità delle classi client si estende anche all’incapsulamento delle procedure messe
a disposizione dall’API rendendo indipendente il resto dell’applicazione. In caso di
aggiornamenti dell’API è quindi sufficiente modificare unicamente queste componenti.
3.2.3 Frontend
Figura 3.7: Architettura frontend
La progettazione del frontend ha richiesto meno tempo del backend in quanto vi erano
meno operazioni da eseguire. La figura 3.7 mostra una semplificazione dell’architettura.
Il mio scopo era aggiungere funzionalità ad un modulo esistente e, con l’aiuto del team,
ho compreso come integrare il controller e la view ad esso collegati.
Ho comunque trovato alcune difficoltà nella realizzazione di questa architettura a causa
della mia scarsa esperienza nell’utilizzo delle tecnologie richieste e della necessità di
adattarmi a strutture e funzionalità esistenti poco organizzate e non propriamente
documentate.
Avendo ora maturato maggiore esperienza a riguardo, non posso ritenermi pienamente3.3. IMPLEMENTAZIONE 23 soddisfatto di questa architettura: era possibile dividere in modo migliore le responsa- bilità di modifica e creazione dei documenti e separare in oggetti diversi le funzioni invocate tramite interazione dell’utente dalle altre. 3.2.3.1 La componente view Le view di mio interesse erano composte da due file HTML, uno per la visualizzazione dell’anteprima di un documento e uno per il caricamento di un nuovo contenuto. A queste avrei aggiunto i pulsanti di modifica e creazione di un nuovo documento con Google Drive e li avrei collegati al controller per gestirne l’abilitazione e la disabilitazione, mantenendo così lo stato del client coerente con quello del server. Ad esempio, un mio obiettivo era la visualizzazione del pulsante di "avvio nuova modifica" solamente per i documenti modificabili e la sua disabilitazione in caso opposto o qualora fosse già attiva una nuova modifica. In tal caso i pulsanti di "annullamento", "check-in" o "continua modifica" avrebbero dovuto sostituirlo. Perché ciò potesse funzionare anche al riavvio dell’applicazione era necessario che la logica dei pulsanti fosse collegata, in qualche modo, al server. 3.2.3.2 La componente controller Per entrambe le view dovevo adattare un unico controller. Qui avrei inserito le funzioni che l’interazione dell’utente avrebbe attivato e le chiamate al componente service per ottenere dati dal server sui cui effettuare le elaborazioni ed aggiornare la componente view di conseguenza. Come pensato per il backend ho ritenuto opportuno dividere i compiti relativi all’autorizzazione e alla modifica dei documenti affidandoli a due oggetti diversi. 3.2.3.3 La componente service La componente service si sarebbe occupata unicamente di creare ed eseguire le chiamate REST al server sia per il processo di autorizzazione che per la gestione dei documenti, per poi restituire il risultato al controller. 3.3 Implementazione Una volta raggiunta un’architettura del software soddisfacente ho iniziato la sua implementazione. Il team aveva già iniziato a ristrutturare, migliorare e documentare il prodotto e mi sono quindi impegnato a produrre codice di qualità. A tal fine ho scelto sempre nomi di funzioni e variabili in modo accurato in base al loro significato nel contesto di utilizzo e ho rispettato le convenzioni di codifica adottate, tra le quali il nome di variabili e metodi in camelCaseg , il nome delle classi camelCase con l’iniziale maiuscola, le costanti rappresentate da lettere maiuscole, l’inserimento di uno spazio prima di una parentesi graffa e l’aggiunta di uno spazio attorno agli operatori. Con qualche eccezione sono sempre riuscito a mantenere lo stesso livello di avanzamento tra documentazione in Javadocg e codifica. Al termine di ogni realizzazione di incremento svolgevo un’attività di verifica volta a correggere la documentazione di componenti che avevano subìto modifiche.
Puoi anche leggere
