Generazione automatica diagrammi di rete con template pptx

UNIVERSITÀ DEGLI STUDI DI
TRIESTE
Dipartimento di Ingegneria e Architettura
Laurea triennale in Ingegneria Elettronica e
Informatica
Generazione automatica di diagrammi di
rete con template PPTX
4 dicembre 2018
Laureando Relatore
Giacomo Zorzin Chiar.mo Prof. Alberto Bartoli
Correlatore
Ing. Marco D’Orlando
Anno Accademico 2017/2018

Sommario
Obbiettivo del lavoro di questa tesi è stato di automatizzare il processo di
generazione dei diagrammi di rete, per conto di un’azienda di telecomunica-
zioni.
Attualmente tali diagrammi vengono generati manualmente da opera-
tori dell’azienda, con un significativo sforzo in termini temporali, e con la
possibilità di contenere errori.
A tale scopo è stata sviluppata un’applicazione in grado di:
• generare automaticamente i diagrammi di rete utilizzando un approccio
basato su template;
• rispettare le convenzioni grafiche in uso presso l’azienda;
• generare diagrammi che riflettano le novità introdotte nelle offerte
dell’azienda, senza richiedere modifiche del software;
Tale applicazione è stata sviluppata per essere facilmente integrabile con
la piattaforma web ConCreTo prodotta da Emaze S.p.A., che offre soluzioni
per l’ottimizzazione delle attività di network provisioning.
Possibili sviluppi futuri includono l’ampliamento della suite di test auto-
matizzati già presente, la creazione di nuovi test di conformità dei template
ed il refactoring di alcune classi dell’applicazione.
i

Indice
Sommario i
Introduzione iv
1 Stato dell’arte 1
1.1 Soluzioni esistenti . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Librerie software disponibili . . . . . . . . . . . . . . . . . . . 2
1.3 Libreria scelta . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Analisi e progettazione 3
2.1 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Analisi del contesto: ConCreTo . . . . . . . . . . . . . 3
2.1.2 Analisi degli obbiettivi . . . . . . . . . . . . . . . . . . 5
2.1.3 Requisiti di progetto . . . . . . . . . . . . . . . . . . . 5
2.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Approcci possibili . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Algoritmo di generazione diagrammi . . . . . . . . . . 7
3 Realizzazione 11
3.1 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . 14
3.2.2 Oﬃce Open XML Presentation Format . . . . . . . . . 14
3.2.3 Criteri di eliminazione degli elementi . . . . . . . . . . 15
3.2.4 Ruolo delle classi principali . . . . . . . . . . . . . . . 17
4 Test del software 20
4.1 TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Test eﬀettuati . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Test d’unità . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Test d’integrazione . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Test di sistema . . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Considerazioni . . . . . . . . . . . . . . . . . . . . . . 22
ii

Introduzione
Una compagnia di telecomunicazioni offre ai propri clienti di tipo Business
una vasta gamma di servizi, oltre a quelli di connettività. Per la loro eroga-
zione sono necessarie diverse configurazioni su piú apparati di rete, a partire
da quelli presso la sede del cliente fino agli apparati broadband per l’accesso
ad Internet. Le operazioni di configurazione rappresentano una grossa parte
del lavoro di network provisioning compiuto dalle aziende.
Allo scopo di facilitare ed automatizzare il processo di generazione delle
configurazioni dei dispositivi coinvolti nell’erogazione del servizio, Emaze
s.p.a. ha sviluppato, per conto di una azienda italiana operante nel campo
delle telecomunicazioni, l’applicazione web ConCreTo.
L’azienda di telecomunicazioni, per ogni progetto cliente deve in seguito
realizzare uno o piú diagrammi di rete. Questa operazione viene attualmente
eseguita manualmente da degli addetti, utilizzando Microsoft PowerPoint.
Essa comporta un significativo sforzo in termini di tempo ed è prona all’errore
umano.
Dall’osservazione di questa criticità nasce l’obbiettivo del lavoro di questa
tesi: sviluppare una proof of value di uno strumento facilmente integrabile
in ConCreTo che permetta la generazione di diagrammi di rete in maniera
automatica, minimizzando il tempo di preparazione e la possibilità di errori.
Alla fine del lavoro si è prodotto uno strumento in grado di generare
automaticamente il diagramma di una rete sulla base delle sue informazioni
di configurazione, controllabile dall’interfaccia di ConCreTo. Tale strumento
ha passato la fase di test e sarà presente nella versione in rilascio nel mese
di dicembre 2018. Per il suo sviluppo si è utilizzato Java, per facilitarne
l’integrazione in ConCreTo.
Questa tesi è suddivisa nei seguenti capitoli:
1. Stato dell’arte: in questo capitolo vengono descritte le tipologie di
software esistenti per la generazione di diagrammi di rete, fornendo le
ragioni per le quali esse non rispondono alle necessità del cliente. Do-
vendo quindi optare per lo sviluppo di una soluzione software persona-
lizzata, si descrivono brevemente le librerie disponibili per lo sviluppo
e le motivazioni che hanno portato a scegliere Apache POI;
iv

INTRODUZIONE
2. Analisi e Progettazione: in questo capitolo si descrivono il contesto
e le criticità da cui nasce l’idea alla base del progetto. Vengono forma-
lizzati gli obbiettivi da raggiungere e i requisiti che ne derivano. Infine
si discutono i due approcci considerati per la soluzione del problema,
motivando la scelta di un approccio basato su template;
3. Implementazione: questo capitolo descrive l’interfaccia che un ope-
ratore dell’azienda utilizza per controllare l’applicazione sviluppata, ed
il funzionamento delle principali classi che compongono il software;
4. Test: in questo capitolo vengono descritti i tipi di test effettuati sul-
l’applicazione, e vengono effettuate alcune considerazioni sui risultati
di tali test;
v

