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
Realizazione di un framework per
l’esecuzione di stress test dei servizi offerti da
Zimbra Collaboration Suite
Tesi di laurea triennale
Relatore
Prof. Tullio Vardanega
Laureando
Ugo Padoan
Anno Accademico 2018-2019
Indice
1 Contesto aziendale 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Organizzazione aziendale . . . . . . . . . . . . . . . . . . . . . 2
1.2 Prodotti e servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Zimbra Collaboration Suite . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Data Protection Manager . . . . . . . . . . . . . . . . . . . . . 5
1.3 Azienda ed innovazione . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Reparto sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Organizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Modello di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Lo stage 13
2.1 Rapporto tra azienda e stage . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Il progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Piano di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Formazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.4 Implementazione framework . . . . . . . . . . . . . . . . . . . . 17
2.5.5 Implementazione plugin . . . . . . . . . . . . . . . . . . . . . . 17
2.5.6 Test di sistema e manuale utente . . . . . . . . . . . . . . . . . 18
3 Svolgimento progetto 19
3.1 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Selezione delle tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Progettazione architetturale . . . . . . . . . . . . . . . . . . . . 25
3.3.3 Progettazione di dettaglio . . . . . . . . . . . . . . . . . . . . . 26
3.3.4 Pattern utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Codifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.2 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.3 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
iii
iv INDICE
3.6 Prodotto finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Conclusioni 41
4.1 Bilancio progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Bilancio requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Problematiche riscontrate . . . . . . . . . . . . . . . . . . . . . 41
4.2 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Competenze acquisite . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 Competenze mancanti . . . . . . . . . . . . . . . . . . . . . . . 44
Glossary 45
Acronyms 47
Bibliografia 49
Elenco delle figure
1.1 Logo aziendale Studio Storti . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Flusso di informazioni tra i reparti . . . . . . . . . . . . . . . . . . . . 2
1.3 Servizi offerti da ZCS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Componenti di ZCS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Data Protection Manager . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Ciclo dell’innovazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Organizzazione reparto sviluppo. . . . . . . . . . . . . . . . . . . . . . 7
1.8 Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.9 Strumenti utilizzati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Ore pianificate per la formazione . . . . . . . . . . . . . . . . . . . . . 16
2.2 Ore pianificate per l’analisi dei requisiti . . . . . . . . . . . . . . . . . 16
2.3 Ore pianificate per la progettazione . . . . . . . . . . . . . . . . . . . . 17
2.4 Ore pianificate per l’implementazione del framework . . . . . . . . . . 17
2.5 Ore pianificate per l’implementazione dei plugin . . . . . . . . . . . . . 18
2.6 Ore pianificate per i test e la stesura del manuale utente . . . . . . . . 18
3.1 Attori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Caso d’uso dettagliato UC1.1.5.1.2.1 . . . . . . . . . . . . . . . . . . . 21
3.4 Apache JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Componenti principali del progetto . . . . . . . . . . . . . . . . . . . . 24
3.6 Package zimbrastresstest . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 Package usersbuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8 Package activesync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 Diagramma delle classi del package activity . . . . . . . . . . . . . . . 27
3.10 Diagramma delle classi del pattern MVP . . . . . . . . . . . . . . . . . 28
3.11 Diagramma delle classi del pattern observer . . . . . . . . . . . . . . . 28
3.12 Diagramma delle classi del pattern command . . . . . . . . . . . . . . 29
3.13 Risultati del test esposto al termine della presentazione . . . . . . . . 33
3.14 Thread in funzione del tempo trascorso . . . . . . . . . . . . . . . . . 33
3.15 Integrazione dell’estensione con JMeter . . . . . . . . . . . . . . . . . . 34
3.16 Esempio di creazione di più utenti . . . . . . . . . . . . . . . . . . . . 35
3.17 Esempio di creazione di un nuovo tipo di utente . . . . . . . . . . . . . 35
3.18 Esempio di creazione di una nuova attività . . . . . . . . . . . . . . . . 36
3.19 Risultato della procedura di creazione degli utenti . . . . . . . . . . . 37
3.20 Sommario del report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.21 Tempo di latenza in funzione del tempo trascorso . . . . . . . . . . . . 39
v
vi ELENCO DELLE FIGURE
3.22 Transazioni fallite in funzione del tempo trascorso . . . . . . . . . . . 39
3.23 Thread in funzione del tempo trascorso . . . . . . . . . . . . . . . . . 40
4.1 Suddivisione della memoria applicata da Parallel GC . . . . . . . . . 42Capitolo 1
Contesto aziendale
1.1 L’azienda
Figura 1.1: Logo aziendale Studio Storti
Ho svolto lo stage presso l’azienda Studio Storti SRL, con sede a Torri di Quartesolo
(VI), via dell’Industria 8.
Azienda fondata nel 1997 da Paolo Storti, offre servizi informatici per la gestione
di posta elettronica e documenti condivisi. Questi servizi sono basati su moltepli-
ci programmi Open SourceG per i quali l’azienda fornisce servizi di installazione,
manutenzione e assistenza.
I principali clienti sono costituiti da pubbliche amministrazioni, le quali per loro
natura necessitano di comunicare e gestire notevoli quantità di documentazione. Il
successo riscontrato nelle pubbliche amministrazioni è in parte dovuto alla spinta legi-
slativa avvenuta negli ultimi anni, la quale ha incentivato le pubbliche amministrazioni
ad utilizzare software Open Source rispetto a soluzioni proprietarie1 .
Per fornire i servizi richiesti, l’azienda utilizza principalmente software sviluppato
da terzi e rilasciato con licenze Open Source. Grazie a queste licenze, l’azienda ha
potuto integrare i prodotti di base con il proprio software, migliorando il software di
partenza e andando a soddisfare le esigenze specifiche dei propri clienti.
Oltre a soluzioni di terze parti, l’azienda offre servizi basati su software sviluppato
interamente, rilasciato anch’esso con licenze Open Source.
Durante il periodo dello stage l’azienda contava un organico di 30 dipendenti e
stava attraversando una fase di crescita, ricercando costantemente nuovi collaboratori
per la nuova sede di Torri di Quartesolo.
1 Con l’introduzione dell’articolo 68 del Codice Amministrativo Digitale, le amministrazioni pub-
bliche sono tenute a utilizzare software Open Source rispetto a soluzioni proprietarie, a meno che la
soluzione Open Source risulti nel complesso più costosa della controparte.
12 CAPITOLO 1. CONTESTO AZIENDALE
1.1.1 Organizzazione aziendale
L’azienda è organizzata in cinque reparti:
• reparto commerciale;
• reparto sviluppo;
• reparto sistemistico;
• reparto assistenza clienti;
• reparto pubbliche relazioni.
In ogni reparto è presente un responsabile che pianifica e assegna le attività da
svolgere.
I responsabili di reparto rendono conto al dirigente e proprietario, Paolo Storti,
che oltre a dirigere l’azienda ed a tenere le relazioni con i principali partner aziendali,
promuove l’azienda tramite la partecipazione a fiere ed a eventi di livello internazionale.
Figura 1.2: Flusso di informazioni tra i reparti
I reparti cooperano per migliorare continuamente il servizio offerto ai clienti, in-
staurano un flusso di informazioni che passa di reparto in reparto, portando ad un
continuo miglioramento dei servizi forniti agli utenti.
Grazie al reparto di pubbliche relazioni, l’azienda committente viene a conoscenza
dei prodotti e servizi offerti dall’azienda. Individuato il prodotto che soddisfi i propri
bisogni, l’azienda committente richiede il prodotto al reparto commerciale. Il reparto
commerciale richiede al reparto di sviluppo di creare un prodotto che soddisfi i requisiti
dell’azienda committente. Una volta creato il prodotto, il reparto di sviluppo lo
consegna al reparto sistemistico, il quale lo installerà per fornire i servizi desiderati
agli utenti. In caso di necessità, il reparto di assistenza è a disposizione per risolvere1.2. PRODOTTI E SERVIZI OFFERTI 3
eventuali problemi, comunicando al reparto sviluppo, eventuali malfunzionamenti
riscontrati dagli utenti.
1.2 Prodotti e servizi offerti
I principali servizi offerti l’azienda sono:
• hosting di server di posta elettronica basati sul software Zimbra Collaboration
Suite (ZCS);
• assistenza e manutenzione di server di posta elettronica basati su ZCS;
• installazione e assistenza per Data Protection Manager, programma per la gestione
della documentazione necessaria per il trattamento dei dati personali.
Questi servizi sono basati sui seguenti programmi Open Source:
• Zimbra Collaboration Suite;
• Data Protection Manager.
1.2.1 Zimbra Collaboration Suite
Il progetto Zimbra nasce nel 2005 con lo scopo di creare un programma Open Source per
la gestione della posta elettronica. Nel corso degli anni ha ampliato le sue funzionalità
includendo l’organizzazione di contatti, la condivisione di documenti e la gestione di
calendari. Con l’aggiunta delle nuove funzionalità il software Zimbra è stato rinominato
in Zimbra Collaboration Suite (ZCS).
Per quanto riguarda la penetrazione del mercato, considerando il numero di caselle
di posta, ZCS costituisce il prodotto più utilizzato nel campo della posta elettronica,
superando concorrenti come IBM Lotus Notes e Microsoft Exchange.
Figura 1.3: Servizi offerti da ZCS4 CAPITOLO 1. CONTESTO AZIENDALE
Fra i vari servizi offerti da ZCS abbiamo:
• server di posta elettronica, con disponibilità di accesso da browser, sia lato utente,
sia lato amministrativo;
• gestione di calendari personali e condivisi;
• gestione contatti organizzati in rubriche;
• comunicazione interna tramite chat;
• gestione e condivisione di documenti.
Per offrire questi servizi, ZCS utilizza una serie di programmi Open Source che
cooperano tra di loro per soddisfare le richieste dei client.
Figura 1.4: Componenti di ZCS.
I tra i principali programmi esterni troviamo:
• nginx, sia un server HTTP sia un Reverse Proxy ServerG , utilizzato all’interno
di Zimbra per il reverse proxy delle richieste, permettendo cosi di bilanciare il
carico sui diversi server disponibili;1.2. PRODOTTI E SERVIZI OFFERTI 5
• Jetty, un server HTTP scritto in Java, viene utilizzato in ZCS per gestire le
richieste effettuate al server;
• OpenZAL (Zimbra Abstraction Layer), una libreria per interfacciarsi con le
funzioni principali di ZCS, costituisce uno strato intermedio tra ZCS e il software
sviluppato dall’azienda. Questo permette al software sviluppato dall’azienda di
essere indipendente dalle modifiche di ZCS ;
• Postfix, un Mail Transfert AgentG , utilizzato per l’instradamento e la consegna
della posta elettronica;
• Amavis, un programma per l’applicazione di filtri ad un server di posta elettro-
nica. Tipici filtri che vengono applicati tramite Amavis sono il filtro anti-spam
(SpamAssasin) e il filtro anti-virus (ClamAV);
• Lucene, una libreria per il recupero di informazioni da testo in molteplici formati.
Principalmente viene utilizzato per indicizzare i documenti presenti sui server e
quindi permettere all’utente di effettuare ricerche testuali;
• Tika, una libreria per l’estrazione del contenuto testuale e di metadata da
molteplici tipi differenti di file. Tipicamente viene utilizzato da Lucene per
l’estrazione del contenuto dai vari file sottoposti ad esame.
1.2.2 Data Protection Manager
Figura 1.5: Data Protection Manager
Data Protection Manager è un programma Open Source, sviluppato da Studio Storti
con lo scopo di agevolare le aziende ad adempiere agli obblighi previsti dalle leggi
vigenti in materia di privacy.
Nello specifico, Data Protection Manager va a gestire e a tracciare gli accessi ai
documenti contenenti dati personali. Per gestire gli accessi, Data Protection Manager
assegna una categoria a ogni documento, la quale ne descrive il contenuto. Ogni utente
fa parte di una o più tipologie di utenti, le quali garantiscono specifici diritti di accesso
per ogni categoria di documento.
Principalmente esso viene utilizzato da parte di quelle aziende e pubbliche ammini-
strazioni che trattano dati personali, quindi soggette alle norme sulla privacy2 .
2 Regolamento UE 2016/676 CAPITOLO 1. CONTESTO AZIENDALE
Una delle funzionalità principali di Data Protection Manager è la creazione auto-
matica del documento programmatico sulla sicurezza, un documento che descrive in
che modo vengono trattati i dati soggetti alle norme sulla privacy. Nonostante questo
documento non sia più obbligatorio, esso è necessario nella pratica per dimostrare il
corretto trattamento dei dati in caso di accertamenti da parte degli enti preposti.
Data Protection Manager è interamente sviluppato da Studio Storti e rilasciato con
licenza Open Source (GNU General Public License v2.0).
1.3 Azienda ed innovazione
Come ci si aspetta da una azienda informatica, Studio Storti ha un forte legame con
l’innovazione, infatti l’azienda è alla continua ricerca di nuove soluzioni per portare un
miglioramento continuo nei servizi e nei prodotti offerti.
La presenza sul mercato di aziende concorrenti molto competitive (ad esempio
Google e Microsoft), rende necessari continui investimenti nell’innovazione per riuscire
a mantenere l’azienda competitiva e non perdere quote di mercato.
L’innovazione non viene usata solamente per difendersi dalla concorrenza, ma
diventa un occasione per aumentare le quote di mercato, sfruttando le nuove tecnologie
per offrire nuovi servizi atti a soddisfare le esigenze dei nuovi clienti.
Figura 1.6: Ciclo dell’innovazione
Per innovarsi, l’azienda segue un percorso ciclico che si divide in sei fasi.
Nella prima fase l’azienda individua le aree dove è possibile applicare dei migliora-
menti. Per ogni area vengono ricercati i possibili cambiamenti che potrebbero migliorare
l’azienda.
Una volta individuato il cambiamento desiderato, l’azienda effettua una fase di
studio nella quale valuta i lati positivi e negativi associati alla proposta di cambiamento.
Se i benefici teorici apportati dal cambiamento sono più rilevanti rispetto ai lati
negativi, il cambiamento viene applicato ad un sottosistema controllato, nel quale
valutare gli effettivi vantaggi e svantaggi della soluzione.
Una volta ottenuti i primi risultati, vengono identificati ed attuati eventuali miglio-
ramenti. Questa fase si ripete finché non si ritiene maturo il cambiamento, solo allora
esso viene applicato a tutto il sistema, entrando in produzione.
Un esempio di questo processo innovativo è dato dall’adozione di Angular come
framework per lo sviluppo dell’interfaccia utente di Data Protection Manager. La
necessità di cambiare framework nacque a causa delle carenze del framework precedente,1.4. REPARTO SVILUPPO 7
il quale veniva di rado aggiornato con aggiornamenti spesso non retro-compatibili.
La comunità di utilizzatori era ormai diventata piccola e ciò rendeva difficile ricevere
supporto e trovare informazioni. L’architettura con cui era stato progettato risentiva
di alcune lacune che rendevano difficile la manutenzione del prodotto finale.
Esasperati da queste carenze, gli sviluppatori hanno iniziato un’approfondita ricerca
per trovare un framework che soddisfacesse i loro bisogni. Tra i vari framework
presi in in considerazione AngularJs è risultato quello più aderente alle necessità
degli sviluppatori. Utilizzato e sviluppato da Google, AngularJs vanta una prospera
comunità di utilizzatori che garantiscono un continuo ed intenso sviluppo unito ad una
adeguato supporto.
Come prima fase di adozione, sono stati convertiti un insieme contenuto di moduli,
necessari ad ottenere un prodotto minimale ma funzionante. Il risultato ha soddisfatto
le attese degli sviluppatori, i quali hanno deciso di proseguire la conversione dei moduli
adottando la versione più aggiornata di AngularJs (rinominata in Angular), la quale
introduce importanti novità, tra cui l’utilizzo di TypeScript in sostituzione di JavaScript.
La conversione dei moduli è proseguita fino alla totale conversione del prodotto ed alla
messa in produzione della nuova versione del prodotto.
I prodotti e i servizi offerti sono i principali soggetti dell’innovazione, essi vengono
innovati introducendo nuove tecnologie scelte ed approvate dal responsabile di repar-
to. Le nuove tecnologie vengono introdotte mediante un processo di formazione del
personale, il quale viene istruito ad utilizzare le nuove tecnologie.
Oltre ai prodotti e ai servizi, anche i processi sono soggetti a cambiamento, anche in
questo caso il personale viene istruito in merito e il responsabile di reparto supervisiona
e garantisce la correttezza con cui vengono attuati i processi.
1.4 Reparto sviluppo
1.4.1 Organizzazione
Figura 1.7: Organizzazione reparto sviluppo.
Durante lo svolgimento dello stage sono stato inserito nel reparto di sviluppo.8 CAPITOLO 1. CONTESTO AZIENDALE
All’interno del reparto è presente un responsabile che organizza e pianifica setti-
manalmente il lavoro da svolgere. Una volta stabilite le priorità e le scadenze delle
attività da svolgere, il responsabile le assegna ai vari team che compongono il reparto
di sviluppo.
Attualmente sono presenti due team, uno che si occupa del front end, l’altro del
back end.
All’interno di ogni team è presente un responsabile che ha il compito di assegnare
ai componenti del team le attività da svolgere, precedentemente assegnate al team dal
responsabile di reparto.
1.4.2 Modello di sviluppo
Figura 1.8: Scrum.
Il reparto di sviluppo addotta ScrumG come metodologia di sviluppo.
La metodologia Scrum è caratterizzata da un approccio iterativo ed incrementale
allo sviluppo del software, suddividendo il lavoro da svolgere in cicli lavorativi definiti1.4. REPARTO SVILUPPO 9
sprint. Lo sprint tipicamente dura due settimane durante le quali ogni team ha un
elenco di lavori da svolgere. Questi lavori vengono inseriti nello sprint mediante una
riunione di pianificazione che avviene all’inizio dello stesso sprint.
I lavori da svolgere nello sprint sono scelti a partire dal backlog, un elenco ordinato
di lavori da svolgere, gestito dal product owner, il quale ha il compito di inserire il
lavori nel backlog ordinandoli in base alla priorità. Al termine di ogni sprint viene fatta
una riunione retrospettiva per evidenziare problematiche ed eventuali miglioramenti
da apportare allo sprint successivo.
Durante lo svolgimento di uno sprint è previsto lo svolgimento di standup meeting
con cadenza giornaliera. Durante queste riunioni, i membri del team riportano lo
stato di avanzamento dei lavori a loro assegnati ed evidenziano eventuali ostacoli allo
sviluppo.
Il reparto di viluppo attua la metodologia Scrum attendendosi all’implementazione
standard, ad eccezione della frequenza degli standup meeting che vengono eseguiti ogni
due o tre giorni.
Il reparto di sviluppo ha scelto di applicare questa metodologia per far fronte
alle incapacità di definire completamente i requisiti del software sviluppato a causa
della volatilità dei requisiti. Questa volatilità è causata da molteplici fattori, tra cui
l’evoluzione delle richieste del mercato, la disponibilità di nuove tecnologie e l’offerta
di nuovi prodotti da parte della concorrenza.
Grazie a Scrum, il reparto di sviluppo riesce ad adattarsi velocemente ai nuovi
requisiti ed a fornire in tempi brevi dei prodotti che seppur incompleti di tutte le
funzionalità, possono essere usati per avere un riscontro dall’utente finale. Oltre a
questo, Scrum permette di avere delle stime sullo stato di avanzamento dello sviluppo
rendendo più accurata la pianificazione del lavoro.10 CAPITOLO 1. CONTESTO AZIENDALE
1.4.3 Tecnologie utilizzate
Strumenti a supporto dei processi di sviluppo
Figura 1.9: Strumenti utilizzati.
Per svolgere il proprio lavoro, il reparto di sviluppo utilizza un insieme di strumenti
integrati fra loro, che aiutano gli sviluppatori in tutte le fasi del sviluppo del software.
Tutti gli sviluppi fatti dal reparto di sviluppo partono da una pianificazione del
lavoro, questa pianificazione viene gestita tramite Jira. Jira è un programma per la
creazione e la gestione di issue sviluppato da Atlassian. Tramite esso, il responsabile del
reparto di sviluppo può pianificare lo sviluppo, assegnando le issue ai programmatori,
tracciandone lo stato di avanzamento e fornendo informazioni sullo stato dei progetti.
In caso sia necessario creare della documentazione per tener traccia delle decisioni
prese o per descrivere dei componenti, viene utilizzato Confluence, un framework per
la gestione della documetazione, sviluppato da Atlassian. Esso permette di creare ed
organizzare la documentazione tramite una semplice interfaccia web.
Una volta pianificato e documentato il lavoro da svolgere, le singole issue vengono
assegnate a uno sviluppatore. Quando una issue viene presa in carico dallo sviluppatore,
per tenere traccia di tutte le modifiche apportate al software, lo sviluppatore utilizza
git, un noto software di versionamento per sviluppare codice in maniera distribuita.
In combinazione con git viene utilizzato BitBucket, un programma per la gestione di
un repository git, sviluppato da Atlassian. La principale funzionalità che introduce1.4. REPARTO SVILUPPO 11
BitBucket sono le pull request, con le quali il programmatore richiede che il codice
su cui ha lavorato, sia integrato nel codice in produzione. Il codice viene revisionato
da almeno due sviluppatori i quali segnalano eventuali carenze e migliorie. Una volta
che il codice viene approvato da due sviluppatori, esso può entrare in produzione.
Ogni volta che un programmatore carica del codice nuovo nel repository, una
procedura automatica esegue tutti i test e ne segnala l’esito. Per automatizzare
questo processo, il reparto di sviluppo utilizza Bamboo, un programma per gestire la
compilazione, l’esecuzione dei test ed il rilascio in maniera automatica, sviluppato da
Atlassian. Bamboo si integra con Bitbucket ed ad ogni push eseguito nel repository
git, viene avviata la compilazione e l’esecuzione dei test. Questo permette di assicurare
l’assenza di regressioni nel codice sviluppato. Ogni notte, Bamboo esegue tutti i test
di unità, integrazione e unità per ogni versione del software sviluppato. Per eseguire
test di sistema ripetibili e non influenzati da fattori esterni, Bamboo utilizza Docker,
un programma per la creazione e la gestine di container dove poter eseguire software
in un ambiente controllato. Infatti ogni container costituisce un strato di astrazione
del sistema operativo sottostante, fornendo un ambiente controllato e ben definito dove
poter eseguire i test. Oltre per i test, Docker è utilizzato anche per lo sviluppo, esso
fornisce allo sviluppatore un ambiente controllato dove poter eseguire il proprio codice.Capitolo 2
Lo stage
2.1 Rapporto tra azienda e stage
Il mio stage è stato il secondo ad essere ospitato nell’azienda, preceduto di pochi mesi
da un altro stage offerto ad uno studente del corso di Informatica del università di
Padova che come me, è entrato in contatto con l’azienda durante l’evento StageIt.
La principale motivazione che ha spinto l’azienda ad ospitare uno stage è stata
l’opportunità di conoscere nuovi potenziali candidati per una futura assunzione. Infatti,
grazie al periodo di stage, l’azienda ha l’occasione di valutare il grado di preparazione
e le attitudini dello stagista, verificando che queste siano congrue a quanto ricercato
dall’azienda.
Oltre a questo, lo stage costituisce un opportunità per l’azienda per confrontarsi con
il mondo accademico, arricchendosi di un nuovo punto di vista, che seppur inesperto
dello specifico settore applicativo, porta con se un bagaglio culturale maturato negli
anni universitari.
Dal punto di vista produttivo, uno stage costituisce per l’azienda un’occasione per
sviluppare un prodotto sperimentale, ottenendo informazioni dal nuovo progetto, allo
stesso tempo, lo stagista viene formato nello specifico tema del prodotto, accumulando
conoscenza specifica del campo di applicazione. Questa conoscenza specifica risulterà
un’ulteriore incentivo all’assunzione dello stagista.
2.2 Il progetto
Uno dei principali servizi offerti dall’azienda è l’hosting di server di posta elettronica.
Questi server sono costituiti da istanze di Zimbra Collaboration Suite ospitate sia su
server locali, sia su server remoti.
Ad ogni nuova installazione emerge il problema di quantificare le risorse hardware
necessarie per offrire una buona qualità di servizio, cercando di minimizzare i costi.
Conoscendo il numero di utenti che in media accederanno al server, non esiste una
regola empirica per calcolare la quantità di risorse necessarie a soddisfare tutte le
richieste con una qualità di servizio accettabile. Attualmente la prassi consiste nel
allocare risorse basandosi sull’esperienza dei sistemisti, ed eventualmente apportando
correzioni quando il prodotto entra in produzione, causando disagi agli utenti.
Da questi bisogni nasce la necessità di creare uno strumento che riesca dare una
stima della qualità del servizio in funzione del numero di utenti, simulando il più
1314 CAPITOLO 2. LO STAGE
realisticamente possibile il comportamento del utente medio. Grazie a questo strumento,
l’azienda avrebbe la possibilità di testare il servizio offerto prima che l’utente finale ne
abbia accesso, individuandone i limiti effettivi, senza che gli utenti abbiano disservizi.
La capacità di simulare uno stato di intenso utilizzo di un server Zimbra, renderebbe
questo strumento utile al reparto di sviluppo per valutare l’impatto del software
prodotto, dando agli sviluppatori la possibilità di analizzare un sistema sotto stress,
testando gli effetti del proprio codice sulle prestazioni.
Con lo scopo di soddisfare questi bisogni nasce il progetto "Stress test for Zimbra".
L’obbiettivo principale del progetto è sviluppare un software che simuli un elevato
numero di utenti che agiscano contemporaneamente su un server Zimbra, avvicinandosi
il più possibile ad un utilizzo reale.
Per simulare un utente, il software dovrà implementare una serie di protocolli
necessari per interagire con i diversi servizi offerti da Zimbra. I componenti che
andranno a testare questi protocolli dovranno essere sviluppati sotto forma di plugin
da aggiungere a un framework che gli gestisca, sviluppando cosi un prodotto modulare
ed espandibile.
Alla fine dello stress test, il software dovrà produrre un documento riassuntivo che
descriva i risultati del test e fornisca degli indici sulla qualità del servizio fornita dal
server sotto esame.
2.3 Vincoli
Dall’analisi della proposta di stage sono emersi i seguenti vincoli:
• il progetto deve essere terminato entro i termini dello stage, quindi il progetto
deve avere una durata complessiva di circa 300 ore;
• il software deve poter simulare il comportamento dell’utente tipico di Zimbra,
quindi ogni utente simulato deve poter eseguire molteplici azioni contemporanea-
mente;
• il framework deve essere espandibile con nuovi plugin che andranno a testare
nuove funzionalità;
• devono essere sviluppati i plugin necessari per testare l’invio e la ricezione di
email tramite protocolli IMAP, SMTP, POP3;
• alla fine dello stress test deve essere prodotto un report contenente i risultati del
test;
• il report prodotto alla fine del test dovrà essere in formato HTML o PDF;
• il software deve poter essere eseguito su un sistema GNU Linux attraverso un
terminale con interfaccia a linea di comando;
• il software deve poter gestire almeno 20.000 thread utilizzando al massimo 2 GB
di memoria.
• il software deve essere eseguito su una Java Virtual Machine versione 8.2.4. OBIETTIVI PERSONALI 15
2.4 Obiettivi personali
Gli obbiettivi che mi sono prefissato nel svolgere questo stage sono:
• concludere lo stage entro i termini definiti avendo soddisfatto i requisiti minimi
richiesti dall’azienda;
• osservare l’ambiente di lavoro ed il modo di lavorare dei programmatori;
• conoscere dall’interno un’azienda informatica che lavora con successo nel mondo
dell’Open Source, osservandone dinamiche aziendali e modello di sviluppo;
• approfondire le mie conoscenze in ambito Java;
• approfondire le mie conoscenze in ambito multi-threading;
• in caso mi fosse piaciuto come ambiente di lavoro, essere assunto alla fine dello
stage presso questa azienda.
2.5 Piano di progetto
Per lo svolgimento dello stage sono state preventivate 316 ore lavorative, comprensive
sia delle ore di sviluppo, sia delle ore di formazione.
Per pianificare le fasi del progetto, ho deciso di adottare un modello di sviluppo
incrementale, questo allo scopo di mitigare i rischi ed aumentare le probabilità di
portare a compimento il progetto, nei tempi previsti.
Come ulteriore contromisura per contenere i rischi, sono state assegnate 48 ore a
requisiti desiderabili, ma non obbligatori. Queste ore potranno essere usate in caso di
imprevisti per mitigarne le conseguenze.
I diagrammi di Grantt che seguono, descrivono la pianificazione delle attività attuata
durante il progetto.
2.5.1 Formazione
Vista la mia inesperienza nel campo dei server di posta elettronica, la prima settimana
di stage è stata dedicata alla formazione.
Nello specifico, la formazione ha avuto un approccio top-down, iniziando a elencare i
componenti che compongo un server di posta elettronica, per poi entrare nello specifico
delle soluzioni adottare da Zimbra, per finire con i pattern e gli stili di programmazione
usati in azienda.
Le ore di formazione sono state suddivise quotidianamente in 5 ore di spiegazione
con il tutor e 3 ore di esercizio e approfondimento individuale sui temi trattati.16 CAPITOLO 2. LO STAGE
Figura 2.1: Ore pianificate per la formazione
2.5.2 Analisi dei requisiti
Seguendo la prassi del modello incrementale, la prima attività di sviluppo che ho
pianificato è stata l’analisi dei requisiti.
Grazie alla chiarezza del capitolato, ho ritenuto sufficienti 16 ore lavorative per
produrre tutta la documentazione necessaria per completare l’analisi dei requisiti.
Figura 2.2: Ore pianificate per l’analisi dei requisiti
2.5.3 Progettazione
La progettazione è stata suddivisa in quattro fasi:
• progettazione architetturale, durante questa attività ho definito l’architettura
ad alto livello del progetto;
• ricerca tecnologie, prima di procedere con la progettazione di dettaglio, ho
ricercato le best practice applicate a software per stress test;
• progettazione di dettaglio, dove ho definito tutte le componeti del mio
progetto;2.5. PIANO DI PROGETTO 17
• revisione, prima di iniziare la scrittura del codice, ho esposto la mia soluzione
al mio tutor interno, ricevendo dei feedback sulle soluzioni da me adottate.
Figura 2.3: Ore pianificate per la progettazione
2.5.4 Implementazione framework
L’ordine dello sviluppo delle componenti è stato scelto dando la precedenza all’interfac-
cia grafica. Questo ha permesso di avere il più presto possibile un feedback dall’utente
finale, grazie al quale ho potuto individuare il prima possibile le differenze tra la mia
soluzione e quella desiderata dal utente, adattando il progetto di conseguenza.
Figura 2.4: Ore pianificate per l’implementazione del framework
2.5.5 Implementazione plugin
Il plugin IMAP, il plugin Zimbra/SOAP ed il plugin ActiveSync sono stati considerati
requisiti desiderabili ma non obbligatori, rendendo disponibili queste ore come slack di
sicurezza, per mitigare gli effetti di eventuali imprevisti.18 CAPITOLO 2. LO STAGE
Figura 2.5: Ore pianificate per l’implementazione dei plugin
2.5.6 Test di sistema e manuale utente
Ho assegnato 32 ore di test di sistema nelle quali individuare gli eventuali bug presenti
e testare le prestazioni dello stress test. In fine ho assegnato 8 ore per la creazione
di documentazione utente nella quale viene riportato come installare ed utilizzare lo
stress test.
Figura 2.6: Ore pianificate per i test e la stesura del manuale utenteCapitolo 3
Svolgimento progetto
3.1 Analisi dei requisiti
Come da piano di progetto, dopo la prima settimana di formazione, ho intrapreso
l’analisi dei requisiti.
L’obiettivo di questa attività è quello di elicitare tutti i requisiti necessari a creare
un prodotto che soddisfi tutte le richieste degli stackholders.
Per prima cosa ho definito che caratteristiche deve avere un requisito. Nel fare ciò,
ho individuato le seguenti proprietà:
• non essere ambiguo, questo per non avere diverse interpretazioni;
• essere facilmente verificabile se sia soddisfatto tramite test automatici e non
dispendiosi, questo per poter provare al committente che ogni requisito richiesto
è stato soddisfatto;
• avere un identificativo univoco, questo per essere identificato senza ambiguità
durante tutte le fasi di sviluppo del progetto;
• avere una priorità, questo permetterà di poter contrattare con gli stackholders
per definire i requisiti obbligatori e quelli desiderabili.
Per identificare i requisiti ho scelto di adottare il seguente schema:
R[importanza][tipo][codice]
Dove:
importanza può assumere uno dei seguenti valori:
O identifica un requisito obbligatorio;
D identifica un requisito desiderabile;
F identifica un requisito facoltativo.
tipo può assumere uno dei seguenti valori:
F identifica un requisito funzionale;
Q identifica un requisito di qualità;
1920 CAPITOLO 3. SVOLGIMENTO PROGETTO
P identifica un requisito prestazionale;
Definite le proprietà dei requisiti, ho identificato le fonti da cui poter iniziare a
estrapolare i requisiti.
Come fonti iniziali dei requisiti ho identificato la proposta di stage avanzata dal-
l’azienda durante l’evento StageIt, le e-mail che ho scambiato con il tutor aziendale
riguardanti lo stage ed il Piano di Lavoro redatto da me e dal tutor aziendale prima di
iniziare lo stage.
Partendo da queste fonti ho iniziato ad estrapolare tutti i requisiti direttamente
derivabili da esse.
Per ogni requisito individuato ho inserito il codice identificativo del requisito in
una tabella di tre colonne dove ogni riga associava l’identificativo del requisito alla
descrizione del requisito ed alla fonte da cui deriva.
ID Descrizione Fonte
ROF23 Il software deve essere eseguito su una Java Virtual Proposta di stage
Machine versione 8
Questo mi ha permesso di tracciare l’origine dei requisiti, assicurandomi che ogni
requisito fosse necessario ed permettendomi di trovare i requisiti associati ad un
particolare documento in caso di cambiamenti delle specifiche in esso descritte.
In caso di dubbi, ho fatto ricorso ad interviste con il tutor aziendale, durante le quali
esponevo i miei dubbi e chiedevo conferma dei nuovi requisiti fino ad allora trovati.
Ho intervistato il tutor aziendale sia nelle vesti di rappresentate dell’azienda richie-
dente, sia nelle vesti di programmatore del reparto sviluppo, cioè un utilizzatore finale
dell’applicazione.
A seguito di ogni intervista ho prodotto un verbale documentasse tutte le scelte
prese durante l’intervista.
Tutti i documenti usati come fonte di requisiti sono stati sottoposti a versionamento
nel repository principale del progetto.
Come ulteriore strumento per portare alla luce nuovi requisiti, ho fatto uso dei
diagrammi dei casi d’uso.
Per prima cosa ho definito i casi d’uso in modo grafico attenendomi alle specifiche
del linguaggio di modellazione UML.
Figura 3.1: Attori
Per definire il modello grafico sono partito dall’individuazione degli attori che
interagiscono con l’applicazione.3.1. ANALISI DEI REQUISITI 21
Figura 3.2: Casi d’uso principali
Una volta individuati gli attori ho steso i principali casi d’uso ad essi associati,
mantenendo un livello di dettaglio basso.
Figura 3.3: Caso d’uso dettagliato UC1.1.5.1.2.1
Per ogni caso d’uso individuato ho iniziato a decomporlo in sotto casi d’uso seguendo
un approccio top-down. Ad ogni nuovo caso d’uso individuato ho assegnato un
identificativo che lo identificasse e contemporaneamente identificasse tutti i casi d’uso
più che lo avevano generato. Ho continuato a creare sotto casi d’uso fino ad ottenere
dei casi d’uso semplici e non ambigui. Da questa rappresentazione grafica dei casi
d’uso, gli ho trascritti in formato testuale, esplicitando pre e post condizioni, la fonte
da cui deriva, l’obbiettivo, lo scenario principale ed eventuali scenari alternativi in caso
di errore.22 CAPITOLO 3. SVOLGIMENTO PROGETTO
ID: UC1.1.5.1.2.1.2
Attori: Utente
Fonte: Proposta di stage
Prerequisiti: L’utente sta creando una nuova attività
Obbiettivo: Specificare quante volte in un ora verrà svolta l’attività
Scenario principale: L’utente inserisce un numero intero maggiore o uguale a zero
Scenario alternativo: Se l’utente inserisce un numero negativo, un messaggio di errore comparirà
avvisando l’utente che non può inserire numeri negativi e richiedendo nuovamente
di inserire il numero.
Postrequisiti: L’utente ha inserito un numero intero maggiore o uguale a zero
Da questi casi d’uso ho ricavato ulteriori requisiti che ho aggiunto alla tabella dei
requisiti.
Una volta terminato l’estrazione dei requisiti dalle fonti in mio possesso, ho
sottoposto i requisiti all’approvazione del tutor aziendale.
Al termine dell’analisi dei requisiti ho ottenuto 159 requisiti cosi suddivisi:
Requisiti obbligatori 137
Requisiti desiderabili 22
Requisiti facoltativi 0
Requisiti funzionali 124
Requisiti qualitativi 34
Requisiti prestazionali 1
3.2 Selezione delle tecnologie
Una volta definiti i requisiti ho iniziato un’attività di ricerca per ottenere maggiori
informazioni sul mondo dei stress test, questo allo scopo di approfondire la mia
conoscenza del settore ed individuare le best practice applicate in questo specifico
campo.
Durante queste ricerche sono venuto a conoscenza del progetto Apache JMeter.
Figura 3.4: Apache JMeter3.2. SELEZIONE DELLE TECNOLOGIE 23
Si tratta di un software Open Source sviluppato allo scopo di eseguire test di carico e
misurare le performance di un servizio. Scritto in Java, fa parte dei progetti mantenuti
dall’Apache Foundation.
JMeter ha una architettura a plugin tramite i quali può essere esteso per supportare
nuovi tipi di test. Tra i moduli già disponibili troviamo quelli per i protocolli di IMAP,
POP3, SMTP e HTTP.
JMeter è dotato sia di una interfaccia grafica sia di un interfaccia a linea di comando.
L’interfaccia grafica di JMeter permette di creare agilmente nuovi test che saranno
salvati in un file di configurazione in formato XML.
Mediante la linea di comando è possibile eseguire i test indicati sul file di configura-
zione e generare un file contenente i risultati in formato testuale (CSV). Dai risultati di
un test è possibile generare un report in formato HTML contenente i principali grafici
atti ad analizzare la qualità di un servizio.
Dato che JMeter sembrava un buona base su cui sviluppare il mio progetto, ho
eseguito su di esso dei test per verificare che soddisfacesse i requisiti prestazionali
richiesti.
In particolare ho creato un test nel quale venivano istanziati 20.000 thread che
restavano in uno stato di idle. Mediante linea di comando ho eseguito il test mentre
monitoravo la memoria utilizzata dal processo. Ho ripetuto il test 10 volte ed ho
appurato che JMeter consumava una quota di memoria inferiore ai 2 GB di Ram.
Questo lo ha reso compatibile con tutti i requisiti, quindi ho proceduto ad informare il
mio tutor aziendale della mia intenzione di basare il progetto su JMeter.
Il tutor aziendale, dopo aver appurato la solidità del progetto JMeter, ha accettato
l’adozione di JMeter come base del progetto a condizione che il software finale dovrà
avere una interfaccia grafica integrata a quella di JMeter che consentirà l’inserimento
dei parametri principali del test.
Dopo un studio del codice di JMeter per valutare la fattibilità della richiesta, ho
accettato i nuovi requisiti.
Grazie all’adozione di JMeter ho soddisfatto 39 dei 159 requisiti.24 CAPITOLO 3. SVOLGIMENTO PROGETTO
3.3 Progettazione
3.3.1 Introduzione
Figura 3.5: Componenti principali del progetto
Dallo studio di JMeter e dall’analisi dei requisiti è emersa la presenza dei seguenti
componenti:
• il componente JMeter UI per l’inserimento delle configurazioni del test tramite
interfaccia grafica;
• il componente User’s Configuration Builder per l’inserimento delle configurazioni
utilizzando un approccio ad utenti come richiesto dai requisiti;
• il componente JMeter Core che esegue i test e ne raccoglie i risultati;
• il componente ActiveSync Plugin Core che esegue i test riguardanti il protocollo
ActiveSync e restituisce il risultato del test;
• il componente ActiveSync Plugin UI che permette l’inserimento della configura-
zione riguardante il plugin tramite interfaccia grafica;
• il componente JMeter Reporter che permette la generazione del report finale.
I componenti JMeter UI, JMeter Core e JMeter Reporter fanno parte dei componenti
offerti da JMeter, mentre i componenti User’s Configuration Builder e ActiveSync
Plugin (UI e Core) sono i componenti che saranno sviluppati da questo progetto.
Allo scopo di avere una chiara visione e comprensione di tutti i componenti che
andranno a far parte del progetto, ho deciso di affrontare la progettazione utilizzando
un approccio top-down. Seguendo i principi della progettazione top-down, ho suddiviso
la progettazione in progettazione architetturale e progettazione di dettaglio, affrontando
per prima la progettazione architetturale.3.3. PROGETTAZIONE 25
3.3.2 Progettazione architetturale
Figura 3.6: Package zimbrastresstest
Durante questa attività ho definito la struttura ad alto livello definendo i package che
compongono il progetto mediante l’utilizzo di diagrammi dei package.
Durante la progettazione dei package ho applicato il Comon Reuse Principle,
andando quindi a raggruppare i vari moduli per funzionalità rendendo il prodotto più
modulare.
Modulo User’s Configuration Builder
Figura 3.7: Package usersbuilder
Lo scopo di questo modulo è permettere all’utente la creazione delle varie tipologie di
utente che saranno simulati dal test, inserendo queste configurazioni tramite l’utilizzo
di un’interfaccia grafica. Una volta inserite le varie tipologie di utente, il modulo
passerà le configurazioni a JMeter il quale si occuperà di visualizzarle con una propria
rappresentazione e salvarle.26 CAPITOLO 3. SVOLGIMENTO PROGETTO
Modulo ActiveSync
Figura 3.8: Package activesync
Il modulo ActiveSync costituisce un plugin che si integrerà con JMeter permettendo di
creare ed eseguire i test che andranno a testare il protocollo ActiveSync
Questo plugin darà la possibilità di autenticarsi, ricevere o inviare email utilizzando
il protocollo ActiveSync. Ognuna di queste funzionalità è data da un specifico sotto-
modulo specializzato in un singolo compito.
Ogni componente è composto da due sotto componenti principali, il componente
UI e il componente Core. Il componente UI ha lo scopo di inserire e visualizzare
le configurazioni specifiche del test, mentre il componente Core gestisce l’esecuzione
effettiva del test.
3.3.3 Progettazione di dettaglio
Durante questa attività ho definito le interfacce e le classi che compongono il mio
progetto, andando a definire i metodi di cui sono composte.3.3. PROGETTAZIONE 27
Figura 3.9: Diagramma delle classi del package activity
A questo scopo ho utilizzato il diagramma delle classi, definendo interfacce e classi,
evidenziando le dipendenze che intercorrono tra esse.
Durante la progettazione delle classi ho cercato di applicare i seguenti principi:
• Single Responsability Principle assegnando una unica e precisa responsabi-
lità ad ogni classe;
• Information Hiding, rendendo privati tutti gli attributi e i metodi di utilità
della classe;
• Encapsulation, assicurandomi che tutte le classi con dipendenze esterne avessero
come dipendenza un’interfaccia e non una classe concreta;
• Interface Segregation Principle, assicurandomi che ogni classe dipendente
da una interfaccia, utilizzi tutti i metodi offerti da quell’interfaccia.28 CAPITOLO 3. SVOLGIMENTO PROGETTO
3.3.4 Pattern utilizzati
MVP
Figura 3.10: Diagramma delle classi del pattern MVP
Per le interfacce grafiche ho scelto di utilizzare il pattern architetturale MVP. Ho deciso
di utilizzare MVP per avere una separazione delle responsabilità dei vari componenti.
Rispetto al più classico MVC, ho scelto MVP poiché svuota dalla logica il componente
View, trasferendola nel Presenter e rendendola più facile da testare in quanto svincolata
dalla parte grafica. Questa particolare forma di MVP viene definita Passive View.
Observer
Figura 3.11: Diagramma delle classi del pattern observer3.4. CODIFICA 29
Per applicare correttamente il pattern MVP ho dovuto applicare il pattern Observer,
questo allo scopo di notificare il Presenter in caso di cambiamenti del Model o della View.
Per mantenere un maggiore indipendenza fra osservatore e oggetto osservato ho deciso
di applicare il pattern Observer usando la versione pull, cioè senza passare ulteriori
informazioni al osservatore, il quale reperirà le informazioni necessarie interrogando
l’oggetto osservato.
Command
Figura 3.12: Diagramma delle classi del pattern command
Un altro pattern che ho utilizzato è stato il Command. Ho utilizzato questo pattern
prevalentemente nelle interfacce grafiche per gestire gli eventi dei pulsanti. Questo mi
ha permesso di separare l’evento dall’azione effettivamente eseguita.
3.4 Codifica
Prima di iniziare a codificare quanto progettato, ho definito le regole a cui attenermi
durante la stesura del codice. In assenza di un documento che descrivesse le regole
aziendali in merito, ho deciso di applicare le direttive di Google per quanto riguarda
il codice scritto in Java. Ho scelto queste direttive perché le ho trovate condivisibili,
complete e ben documentate.
Oltre alle linee guida di Google, per aumentare la leggibilità del codice ho deciso di
seguire le seguenti linee guida:
• evitare la creazione di metodi con più di due livelli di blocchi di codice innestati.
Questa scelta mi ha forzato a semplificare i metodi più complessi spezzandoli in
funzioni più piccole. Tutto ciò mi ha portato a scrivere metodi di piccole dimen-
sioni, più chiari, semplici e con nomi più descrittivi, rendendoli più comprensibili
e di conseguenza, meno soggetti contenere errori;
• evitare l’utilizzo di commenti allo scopo di documentare un pezzo di codice poco
chiaro. A causa della loro tendenza a diventare obsoleti, non ritengo i commenti
un buon metodo per documentare il codice. Invece di introdurre commenti30 CAPITOLO 3. SVOLGIMENTO PROGETTO
esplicativi, prediligo la scrittura di codice auto-esplicativo che utilizzi nomi più
chiari e significativi.
Esempio di codice con commenti non necessari:
public void mouseClicked(MouseEvent e) {
// get the coloum of the button
int a = table.getColumnModel().getColumnIndexAtX(e.getX());
// get the row of the button
int b = e.getY()/table.getRowHeight();
// Checking the row and column are valid
if (b < table.getRowCount() && b >= 0 && a < table.getColumnCount() && a >= 0) {
Object v = table.getValueAt(b, a);
if (v instanceof JButton) {
// perform a click event
((JButton)v).doClick();
}
}
Refactoring del codice utilizzando variabili con nomi più significativi e funzioni
di utilità: utilizzando variabili con nomi più significativi e funzioni di utilità:
public void mouseClicked(MouseEvent e) {
int column = getColumnIndexAtX(e.getX());
int row = getRowIndexAtY(e.getY());
if (isValidRow(row) && isValidColumn(column)) {
clickContentOfCell(row, column);
}
Per la stesura del codice ho scelto di utilizzare IntelliJ Idea, un IDE con molte
funzionalità a supporto dello sviluppo di codice Java. Grazie alla possibilità di
poter configurare lo stile del codice, ho potuto inserire le linee guida da me adottate,
ottenendo cosi segnalazioni sulla non conformità del codice rispetto alle regole da me
precedentemente inserite.
Per versionare lo stato del codice ho utilizzato il software di versionamento git
associandolo ad un repository remoto messomi a disposizione dall’azienda.
Per ottenere dei feedback dal tutor aziendale il prima possibile, ho deciso di
sviluppare per prime le interfacce grafiche. Una volta ottenuto un feedback positivo
sulle interfacce grafiche da parte del tutor aziendale, ho proceduto con l’implementazione
delle parti rimanenti.
Durante tutta la fase di codifica ho utilizzato SonarCube per calcolare le statistiche
riguardanti il codice. Alla fine della codifica ho ottenuto le seguenti metriche riguardanti
il codice:3.5. VERIFICA E VALIDAZIONE 31
Linee di codice (LOC) 2750
Funzioni 369
LOC per funzione 7.5
Classi 66
Funzioni per classe 5.6
LOC per classe 41.7
Commenti 17
Commenti % 0.6%
Complessità ciclomatica 338
Complessità ciclomaticaG massima 30
Complessità ciclomatica media 5.1
Complessità cognitiva 103
Complessità cognitivaG massima 17
Complessità cognitiva media 1.6
3.5 Verifica e validazione
3.5.1 Introduzione
Allo scopo di accertarmi che il prodotto soddisfacesse le specifiche richieste e che
andasse in contro ai bisogni dell’utente finale, durante lo sviluppo del progetto ho
proceduto a verificare e validare il prodotto sviluppato.
3.5.2 Verifica
Fin dalle prime fasi del progetto ho svolto l’attività di verifica per assicurarmi che il
prodotto sviluppato rispettasse i requisiti imposti dall’azienda.
La principale attività di verifica che ho effettuato è stata la creazione di una batteria
di test automatici che andassero a testate il prodotto. Ognuno di questi test è stato
sviluppato con lo scopo di testare il soddisfacimento di un specifico requisito. Per
tenerne traccia di quali requisiti siano testati, ho creato una tabella che legasse i test
ai requisiti.
ID Requisito Test
ROF33 CallShowNegativeFrequencyErrorWhen-
NegativeFrequencyIsInserted
Per lo sviluppo di questi test ho utilizzato la libreria JUnit che mi ha permesso di
scrivere i test direttamente in Java.
A causa del tempo limitato non sono riuscito a testare tutti i requisiti emersi durante
l’analisi dei requisiti. Alla fine del progetto sono riuscito a creare un test automatico a
74 dei 159 requisiti, raggiungendo una copertura delle righe di codice pari al 57%.
Oltre all’esecuzione di test, un’altra forma di verifica che ho applicato e stata
l’analisi statica del codice. Per effettuare questa analisi ho utilizzato gli strumenti
messi a disposizione da IntelliJ IDEA. Grazie a questi strumenti, la presenza di
problemi rivelabili da un’analisi statica è stata evidenziata durante la stesura del codice
permettendo un’immediata eliminazione del problema.
Per garantire una verifica continua ed evitare regressioni del prodotto, ho configurato
git per eseguire i test e l’analisi statica ad ogni nuova versione del codice ricevuta
dal repository remoto, accettando i nuovi cambiamenti solamente se l’esito dei test e
dell’analisi statica è favorevole.32 CAPITOLO 3. SVOLGIMENTO PROGETTO
Per automatizzare l’analisi statica del codice ho utilizzato:
• FingBug, un programma appositamente studiato per l’analisi statiche del codice
Java;
• Checkstyle, un programma che verifica che le regole di stile del codice siano
state rispettate.
3.5.3 Validazione
Per validare il prodotto, ho organizzato una presentazione delle funzionalità sviluppate,
a cui ha partecipato il tutor aziendale.
Per rendere la dimostrazione realistica, ho richiesto al reparto sistemistico le stati-
stiche di utilizzo delle principali funzionalità offerte da un server Zimbra, organizzate
per tipologia di utente.
Da queste statistiche ho creato un test che simula due tipologie di utenti, i manager
e gli impiegati. Gli utenti manager sono il 10% di tutti gli utenti e si distinguono
dagli impiegati perché accedono alla posta elettronica mediante l’utilizzo di client che
utilizzano il protocollo IMAP. Gli impiegati sono il restante 90% e accedono alla posta
elettronica tramite interfaccia web.
Ogni utente è caratterizzato dalle seguenti attività:
• ogni ora riceve da utenti esterni 10 email, delle quali il 75% è di piccole dimensioni
ed il restante 25% è di medie dimensioni;
• ogni ora invia a utenti interni 3 email, delle quali il 75% è di piccole dimensioni
ed il restante 25% è di medie dimensioni;
• ogni ora controlla la posta in entrata 12 volte;
• ogni ora spediscono 6 messaggi sulla chat aziendale.
La simulazione dovrà fermarsi quando più del 5% delle richieste avrà come risultato
un errore.
Nei giorni precedenti alla presentazione, ho eseguito dei test basati su questa
configurazione, utilizzando un server Zimbra installato su una macchina creata e
configurata appositamente per il test.
Il giorno della presentazione ho illustrato le varie funzionalità offerte dal prodotto,
dando una dimostrazione pratica del suo funzionamento. Grazie ai dati raccolti nei
giorni precedenti, ho potuto esporre i risultati del test, mostrando un report dove si
evidenziavano i limiti della macchina.3.5. VERIFICA E VALIDAZIONE 33
Figura 3.13: Risultati del test esposto al termine della presentazione
Osservando i risultati del test si nota dopo le 19:52 è stato registrato un deciso
peggioramento nei tempi di risposta delle richieste inviate al server, abbassando
drasticamente la qualità del servizio, rendendolo inutilizzabile.
Figura 3.14: Thread in funzione del tempo trascorso
Grazie al grafico dei thread in funzione del tempo, possiamo dire che alle 19:52
c’erano circa 2500 utenti attivi. Da questo dato possiamo dedurre che una macchina
con le stesse caratteristiche della macchina del test non può supportare più di 2500
utenti attivi contemporaneamente.Puoi anche leggere