Capitolo 1
Stato dell’arte
In questa sezione si descrivono le tipologie di software esistenti per la gene-
razione di diagrammi di rete, e vengono dettagliate le ragioni per le quali
esse non rispondono alle necessità del cliente. Si descrivono quindi sinte-
ticamente le librerie software considerate per lo sviluppo di una soluzione
personalizzata e le motivazioni che hanno portato a scegliere Apache POI.
1.1 Soluzioni esistenti
Esistono numerose applicazioni per la generazione di diagrammi di rete in
formato PPTX e non. La maggior parte di queste soluzioni sono essenzial-
mente software per il disegno di diagrammi. Alcune offrono la possibilità di
creare ed utilizzare dei template, ma l’operatore deve comunque inserire a
mano i parametri specifici del progetto cliente, dopo averli cercati fra i file
di configurazione.
Sono state scartate poichè si vuole una soluzione che generi automatica-
mente i diagrammi di rete.
Alcune applicazioni forniscono un certo grado di automatismo grazie al-
l’uso del protocollo SNMP1 o di altri protocolli proprietari. Grazie a tali
protocolli queste applicazioni riescono a tracciare una mappa dei dispositivi
all’interno della rete, attraversandoli tutti.
Queste applicazioni sono state però scartate per due motivi principali:
• richiedono che la rete esista già: questa condizione non è in generale
soddisfatta nei casi d’uso visti col cliente;
• non forniscono sufficiente libertà nella resa grafica del documento;
1
Simple Network Management Protocol
1

CAPITOLO 1. STATO DELL’ARTE
1.2 Librerie software disponibili
Esistono varie librerie che permettono la manipolazione dei file PPTX. Si
presentano di seguito le principali.
• Aspose.slides2: libreria con licenza proprietaria che fornisce API ad
alto livello per la manipolazione di file PPTX, in vari linguaggi di
programmazione;
• docx4j3: libreria con licenza Apache 2.0 utilizzata per manipola-
re principalmente file DOCX, ma utilizzabile anche per file PPTX e
XLSX;
• Apache POI XSLF4: libreria con licenza Apache 2.0 che fornisce API
ad alto livello per manipolare file PPTX in linguaggio Java;
1.3 Libreria scelta
Per lo sviluppo dell’applicazione si è deciso di utilizzare la libreria Apache
POI XSLF. Di seguito le motivazioni che hanno guidato la scelta:
• l’integrazione dell’applicazione è facilitata dal fatto che ConCreTo uti-
lizza già altre librerie della suite Apache POI;
• fornisce API ad alto livello, al contrario di docx4j, permettendo di
astrarsi dalla struttura XML dei file PPTX descritta in sottosezio-
ne 3.2.2 e di scrivere codice piú leggibile;
• contrariamente ad Aspose.slides, è distribuita con licenza Apache 2.05
che ne permette il libero uso in software a scopi commerciali, a patto
di non usare i simboli o il nome della Apache Foundation;
• rispetto a docx4j Apache POI possiede una comunità di utilizzatori
piú sviluppata, e ciò può costituire un valido aiuto in caso di problemi
durante lo sviluppo;
2
https://products.aspose.com/slides
3
https://www.docx4java.org/trac/docx4j
4
https://poi.apache.org/components/slideshow/
5
http://www.apache.org/licenses/LICENSE-2.0.txt
2

Capitolo 2
Analisi e progettazione
2.1 Analisi
In questa sezione si descrivono il contesto in cui nasce l’idea alla base del
progetto, e gli obbiettivi da raggiungere. Si elencano infine i requisiti di
progetto che ne derivano.
2.1.1 Analisi del contesto: ConCreTo
ConCreTo è un applicazione web progettata e sviluppata da Emaze S.p.A.
per automatizzare parte delle operazioni di network provisioning di una
compagnia di telecomunicazioni.
Viene utilizzato da due tipologie di utenti, con scopi diversi:
• operatore di network delivery: a partire da un progetto cliente, genera
le configurazioni per tutti i servizi richiesti inserendo in ConCreTo i
parametri specifici del cliente;
• operatore network admin: è autore dei progetti cliente, ed è responsa-
bile della generazione e aggiornamento dei template usati da ConCreTo
per la generazione delle configurazioni;
In particolare, per ciascun apparato presente nel progetto cliente, l’ap-
plicazione web valorizza il corrispondente template delle configurazioni con i
parametri specifici inseriti dall’operatore di network delivery. Genera quindi
dei file XLSX che contengono, suddivisi per dispositivo, i comandi necessari
per l’attivazione di tutti i servizi.
A questo punto gli operatori generano manualmente i diagrammi di rete
per il progetto. Attualmente ciò viene fatto utilizzando Microsoft Power-
Point. Questa scelta ha due ragioni:
• semplicità di distribuzione dei diagrammi: chiunque è in grado
di leggere e modificare file PPTX data la larga diffusione della suite
3

CAPITOLO 2. ANALISI E PROGETTAZIONE
Microsoft Office o degli equivalenti liberi OpenOffice e LibreOffice. In
caso di necessità particolari si può esportare la presentazione in formato
PDF, perdendo però la possibilità di modificare il file;
• facilità d’uso: i software appena citati permettono di generare e modi-
ficare presentazioni senza richiedere formazione specifica del personale
addetto, nè l’uso di software dedicato;
Un progetto cliente può richiedere la realizzazione di piú diagrammi. Il
numero varia a seconda dei servizi richiesti dal cliente. Ciascun diagramma
mostra di volta in volta la struttura e le proprietà della rete relativamente
al servizio in evidenza: in tale caso ogni diagramma si dirà rappresentare un
contesto diverso.
Ad esempio, ad un cliente che richieda l’attivazione di un servizio Internet
ed un servizio VPN verranno forniti due diversi diagrammi di rete: uno per
il contesto Internet ed uno per il contesto VPN.
In un diagramma, per ciascun dispositivo e collegamento vengono indi-
cate alcune proprietà, come l’indirizzo di rete, l’indirizzo fisico o la tipologia
di collegamento. Allo scopo di rendere immediata la visualizzazione della
struttura di rete e la tipologia dei vari elementi che la costituiscono, si ricor-
re ad icone, colorazioni degli elementi di rete o frasi in linguaggio naturale.
Alcune di queste pratiche, come ad esempio i colori da associare ai diversi
tipi di connessione, seguono delle convenzioni stabilite a livello aziendale,
altre sono invece frutto di scelte individuali dell’operatore.
Tali diagrammi di rete vengono poi consegnati al cliente come parte della
documentazione dei servizi acquistati. Infine gli operatori procedono poi con
la configurazione di tutti gli apparati connettendosi in SSH e inserendo i
comandi da terminale.
Esempio di diagrammi di rete attualmente in uso
In Figura 2.1 e Figura 2.2 sono visibili i diagrammi rappresentanti i contesti
Internet e cloud-PBX di un progetto cliente. Il diagramma in Figura 2.1
evidenzia la struttura del servizio Internet offerto al cliente. Il diagramma in
Figura 2.2 evidenzia la struttura del servizio cloud e PBX1 offerto al cliente.
In entrambi sono visibili, dal basso verso l’alto:
• la rete del cliente, limitatamente ai CPE2 ed eventuali altri appara-
ti forniti dalla compagnia di telecomunicazioni come parte dei servizi
acquistati;
• la rete d’accesso;
• la rete di trasporto, limitatamente ai router PE3 e ad un elemento a
1
Private Branch Exchange
2
Customer Premises Equipment
3
Provider Edge
4

forma di nuvola che rappresenta il servizio offerto;
2.1.2 Analisi degli obbiettivi
Dall’analisi del contesto appena effettuata emergono le seguenti criticità,
riguardanti la generazione manuale dei diagrammi di rete:
• è lenta. Costituisce un notevole collo di bottiglia nelle operazioni di
network provisioning dell’azienda;
• è soggetta ad errore umano. Poichè tale diagramma costituisce par-
te della documentazione tecnica del progetto cliente, è importante
eliminare tali errori;
• produce diagrammi che non soddisfano fedelmente uno standard di
qualità, essendo lavoro di operatori diversi;
Il lavoro di questa tesi si pone allora i seguenti obbiettivi:
• automatizzare la produzione dei diagrammi di rete per ogni progetto
cliente;
• standardizzare la qualità e il contenuto dei diagrammi prodotti;
• assicurare che il contenuto dei diagrammi corrisponda esattamente
ai parametri specifici del progetto cliente, usati nelle configurazioni
generate da ConCreTo;
2.1.3 Requisiti di progetto
Al fine di raggiungere gli obbiettivi sopra elencati, sono stati definiti i se-
guenti requisiti per l’applicazione da progettare:
1. deve essere in grado di generare i diagrammi di rete per ogni possibile
progetto cliente, anche tenendo conto degli sviluppi tecnologici futuri
che influenzeranno l’offerta della compagnia di telecomunicazioni;
2. deve farlo automaticamente, ovvero senza altro input da parte dell’o-
peratore al network delivery al di fuori della richiesta;
3. deve generare diagrammi che rispettano delle convenzioni grafiche e di
struttura decise dall’azienda, variabili nel tempo;
2.2 Progettazione
Questa sezione descrive i due approcci vagliati in fase di progettazione, det-
tagliando le ragioni che hanno portato ad adottare quello di eliminazione,
basato su template. Si procede poi a descrivere l’algoritmo di generazione
dei diagrammi che è stato realizzato.
5

2.2.1 Approcci possibili
Dall’analisi effettuata nella sezione 2.1 sono emersi i due seguenti possibili
approcci al problema della generazione automatica dei diagrammi di rete.
Approccio costruttivo
Tale approccio prevede che il software generi i diagrammi a partire da un file
PPTX vuoto, al quale si vanno ad aggiungere poi una slide per ogni diagram-
ma da disegnare. Per ciascun diagramma vengono aggiunti i dispositivi di
rete, le connessioni fra di essi, e le proprietà dei vari elementi. Questa proce-
dura rispecchia quella seguita dagli operatori nella generazione manuale dei
diagrammi.
Questo approccio, sebbene intuitivo, è stato scartato dopo una breve con-
siderazione. La sua realizzazione richiede infatti che il software sappia, per
ogni rete che si voglia rappresentare, quali dispositivi debbano essere rap-
presentati, quali loro proprietà e quali tipi di connessioni. Tali informazioni
non sono ottenibili dai parametri di configurazione contenuti in ConCreTo.
Pertanto, sarebbe necessario procedere in uno dei due seguenti modi:
• Inserire queste informazioni nella logica del software. Questa soluzione
contraddice il primo requisito di progettazione. Infatti renderebbe l’ap-
plicazione incapace di adattarsi a variazioni dei diagrammi da generare,
dovute per esempio a novità nell’offerta dell’azienda;
• Richiedere un input all’utente che determini cosa debba essere rap-
presentato nel diagramma. Ciò contraddice il secondo requisito di
progettazione, quello di automazione del processo;
Approccio di eliminazione
Osservando i principali diagrammi di rete generati dagli operatori manual-
mente, è emersa la possibilità di adottare un approccio diverso che chiame-
remo di seguito di "eliminazione".
Tale approccio prevede la generazione una tantum da parte dell’operatore
network admin di un documento PPTX contenente dei template di diagram-
mi di rete. Questi rappresentano il limitato sottoinsieme di strutture di rete
che si ripete fra i vari progetti. Tra questi template, in fase di generazione
del diagramma si andrà a rimuovere i template incompatibili con la struttu-
ra di rete del progetto cliente, e compilare i template rimanenti con i dati
necessari.
Inoltre, per fare in modo che la formattazione di certi elementi di rete
rispetti le convenzioni grafiche decise dall’azienda, si è proposto analogamen-
te di creare una tantum un documento contenente tali regole, che verranno
poi importate ed utilizzate dal software. In questo modo, il documento può
6

essere aggiornato quando siano introdotte nuove convenzioni, o modificate
quelle esistenti.
Tale tecnica permette di soddisfare i requisiti di progettazione:
• permette la generazione completamente automatica dei diagrammi per
gli operatori di network delivery;
• i diagrammi generati soddisfano le convenzioni grafiche specificate nel
documento generato dagli operatori network admin;
• in presenza di aggiornamenti delle tipologie di reti e servizi offerti, non
sono richieste modifiche alla logica del software: si richiede soltanto che
un operatore network admin aggiorni il documento contenente i tem-
plate e quello contenente le regole di formattazione, per poter generare
diagrammi aggiornati;
L’unico svantaggio risulta essere la necessità di creare manualmente, e
tenere aggiornati, i documenti contenenti i template e le convenzioni grafiche.
Dalle interazioni con il committente si è però giunti alla conclusione che il
costo temporale di ciò sia ragionevole quando confrontato con il risparmio di
tempo dato dalla generazione automatica dei diagrammi. Si è quindi deciso
di seguire questo approccio.
2.2.2 Algoritmo di generazione diagrammi
Durante il periodo di tirocinio è stato progettato e realizzato un algoritmo
di generazione dei diagrammi. Si descrive in seguito la versione definitiva
implementata dal software: gli aspetti tecnici della sua implementazione
verranno discussi nel Capitolo 3.
Nel momento in cui viene richiesta la generazione di un diagramma di
rete, il software
1. Apre una copia documento contenente i template di rete;
2. Rimuove i template incompatibili con la struttura di rete corrente;
3. Per ciascuno dei template rimasti, e quindi compatibili:
(a) Rimuove eventuali elementi che rappresentano dispositivi di rete
non presenti nello schema con i servizi richiesti dal cliente;
(b) Controlla l’esistenza di eventuali connessioni rimaste senza dispo-
sitivi ad uno dei due capi: se presenti, le rimuove;
(c) Rimuove le proprietà riguardanti gli eventuali dispositivi rimossi;
(d) Compila il testo degli elementi rimanenti con i parametri specifici
del progetto cliente;
7

(e) Sostituisce gli elementi che rappresentano dispositivi di rete con
le opportune icone prelevate dal database di ConCreTo.
(f) Cambia le proprietà grafiche di alcuni elementi specifici (connetto-
ri e forme "nuvola") secondo le regole di formattazione specificate
nel documento creato dagli operatori network admin;
4. Salva i diagrammi cosí generati in un nuovo documento, per essere
esportato dagli operatori.
8

Figura 2.1: Esempio di diagramma generato manualmente che evidenzia il
contesto Internet.
9

Figura 2.2: Esempio di diagramma generato manualmente che evidenzia il
contesto cloud-PBX.
10

Capitolo 3
Realizzazione
In questo capitolo verranno descritte l’interfaccia con il quale l’utente intera-
gisce con ConCreTo allo scopo di generare i diagrammi di rete, ed i dettagli
implementativi del modulo software sviluppato come lavoro di questa tesi.
3.1 Interfaccia
L’utente di ConCreTo genera le istruzioni di configurazione di una rete ed
i relativi diagrammi tramite l’interfaccia grafica web dell’applicazione. In
questa sezione si descrivono sinteticamente le varie parti di tale interfaccia.
In particolare, non si scenderà nei dettagli riguardanti l’utilizzo di ta-
le interfaccia per la generazione delle istruzioni di configurazione, ma ci si
concentrerà sulla parte riguardante la generazione dei diagrammi di rete.
La pagina web è divisa in un menú laterale ed una vista centrale. A
seconda della voce selezionata nel menú laterale, il contenuto della vista
centrale cambia.
In Figura 3.1 è visibile il menú laterale: esso mostra opzioni differenti
a seconda del ruolo dell’utente correntemente autenticato (utente network
admin o utente network delivery) e vi si possono individuare tre parti.
La parte 1 permette all’utente network admin la gestione e creazione dei
template di configurazione per gli apparati di rete.
La parte 2 viene solitamente utilizzata solo dagli utenti network delive-
ry. Qui essi possono, a partire dal progetto cliente, determinare la struttura
della rete ed inserire i parametri specifici del cliente. Infine, alla voce Confi-
gurazioni possono chiedere la generazione dei comandi di configurazione.
I diagrammi di rete per il progetto vengono creati automaticamente
quando viene richiesta la generazione dei comandi di configurazione. Il file
PPTX che contiene i diagrammi viene inserito in un archivio ZIP assieme
al file XLSX con le configurazioni generate; l’archivio viene poi esportato
dall’utente.
11

CAPITOLO 3. REALIZZAZIONE
Figura 3.1: Menú laterale di ConCreTo per utenti amministratori
12

La parte 3 permette agli utenti network admin di modificare alcune
impostazioni generali riguardanti la generazione delle configurazioni degli
apparati e, tramite la voce Schemi di rete, di accedere alla interfaccia di
amministrazione dello strumento di generazione dei diagrammi di rete.
Figura 3.2: Vista sezione Schemi di rete
Qui l’utente amministratore può effettuare l’importazione o l’esportazio-
ne di un archivio in formato ZIP. Tale file deve contenere tutti i file necessari
alla generazione dei diagrammi di rete:
• un file templates.pptx contenente i template dei diagrammi di rete;
• un file formatting.xlsx contentente le informazioni sulla formatta-
zione dei connettori e delle forme che rappresentano le VPN;
• un insieme di file PNG contenenti le icone che verranno utilizzate per
rappresentare i dispositivi di rete; ciascuna icona dovrà avere come
nome quello con cui il corrispondente dispositivo di rete viene indicato
nei parametri di configurazione.
Per poter generare i diagrammi di rete l’insieme di questi file deve essere
presente nel database di ConCreTo; nel caso siano assenti uno o piú file,
l’archivio ZIP prodotto premendo il tasto Scarica tutte le configurazioni nella
sezione Configurazioni contiene solamente i file XLSX con le istruzioni di
configurazione.
Quando è necessario aggiornare i template per includere nuove tipologie
di reti, aggiungere altre icone corrispondenti a nuovi dispositivi di rete o
specificare nuove regole di formattazione, l’utente amministratore deve creare
13

un nuovo archivio ZIP contenente tutti i file elencati sopra, aggiornati con le
necessarie modifiche, ed importarlo in ConCreTo. Questa azione eliminerà
dal database i file precedentemente esistenti, ed inserirà quelli nuovi. Dopo
di ciò lo strumento sarà in grado di generare diagrammi di rete che riflettano
le novità introdotte.
L’interfaccia contiene inoltre dei brevi richiami ai punti salienti della do-
cumentazione corredati da esempi, riguardo l’uso dell’interfaccia e i requisiti
di conformità per i file templates.pptx e formatting.xlsx. Nella figura gli
esempi sono stati nascosti, in quanto contenenti dati sensibili.
3.2 Implementazione
In questa sezione si introducono brevemente le tecnologie utilizzate per lo
sviluppo del software. Si descrivono poi i ruoli delle classi che realizzano
l’algoritmo descritto nella sottosezione 2.2.2, ed i criteri che sono stati definiti
per l’eliminazione degli elementi dal template. Per meglio spiegare la ragione
di alcune scelte implementative si ritiene inoltre necessaria una sintetica
descrizione della struttura di un file PPTX.
3.2.1 Tecnologie utilizzate
Il modulo software è stato sviluppato utilizzando il linguaggio Java, ver-
sione 8. La motivazione di tale scelta è stata la facilità di integrazione in
ConCreTo, che è sviluppato nello stesso linguaggio.
Come ambiente di sviluppo si è utilizzato IntelliJ IDEA, per sfruttare le
pregresse esperienze del tirocinante con lo strumento.
Per manipolare i file PPTX si è fatto uso della libreria Apache POI XSLF:
le ragioni della sua scelta sono state esposte nel Capitolo 1.
3.2.2 Office Open XML Presentation Format
Il formato PPTX, o Office Open XML Presentation, e’ uno dei tre formati
Office Open XML1, assieme ai formati Office Open XML Document (DOCX)
e Office Open XML Workbook (XLSX).
Tutti questi formati condividono la stessa struttura: un archivio ZIP con-
tenente un certo numero di file xml ed altri file di dati, in numero variabile a
seconda dei contenuti del documento. Un file PPTX contiene nella directory
principale dell’archivio:
• un file [Content_Types].xml;
• una cartella _rels;
• una cartella docProps;
1
http://officeopenxml.com/
14

• una cartella ppt;
Nella cartella ppt è contenuta una gerarchia di cartelle contenenti vari file
XML che descrivono le parti costitutive del documento e le relative proprietà.
In particolare esiste una cartella slides contenente
• un insieme di file XML nominati slide1.xml, ..., slideN.xml (dove N
è il numero di slide contenute nel documento);
• una cartella _rels, contenente file XML che definiscono le relazioni tra
le slide e altre parti del documento o elementi esterni (ad esempio file
multimediali);
I file slide1.xml, ..., slideN.xml contengono una descrizione in linguag-
gio XML del contenuto di ciascuna slide della presentazione. Ogni tipo di
elemento contenuto in una slide è definito con un tag XML. Ciascun elemento
può essere radice di un sottoalbero di tag che ne rappresentano le proprietà.
3.2.3 Criteri di eliminazione degli elementi
Avendo deciso in fase di progettazione di affrontare il problema con un ap-
proccio di eliminazione è importante descrivere i criteri che determinano se
un elemento contenuto nel template debba venire scartato o meno.
Si introducono qui brevemente i tipi di elementi che compongono il
template PPTX.
• Presentazione: una presentazione è un contenitore di slides;
• Slide: una slide è un contenitore di shapes. Una slide contiene il tem-
plate di un solo tipo di diagramma di rete. Ciascuna slide può esse-
re corredata da delle note del relatore che in genere sono stringhe di
caratteri;
• Shape: una shape è un singolo elemento grafico. In particolare, nei
diagrammi di rete generati si utilizzano le seguenti tipologie di shape:
– Rettangolo: contiene del testo che può essere statico, dinamico,
o un misto dei due tipi. Viene definito "dinamico" nel caso con-
tenga dei placeholder che verranno sostituiti dal software con il
corrispondente valore contenuto nei parametri di configurazione
forniti da ConCreTo. Viene definito "statico" quando non con-
tiene alcun placeholder. Il testo statico è mantenuto intatto dal
software. Indipendentemente dal tipo di testo inoltre, la logica
del software preserva le proprietà di formattazione che sono state
scelte al momento della generazione del template.
Un rettangolo può essere destinato anche a rappresentare un di-
spositivo di rete, e quindi ad essere sostituito da un’icona. In tal
caso esso conterrà solo testo di tipo dinamico.
15

– Connettore: rappresenta una connessione fra due dispositivi di
rete.
– Nuvola: rappresenta i servizi offerti offerti dal provider al cliente,
ed è quindi sempre presente in ogni struttura di rete. Può con-
tenere testo. Assieme ai connettori, è uno dei due tipi di shape
che richiede una formattazione specifica in dipendenza dal servizio
offerto.
Sono stati individuati i seguenti criteri per l’eliminazione dei diversi tipi
di elemento:
• eliminazione slide: ciascuna slide può contenere nelle proprie note del
relatore un predicato booleano che coinvolga piú parametri di confi-
gurazione; se, in base ai parametri specifici di un progetto cliente, il
predicato ha valore Falso, la slide viene scartata. Se invece assume va-
lore Vero, o se le note del relatore non contengono testo, la slide viene
conservata. Viene fornito un esempio in seguito;
• eliminazione rettangoli: un rettangolo viene scartato se il suo testo
contiene dei placeholder per variabili che non compaiono fra i parametri
di configurazione della rete forniti da ConCreTo.
• eliminazione connettori: un connettore ha ragione di esistere solo se
connette due elementi di rete, pertanto viene scartato non appena uno
degli elementi che collegava viene eliminato.
Per chiarire ulteriormente il meccanismo di scarto delle slide, si consi-
deri il seguente esempio illustrativo: Si supponga che l’azienda offra diversi
tipi di servizio VPN. Questi richiederanno in generale diversi parametri di
configurazione. Si supponga però che tutti quanti i servizi VPN richiedano
l’inserimento di uno specifico valore per un dato parametro. Per semplicità,
chiamiamo tale parametro "VPN" e supponiamo il suo valore debba essere
1. Allora, alla generazione dei template andrà inserito il predicato VPN=1
nelle note della slide contenente il template che rappresenta il servizio VPN.
In questo modo, essa verrà scartata quando il parametro non è presente fra
quelli specifici del progetto cliente, poichè il predicato assumerà valore Falso.
La complessità dei predicati potrà essere in generale piú elevata. Il parser
che viene utilizzato per valutarli supporta l’uso di operatori AND, OR e
dell’operatore di uguaglianza.
Questi criteri sono stati frutto di una serie di colloqui effettuati insieme
al team di sviluppo. Particolare attenzione è stata posta nel definirli in
modo che il lavoro manuale di generazione e aggiornamento dei template
non diventasse troppo complesso.
Ad esempio, il criterio per l’eliminazione di un rettangolo permette di
aggregare all’interno di un solo rettangolo tutti i placeholder che rappresen-
tano le propietà di configurazione di un dispositivo di rete. Infatti, se una
16

di quelle proprietà è presente fra i parametri di configurazione della rete ciò
significa che il dispositivo è presente, e quindi i parametri di configurazione
conterranno anche le altre proprietà di quel dispositivo.
Lo stesso criterio, se non si fosse posta attenzione a facilitare il lavoro
degli addetti alla generazione dei template, si sarebbe potuto definire diver-
samente. Ad esempio obbligando ad inserire un solo placeholder per ogni
rettangolo. Questo però avrebbe fatto crescere enormemente il numero di
rettangoli in una slide, rendendo difficoltoso o impossibile il loro piazzamento
durante la generazione del template.
L’insieme di questi criteri è stato sintetizzato in un documento sotto
forma di istruzioni per la generazione di template conformi. Tale documento
farà parte della documentazione di ConCreTo distribuita al cliente.
3.2.4 Ruolo delle classi principali
Vengono descritte ora le classi che ricoprono un ruolo principale all’interno
del software. Tutte queste classi, per svolgere il loro compito, necessitano di
avere i parametri di configurazione della rete per cui si sta generando il dia-
gramma. Questi dati vengono trasmessi al software da ConCreTo utilizzando
il formato JSON[2].
SlideManager
Questa classe contiene i metodi che implementano la parte di logica che si
occupa di manipolare le slide della presentazione, e le eventuali note del
relatore di tali slide. In particolare, utilizzando la classe Parser descritta
sotto, consentono di filtrare le slide della presentazione in base al criterio
definito in sottosezione 3.2.3.
ShapeManager
Questa classe contiene invece i metodi che implementano la parte di logica
che si occupa di manipolare le shape all’interno di una slide. In particolare
implementa i criteri di eliminazione per i vari tipi di shape. Inoltre permette
di sostituire shape di tipo rettangolo con un immagine in formato PNG, al
fine di poter rappresentare i dispositivi di rete con le icone fornite tramite
l’interfaccia di ConCreTo.
L’implementazione del criterio di eliminazione dei connettori si è rivelata
particolarmente problematica rispetto alle altre. Ciò è dovuto alla mancan-
za, fra i metodi forniti dalla libreria Apache POI XSLF, di un metodo che
permetta di risalire a quali shape siano connesse ad un connettore. Questo
rende pertanto complicato sapere utilizzando le sole funzioni di libreria se il
connettore stia effettivamente collegando due elementi, o meno.
Questo problema è stato risolto utilizzando un’altra funzione di Apache
POI XSLF: il metodo getXmlObject() della classe XSLFShape. Tale me-
17

todo, quando invocato da un’istanza della classe XSLFShape restituisce un
XmlObject dal quale si può ottenere, tramite metodo toString(), la stringa
contenente il sottoalbero XML che rappresenta la shape.
Fra i tag contenuti in quest’albero, che definiscono le proprietà del con-
nettore, vi sono i due tag <a:stCxn> e <a:endCxn> che ammettono come
attributo l’identificatore di una shape. Quando tale attributo è assente da
uno di questi tag, significa che il connettore ha un’estremità a cui non è
collegata alcuna shape.
Poichè tali tag devono essere sempre presenti fra i figli del tag che rappre-
senta un connettore2, si procede quindi applicando un’espressione regolare
alla stringa contenente la rappresentazione XML del connettore che permette
di identificare la porzione che li contiene. Di questa porzione interessa legge-
re il contenuto degli identificatori delle due shape connesse dagli attributi dei
due tag. Se uno dei due identificatori manca, significa che il connettore ha
un’estremità a cui non è collegata alcuna shape e può quindi essere rimosso.
ConnectorFormatter e CloudFormatter
Queste due classi offrono metodi per gestire la formattazione di shape, rispet-
tivamente, di tipo connettore e nuvola. Le proprietà di formattazione gestite
da questa classe vengono specificate nel file XLSX importato in ConCreTo
secondo le istruzioni descritte nella sezione 3.1 e riguardano
• colore di riempimento della shape di tipo nuvola;
• colore, spessore e stile del tratto per le shape di tipo connettore;
Tali proprietà di formattazione vengono assegnate sulla base del valore, al-
l’interno dei parametri di configurazione, del placeholder contenuto nella
shape.
In Figura 3.3 è visibile un diagramma di flusso dei dati utilizzati dall’ap-
plicazione.
2
secondo le specifiche del formato Office Open XML
18

Figura 3.3: Flusso dei dati gestiti dall’applicazione
19

Capitolo 4
Test del software
L’applicazione oggetto di questa tesi è stata sviluppata seguendo una co-
mune variante del paradigma TDD, sinteticamente riassunta in questo ca-
pitolo. Vengono descritte poi le tipologie di test effettuati e alcune delle
problematiche incontrate durante la stesura dei test.
4.1 TDD
Nel paradigma di progettazione software Agile1, come anche in quello Extre-
me Programming2, il TDD3 è un processo di sviluppo del software suddiviso
in un insieme ordinato di fasi.
Il suo obbiettivo è quello di portare alla scrittura di codice che imple-
menti la funzionalità desiderata e soddisfi certi requisiti di qualità quali la
leggibilità, la semplicità e la assenza di ripetizioni.
Le fasi caratteristiche del TDD sono le seguenti:
1. Creazione di un test che verifichi il raggiungimento della funzionalità
desiderata;
2. Esecuzione del test;
3. Scrittura della minima quantità di codice ritenuta necessaria a superare
il test;
4. Il test viene eseguito nuovamente. Se viene superato, si procede alla
fase successiva. Se viene fallito, si ritorna alla fase precedente;
5. Refactoring del codice: il codice prodotto viene rivisto e modificato in
modo da soddisfare i requisiti di qualità descritti sopra[1].
1
https://www.agilealliance.org
2
http://www.extremeprogramming.org/
3
Test Driven Development
20

CAPITOLO 4. TEST DEL SOFTWARE
Per lo sviluppo di questa applicazione si sono seguite le fasi tipiche del
TDD, rilassando però il vincolo sulla scrittura dei test prima della scrittura
del codice.
4.2 Test effettuati
Vengono ora descritte le diverse tipologie dei test effettuati.
4.2.1 Test d’unità
Seguendo il processo di TDD, per ogni metodo di classe scritto sono stati
creati due o piú test. Almeno due test sono necessari per poter verificare che
il codice scritto si comporti come atteso quando è nelle condizioni di farlo,
e che invece fallisca quando tali condizioni non sono rispettate. Questo tipo
di test si dicono test d’unità.
4.2.2 Test d’integrazione
I test d’unità non sono sufficienti ad identificare tutti i possibili errori in un
programma. Vi sono errori che derivano dalla composizione di piú funziona-
lità, ad esempio dovuti al loro interfacciamento.
Sono stati scritti allora una serie di test d’integrazione, i quali verificano
che il comportamento di un dato insieme di funzionalità sia quello desiderato.
La loro creazione è risultata in generale piú complessa rispetto a quella dei
test d’unità, ma sono stati anche responsabili della scoperta della maggior
parte degli errori di sviluppo.
4.2.3 Test di sistema
Alla fine del processo di sviluppo dell’applicazione è seguita una fase di test
di sistema. Tali test sono stati di tipo non automatizzato: sono consistiti
infatti nella verifica che in corrispondenza a diverse configurazioni di rete
inserite da un operatore, il software producesse correttamente i diagrammi
di rete corrispondenti.
Questi test sono stati svolti in collaborazione con gli operatori network
admin dell’azienda, al quale è stato affidato il compito di generare vari tem-
plate, seguendo le istruzioni specificate nella documentazione. Allo stesso
si è poi richiesto di generare delle configurazioni di rete tramite ConCreTo
compatibili con i template generati. Si sono infine confrontati i diagrammi
di rete prodotti dall’applicazione con quelli attesi dal cliente.
Il coinvolgimento del cliente nei test di sistema ha apportato tre principali
benefici:
• si sono evitati potenziali bias dei test dovuti alla conoscenza dell’im-
plementazione dell’applicazione;
21

• si è avuto un riscontro sulla qualità della documentazione prodotta;
• si è avuto un riscontro sul grado di soddisfacimento delle aspettative
del committente;
4.2.4 Considerazioni
Test automatizzati
I test d’unità e di integrazione hanno permesso di ridurre considerevolmente
il tempo dedicato al debugging dell’applicazione. In particolare i test d’unità
hanno permesso di evitare che errori nel codice dei singoli metodi venissero
ereditati dai metodi compositi, rendendone poi difficile l’individuazione e
l’attribuzione di responsabilità.
Si osserva come l’utilità di questi test sia fortemente accresciuta dall’uti-
lizzo di un sistema di controllo di versione del software: ciò permette infatti
di individuare in modo rapido errori introdotti in nuove versioni del codice.
Tali errori infatti causeranno il fallimento di alcuni test d’unità, permettendo
di individuare le unità affette da tali errori. Sarà allora sufficiente verificare
le modifiche apportate con l’ultima versione del codice a quelle particolari
unità per risalire agli errori introdotti. Durante lo svolgimento del lavoro di
questa tesi si è utilizzato Git4 come software per il controllo di versione.
Test coverage
La test coverage è una misura percentuale di quanto codice di un applica-
zione venga eseguito quando si esegue l’insieme dei test sviluppati. Fornisce
una stima della robustezza del codice sviluppato. A parità di test superati,
maggiore è la percentuale di coverage, piú robusto è il software, poichè ciò
significa che una maggior parte del suo codice è stata eseguita durante i test
e pertanto ci sono minori possibilità che esistano errori nel codice.
In Tabella 4.1 le percentuali di test coverage dell’applicazione sviluppata.
La misura è stata effettuata con il plugin messo a disposizione dalla IDE
IntelliJ IDEA5, utilizzata per lo sviluppo.
Tabella 4.1: Risultati test coverage.
Metrica Risultato % Risultato assoluto
Classi 100% 25/25
Metodi 94% 93/99
Linee di codice 93% 418/446
4
https://git-scm.com/
5
https://www.jetbrains.com/idea/
22

Test di sistema
I test di sistema hanno portato all’individuazione di errori difficilmente rile-
vabili nella generazione manuale dei template di rete, non dipendenti da ca-
renze nella documentazione dell’applicazione. Grazie alla loro individuazione
si sono potute elaborare delle contromisure, ed evitare cosí che causassero
comportamenti apparentemente inspiegabili dell’applicazione in sede d’uso.
Ad esempio, piú di una volta è capitato che nei template generati dai
network admin due rettangoli sembrassero a tutti gli effetti collegati da un
connettore, quando in realtà solo uno dei due lo era. Pertanto, soddisfacendo
il suo criterio di eliminazione, il connettore veniva rimosso durante l’esecu-
zione dell’algoritmo di generazione, nonostante entrambi i rettangoli venis-
sero conservati. Per il momento, si è ricorso a segnalare questa eventualità
all’interno della documentazione.
Inoltre si è potuto porre rimedio a delle carenze nella documentazione,
emerse dal riscontro fornito dagli utenti. In particolare, è stata ampliata la
parte di esempi che corredano le definizioni dei criteri di eliminazione dei
vari elementi di un template.
23

Conclusioni
L’obbiettivo di questa tesi è stato quello di sviluppare, per conto di un azien-
da italiana di telecomunicazioni, un applicazione capace di generare automa-
ticamente i diagrammi di rete per i progetti cliente, a partire dai parametri
specifici del progetto. La generazione manuale di tali diagrammi rappresenta
un collo di bottiglia per l’attività di network provisioning dell’azienda, ed è
prona ad errori.
Per rispondere a questi problemi si è realizzato un software integrato nel-
l’applicazione web ConCreTo sviluppata da Emaze S.p.A.. Il software è in
grado di compilare i template dei diagrammi di rete, e di modificarne la strut-
tura, sulla base degli stessi parametri di configurazione della rete già inseriti
in ConCreTo dagli operatori di network delivery. Poichè inoltre le tecnologie
ed i servizi offerti dall’azienda evolvono nel tempo, il software è stato rea-
lizzato in modo che gli utenti network admin possano aggiornarlo tramite
l’interfaccia di ConCreTo, affinchè i diagrammi prodotti riflettano le novità
introdotte. Infine è stato prodotto un documento che definisce il protocollo
da seguire per generare template che siano utilizzabili dall’applicazione.
I risultati della misura di test coverage indicano che il codice dell’appli-
cazione è robusto. Alla fine della fase di sviluppo è seguita una estensiva fase
di test di sistema nella quale si sono coinvolti alcuni network admin dell’a-
zienda. Da tale fase sono emersi alcuni comportamenti inattesi del software,
dovuti non ad errori nella logica dell’applicazione, ma ad errori di diffici-
le rilevazione nei template realizzati, che li rendevano quindi non conformi
alle specifiche espresse nella documentazione. Il riscontro ricevuto durante
questi test ha permesso quindi di elaborare ed implementare delle strategie
per evitare tali comportamenti inattesi. Inoltre ha evidenziato carenze della
documentazione e ne ha permesso il miglioramento.
Test di sistema successivi che hanno coinvolto anche altri network admin
dell’azienda hanno confermato che i risultati prefissati sono stati raggiunti: il
software è in grado di generare automaticamente diagrammi di rete a partire
dai template che gli vengono forniti e dai parametri di configurazione della
rete, soddisfacendo le aspettative del cliente in termini di qualità dei docu-
menti prodotti ed abbreviando i tempi dell’attività di network provisioning
dell’azienda.
24

CONCLUSIONI
L’applicazione, avendo superato la fase di test, verrà rilasciata in produ-
zione presso i data center del cliente nel mese di dicembre 2018.
Personalmente, il lavoro svolto per questa tesi è stato un’esperienza di
grande valore formativo, sia professionale che umano. In particolare il con-
tatto diretto con il cliente ed il lavoro di squadra con colleghi piú esperti
sono stati motivo di grande soddisfazione.
Durante lo sviluppo dell’applicazione e le fasi di test si sono inoltre in-
dividuati delle possibilità di ottimizzazione e di estensione dell’applicazione.
Di seguito si elencano le principali:
• Creazione di ulteriori test automatici di conformità dei template con le
speciﬁche di documentazione, per avvisare il network admin di even-
tuali errori al momento della loro importazione in ConCreTo;
• Ampliamento e miglioramento della suite di test esistente;
• Refactoring e ottimizzazione di alcune classi dell’applicazione;
25

Bibliograﬁa
[1] Kent Beck. Extreme Programming Explained: Embrace Change. Addison-
Wesley, 1999.
[2] T. Bray. The JavaScript Object Notation (JSON) Data Interchange
Format. RFC, RFC Editor.
[3] The Apache Software Foundation. Apache POI - Javadocs. https://
poi.apache.org/apidocs/index.html.
[4] Nicolai Josuttis. eXtreme Programming An interview with Kent Beck.
[5] Oracle. Java Platform Standard Edition 8 Documentation. https://
docs.oracle.com/javase/8/docs/.
[6] The Git Project. Git documentation - Reference. https://git-scm.
com/docs.
[7] Ben Straub Scott Chacon. Pro Git. 2nd edition, 2014.
[8] Jetbrains s.r.o. IntelliJ IDEA - Documentation. https://www.
jetbrains.com/idea/documentation/.
26

Ringraziamenti
Ad Alice, compagna di vita e di avventure.
Alla mia famiglia, Alvaro, Denise ed Ugo.
Ai miei nonni, Onorina, Millo, Eleonora ed Olinto.
Ai miei tre moschettieri, Federico, Marco e Moreno.
Ad Andrea e Bruno.
A Stoyan ed Elena.
A Patrick e Kate.
A Christopher e Rebecca.
A Marco, Elettra, Francesco ed Hervé.
Alla ﬁsica e ai ﬁsici, in particolare Matteo, Giacomo e Marco.
All’arrampicata e agli arrampicatori, in particolare Flavio, Diego, Erica e
Tommaso.
Grazie

Generazione automatica diagrammi di rete con template pptx

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to Generazione automatica diagrammi di rete con template pptx

Similar to Generazione automatica diagrammi di rete con template pptx (20)

Generazione automatica diagrammi di rete con template pptx