Carraro Filippo Tesi

UNIVERSITÀ DEGLI STUDI DI PADOVA
Facoltà Di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea Triennale in Informatica
Creazione Di Un Componente
Per La Visualizzazione Di PDF
Relatore: Laureando:
Dott. Silvia Crafa Filippo Carraro
Anno Accademico 2009/2010

Alla mia Famiglia e a Floriana
Pagina 2 di 60
Sommario
1 Introduzione ....................................................................................................................................... 6
1.1 ASI S.r.l ...................................................................................................................................... 7
2 Descrizione del prodotto ................................................................................................................... 9
2.1 Contesto d’uso del prodotto ...................................................................................................... 9
2.1.1 Plain® Portal ...................................................................................................................... 9
2.1.2 Plain® Documentale ........................................................................................................ 10
2.2 Obiettivo del prodotto .............................................................................................................. 12
3 Strumenti utilizzati .......................................................................................................................... 13
3.1 Tecnologie, linguaggi, software di sviluppo .......................................................................... 13
3.1.1 .NET Framework .............................................................................................................. 13
3.1.2 C# ...................................................................................................................................... 15
3.1.3 WPF .................................................................................................................................. 16
3.1.4 Visual Studio Team System 2008 ................................................................................... 18
3.1.5 Microsoft SQL Server ...................................................................................................... 19
3.2 Software per la documentazione ............................................................................................. 19
3.2.1 Microsoft Word 2003 ...................................................................................................... 19
3.2.2 Microsoft Visio................................................................................................................. 19
3.2.3 Poseidon per UML ........................................................................................................... 19
4 Analisi .............................................................................................................................................. 20
4.1 Studio delle tecnologie ............................................................................................................ 20
4.2 Situazione iniziale e studio del dominio................................................................................. 20
4.3 Descrizione generale ................................................................................................................ 21
4.3.1 Premessa ........................................................................................................................... 21
4.3.2 Contesto d’uso .................................................................................................................. 21
4.3.3 Caratteristiche degli utenti ............................................................................................... 21
Pagina 3 di 60
4.3.4 Casi d'uso .......................................................................................................................... 22
4.4 Requisiti .................................................................................................................................... 26
4.4.1 Vincoli generali ................................................................................................................ 28
4.4.2 Assunzioni e dipendenze ................................................................................................. 28
4.4.3 Attributi di prodotto ......................................................................................................... 28
4.4.4 Attributi di processo ......................................................................................................... 30
5 Progettazione e sviluppo ................................................................................................................. 32
5.1 Modello di ciclo di vita adottato ............................................................................................. 32
5.1.1 Il modello evolutivo ......................................................................................................... 32
5.2 Analisi degli strumenti e delle librerie ................................................................................... 33
5.2.1 Strumenti e librerie realmente utilizzati alla fine del progetto ...................................... 33
5.2.2 Strumenti e librerie che si sono rivelati inadeguati ........................................................ 38
5.3 Sviluppo interfaccia grafica per Plain.File.Extraction. ......................................................... 41
5.3.1 Progettazione .................................................................................................................... 42
5.4 Sviluppo Plain.PDFViewer ..................................................................................................... 46
5.4.1 Progettazione .................................................................................................................... 46
6 Verifica e validazione...................................................................................................................... 52
6.1 Strumenti, tecniche, metodi adottati ....................................................................................... 52
6.2 Analisi statica ........................................................................................................................... 53
6.3 Analisi dinamica ...................................................................................................................... 53
6.4 Risultati dei test........................................................................................................................ 53
7 Conclusioni ...................................................................................................................................... 55
7.1 Pianificazione iniziale e finale ................................................................................................ 55
7.1.1 Fasi del progetto ............................................................................................................... 55
7.1.2 Preventivo ore ................................................................................................................... 56
Pagina 4 di 60
7.1.3 Requisiti soddisfatti.......................................................................................................... 57
7.1.4 Consuntivo ore ................................................................................................................. 57
7.2 Conoscenze acquisite grazie al progetto................................................................................. 57
7.3 Considerazioni sull’esperienza lavorativa .............................................................................. 58
7.4 Obiettivi raggiunti .................................................................................................................... 60
Pagina 5 di 60
1 Introduzione
Questo documento descrive il lavoro svolto durante la mia attività di stage presso la ASI S.r.l. nel
periodo che va da lunedì 28 Settembre 2009 a venerdì 20 Novembre 2009.
Sono venuto a conoscenza di questa opportunità di stage grazie al documento rilasciato ogni anno
durante l’incontro Stage-It 2009, un evento organizzato dall'Università degli Studi di Padova e dalla
Camera di Commercio di Padova, pensato come luogo d'incontro tra le aziende e gli studenti. In
questo documento sono raccolte le informazioni sulle aziende partecipanti all’evento e i progetti
disponibili per l’inizio di uno stage.
Al mio primo colloquio alla ASI mi sono stati illustrati tutti i progetti che l’azienda proponeva, le
aspettative e le varie priorità.
Tra i progetti proposti c’erano:
1. Riconoscimento posizionale di testo all’interno di un PDF

2. Creazione di un componente per la visualizzazione di PDF
Il progetto da me scelto, il secondo della lista, consisteva nella creazione di un nuovo componente
in grado di visualizzare un file PDF a cui erano associati degli attributi generici e specifici residenti
nel database aziendale.
Parallelamente al mio stage è stato avviato anche l’altro progetto (il primo della lista), sul
riconoscimento posizionale di testo, affidato ad un mio collega. Entrambi i moduli avrebbero
dovuto integrarsi in un software già utilizzato in azienda, chiamato plain® documentale.
I due prodotti erano all’inizio abbastanza distinti ma dopo una prima analisi, l’azienda ha pensato
che era più sensato, visto che i progetti crescevano in parallelo, fornire un’ unica interfaccia grafica
per entrambi i prodotti, sviluppando un unico visualizzatore, a cui poi sarebbe stato integrato il
modulo per la mappatura dei PDF relativo al progetto del mio collega.
Questo nuovo requisito ha portato ad una seconda analisi del problema , allo studio di nuove librerie
e progetti e logicamente a del dispendio di tempo.
La dinamicità delle richieste e l’introduzione di altri due requisiti nella fase finale del progetto ha
portato a fare una scelta: dividere il visualizzatore in due prodotti, uno che permettesse di
Pagina 6 di 60
soddisfare le ultime richieste dell’azienda e l’altro utilizzato come interfaccia grafica per la
mappatura . I requisiti infatti non potevano essere più soddisfatti dallo stesso visualizzatore.
Il fatto di dover sviluppare due prodotti distinti nell’ ultima fase dello stage ha portato ad un
maggiore carico di lavoro rispetto a quanto previsto, sottraendo qualche ora alla fase di
documentazione finale, recuperate poi fuori piano.
Nonostante tutte le problematiche avute durante lo stage, gli obiettivi principali e secondari sono
stati tutti raggiunti. I due moduli sono stati completati e integrati senza problemi nel software
sviluppato in azienda.
Nei prossimi capitoli verranno esposti più in dettaglio gli aspetti rilevanti, i problemi incontrati
durante il percorso e gli aspetti tecnici legati allo sviluppo del prodotto.
1.1 ASI S.r.l
ASI S.r.l. inizia la propria attività nel 1989 e ad oggi conta circa cinquanta dipendenti. I settori
d’impresa a cui si rivolge sono:
- Carta e cancelleria
- Giocattoli e articoli da regalo
- Noleggio,vendita macchine per ufficio
- Ricambi, ferramente e utensileria
- Stampaggio materie plastiche
È specializzata nella progettazione e sviluppo di software industrializzato:
- ERP per aziende manifatturiere e commerciali

- Gestione delle presenze - HR
- e-Commerce e integrazione rete di vendita
- Portali aziendali
- Gestione documentale
- Sincronizzazione di DB
- Soluzioni di reportistica web
Offre inoltre assistenza e consulenza software, servizi internet a valore aggiunto e servizi di
networking.
È partner IBM, Microsoft, Oracle-Hyperion e Juniper.

Pagina 7 di 60
Le linee guida dell’azienda sono:
- Risorse dedicate alla ricerca

- Sviluppo di prodotti industrializzati
- Integrazione tra i prodotti proprietari
- Integrazione con prodotti non proprietari
- Innovazioni sui prodotti e sul modo di proporli
- Orientamento deciso sulle tecnologie web
Pagina 8 di 60
2 Descrizione del prodotto
Questo secondo capitolo introduce il lettore al software prodotto durante il periodo di stage. Ne
vengono descritte le caratteristiche generali, il contesto d’uso e le funzionalità principali. Nei
capitoli successivi, invece, si condurrà il lettore più in dettaglio attraverso le fasi di analisi,
progettazione e realizzazione del software.
2.1 Contesto d’uso del prodotto
Nei prossimi due sottoparagrafi vengono fornite alcune informazioni utili a meglio comprendere il
contesto in cui la mia applicazione va a collocarsi. Nello specifico il mio componente va ad
estendere plain® documentale con la nuova funzionalità di visualizzazione PDF, lettura e modifica
degli attributi e delle proprietà ad esso associati.
plain® portal è invece il modulo che contiene il portale aziendale e il Web Service che verrà
largamente utilizzato dal mio componente. Gran parte dei metodi utili al funzionamento di
quest’ultimo, per esempio l’autenticazione e la possibilità di utilizzo del database aziendale, sono
accessibili solo dopo essersi autenticati al portale.
2.1.1 Plain® Portal
plain® portal è il modulo della Suite Plain che permette di realizzare portali aziendali con
semplicità e in autonomia. Consente oltre ad avere un sito sempre aggiornato in tempo reale anche
di creare home page differenziate a seconda degli utilizzatori, siano clienti o dipendenti,di
aggiornare in tutta autonomia i contenuti grafici e testuali del Portale, raggiungere velocemente
documenti necessari alla vendita di un prodotto e accedere all’area di Commercio elettronico
intervenendo sui dati: permette quindi di avere un portale flessibile e accessibile. La caratteristica
che lo diversifica da un comune pacchetto pensato “solo per fare siti”, è la predisposizione a
rivolgersi anche verso l’interno dell’azienda facilitando il dialogo tra persone della stessa struttura,
rendendo loro trasparente l’accesso alle diverse piattaforme tecnologiche su cui sono basate le
diverse applicazioni aziendali. L’azienda quindi adotta un unico strumento che ne garantisce la
produttività. Ogni utente avrà accesso immediato a tutte le risorse aziendali a cui ha diritto.
Vengono cosi semplificati al massimo tutti i processi di scambio, in modo da rendere più immediate
e corrette le decisioni.
Pagina 9 di 60
2.1.1.1 Caratteristiche funzionali
- Facilità di utilizzo: Il prodotto è dotato di un’interfaccia intuitiva che lo rende facilmente

installabile e configurabile. Semplice nella creazione delle pagine e nell’assegnazione delle
autorizzazioni all’utilizzo da parte degli amministratori.
- Sicurezza: Un motore gestisce le autorizzazioni per utenti/gruppi e account/ruoli. In tal
modo l’Azienda ha la garanzia che ognuno veda e faccia solo ciò che gli è stato permesso.
- Grande creatività: Tramite le pervasive funzioni di gestione dell’interfaccia grafica è
possibile plasmare l’immagine del portale secondo le proprie esigenze.
- Dinamicità: La facilità di utilizzo permette a utenti non particolarmente esperti di accedere
e modificare i contenuti delle varie sezioni, tenendo sempre costantemente vivi e aggiornati i
versanti del portale che danno all’interno o all’esterno dell’azienda.
- Integrazione: Dalle pagine di plain® portal è possibile raggiungere applicazioni esterne e
informazioni residenti su altri ambienti. Ciò semplifica qualsiasi processo di scambio
aumentando la produttività dell’azienda.
- Statistiche immediate: Il modulo extended data publisher permette di connettersi ai
database aziendali per creare report di analisi e statistiche. Il sistema può leggere i dati in
tempo reale oppure memorizzarli all’interno del proprio database. Gli utenti che accedono ai
report dispongono di filtri per effettuare analisi sui dati e, se autorizzati, possono estrarre le
informazioni per ulteriori elaborazioni nel proprio PC.
- Scalabilità: plain® portal è dotato di fondamenta stabili, in grado di sostenere grandi flussi
di informazioni e l’utilizzo da parte di un elevato numero di utenti.
- Elasticità: plain® portal dialoga naturalmente con tutti gli altri moduli della Suite Plain,
per un utilizzo semplice e trasparente, dalla gestione documentale al modulo HR, da parte di
tutti gli utenti.
2.1.2 Plain® Documentale
Permette di gestire il “patrimonio documentale” dell’azienda e si da come obiettivo finale quello di

non far perdere redditività per gestire la produzione e l’archiviazione dei propri documenti. In
termini pratici si tratta di un prodotto software, dotato di una interfaccia user friendly, il cui
obiettivo è quello di alleggerire il carico prodotto dall’archiviazione e gestione tradizionale dei
documenti, riducendo i tempi di lavoro e le perdite che ne conseguono. Garantisce facilità nella
ricerca, nella condivisione e nella trasmissione dei contenuti, navigabilità tra i documenti, sicurezza
Pagina 10 di 60
nell’accesso alle informazioni e unificazione dei diversi database documentali presenti in azienda.
Copre tutti i processi documentali:
- il ciclo attivo dei documenti prodotti dal sistema gestionale (dalla definizione del layout alla
stampa, all’archiviazione, alla trasmissione via fax o e-mail);
- il ciclo attivo dei documenti office;
- il ciclo attivo e passivo della posta elettronica;
- il ciclo attivo e passivo dei documenti trattati via fax automatico;
- il ciclo passivo dei documenti cartacei;
- il supporto della firma digitale e della conservazione sostitutiva a norma;
2.1.2.1 Caratteristiche funzionali
- Archiviazione globale: plain® documentale gestisce qualsiasi tipo di documento creando

un unico archivio di riferimento per tutti gli utenti aziendali.
- Facilità di accesso: Il motore di ricerca garantisce rapidità e accuratezza
nell’individuazione delle informazioni, mentre la navigazione per cartelle assicura la
fruibilità tipica dell’ambiente operativo aziendale.
- Usabilità senza limiti: L’interfaccia di cui è dotato l’applicativo alleggerisce il carico
prodotto dalla gestione tradizionale dei documenti, riducendo i tempi di lavoro.
- Navigazione intelligente: Il sistema gestisce i legami logici tra documenti diversi così da
permettere una maggiore navigabilità all’interno del database documentale.
- Sicurezza: Il motore di plain® documentale gestisce le autorizzazioni per utenti/gruppi e
account/ruoli. In tal modo gli amministratori hanno la garanzia che ogni utente vede e fa
solo ciò che gli è stato permesso. Per evitare che contenuti preziosi vengano corrotti o
perduti, specifiche funzioni di sicurezza proteggono sia i documenti che le cartelle alle quali
sono associati.
- Conversioni senza limiti: Permette di: analizzare il database documentale storico, segnalare
files doppi e incompatibilità, normalizzare i vecchi documenti e convertirli all’interno del
database, garantendo all’azienda di salvaguardare e di migliorare la fruibilità di tutto il
patrimonio documentale esistente.
- Scalabilità: L’architettura di plain® documentale lo rende capace di sostenere grandi
carichi di lavoro, permettendo l’accesso simultaneo ad una grande moltitudine di utenti.
Pagina 11 di 60
- Elasticità: plain® documentale dialoga naturalmente con tutti gli altri moduli della Suite
Plain, per un utilizzo semplice e trasparente, dal portale aziendale al modulo HR, da parte di
tutti gli utenti.
2.2 Obiettivo del prodotto
Come detto precedentemente il mio componente si colloca nell’ambito della gestione e

distribuzione informatizzata dei documenti all’interno dell’azienda grazie all’integrazione con il
software già sviluppato in azienda plain® documentale .
L’obiettivo era quello di sviluppare un nuovo componente in grado di visualizzare un file PDF a cui
sono associati degli attributi generici, chiamati anche proprietà (ad esempio: nome del file, numero
revisione, lingua) e degli attributi specifici, salvati nel database aziendale (ad esempio: numero
documento, data, mittente).
Non era richiesto di sviluppare il prodotto da zero, si potevano infatti utilizzare anche prodotti di
terze parti, o nel peggiore dei casi anche software o librerie a pagamento.
In sintesi gli obiettivi da raggiungere erano i seguenti:
- sviluppare il software adottando le tecnologie richieste dall’azienda, che vedremo meglio nel
prossimo capitolo “Strumenti Utilizzati” e le linee guida decise assieme al tutor aziendale.
- stendere l’analisi funzionale e tecnica, cioè produrre una buona documentazione sul lavoro
svolto, per permettere a chiunque di potersi integrare con semplicità e velocità nel progetto;
- produrre un componente utilizzabile senza ulteriori modifiche.
Pagina 12 di 60
3 Strumenti utilizzati
L’azienda ospitante ha messo a disposizione per lo svolgimento dell’attività di stage un ufficio con
due postazioni di lavoro. Una per me e una per il mio collega che seguiva il progetto parallelo e
con cui dovevo interagire e comunicare. Ogni postazione di lavoro era costituita da un personal
computer Intel Pentium 4 2,6Ghz con 2 Gb di Ram e installato il sistema operativo Windows XP
Professional Service Pack 3.
Per lo sviluppo del progetto erano stati imposti come requisiti obbligatori l’utilizzo dell’ ambiente
di sviluppo Microsoft Visual Studio Team System 2008 ed il linguaggio C#.
Oltre al framework .NET, un altro requisito obbligatorio, introdotto durante la fase finale di studio,
è stato quello di imparare a utilizzare WPF, la nuova libreria per interfacce grafiche di Visual
Studio al posto del precedente WinForm.
Questi requisiti permettono alla ASI di avere sempre un prodotto integrabile in altre applicazioni e
facilmente mantenibile da parte di altre persone diverse dallo stagista.
Di seguito si propone una descrizione di tutte le tecnologie principali adottate dall’azienda, mentre
le librerie utilizzate, o anche solo oggetto di studio durante il progetto, verranno introdotte nel
momento più adeguato.
3.1 Tecnologie, linguaggi, software di sviluppo
3.1.1 .NET Framework
.NET Framework è un ambiente multilinguaggio per la creazione, la distribuzione e l'esecuzione di

servizi Web XML e di altre applicazioni. È costituito da tre parti principali:
- Common Language Runtime Nonostante il nome, il runtime in realtà agisce sia nella fase
di esecuzione che nella fase di sviluppo di un componente. Durante l'esecuzione del
componente, il runtime è responsabile della gestione dell'allocazione di memoria, dell'avvio
e interruzione di thread e processi e dell'implementazione della politica di protezione,
nonché del rispetto di tutte le eventuali dipendenze tra il componente e gli altri. In fase di
sviluppo, il ruolo del runtime varia leggermente; dato l'elevato numero di automatismi che
implementa (ad esempio la gestione della memoria), semplifica notevolmente il compito
Pagina 13 di 60
dello sviluppatore, soprattutto se paragonato al modello COM attualmente in uso. In
particolare, vi sono alcune caratteristiche, come la reflection, che riducono drasticamente la
quantità di codice che lo sviluppatore deve scrivere per trasformare la logica business in un
componente riutilizzabile.
- Classi di programmazione unificate Il framework offre agli sviluppatori un insieme

unificato di librerie di classi (API) estensibile, gerarchico e orientato ad oggetti.
Attualmente, gli sviluppatori C++ utilizzano le classi MFC (Microsoft Foundation Classes)
e gli sviluppatori Java utilizzano le classi WFC (Windows Foundation Classes). Il
framework unisce questi modelli e consente l'accesso alle librerie di classi anche ai
programmatori in Visual Basic e JScript. Creando un insieme di API comune a tutti i
linguaggi di programmazione, il Common Language Runtime assicura l'ereditarietà, la
gestione degli errori e il debug multilinguaggio. Tutti i linguaggi di programmazione, da
JScript a C++, hanno accesso analogo al framework, lasciando agli sviluppatori la facoltà di
utilizzare il linguaggio che preferiscono.
- ASP.NET ASP.NET si basa sulle classi di programmazione di .NET framework e fornisce

un modello di applicazione Web con un insieme di controlli e un'infrastruttura ch e
semplificano la creazione di applicazioni Web ASP. Contiene inoltre un insieme di controlli
che integrano elementi comuni dell'interfaccia utente HTML, quali caselle di testo e menu a
discesa. Tali controlli, tuttavia, vengono eseguiti sul server Web e svolgono il push della
propria interfaccia come HTML sul browser. Sul server, i controlli espongono un modello di
programmazione orientato ad oggetti che consente agli sviluppatori Web di sfruttare tutte le
potenzialità della programmazione orientata ad oggetti. ASP.NET fornisce anche servizi di
infrastruttura, quali la gestione dello stato delle sessioni e il riciclo di processi, che riducono
ulteriormente la quantità di codice che lo sviluppatore deve scrivere, aumentando nel
contempo l'affidabilità dell'applicazione. ASP.NET utilizza questi stessi concetti per
consentire agli sviluppatori di distribuire software come servizio. Avvalendosi delle
funzionalità dei servizi Web XML, gli sviluppatori ASP.NET possono scrivere la logica
business e utilizzare l'infrastruttura ASP.NET per distribuire tale servizio tramite SOAP. Per
ulteriori informazioni, vedere Soap CommunityLinks.
Pagina 14 di 60
3.1.2 C#
C# (si pronuncia C sharp) è un linguaggio di programmazione object-oriented sviluppato da

Microsoft all’interno dell’iniziativa .NET, e successivamente approvato come standard ECMA. C#
è uno dei pochi linguaggi di programmazione che può essere definito completamente orientato agli
oggetti. La sintassi prende spunto da quella del C++ e da quella di Java, e da Visual Basic per gli
strumenti di programmazione visuale e per la sua semplicità (meno simbolismo rispetto a C++,
meno elementi decorativi rispetto a Java).
C# è, in un certo senso, il linguaggio che meglio degli altri descrive le linee guida sulle quali ogni
programma .NET gira; questo linguaggio è stato infatti creato da Microsoft specificamente per la
programmazione nel Framework .NET. I suoi tipi di dati primitivi hanno una corrispondenza
univoca con i tipi .NET e molte delle sue astrazioni, come classi, interfacce, delegati ed eccezioni,
espongono esplicitamente caratteristiche proprie del .NET framework. In confronto al C++ il
linguaggio ha subito una serie di modifiche volte principalmente ad evitare quegli errori tipici della
programmazione C:
- i puntatori possono essere utilizzati solo in particolari blocchi di codice marcati come
“unsafe”
- in molte operazioni aritmetiche vengono controllati eventuali “overflow”
- gli oggetti dinamici non vengono deallocati esplicitamente; la loro rimozione viene gestita
automaticamente (implicitamente) dal garbage collector quando non esistono più riferimenti
a tali oggetti. Questa gestione evita i due problemi ben noti dei dangling pointer e del
memory leak
- come in Java, è possibile ereditare da una sola classe (diversamente da come avviene in
C++) ma è possibile implementare un numero indefinito di interfacce
- le sole conversioni implicite che sono consentite sono quelle “safe”, ovvero che non
espongono al rischio di perdita di dati causata dalla diversa tipologia di dato. Ad esempio
non sono consentite conversioni implicite fra int e bool o fra enumerati ed int
- C# non possiede i templates (tipici del C++) ma nella versione 2.0 sono stati introdotti i
generics
- Sebbene C# sia ritenuto simile a Java, una risposta commerciale alla Sun Micro-system,
esistono alcune importanti differenze fra i due linguaggi:
- Java non gestisce le proprietà di una classe
- Java non permette il sovraccarico (overload) degli operatori
Pagina 15 di 60
- Java non permette blocchi di codice “unsafe” che consentono di gestire i puntatori
- Java utilizza i commenti Javadoc-sintax per generare la documentazione dal codice sorgente,
mentre C# utilizza la sintassi XML nei commenti per lo stesso scopo
- C# supporta gli indicizzatori ed i delegati
- C# supporta le strutture; blocchi di memoria che non derivano dalla classe object e che sono
memorizzati nello stack (value-type)
Come Java ha i suoi package anche nel C# possiamo ritrovare una serie di classi già sviluppate per
l’interazione con i vari ambienti, Front End, Database, XML e altri. Questo è il .NET framework,
del quale utilizza una serie di librerie di classi che gli permettono l’accesso alle funzionalità del
sistema. In C# quello che in Java è chiamato package viene chiamato namespace o “spazi di nomi”.
Le classi sono organizzate all’interno di una serie di namespaces che le raggruppano per
funzionalità simili; ad esempio System.Windows.Forms per la gestione delle finestre di tipo
“Forms”, System.Xml per l’elaborazione di XML e System.Data per l’accesso alle basi dati. Un
ulteriore livello di organizzazione è costituito dagli “assembly”. Un assembly può essere un singolo
file od una serie di files linkati fra di loro. Un assembly può avere al suo interno diversi spazi di
nomi. Microsoft ha sottoposto C# ad ECMA (European Computer Manufacturers Association) per
una standardizzazione formale. Nel Dicembre del 2001 ECMA ha rilasciato “ECMA-334 C#
Language Specification”. C# è diventato uno standard ISO nel 2003 (ISO/IEC 23270). Esistono
implementazioni indipendenti di .NET e del C#, fra cui il progetto Mono di Ximian e dotGNU &
Portable .NET della Free Software Foundation. Recentemente Microsoft ha introdotto, nella
versione 2.0 del framework, i generics, le partial-class ed altre nuove funzionalità. È stata proposta
la standardizzazione ECMA/ISO anche per queste funzionalità, ma allo stato attuale non fanno parte
della definizione standard del linguaggio.
3.1.3 WPF
Windows Presentation Foundation (o WPF), nome in codice Avalon, è una libreria di classi
del Framework .NET proprietarie Microsoft (introdotta con la versione 3.0) per lo sviluppo dell'
interfaccia grafica delle applicazioni in ambienti Windows.
L'innovazione principale di WPF è la rimozione di ogni legame con il modello di sviluppo

tradizionale di Windows, introdotto con la versione 1.0 del sistema operativo. Tutti i controlli sono
stati riscritti (non si appoggiano più a quelli della libreria “user”) e lo stesso meccanismo basato su
scambio di messaggi, cuore del modello di programmazione di Windows, è stato abbandonato.
Pagina 16 di 60
WPF è basato su un sistema di grafica vettoriale che si appoggia alle DirectX per sfruttare
l'accelerazione hardware delle moderne schede grafiche. WPF può essere impiegato per realizzare
applicativi eseguibili anche all'interno del browser Microsoft Internet Explorer o di altri browser
avanzati, purché sia presente il Framework. Il linguaggio usato per la creazione di una interfaccia
utente in WPF è l'XAML (eXtensible Application Markup Language), basato su XML.
3.1.3.1 Architettura
L'architettura di Windows Presentation Foundation si basa sia su codice gestito che su codice
nativo. Comunque, le API pubbliche esposte sono disponibili soltanto come codice gestito. Mentre
la maggior parte di WPF è in codice gestito, il motore di composizione che renderizza le
applicazioni WPF è un componente nativo. Il suo nome è Media Integration Layer (MIL) e risiede
in "milcore.dll". Esso si interfaccia direttamente con DirectX e provvede al supporto di base per le
superfici 2D e 3D, effettua la manipolazione controllata nel tempo dei contenuti di u na superficie
con una vista per esporre animazioni costruite ad alto livello, esegue la composizione degli elementi
individuali di una applicazione WPF nella scena finale 3D che rappresenta la UI dell'applicazione e
quindi si incarica di renderizzarla sullo schermo. I media codec sono anche implementati come
codice non gestito, e sono forniti da "windowscodecs.dll". Nella parte di codice gestito abbiamo il
PresentationCore ("presentationcore.dll") che fornisce un wrapper per MIL e implementa il cuore
dei servizi per WPF e il PresentationFramework ("presentationframework.dll") che implementa le
novità incluse layouts, time-dependent, story-board based animations e data binding.
Tutte le applicazioni WPF sono composte da 2 threads: il thread per gestire la UI e l'altro thread
detto render thread che in maniera nascosta gestisce le funzioni di rendering e repainting. Perciò
rendering e repainting sono gestite da WPF stesso, senza intervento dello sviluppatore. Il thread per
la UI ospita il Dispatcher (attraverso un'istanza dell'oggetto DispatcherObject), il quale mantiene
Pagina 17 di 60
una coda di operazioni che necessitano di essere eseguite sulla UI (come un albero fatto di oggetti
Visual, detto albero visuale) ordinate per priorità. Gli eventi della UI, compreso il cambiamento di
una proprietà che riguarda il layout, ed eventi causati dall'interazione dell'utente sono accodati nel
dispatcher, il quale invoca i gestori degli eventi. Microsoft raccomanda che i gestori degli eventi
solo aggiornino le proprietà per riflettere il nuovo contenuto come risposta; il nuovo contenuto sarà
generato o recuperato dal render thread.
Il render thread prende una copia dell'albero visuale e lo attraversa calcolando quali componenti
saranno visibili e renderizzandoli come superfici Direct3D. Inoltre, all’inizio salva in una cache
l'albero visuale, così che solo i cambiamenti all'albero devono essere comunicati, e , perciò, soltanto
i pixel cambiati risulteranno aggiornati. WPF supporta un modello di layout estendibile. Il layout è
diviso in due fasi che svolgono le funzioni di misurare ed adattare. Nella fase di misura vengono
chiamati ricorsivamente tutti gli elementi e determinato lo spazio che essi prendono. Nella fase di
adattamento, gli elementi figli vengono ricorsivamente sistemati nello spazio dei loro genitori,
invocando l'algoritmo di layout del modulo in uso.
3.1.4 Visual Studio Team System 2008
Visual Studio rappresenta un insieme completo di strumenti per la compilazione di applicazioni

Web aziendali per la produttività individuale e per il lavoro di gruppo. Oltre che per la
compilazione di applicazioni desktop ad alte prestazioni, è possibile utilizzare i potenti strumenti di
sviluppo basati su componenti e le altre tecnologie di Visual Studio per semplificare la
progettazione, lo sviluppo e la distribuzione orientati ai team di soluzioni aziendali.
Più in particolare si tratta di un insieme completo di strumenti di sviluppo per la compilazione di

applicazioni Web ASP.NET, Servizi Web XML, applicazioni desktop e applicazioni per dispositivi
mobili. Visual Basic, Visual C# e Visual C++ utilizzano lo stesso ambiente di sviluppo integrato
(IDE) che consente di condividere lo strumento e semplifica le creazione di soluzioni con
linguaggio misto. Questi linguaggi sfruttano inoltre le funzionalità di .NET framework, che fornisce
l'accesso a tecnologie chiave in grado di semplificare lo sviluppo di applicazioni Web ASP e Servizi
Web XML.
Microsoft Visual Studio Team System 2008 è una delle versioni disponibili oltre alla express e alla
professional, ed è la soluzione per la gestione del ciclo di vita delle applicazioni (ALM, Application
Lifecycle Management) composta da strumenti, processi e procedure che consentono ai membri del
Pagina 18 di 60
team di migliorare le proprie competenze e di collaborare più efficacemente. Visual Studio Team
System consente ai membri del team di:
- Collaborare e comunicare con maggiore efficienza con altri membri del team e i soggetti
interessati al settore commerciale.
- Garantire qualità del software tramite strumenti di qualità avanzati in ogni fase del ciclo di vita
dell'applicazione.
- Acquisire visibilità nell'attività e nelle priorità del progetto per prendere decisioni consapevoli
in base ai dati e in tempo reale.
3.1.5 Microsoft SQL Server
Microsoft SQL Server è un DBMS relazionale prodotto da Microsoft, meglio noto Relational
Database Management System (RDBMS). Nelle prime versioni era utilizzato per basi dati medio-
piccole, ma a partire dalla versione 2000 è stato utilizzato anche per la gestione di basi dati di
grandi dimensioni. Microsoft SQL Server usa una variante del linguaggio SQL standard (lo
standard ISO certificato nel 1992) chiamata T-SQL Transact-SQL. Sia Microsoft SQL Server che
Sybase Adaptive Server Enterprise comunicano sulla rete utilizzando un protocollo a livello di
applicazione chiamato "Tabular Data Stream" (TDS). SQL Server supporta anche "Open Database
Connectivity" (ODBC). Il servizio di SQL Server risponde per default sulla porta 1433.
3.2 Software per la documentazione
3.2.1 Microsoft Word 2003
Per le stesura dei documenti di analisi e specifica richiesti è stato utilizzato Microsoft Word 2003 e
il modello (.dot) di riferimento già adottato e standard all’ interno dell’ azienda.
3.2.2 Microsoft Visio
Microsoft Visio è un software per la creazione di grafici e diagrammi, sviluppato da Microsoft per
i sistemi operativi Windows e disponibile in diverse edizioni
(principalmente standard e professional) per la suite Office.
3.2.3 Poseidon per UML
Poseidon per UML è un tool commerciale, per la creazione di diagrammi UML e la generazione
automatica di codice in C++, Java, Idl, Php and Python.
Pagina 19 di 60
4 Analisi
4.1 Studio delle tecnologie
La prima fase dello stage è stata completamente dedicata allo studio delle tecnologie e degli
strumenti di sviluppo adottati in azienda. E’ stato necessario focalizzare l’attenzione più su alcune
cose e meno su altre, limitando il livello di approfondimento di alcuni strumenti che non ritenevo
utili al fine del raggiungimento del mio scopo.
Le scelte sono state fatte in base ai seguenti parametri:
- complessità di utilizzo: le tecnologie che richiedevano un’ apprendimento più approfondito

per la loro complessità di utilizzo hanno ricevuto priorità;
- somiglianza con strumenti già conosciuti: strumenti che avessero caratteristiche già
incontrate altrove, lasciavano il posto a quelle che invece risultavano completamente nuove;
- ipotesi sulla frequenza d’uso nel corso del progetto: in questo caso la priorità è stata data
agli strumenti che sarebbero stati ipoteticamente utilizzati con una certa regolarità e
frequenza nel corso di tutto lo stage;
È stato necessario iniziare lo studio di C# e delle differenze tra quest’ ultimo e i linguaggi C, C++ e
Java appresi nei corsi universitari. L’azienda ha fornito un corso a questo scopo e un documento di
codifica standard aziendale, al quale ho dovuto attenermi per la scrittura del codice e dei commenti.
Buona parte del tempo è stata utilizzata anche per prendere confidenza con la, per me nuova, IDE di
Visual Studio 2008.
Alla fine dello studio di C#, IDE e standard di codifica, mi sono dedicato alla creazione di alcuni
esempi di prova di interfacce grafiche in WinForm e successivamente WPF.
4.2 Situazione iniziale e studio del dominio
All’inizio del progetto mi è stato assicurato che la parte di estrazione dati, cioè ricavare le proprietà
del documento e i relativi attributi specifici dal database, attraverso il Web Service comune, sarebbe
stata una cosa abbastanza veloce da realizzare, in quanto già utilizzata per altri moduli presenti
all’interno dell’azienda. Al momento della costruzione di tale modulo ho avuto l’ appoggio da parte
del tutor che mi ha spiegato come accedere al portale, che funzioni usare per la fase di
Pagina 20 di 60
autenticazione e i metodi già in uso per estrarre i documenti e le informazioni ad esse relativi. In un
primo momento, quindi, mi sono dedicato completamente allo studio e alla ricerca di librerie o
progetti online in grado di aiutarmi nella progettazione del visualizzatore. A causa dei vari
cambiamenti di requisiti, sono state apportate varie modifiche al progetto iniziale, ma quest’ultime
verranno trattate maggiormente nel capitolo di analisi per evitare di ripetermi.
4.3 Descrizione generale
4.3.1 Premessa
Dopo la fase di studio sono stati fatti vari incontri per formalizzare le richieste del cliente,
identificando in modo univoco i requisiti richiesti, necessari alla fase di sviluppo relativamente alla
commessa. In questa analisi si riportano tutti i requisiti emersi nel corso dell’intero stage che, per
una maggiore comprensione delle varie scelte effettuate, verranno classificati anche in base alla fase
in cui sono stati introdotti.
4.3.2 Contesto d’uso
L’ applicazione verrà integrata in plain® documentale e sarà utilizzabile attraverso un qualsiasi

personal computer della rete aziendale.
4.3.3 Caratteristiche degli utenti
L’utente dell’applicazione sarà uno o più dipendenti dell’azienda. Avrà accesso solamente dopo
autenticazione al portale e ai soli documenti a cui è autorizzato.
Pagina 21 di 60
4.3.4 Casi d'uso
4.3.4.1 Generale
Nelle prossime tabelle si riportano, per ogni use case rilevato in fase di analisi, le seguenti
informazioni: gli attori coinvolti, lo scopo, il flusso di eventi, quali altri casi d’ uso include o
estende, le precondizioni e le postcondizioni.
Apri Documento Descrizione

Attori coinvolti L’utente che avvia l’applicazione, il Web Service e il DB
Aziendale
Pagina 22 di 60
Apri Documento Descrizione
Scopo e descrizione sintetica Recuperare il documento dal database aziendale, visualizzare il
PDF e le informazioni ad esso associate, cioè proprietà e attributi
e mostrare quali sono i documenti sui quali si sta lavorando
Flusso di eventi (scenario L’utente seleziona da menù il documento da aprire. Dopo la fase
base) d’ integrazione sarà plain® documentale a richiamare
correttamente il programma.
Include i seguenti casi d’uso Accedi al portale,Autentica Utente,Recupera
Documento,Visualizza file PDF,Visualizza Proprietà
Associate,Visualizza Attributi Associati,Visualizza Documenti in
Focus
È esteso dai seguenti casi -
d’uso
Precondizioni Il Web Service e il DB sono raggiungibili
Postcondizioni Il programma si è caricato, ha aperto un documento PDF e i
relativi attributi e proprietà e li mostra negli appositi pannelli
Accedi al Portale Descrizione

Attori coinvolti L’utente, il Web Service
Scopo e descrizione sintetica L’utente accede al Web Service per poter accedere ai servizi
Flusso di eventi (scenario Il programma accede al Web Service passandogli una url
base)
Include i seguenti casi d’uso Autentica Utente,Recupera Documento,Visualizza file
PDF,Visualizza Proprietà Associate,Visualizza Attributi
Associati,Visualizza Documenti in Focus
d’uso
Precondizioni L’applicazione è stata avviata e si conosce l’url del portale
Postcondizioni L’applicazione ha avuto accesso
Autentica Utente Descrizione

Attori coinvolti L’utente, il Web Service
Scopo e descrizione sintetica Ogni utente deve autenticarsi al portale come utente normale o
amministratore.
Flusso di eventi (scenario Il programma richiama un metodo di autenticazione utente dal
base) Web Service
Include i seguenti casi d’uso Autentica Utente,Recupera Documento,Visualizza file
PDF,Visualizza Proprietà Associate,Visualizza Attributi
Associati,Visualizza Documenti in Focus
d’uso
Precondizioni Nessuna autenticazione utente
Postcondizioni Utente autenticato e autorizzato a visualizzare un sottoinsieme di
documenti
Recupera Documento Descrizione

Attori coinvolti L’utente, il Web Service e il DB Aziendale
Pagina 23 di 60
Recupera Documento Descrizione
Scopo e descrizione sintetica Il programma estrae dal DB il documento selezionato,contenente
anche i dati associati.
Flusso di eventi (scenario Il programma richiama un metodo del Web Service per recuperare
base) il documento con un codice documento
Include i seguenti casi d’uso Visualizza file PDF,Visualizza Proprietà Associate,Visualizza
Attributi Associati,Visualizza Documenti in Focus
d’uso
Precondizioni Nessun documento è stato selezionato
Postcondizioni Un documento è pronto per essere visualizzato
Visualizza PDF Descrizione

Attori coinvolti L’utente
Scopo e descrizione sintetica Il programma estrae dal documento il file PDF associato e lo
mostra nel modulo di visualizzazione
Flusso di eventi (scenario base) Il programma richiama la funzione di visualizzazione PDF
passandogli il file PDF appena estratto
Include i seguenti casi d’uso -
d’uso
Precondizioni Un documento è stato estratto dal DB
Postcondizioni Il PDF relativo al documento è visibile nell’ apposito
visualizzatore
Visualizza Proprietà Descrizione

Associate
Scopo e descrizione sintetica Il programma estrae dal documento le relative proprietà associate
e le mostra nell’apposito modulo
Flusso di eventi (scenario base) Il programma richiama la funzione di visualizzazione proprietà
associate al documento
d’uso
Postcondizioni Le proprietà vengono visualizzate dal programma
Visualizza Attributi Associati Descrizione

Scopo e descrizione sintetica Il programma estrae dal documento gli attributi associati e li
mostra nell’apposito modulo
Flusso di eventi (scenario base) Il programma richiama la funzione di visualizzazione attributi
associati al documento
Pagina 24 di 60
Visualizza Attributi Associati Descrizione
d’uso
Postcondizioni Gli attributi vengono visualizzati dal programma
Visualizza Documenti in Descrizione

Focus
L’utente, il Web Service L’utente, il Web Service e il DB Aziendale
Scopo e descrizione sintetica Avere la lista dei documenti sui quali si sta lavorando in real time
Flusso di eventi (scenario base) Il programma richiama la funzionalità accessibile dal Web
Service
È esteso dai seguenti casi d’uso -
Postcondizioni Il programma mostra quali documenti sono attualmente utilizzati
Modifica Attributi Descrizione

Attori coinvolti L’utente, il Web Service e il DB Aziendale
Scopo e descrizione sintetica Il programma permette di modificare gli attributi del documento
aperto corrente e di farne automaticamente un salvataggio nel
database
Flusso di eventi (scenario base) L’utente seleziona l’attributo desiderato nella lista di attributi e ne
modifica il campo corrispondete
d’uso
Postcondizioni Il documento e il database vengono aggiornati con i nuovi
attributi
Carica/Salva Layout Descrizione

Interfaccia
Attori coinvolti L’utente,file XML
Scopo e descrizione sintetica Permettere all’utente di modificare la disposizione dei pannelli
all’interno dell’interfaccia.
Flusso di eventi (scenario base) L’utente richiama dal menù l’opzione desiderata per caricare o
salvare un file XML.
d’uso
Precondizioni La GUI si presenta con il layout di default
Postcondizioni La GUI si presenta con i pannelli disposti in un modo diverso da
quello di default o si sta salvando il layout di default su disco.
Esegui Mappatura Descrizione

Pagina 25 di 60
Esegui Mappatura Descrizione
Attori coinvolti L’utente, Plain.File.Extraction
Scopo e descrizione sintetica Il programma entra nella fase di mappatura per poter analizzare il
file PDF
Flusso di eventi (scenario Il programma blocca la visualizzazione del PDF e permette di
base) tracciare il rettangolo per la mappatura.
Include i seguenti casi d’uso Traccia Selezione
d’uso
Precondizioni Il programma è operativo
Postcondizioni Il programma entra nello stato detto di “mappatura”.
Traccia Selezione Descrizione

Attori coinvolti L’utente, Plain.File.Extraction
Scopo e descrizione sintetica Definire un area di PDF da analizzare.
Flusso di eventi (scenario L’utente definisce un’ area sul PDF, tracciando un rettangolo con
base) il mouse. Le informazioni relative all’area e alla posizione del
rettangolo vengono inviate al modulo Plain.File.Extraction per la
fase di analisi dell’area.
d’uso
Precondizioni Il programma è operativo e si è entrati nella fase di “mappatura”
Postcondizioni Il programma ha inviato le informazioni necessarie alla analisi e
ritorna nello stato pre-mappatura
4.4 Requisiti
In questa introduzione voglio spiegare come, a causa della forte variabilità dei requisiti, alla fine
dello stage si sia dovuto dividere il prodotto in due programmi distinti e con funzionalità diverse pur
di soddisfare tutte le richieste emerse durante il percorso.
Prima dello stage, nell’incontro del 3 Settembre, sono stati formalizzati i primi requisiti estratti dal
capitolato. A inizio stage dovevo quindi creare un visualizzatore di PDF con funzionalità simili a
quelle del ben noto Acrobat Reader e la possibilità di mostrare in un pannello laterale tutti i dati
(attributi specifici e generici) legati al file PDF che ad esso venivano associati e caricati nel
database aziendale. Era un prodotto che doveva essere integrato nel più ampio progetto aziendale
plain® documentale che gestisce l’intera rete di documenti in entrata e uscita dall’azienda.
Il progetto parallelo assegnato al mio collega, “Riconoscimento posizionale di testo all’interno di un

PDF”, era un progetto più sperimentale e che avrebbe richiesto, secondo il tutor aziendale, più
tempo per essere realizzato. Erano comunque progetti che sarebbero evoluti nello stesso periodo.
Pagina 26 di 60
Al secondo incontro, il 6 Ottobre, all’inizio della fase di Analisi, è stata fatta la scelta di creare un
unico visualizzatore per non duplicare inutilmente il lavoro. Le poche funzionalità legate all’
interfaccia grafica che dovevano essere implementate dal mio collega sono state date da fare a me
come requisiti opzionali. Al momento avevo iniziato a studiare l’ Acrobat Reader SDK e mi sono
ritrovato ad analizzare di nuovo il problema. Dovevo capire se le nuove richieste, per esempio il
tracciamento di un area sopra il PDF per la mappatura, erano implementabili con l’SDK di Abobe.
Alla fine di questa analisi ho capito che non era possibile. Ho quindi abbandonato lo studio di
Adobe per cercare altro. Dopo la ricerca di varie librerie e prodotti non utilizzabili per diversi
motivi, che descriverò meglio nella fase di sviluppo, ho trovato un progetto chiamato pdfviewer-
win32 liberamente scaricabile, costantemente in sviluppo, e che sfruttava motori di rendering noti
come XPDF e MuPDF. Mi sono dedicato completamente allo studio del progetto e a fare le prove
necessarie per vedere se soddisfaceva tutti i requisiti. L’analisi ha dato esito positivo. Il progetto
implementava già buona parte dei metodi richiesti. Dovevo studiarne la struttura per poterlo
integrare in una interfaccia grafica WPF e per implementare i nuovi metodi utili a fare le mappature
(tracciamento di rettangolo, e ricerca della posizione all’ interno della pagina).
Quando il prodotto era ormai stato progettato, si è tenuto un nuovo incontro (21 Ottobre) per
aggiornare il tutor. In questo incontro sono state espresse due nuove richieste, catalogate come
requisiti desiderabili:
- Apertura e riconoscimento di PDF/A

- Apertura e riconoscimento di PDF con firma digitale
A questo punto avevo già studiato entrambi i prodotti (Acrobat Reader SDK e pdfviewer-win32) e
sapevo abbastanza bene cosa poteva fare uno e l’altro.
Le nuove richieste venivano soddisfatte dall’SDK di Acrobat Reader, che avevo smesso di
implementare per i motivi precedentemente citati. Ho capito cosi, che tutti i requisiti non potevano
essere realizzati in un unico prodotto e ho deciso,di conseguenza, di dividere il lavoro e tornare
all’idea iniziale dei due visualizzatori. Sotto consenso del tutor aziendale, sono nati cosi i due
sottoprogetti:
- Plain.PDFViewer che sfrutta l’ActiveX dell’Acrobat Reader

- l’interfaccia per Plain.File.Extraction che invece sfrutta il visualizzatore open source
pdfviewer-win32.
Pagina 27 di 60
Una panoramica più tecnica di entrambi i progetti verrà data nel capitolo di progettazione e
sviluppo.
4.4.1 Vincoli generali
Seguono gli elementi che il fornitore ha individuato come vincolanti:
- Sviluppo del modulo d’ interfaccia grafica WPF per la visualizzazione dei PDF, degli
attributi generici e specifici.
- Integrazione con database preesistente.
- Comunicazione col database attraverso Web Service.
- Possibilità di aggiunta di pannelli legati a nuove funzionalità in modo semplice.
- L’ interfaccia grafica deve avere un layout a pannelli. Un pannello diverso per ogni modulo
sviluppato o integrato.
4.4.2 Assunzioni e dipendenze
Di seguito l’elenco delle dipendenze:
- Il progetto deve essere sviluppato con Visual Studio Team System 2008 come dettato dai
requisiti espressi dal committente.
- Il linguaggio di programmazione usato deve essere C# come dettato dai requisiti espressi dal
committente.
- Il database di appoggio deve essere Microsoft SQL Server come dettato dai requisiti espressi
dal committente.
4.4.3 Attributi di prodotto
Ogni requisito è identificato da un ID univoco e da una tipologia (vedi 1.3) che ne specifica
l'importanza. L'ID, inoltre, indica la dipendenza e il contesto di un requisito rispetto ad un altro
(esempio: il requisito x.y dipende dal requisito x; x.y.z dipende dal x.y).
Simbolo Descrizione
O Obbligatorio
D Desiderabile
F Facoltativo/Opzionale
Pagina 28 di 60
Gli O sono quelli che sono sviluppati in ogni caso, i D sono implementati al termine di tutti gli O in
caso sia rimasto del tempo, oppure prevedono funzionalità molto richieste mentre gli F sono quelli
opzionali che saranno inseriti solo al termine dei D.
Fonte Descrizione
Capitolato Con questa sigla si intendono i requisiti ricavati dal capitolato presentato a Stage-IT
Incontro 0 Con questa sigla si intendono i requisiti ricavati dall’incontro del 3 Settembre 2009,
volto ad approfondire il contenuto del capitolato presso l’azienda.
Incontro 1 Con questa sigla si intendono i requisiti ricavati dall’ incontro del 6 Ottobre 2009, volto
a definire maggiormente i requisiti dell’applicazione.
Incontro 2 Con questa sigla si intendono i requisiti aggiunti all’ incontro del 21 Ottobre 2009.
Implicito Con questa sigla si intendono quei requisiti definiti implicitamente e non ricavati da un
documento.
4.4.3.1 Requisiti funzionali (RF)
ID Tipo Descrizione Fonte

1 O Il programma deve permettere di aprire un documento tramite Web Incontro 0
Service dal Database aziendale.
1.1 O Il programma deve permettere di visualizzare un file PDF Capitolato
1.1.1 O Il visualizzatore deve mostrare il numero di pagina corrente all’interno Incontro 0
del PDF
1.1.2 O Il visualizzatore deve mostrare il numero totale di pagine del PDF Incontro 0
1.1.3 O Il visualizzatore deve permettere di scorrere le pagine avanti e indietro Incontro 0
1.1.4 O Il visualizzatore deve permettere di fare zoom in e zoom out sulla Incontro 0
pagina
1.1.5 D Il visualizzatore deve permettere una visualizzazione a una o più Incontro 0
pagine
1.1.6 D Il visualizzatore deve permettere di fare una ricerca di testo all’interno Incontro 0
del PDF
1.1.7 D Il visualizzatore deve permettere di adattare la pagina in altezza o Incontro 0
larghezza
1.1.8 F Il visualizzatore deve permettere la visione dei bookmarks all’interno Incontro 1
del documento in un pannello laterale
1.1.9 F Il visualizzatore deve permettere l’anteprima delle pagine in un Incontro 1
pannello laterale
1.1.10 D Il visualizzatore deve permettere il riconoscimento dell’apertura di un Incontro 2
PDF/A
1.1.11 D Il visualizzatore deve permettere l’apertura di PDF con firma digitale Incontro 2
1.2 O Il programma deve permettere di visualizzare gli attributi generici Capitolato
(proprietà) associate al file PDF
1.2.1 O Il programma deve creare un nuovo pannello contenente una lista delle Incontro 0
proprietà del documento in modo che siano facilmente accessibili
1.3 O Il programma deve permettere di visualizzare e modificare gli attributi Capitolato
specifici associati al file PDF
1.3.1 O Il programma deve richiamare un metodo su Web Service per ottenere Incontro 0
gli attributi
Pagina 29 di 60
1.3.2 O Il programma deve creare un nuovo pannello contenente una lista degli Incontro 0
attributi specifici del documento in modo che siano facilmente
accessibili
1.3.2.1 O Il programma deve permettere di accedere allo specifico attributo. Implicito
1.3.2.2 O Il programma deve permettere di modificare uno specifico attributo. Implicito
1.3.2.3 O Il programma deve permettere di salvare nel database l ’attributo Implicito
specifico modificato.
2 F Il programma deve permettere di eseguire una mappatura sul PDF Incontro 1
aperto
2.1 F Il programma dovrà avere un bottone per l’inizio mappatura Incontro 1
F Il visualizzatore dovrà permettere di tracciare un’ area sopra ad una Incontro 1
zona desiderata del PDF
2.1.1 F Il programma dovrà salvare i dati relativi all’area scelta (posizione Incontro 1
all’interno della specifica pagina)
2.2 F Il programma dovrà avere un tasto esegui mappatura che invia le Incontro 1
informazioni relative all’area da mappare al modulo esterno per la
successiva estrazione dati
2.3 F Il programma dovrà avere un pannello in cui verranno mostrati i Incontro 1
risultati relativi alla mappatura.
3 F Il programma dovrà permettere di visualizzare le relazioni tra i Incontro 2
documenti
3.1 F Il programma dovrà avere un pannello in cui verranno mostrate le Incontro 2
relazioni che intercorrono tra i vari documenti.
4.4.4 Attributi di processo
4.4.4.1 Requisiti di qualità (RQ)

1 O Il programma dovrà essere accompagnato da un manuale utente, che ne Capitolato
descriva l’installazione e l’utilizzo.
2 O Il programma dovrà essere accompagnato da un documento che formalizzi Capitolato
l’analisi funzionale
3 O Il programma dovrà essere accompagnato da un documento che formalizzi Capitolato
la specifica tecnica del programma stesso.
4.4.4.2 Requisiti d’interfacciamento (RI)

1 O Il programma dovrà interfacciarsi con il Web Service aziendale per Capitolato
recuperare il documento da aprire
2 O Il programma dovrà interfacciarsi con il database aziendale per ricavare gli Capitolato
attributi generici e specifici del documento aperto
Pagina 30 di 60
3 F Il programma dovrà interfacciarsi e integrare una componente esterna che Incontro 1
permetta la mappatura di PDF
4.4.4.3 Requisiti GUI (RG)

1 D La GUI deve essere il più possibile intuitiva Implicito
1.1 D La GUI deve avere un layout a pannelli. Un pannello diverso per ogni Capitolato
modulo sviluppato o integrato.
1.1.1 F La GUI deve avere un layout a pannelli dockable (stile Visual Studio) Incontro 1
1.2 D La GUI deve permettere il salvataggio del layout dei pannelli Capitolato
Pagina 31 di 60
5 Progettazione e sviluppo
5.1 Modello di ciclo di vita adottato
Il modello di ciclo di vita adottato per lo sviluppo del progetto è stato quello evolutivo. La scelta è
stata dettata essenzialmente dal fatto che l’azienda voleva un prototipo iniziale per farne una
valutazione e eventualmente apportare modifiche in fase di progettazione, come è effettivamente
avvenuto. Di conseguenza si è scelto un modello di ciclo di vita che permettesse il soddisfacimento
di nuove richieste e l’aggiunta incrementale di moduli non previsti in partenza.
5.1.1 Il modello evolutivo
Il modello evolutivo è uno dei modelli del ciclo di vita del software che cerca di superare i limiti
principali del modello a cascata. Si basa sulla creazione di un prototipo, cioè nell'uso di specifici
strumenti software per la realizzazione rapida di una versione semplificata del sistema informativo,
con la quale sperimentare le sue funzionalità. La verifica del prototipo può portare a una modifica
dei requisiti e una eventuale revisione del progetto.
Con il fallimento della prima versione software, infatti, occorre rifare buona parte dell’applicazione.
In tal modo conviene considerare la prima versione come un throw-away (un prototipo
"cestinabile") che è valido finché non fornisce al progettista un feed-back sufficiente. La versione
iniziale o prototipo viene utilizzata temporaneamente dopo di che viene cestinata e si procede a
produrre l'applicazione vera e propria. La seconda versione può essere sviluppata seguendo il
modello a cascata.
È un modello costituito, quindi, da poche fasi che si ripetono
- Costruisci qualcosa
- Consegnalo all’utente
- Ottieni delle valutazioni
- Modifica il progetto in funzione delle valutazioni
Questo approccio fornisce solo una soluzione parziale ai problemi del modello a cascata per cui
elimina gli errori nei requisiti ma non riduce la distanza temporale per il completamento del ciclo di
sviluppo.
Pagina 32 di 60
Per tale motivo, il modello evolutivo si è evoluto nel modello incrementale, perché alcune fasi
possono essere rimandate in modo da produrre comunque un insieme utile di funzionalità. In tal
modo si forniscono al cliente una serie di prototipi successivi e si integrano i feedback in maniera
incrementale. Questa fase viene detta modello di sviluppo e rilascio incrementale.
Il modello si può complicare ulteriormente per cui le fasi possono anche essere concorrenti, ad
esempio mentre si integra una versione, già si lavora sul design di quella successiva. I tempi si
riducono di parecchio ma i rischi sono tantissimi.
Il problema maggiore di questo modello è che si rischia di essere indisciplinati. È necessario far uso
di standard di processo e non perdere i punti migliori del modello a cascata. In tal modo scompare
la fase di manutenzione e si parla di evoluzione continua. A volte il modello throw-away si può
sostituire con un prototipo evolutivo che poco per volta si trasforma nell’applicazione finale. Il
modello, comunque è molto utile per verificare alcune componenti del software come le interfacce,
poichè si possono creare interfacce adatte all’utente e ben testate.
5.2 Analisi degli strumenti e delle librerie
5.2.1 Strumenti e librerie realmente utilizzati alla fine del progetto
5.2.1.1 Adobe Acrobat, Acrobat Reader e relativa SDK
5.2.1.1.1 Descrizione
Adobe Acrobat è un’ applicazione realizzata dalla Adobe Systems per creare e modificare
file Portable Document Format (PDF). Adobe Acrobat, in quanto prodotto dalla stessa società che
ha sviluppato lo standard PDF, è stato il primo programma in grado di lavorare su questo formato. È
un programma shareware disponibile in varie versioni e acquistabile dal sito del produttore.
Adobe Reader è un programma complementare ad Adobe Acrobat. È gratuito e liberamente

scaricabile dal sito web di Adobe. Reader permette agli utenti finali di aprire, consultare e stampare
(salvo restrizioni) i file PDF. Non permette però alcuna modifica del file.
Il formato PDF ha ottenuto nel 2008 la certificazione come standard internazionale. Pur restando
un formato proprietario, la Adobe ne ha reso pubblica la specifica. Sono nati in questo modo
software gratuiti, come ad esempio Foxit Reader, in grado non solo di leggere, ma di includere
Pagina 33 di 60
commenti nei documenti PDF. In precedenza invece, Adobe deteneva il brevetto del formato e tutti
i programmi per la modifica dovevano essere acquistati dalla casa madre.
L’ SDK di entrambi i prodotti, l’ insieme degli strumenti utili allo sviluppo di nuove applicazioni a
partire da essi, e la relativa documentazione, è disponibile in un unico pacchetto scaricabile da:
http://www.adobe.com/devnet/acrobat/?view=downloads
Adobe Acrobat supporta la comunicazione tra applicazioni grazie agli oggetti OLE su Windows.
Un oggetto OLE (Object Linking and Embedding) è una tecnologia per la creazione di “documenti
composti” sviluppata da Microsoft. L'applicazione ospite non ha la necessità di conoscere il formato
interno dell'oggetto inserito, perciò è possibile integrare un “documento” generato da una qualsiasi
applicazione in un'altra, a patto che entrambe supportino OLE.
Nel nostro caso questi oggetti permettono di vedere l’ Acrobat o l’ Acrobat Reader come il
“documento” in questione e la nostra applicazione come l’ applicazione ospite.
5.2.1.1.2 IAC (Acrobat Interapplication Communication)
Con IAC, un’applicazione esterna può controllare Acrobat o Acrobat Reader. Per esempio, è
possibile scrivere un’ applicazione che lancia Acrobat, apre uno specifico file, imposta le proprietà
di pagina e lo zoom. Si possono anche manipolare i file PDF, per esempio, cancellando pagine o
aggiungendo annotazioni e riferimenti.
Acrobat Reader mette a disposizione un oggetto chiamato AcroPDF che supporta l’automazione tra
oggetti OLE. AcroPDF sarà visto nel nostro progetto come un controllo ActiveX che fornisce
all’esterno tutti i metodi utili all’applicazione.
All’interno del pacchetto dell’ SDK sono presenti degli esempi in Visual C# per dimostrarne l’uso
all’interno di un progetto.
5.2.1.1.3 Uso all’interno del progetto
Il controllo ActiveX AcroPDF verrà integrato nel progetto Plain.PDFViewer come un nuovo
componente .NET. Questo nuovo componente verrà utilizzato poi in uno user control di tipo
WinForm. A sua volta l’interfaccia grafica WPF finale integrerà tale controllo in uno dei pannelli
dockable dell’applicazione.
Il componente AcroPDF permetterà, oltre a visualizzare i documenti nello stile Adobe Reader, di:
- Aprire PDF
Pagina 34 di 60
- Scegliere quale pagina mostrare
- Scegliere come mostrare il PDF, e lo zoom sulla pagina
- Mostrare o nascondere scrollbar, toolbar, il pannello con i bookmarks o le anteprime.
- Stampare pagine con varie opzioni
- Evidenziare una parte di testo
Tutte queste funzioni possono essere fatte da codice. Le altre funzioni tipiche del visualizzatore, per
esempio la ricerca di testo, sono accessibili solo tramite l’interfaccia grafica.
Nel paragrafo dedicato allo sviluppo di Plain.PDFViewer verrà mostrato più in dettaglio come sia
stato possibile integrare AcroPDF nel progetto.
5.2.1.2 Il progetto pdfviewer-win32 e la libreria PDFLibNet
Il progetto pdfviewer-win32 è nato dall’idea di creare un componente per fare l’anteprima di PDF
in C#. Si è poi trasformato in un visualizzatore di PDF vero e proprio che sfrutta la libreria
PDFLibNet di Xpdf.
Xpdf è un visualizzatore di PDF open source che include la possibilità di estrarre testo dal PDF e di
fare la conversione da PDF a PostScript. Entrambe queste funzioni sono state implementate anche
nel progetto pdfviewer-win32. Quest’ultimo supporta da pochissimo anche MuPDF come motore di
rendering (il motore di rendering di SumatraPDF) al posto di quello di Xpdf. È comunque un
progetto sempre in fase di aggiornamento e testing. Qui di seguito vengono riportati i link
indispensabili per comprendere meglio il progetto.
Pagina di riferimento su codeproject: http://www.codeproject.com/KB/files/xpdf_csharp.aspx
Codice sorgente: http://code.google.com/p/pdfviewer-win32/
Pdfviewer-win32 è stato utilizzato come visualizzatore di PDF per l’interfaccia grafica del progetto
Plain.File.Extraction. Un’ interfaccia grafica minimale, ma che permette di tracciare aree al di sopra
di una qualunque pagina del PDF, di sapere esattamente dove si trova il rettangolo tracciato
all’interno della pagina e quindi di avere le informazioni indispensabili per poter fare un
riconoscimento posizionale di testo all’interno del PDF.
Pagina 35 di 60
Nel paragrafo dedicato allo sviluppo dell’interfaccia per Plain.File.Extraction verrà mostrato più in
dettaglio come sia stato possibile integrare parte del visualizzatore Pdfviewer-win32 nel progetto e
quali siano state le problematiche di rilievo che si sono verificate durante lo sviluppo.
Nella prossima immagine viene mostrato il progetto Pdfviewer-win32 originale in esecuzione.
5.2.1.3 AvalonDock
AvalonDock è una libreria di controlli WPF che può essere utilizzata per creare un layout detto
“docking” come quello utilizzato da Visual Studio per le finestre. O per essere più chiari un layout a
pannelli trascinabili e ancorabili in varie zone dell’interfaccia. Supporta pannelli fly-out, finestre
floating, docking manager multipli nella stessa finestra, stili e temi, e può ospitare controlli
WinForm all’interno di un pannello.
Caratteristiche:
- Scritto completamente in C# e XAML

- A quasi ogni controllo si può cambiare lo stile
- Offre supporto per i controlli WinForm
Pagina 36 di 60
Il progetto di riferimento si trova qui, con la documentazione, e il codice sorgente corrispondente:
http://avalondock.codeplex.com/
Mentre alcuni tutorial sul suo funzionamento possono essere trovati qui: http://www.youdev.net/
L’immagine successiva mostra una demo del progetto AvalonDock in esecuzione.
Il capitolato richiedeva che l’interfaccia grafica del programma fosse strutturata ad aree di lavoro:
una per la visualizzazione del documento e una che riportava le informazioni relative al PDF aperto.
Il layout della finestra doveva essere configurabile dall’utente e salvato in un file di configurazione.
La libreria individuata, oltre a soddisfare tutti i requisiti richiesti, ha permesso di soddisfare anche il
successivo requisito opzionale di avere pannelli ancorabili in stile Visual Studio.
I requisiti soddisfatti dalla libreria sono : RG 1, RG1.1, RG 1.1.1, RG 1.2
Pagina 37 di 60
La documentazione di AvalonDock, autogenerata dal codice e scaricabile assieme allo stesso
sorgente e ad una demo, non è stata comunque sufficiente a comprenderne tutte le funzionalità. Ho
dovuto per questo leggermi molti dei post presenti nell’ area “discussion” online, dove vengono
riportati anche i bug eventualmente rilevati dagli utenti, prima di poterne apprendere appieno il
funzionamento. La GUI che era già stata scritta in XAML è stata completamente riscritta per
ospitare i nuovi controlli. Lo sforzo è stato premiato da un interfaccia molto più user friendly e
configurabile.
5.2.2 Strumenti e librerie che si sono rivelati inadeguati
In questa sezione discuterò le librerie che sono state studiate durante lo stage ma che, a causa dei
motivi che qui vi spiegherò, sono alla fine state scartate perché non soddisfano in parte o totalmente
i requisiti richiesti.
5.2.2.1 DocumentViewer di Visual Studio e i file XPS
5.2.2.1.1 Descrizione generale
DocumentViewer rappresenta un controllo per la visualizzazione di documenti incluso tra i controlli

standard di Visual Studio. Permette di visualizzare documenti FixedDocument e di tipo
FlowDocument. I FixedDocument sono quei documenti che hanno una paginazione fissa, scelta a
priori e pronti per la stampa. I FlowDocument ospitano invece un flusso di contenuti, paragrafi di
testo e immagini, che si adattano e scalano con la pagina, o su più pagine, per una migliore
visualizzazione dei contenuti.
DocumentViewer è stata la mia prima prova di realizzazione di un visualizzatore PDF all’interno

del progetto. Mi è stato consigliato il suo studio, all’ inizio dello stage, dal tutor aziendale,
principalmente per il fatto che presentava già controlli per lo zoom, stampa, ricerca e
visualizzazione a più pagine e perché veniva già utilizzato per altre applicazioni aziendali.
Prova fatta in modalita FixedDocument.
In questa modalità si possono visualizzare all’interno del controllo solamente i file di tipo XPS
(XML Paper Specification). I file di questo tipo non sono ancora largamente utilizzati e la
conversione da PDF a XPS a volte non avviene correttamente. Il motivo principale è che XPS non
ha una conoscenza completa della struttura dei file PDF. In particolare, quando il PDF usava l'
encoding WinAnsi (nel quale viene assegnato un codice arbitrario ad ogni carattere) non riusciva a
fare la mappatura dei caratteri e li trattava come immagini, riportando nel file XPS convertito una
Pagina 38 di 60
serie di tracciati vettoriali. Il file XPS visualizzato era molto simile al PDF originale ma
logicamente non era più possibile fare ricerca di testo all’interno della pagina come richiedeva il
requisito RF1.1.6.
Prova fatta in modalita FlowDocument.
Per escludere anche la modalità FlowDocument è stata fatta una prova in cui si spezzava il PDF in
immagini, una per pagina. Poi si inserivano le pagine cosi ottenute, all’interno del FlowDocument,
una per sezione. Il risultato finale era abbastanza scadente. Il testo all’interno di ogni pagina era
poco leggibile, non selezionabile, e quindi nemmeno riconoscibile tramite una eventuale ricerca.
5.2.2.1.2 Causa di cessazione studio
I motivi per i quali è stata abbandonata questa strada sono qui riassunti:
- La conversione da PDF a XPS non può essere fatta all’apertura di un PDF perché troppo
lenta e soprattutto perché non esiste ancora un modo per farla programmaticamente.
Bisognerebbe aprire il PDF con un qualsiasi visualizzatore e stampare il documento in XPS
tramite la stampante virtuale che viene installata ormai di default nelle nuove versioni di
Windows.
- Dopo la conversione, non si può essere certi di avere un pagina di testo searchable.
- I controlli di default non erano comunque sufficienti a soddisfare i soli requisiti obbligatori.
5.2.2.2 SumatraPDF
Sumatra PDF è un lettore PDF open source molto leggero. Ha solamente le funzionalità essenziali e
utilizza MuPDF come motore di rendering. È stato progettato per essere portable e occupare il
minor spazio possibile.
L’home page del prodotto è: http://blog.kowalczyk.info/software/sumatrapdf/index.html
Il codice sorgente e la documentazione sono raggiungibili attraverso questo link:
http://code.google.com/p/sumatrapdf/
Sono scaricabili sia i progetti in Visual Studio sia tutti i file sorgente del visualizzatore e del suo
motore di rendering MuPDF.
Pagina 39 di 60
Pensavo di poter estrarre il solo modulo di visualizzazione per metterlo in uno user control
WinForm che poi sarebbe stato integrato nell’interfaccia grafica WPF, ma la complessità del
codice, il fatto che non ci sia una documentazione se non i commenti all’interno del codice stesso e
che sia scritto in C al posto che in C# ha portato a tralasciarne lo studio. Non avrebbe comunque
potuto fornire successivamente tutte le funzionalità richieste dal committente.
5.2.2.3 Foxit Reader
Foxit Reader è un lettore di PDF freeware, molto leggero e veloce. La versione base è scaricabile
gratuitamente, mentre l’SDK e le altre versioni sono tutte a pagamento. Supporta i PDF Standard
1.7.
Le sue funzionalità sono:
- Leggero
- Tempi di avvio veloci, nessun splash screen
- Permette di disegnare forme, sottolineare testo, scrivere note e permette di salvare il PDF
con tali annotazioni.
- Permette di convertire il PDF in un file di testo
Offre una ricca documentazione.
L’home page del prodotto è la seguente: http://www.foxitsoftware.com/
L’SDK in diversi formati è disponibile qui: http://www.foxitsoftware.com/pdf/sdk/ActiveX/ ,

http://www.foxitsoftware.com/pdf/sdk/dll/
Foxit Reader offriva le caratteristiche necessarie al soddisfacimento di gran parte dei requisiti in un
unico prodotto.
I pro erano i seguenti:
- La possibilità di avere un interfaccia in stile Acrobat Reader, che permetteva di soddisfare la

maggior parte dei requisiti
- La possibilità di scelta tra ActiveX o DLL (Dynamic Link Library)
Pagina 40 di 60
- La buona documentazione (l’SDK contiene progetti,demo e una guida alla programmazione)
- La possibilità di disegnare forme geometriche, tra cui rettangoli, su di una pagina del PDF.
I contro per i quali non è stato scelto:
- L’SDK è a pagamento, anche per le funzioni base disponibili nella versione gratuita del
programma che sarebbero bastate a risolvere gran parte dei problemi
- Non riconosce PDF/A ma li visualizza correttamente
- Non riconosce PDF con firma digitale ma li visualizza correttamente
- Il programma permette di disegnare aree e forme, anche programmaticamente in punti
precisi della pagina, ma non è stato possibile ottenere la posizione del rettangolo all’interno
della pagina (cioè le coordinate dei due punti che descrivono un rettangolo).
5.3 Sviluppo interfaccia grafica per Plain.File.Extraction.
La fase di progettazione e sviluppo dell’interfaccia grafica minimale per Plain.File.Extraction ha

richiesto sicuramente più lavoro che sviluppare l’intero Plain.PDFViewer. Molte ore sono state
dedicate alla ricerca e allo studio di progetti o librerie che permettessero di tracciare un’ area sopra
ad una pagina del PDF e poterne ricavare la posizione nella pagina. Per quanto banali queste
operazioni possano sembrare, non erano disponibili in nessuna delle API provate. Bisognava
scendere più a basso livello e andare a modificare gli eventi per il mouse per quanto riguarda il
tracciamento del rettangolo, mentre, per trovare la posizione all’interno della pagina bisognava
trovare le coordinate in cui la pagina iniziava, la sua dimensione, e la distanza tra il punto O di
origine della pagina e A, punto di inizio tracciamento del rettangolo. Qui di seguito vengono
presentate le varie attività svolte e i problemi incontrati.
Pagina 41 di 60
5.3.1 Progettazione
Il sistema si compone principalmente di cinque componenti:
1) PdfViewer: Fa riferimento al progetto pdfviewer-win32 per la visualizzazione del PDF

2) PdfLibNet: Libreria Xpdf utilizzata dal progetto pdfviewer-win32
3) GUI: Interfaccia grafica minimale che permette di visualizzare il PDF e di tracciare l’area
per la successiva mappatura.
Pagina 42 di 60
4) Analyzer: Componente che permette di fare l’estrazione del testo data una certa area della
pagina da analizzare (Sviluppato dal mio collega, nel progetto parallelo
Plain.File.Extracion).
5) AvalonDock: libreria di controlli WPF utilizzata per creare il layout a pannelli ancorabili o
floating.
5.3.1.1 La componente PdfViewer
La componente principale del progetto, su cui ho lavorato di più, è sicuramente PdfViewer.

PdfViewer rappresenta il lavoro svolto per poter integrare il progetto pdfviewer-win32 (di cui ho
già parlato in precedenza nello studio delle librerie) nella componente GUI e per poter aggiungere
le nuove funzionalità richieste dal requisito RF2 e quelli ad esso legati.
Qui di seguito verranno spiegate in dettaglio solamente le classi a cui sono stati apportati dei seri
cambiamenti e le varie modifiche a cui sono state sottoposte.
Pagina 43 di 60
5.3.1.1.1 La classe PageViewer
La classe PageViewer rappresenta una specifica pagina all’interno di un PDF. Ogni pagina viene
renderizzata a partire da una certa posizione dello schermo. Uno dei problemi avuti all’inizio è stato
proprio quello di trovare tale posizione senza avere una documentazione o un minimo commento
nel codice. All’interno dei tanti metodi presenti all’interno della classe però c’erano:
- PointToScreen() : ritornava la distanza in pixel tra l’origine (0,0) dello schermo e il punto in
cui si trovava l’attuale controllo della finestra PageViewer.
- PointUserToPage() : ritornava la distanza in pixel tra il punto in cui iniziava il controllo
PageViewer e il punto in cui iniziava la pagina PDF.
Sommando le rispettive coordinate x e y dei punti è stato possibile ottenere la posizione dell’origine
della pagina. I metodi principali sono i seguenti:
- MapOnOff() : permette di bloccare la pagina e di evitare zoom e scrolling. Questo metodo

serve al corretto funzionamento della mappatura.
- DrawReversableRectangle() : permette di disegnare un rettangolo sopra la pagina del PDF in
cui ci si trova. Sfrutta anche gli eventi del mouse: OnMouseMove(), OnMouseDown(),
OnMouseUp() e OnMouseWheel() da me riscritti.
- GetA() : ritorna il punto in cui si inizia a tracciare il rettangolo per la mappatura. È relativo
alla pagina, cioè considera come origine il punto in cui inizia la pagina PDF.
- GetB() : ritorna il punto in cui si finisce di tracciare il rettangolo per la mappatura. È relativo
alla pagina, cioè considera come origine il punto in cui inizia la pagina PDF.
5.3.1.1.2 La classe frmPDFViewer
La classe frmPDFViewer rappresenta la classe principale di tutta la componente PdfViewer.

Rispetto alla classe originale sono stati fatti alcuni cambiamenti:
- La classe è stata trasformata in UserControl WinForm per poter essere cosi integrata nella
successiva interfaccia grafica WPF.
- Sono stati aggiunti i metodi pubblici: OpenPDF(), NextPage(), PreviousPage(), ZoomIn(),
ZoomOut(), PNumber(), PCount(), Map(), GetPageWidth(), GetPageHeight(), GetO(),
GetA(), GetB(). Tali metodi saranno utilizzati dalla componente Analyzer per l’estrazione di
testo.
Pagina 44 di 60
5.3.1.2 La componente GUI
Questa componente fornisce all’utente un’interfaccia minimale che gli consente di effettuare
operazioni di apertura PDF da disco, zoom sulla pagina, inizio/fine mappatura per il blocco della
pagina, l’inizio tracciamento dell’area e infine l’ EstraiTesto, che richiama il metodo
ExtractTextFrom() della classe PdfPage nella componente Analyzer.
Nella successiva immagine viene mostrato il programma in esecuzione. Il rettangolo nero

all’interno della pagina rappresenta l’area da mappare. Sulla destra, invece, c’è il pannello che
permette di estrarre il testo da tale area prescelta.
Come nel progetto PDFViewer, che sarà il prossimo argomento di questo capitolo, è stata utilizzata
la libreria AvalonDock per la visualizzazione a pannelli mobili e ancorabili. Sono pertanto
disponibili dal menù anche tutte le funzioni per caricare o salvare il layout dell’interfaccia.
Pagina 45 di 60
5.4 Sviluppo Plain.PDFViewer
5.4.1 Progettazione
Plain.PDFViewer è stato sviluppato per poter essere successivamente integrato in plain®

documentale. Per questo motivo ha facile accesso al Web Service aziendale e a tutti i metodi da
esso offerti per l’autenticazione degli utenti e l’accesso al database.
Plain.PDFViewer deve, come detto più volte, recuperare un documento dal database aziendale
tramite Web Service e solo dopo una prima fase di autenticazione, estrarre dal documento il file
PDF e visualizzarlo nel viewer (la componente qui chiamata ActiveX).
Dal documento appena recuperato è possibile anche estrarre immediatamente la lista di attributi
generici (Proprietà) e mostrarle nell’apposito pannello. Le proprietà di un documento sono: titolo,
numero di revisione, numero identificativo del documento e lingua. Per mostrare la lista degli
attributi specifici, invece, è stato necessario costruire due UserControl, uno per lo specifico
attributo, e uno per l’ intera lista e le modalità di selezione e modifica. Entrambi questi UserControl
usano una classe wrapper che incapsula, dato un documento, tutta la lista degli attributi e li rende
disponibili presso il Web Service.
La componente AvalonDock permette di utilizzare un’interfaccia a pannelli configurabili, dove ogni

layout potrà essere salvato o caricato a piacimento dal menù del programma.
Pagina 46 di 60
La componente Plain.Gui.References permette di avere sotto controllo l’albero di relazioni tra il
documento aperto e i possibili figli e padri. Nei prossimi paragrafi verranno esposte con più dettagli
e chiarezza le caratteristiche più importanti di ogni componente.
5.4.1.1 La componente Adobe
5.4.1.1.1 La classe AcrobatUC
La classe AcrobatUC, utilizzata come UserControl all’interno della componente Gui, è la classe che
fa da contenitore per l’ActiveX AcroPDF e quindi da visualizzatore di PDF all’interno del progetto.
Il primo problema del progetto è stato proprio cercare di integrare un ActiveX all’interno di una
applicazione WPF. Il solo esempio presente nell’SDK di Adobe Reader scritto in C# era stato
sviluppato in WinForm e quindi il passaggio da WinForm a WPF non era ancora chiaro. L’unico
modo per farlo è risultato quello di usare un componente WPF chiamato WindowsFormsHost. In
particolare è stata creata la classe AcrobatUC ed è stato aggiunto un nuovo riferimento all’oggetto
COM chiamato Adobe Acrobat Browser Document. Questo ha importato a sua volta un nuovo
componente .NET nel pannello contenitori presenti nella toolbox. Trascinando questo nuovo
contenitore nell’area di lavoro venivano automaticamente aggiunti i riferimenti AcroPDFLib e
axAcroPDFLib fondamentali per il funzionamento del visualizzatore.
Bisogna però specificare che il componente COM non è presente nel sistema se non dopo
l’installazione di Adobe Reader nel personal computer. Bisogna quindi avere installato questo
software per poter usufruire del nuovo programma.
Pagina 47 di 60
5.4.1.2 La componente Database
5.4.1.2.1 La classe PortalPlain
La classe PortalPlain rappresenta l’ interfaccia d’accesso al portale aziendale.
Contiene solamente il campo url e il costruttore che permette di riferirsi al portale aziendale dato
l’indirizzo web. PortalPlain viene costruito all’avvio dell’applicazione, prima di poter fare
l’autenticazione. Il campo url gli viene passato dall’esterno, cioè dal programma in cui andrà ad
integrarsi. Per la crittazione delle informazioni sensibili viene utilizzato l’algoritmo AES.
5.4.1.2.2 La classe UserPlain
La classe UserPlain rappresenta un utente che accede al sistema. Ogni utente è provvisto di un
codice identificativo, di un tipo (utente semplice o amministratore) e di una lingua.
Il seguente pezzo di codice mostra come un utente viene creato all’interno del sistema.
UserPlain user = new UserPlain(usernameAdmin,

passportAdmin.Autenticazione.TipoAmministratore, lang);
Un Passport è un oggetto che rappresenta una chiave di accesso a tutti gli applicativi windows del
portale aziendale. Permette di avere un ticket per l’autenticazione al portale aziendale.
Pagina 48 di 60
5.4.1.3 La componente DocumentAssignControl
5.4.1.3.1 La classe AttributeDocWrapper
La classe AttributeDocWrapper è la classe che rende disponibile, presso il Web Service, la

possibilità di estrarre uno specifico attributo di un documento o l’intera lista. Evita quindi difficili o
ripetitive operazioni sul database fornendo metodi più ad alto livello. Questa classe verrà utilizzata
dagli controlli utente AttributeControl e DocumentAssignControl.
5.4.1.3.2 La classe AttributeControl
La classe AttributeControl è l’UserControl che rappresenta uno specifico attributo all’interno della
lista degli attributi estratti. Utilizza la classe appena vista, AttributeDocWrapper, per recuperare le
Pagina 49 di 60
informazioni dal database. Soltanto alcuni utenti potranno modificare le informazioni di un
attributo, per altri viene mostrato il campo in sola lettura.
5.4.1.3.3 La classe DocumentAssignControl
La classe DocumentAssignControl rappresenta lo UserControl creato per la visualizzazione

dell’intera lista degli attributi specifici all’interno del progetto. Ha come campi, oltre al Portale e
all’utente correnti, un oggetto di tipo Document.
La classe Document è l’oggetto che rappresenta un documento all’ interno del sistema. Oltre ai
PDF, un documento può contenere oggetti quali fax, mail o altro. Questa classe contiene i campi:
Dimension, ElementTypeCode, Filename, IsNew, Language, ModuleTypeCode, Number, Revision
e Title. Il Documento sarà utilizzato per estrarre la lista degli attributi attraverso la classe
AttributeDocWrapper.
5.4.1.4 La componente Plain.Gui.References
Questa componente è stata aggiunta al progetto solo in una fase finale. Non è stata sviluppata da
me, in quanto era già presente in altre applicazioni all’interno dell’azienda. Si è rivelato utile
includere questo quarto modulo nel programma, per poter avere sempre sotto controllo le relazioni
che intercorrono tra i vari documenti. Infatti, un documento all’interno dell’ azienda può avere più
di un figlio e allo stesso tempo più di un padre. L’ inclusione del modulo non ha portato a nessun
ritardo grazie al fatto che il prodotto era stato sviluppato appunto per l’aggiunta di nuovi moduli nel
modo più flessibile possibile.
Pagina 50 di 60
Nella successiva immagine viene mostrato il programma in esecuzione. Nel pannello centrale è
presente il visualizzatore integrato che sfrutta l’ActiveX Adobe.
Sulla destra invece ci sono i tre pannelli con le informazioni riguardanti il file PDF aperto. Il primo
in alto a destra riguarda le proprietà o attributi generici del documento. Il pannello centrale è quello
che permette di visualizzare gli attributi specifici e di poterli modificare al volo. Il terzo pannello
sulla destra, come già detto, mostra le relazioni tra il documento aperto e quelli presenti all’interno
del database aziendale. La libreria AvalonDock permette, anche in questo caso, di avere pannelli
ancorabili e floating e di salvare da menù in un file xml tutte le informazioni sul layout corrente per
poi poterlo ripristinare in futuro.
Pagina 51 di 60
6 Verifica e validazione
In questo capitolo vengono illustrate le modalità di test e di validazione che sono state utilizzate per
garantire la qualità del prodotto realizzato durante il periodo di stage.
L’ inconveniente maggiore, che ha reso questa procedura più problematica è stato il cambiamento
dei requisiti in corso d’opera. Durante lo stage, come spiegato precedentemente nel capitolo di
analisi, sono stati aggiunti alcuni requisiti. Per tale ragione, si sono rivelate necessarie modifiche a
quanto già fatto per riadattarlo alle esigenze dell’azienda. Talvolta si sono dovuti riprogettare o
sviluppare dall’ inizio i nuovi moduli.
Un altro inconveniente non da sottovalutare è che le librerie e il codice prodotto da terze parti,
utilizzato e poi esteso o modificato, aveva pochi commenti e una scarsa documentazione. Di fatto
non si è potuto verificare se già quel codice era stato sottoposto a test o meno.
Questi due fattori hanno portato alla decisione di effettuare i test completi solamente alla fine della
codifica di un intero modulo del programma.
6.1 Strumenti, tecniche, metodi adottati
Si utilizzerà l’analisi statica, sotto forma di ispezioni del codice e dei documenti, al fine di
individuare errori e difetti negli stessi. Verrà inoltre utilizzata l’analisi dinamica del codice,
sottoforma di test, per soddisfare i requisiti quali funzionalità, affidabilità e usabilità del prodotto.
- Funzionalità: Il prodotto soddisferà pienamente i requisiti descritti nel precedente capitolo di

Analisi.
- Affidabilità: Il sistema sarà privo di errori in quanto la verifica verrà effettuata attraverso
opportuni strumenti di controllo (test e ispezioni).
- Usabilità: L’utente finale del sistema non dovrà necessariamente avere grandi competenze
nel campo informatico.
Validazione
La validazione dell’ intero sistema avverrà dopo l’integrazione di plain.PdfViewer a plain®

documentale. Verrà garantito in sede di collaudo il funzionamento corretto del software.
Pagina 52 di 60
6.2 Analisi statica
Verrà utilizzata durante la stesura del codice sorgente per rilevare errori, omissioni o anomalie, oltre
a incongruenze che possono sorgere tra il progetto ed i requisiti; sarà quindi applicata sulla struttura
delle varie componenti del sistema. Essa comprende le seguenti sottofasi:
- Analisi del flusso di controllo: Verificherà una corretta esecuzione del codice. In
particolare si controllerà che non vi siano statement irraggiungibili, ossia istruzioni la cui
condizione di accesso non può mai essere vera.
- Analisi dell’uso dei dati: Verificherà un corretto utilizzo delle variabili. In particolare si
controllerà che non vi siano variabili utilizzate prima di essere inizializzate, variabili
inutilizzate, variabili sempre vere o sempre false.
- Verifica formale del codice: Verificherà la correttezza del codice scritto. In particolare si
constaterà la correttezza totale di ogni unità, in modo che non conduca mai ad uno stato di
non terminazione.
6.3 Analisi dinamica
Verrà applicata durante la progettazione e la stesura del codice, al fine di verificare dinamicamente
l’indipendenza delle singole unità rispetto all’integrazione del sistema. Verrà testato quindi il
sistema in tutti i suoi possibili casi e verranno effettuate prove per verificarne l’integrità. L’analisi
avverrà tramite:
- White-box: modalità di test di un’applicazione. Si chiamano anche test strutturali perché lo

scopo è esaminare la logica e la struttura del codice.
- Black-box: modalità di esecuzione dei test dinamici. Consiste nel considerare l’unità come
una scatola chiusa, studiando i suoi output senza analizzare il codice e i flussi di esecuzione.
6.4 Risultati dei test
La verifica della fase di codifica, visto il ciclo di vita adottato, sarebbe dovuta avvenire ciclicamente
seguendo l’evolversi del prodotto per ogni iterazione successiva. Visti gli inconvenienti
precedentemente citati, la maggior parte dei test è avvenuta nella fase finale a modulo completato.
Test case sui componenti e sul codice “a rischio” sono comunque stati fatti ad ogni iterazione
avendo cosi più sensibilità ad eventuali errori. Lavorare in un ambiente di sviluppo come Visual
Pagina 53 di 60
Studio e il debug costante ha comunque permesso di risolvere tutte le anomalie riscontrate nel
percorso.
Nella seguente tabella sono descritti i test fatti staticamente sul codice sorgente.
Tecnica di verifica Esito
Ricerca di campi di default che non vengono Nessuna (IDE Visual Studio)
inizializzati
Ricerca di codice non conforme alle norme di Nessuna
codifica stabilite
Ricerca di parti di codice non raggiungibili Nessuna (IDE Visual Studio)
Ricerca di parti di codice complesse che possono Nessuna
essere semplificate
Ricerca di documentazione del codice prodotto Nessuna
sintatticamente scorretta o mancante
Ricerca di eccezioni non gestite Nessuna
I test dinamici non hanno sollevato problematiche di rilievo ed hanno dimostrato una buona
affidabilità del sistema. L’integrazione della componente all’interno del prodotto già presente in
azienda (plain® documentale) non ha riportato problemi di alcun tipo.
Pagina 54 di 60
7 Conclusioni
7.1 Pianificazione iniziale e finale
7.1.1 Fasi del progetto
Durante la fase di pianificazione del lavoro, ho stabilito insieme all’azienda gli obiettivi principali
da portare a termine nel corso delle varie fasi dello stage.
Il progetto consisteva nell’analisi, progettazione, implementazione e verifica del componente per la

visualizzazione di documenti PDF al fine di essere integrato con quanto già sviluppato in azienda.
Le principali fasi di sviluppo previste erano:
1) acquisizione delle conoscenze dell’ambiente di lavoro e del dominio;

2) acquisizione di maggiori conoscenze tecniche e di sviluppo (strumenti informatici,
linguaggio di sviluppo);
3) analisi dei requisiti necessari alla realizzazione del pacchetto assegnato, in rapporto ai
bisogni aziendali;
4) progettazione di un prototipo della soluzione studiata in fase di analisi;
5) codifica, test e integrazione del prototipo;
6) documentazione;
Nella tabella seguente sono riportate le varie fasi e le ore stimate a inizio stage.
Fasi di progetto Ore stimate
1. Conoscenze generali. 20 ore

a. Conoscenze del .Net Framework 3.x
2. Studio generale di Visual Studio 2008 25 ore

a. Interfaccia IDE
b. Esempi di Visual C#
c. Creazione di progetti WinForm
3. Analisi dei requisiti. 50 ore

a. L’obiettivo principale consiste nella realizzazione di un’applicazione windows
che permetta di visualizzare un file, in formato PDF, salvato su un database
SQL Server con i relativi attributi generici e specifici. Gli attributi generici
sono quelli che possiedono tutti i documenti, mentre quelli specifici sono quelli
valorizzati in base al tipo di documento.
b. La finestra sarà strutturata ad aree di lavoro: una per la visualizzazione del
Pagina 55 di 60
documento e una che riporta le informazioni relative. Il layout della finestra
dovrà essere configurabile dall’utente e salvato in un file di configurazione.
c. Non si esclude la possibilità di identificare una libreria di terze parti che
permetta la visualizzazione di file in formato PDF.
d. Documentazione
4. Progettazione di un prototipo. 45 ore

a. Progettazione architetturale e di dettaglio degli oggetti coinvolti nel prototipo.
b. Progettazione d’interfacce grafiche utilizzando Microsoft Visio.
c. Documentazione
5. Codifica 110 ore

a. Sviluppo, seguendo le norme di codifica utilizzate all’interno dell’azienda.
b. Test, utilizzando le funzioni offerte dall’ambiente di sviluppo Microsoft.
6. Documentazione prodotto 50 ore
Totali 300 ore
7.1.2 Preventivo ore
La data di inizio stage è stata fissata per lunedì 28 Settembre 2009 e la fine per il mercoledì 18
Novembre 2009. La durata prevista era di 300 ore, suddivise in circa 40 ore settimanali. Di seguito
viene riportato il piano settimanale con la suddivisione delle ore dedicate ad ogni attività.
Fase Settimana 1 Settimana 2 Settimana 3 Settimana 4
1 8 8 4
2 4 8 8 5
3 3 8 8 8 8 8 7
4 1 8 8 8 8 8 4
5 4 8 8
6
Fase Settimana 5 Settimana 6 Settimana 7 Settimana 8
1
2
3
4
5 8 8 8 8 8 8 8 8 8 8 8 2
6 6 8 8 8 8 8 4 - -
Pagina 56 di 60
7.1.3 Requisiti soddisfatti
Tutti i requisiti di progetto sono stati soddisfatti, sia quelli obbligatori, sia quelli opzionali. Alcuni
in un prodotto, altri nell’altro. Molti invece sono stati soddisfatti da entrambi i moduli. Per chiarire
meglio questo particolare viene fornita la tabella seguente.
Progetto Requisiti Soddisfatti
Plain.PDFViewer RF1, RF1.1.6, RF1.1.8, RF1.1.9, RF1.1.10, RF1.1.11, RF1.2, RF1.2.1,

RF1.3, RF1.3.1, RF1.3.2, RF1.3.2.1, RF1.3.2.2, RF1.3.2.3, RF3, RF3.1, RI1,
RI2
Plain.File.Extraction RF2, RF2.1, RF2.1.1, RF2.2, RF2.3, RI3
Requisiti Comuni RF1.1, RF1.1.1, RF1.1.2, RF1.1.3, RF1.1.4, RF1.1.5, RF1.1.7, RQ1, RQ2,
RQ3, RG1, RG1.1, RG1.1.1, RG1.2
7.1.4 Consuntivo ore
I tempi preventivati all'inizio dell'attività di stage sono stati soddisfatti senza cambiamenti di rilievo;
Sono stati sfruttati i due ultimi giorni dell’ ottava settimana di lavoro per finire la documentazione e
per recuperare alcune ore perse durante lo stage.
Lo stage è quindi finito venerdì 20 Novembre. Nonostante la variabilità dei requisiti, le nuove
attività sono rientrate nella somma delle ore richieste da analisi, progettazione e codifica iniziali,
rubando solamente qualche ora, come già detto, alla verifica e alla documentazione.
7.2 Conoscenze acquisite grazie al progetto
Il progetto che mi è stato affidato consisteva, come visto già più volte, nella creazione di un nuovo
componente per la visualizzazione di PDF che permettesse, oltre alla visualizzazione in stile
Acrobat del file PDF, anche l’estrazione e l’eventuale modifica degli attributi a esso associati,
presenti all’ interno del database aziendale. Questo modulo doveva potersi semplicemente integrare
all’interno del software aziendale già presente.
Pagina 57 di 60
Costruire un visualizzatore di PDF partendo da zero, all’inizio dello stage, non era stato dato subito
per irrealizzabile; principalmente perché non avevo le conoscenze sufficienti a escludere questa
possibilità. Presto però, anche solo sfogliando la specifica tecnica dei PDF rilasciata da Adobe (PDF
Reference), mi sono reso conto che sarebbe stato un lavoro troppo complesso, e che non aveva
molto senso visti i buoni prodotti già presenti sul mercato. Inoltre, la quantità di tempo era
veramente insufficiente per sviluppare una idea del genere; l’azienda richiedeva un prodotto
funzionante e utilizzabile a fine stage.
Mi sono dedicato molto di più alla ricerca di qualche libreria o progetto che potesse risolvere il mio
problema in tempi ragionevoli. Molte delle conoscenze e delle capacità ottenute grazie allo stage
sono state dovute alle prove fatte su tali librerie, che poi magari si sono rilevate inutili al
raggiungimento dello scopo finale, ma che hanno permesso uno studio più approfondito e vario
delle tecnologie adottate in azienda quali C# e Visual Studio. Entrambe queste tecnologie erano a
me precedentemente sconosciute, dato che all’interno dei corsi universitari si trattano
principalmente software e linguaggi open source e in ambiente GNU/Linux.
Ritengo che imparare a lavorare in ambiente di sviluppo come Visual Studio .NET mi consenta ora
di gestire richieste (progetti, lavori e situazioni) molto più complesse dei vari progetti universitari
affrontati nel corso di questi anni. Allo stesso tempo, penso che questa esperienza verrà valutata
molto positivamente da qualsiasi altra azienda che leggerà il mio curriculum. Visual Studio e C#
sono ormai diventati strumenti fondamentali da conoscere, non solamente per una maggiore cultura
informatica, ma anche per avere una futura carriera in questo campo.
7.3 Considerazioni sull’esperienza lavorativa
Ritengo che l’esperienza lavorativa presso ASI S.r.l sia stata in sé molto utile, non solamente per lo
studio pratico di nuovi strumenti e tecnologie ma anche per entrare in contatto diretto con il mondo
del lavoro. Lavorare su un progetto reale è molto diverso dal lavorare su un progetto universitario.
Richiede una maggiore responsabilità e una buona pianificazione. Allo stesso tempo però, sapere
che il tuo prodotto avrà un utilità e che magari potrà essere venduto, ti ripaga degli sforzi fatti.
Nel mio stesso ufficio lavoravo a stretto contatto con il mio collega a cui era stato affidato il
progetto da portare avanti in parallelo al mio, mentre, nell’ufficio a fianco, c’era un altro stagista e
due altri ragazzi che avevano finito da poco lo stage all’interno dell’azienda ed erano stati assunti a
progetto. Nonostante ognuno si occupasse di un progetto diverso, i problemi spesso risultavano
Pagina 58 di 60
simili. Collaborare e confrontarsi ha permesso di risolverli in modo sicuramente molto più veloce
che affrontandoli da solo. I rapporti con l'azienda sono stati sempre semplici ed ho potuto
riscontrare una totale disponibilità del tutor aziendale verso le mie esigenze.
Con lo stage sono entrato per la prima volta nello sviluppo di un’applicazione aziendale di una
utilità immediata, con dei veri requisiti e delle vere scadenze. È stato molto utile allo stesso tempo
essere incorso in tutta una serie di problematiche che in un progetto universitario non si hanno. Per
fare un esempio, la variazioni all’ultimo momento dei requisiti nel prodotto ormai sviluppato.
Variazioni che, per quanto semplici possano sembrare al committente, richiedono invece un
notevole sforzo sia in termini di tempo che in termini di lavoro.
Ritengo utile elencare qui di seguito i vari problemi incontrati durante lo stage.
Variabilità dei requisiti : come visto nel capitolo di analisi, sono state richieste da parte
dell’azienda alcune modifiche ai requisiti in corso d’opera con conseguente necessità di effettuare
ulteriori analisi e progettazioni e che hanno portato ad un sovraccarico di lavoro nelle fasi centrali
del progetto.
Tali modifiche riguardavano:
- aggiunta di funzionalità inizialmente non previste nei requisiti: L’esempio più

importante è quello dell’introduzione del requisito RF2 (Il programma deve permettere di
eseguire una mappatura sul PDF aperto) che ha portato, dopo aver visto che tale funzionalità
non era permessa dall’ SDK di Adobe Acrobat, all’analisi di molti altri software prima di
poterne trovare uno che permettesse di tracciare aree sopra il PDF stesso. Questo requisito
ha inoltre comportato lo scambio di opinioni e di idee sul lavoro da svolgere perché
l’interfaccia grafica finale fosse realmente utilizzabile dal progetto parallelo del mio collega.
- cambiamento parziale o totale di un requisito: per esempio il requisito RG 1.1.1 (La GUI
deve avere un layout a pannelli dockable (stile Visual Studio)) che ha comportato la ricerca
e l’analisi di varie nuove librerie in grado di soddisfare tale richiesta.
Lo studio delle varie librerie ha richiesto più tempo del previsto per realizzare determinate
funzionalità. Sono riuscito in gran parte a rispettare le tempistiche, rubando solamente qualche ora
alla fase di documentazione e test finali.
Scarsa documentazione: la maggior parte delle librerie provate, prima di trovare quelle utili e
finali per il progetto, avevano scarsissima documentazione. Molto spesso erano più utili le
discussioni online che i documenti. Spesso ho dovuto procedere per tentativi prima di trovare classi
Pagina 59 di 60
o funzioni che offrissero le funzionalità di cui avevo bisogno. Questo ha comportato logicamente
notevole dispendio di tempo.
7.4 Obiettivi raggiunti
Nonostante tutto, i problemi e gli ostacoli sopra elencati, hanno permesso di sviluppare le mie
capacità organizzative e conoscenze tecniche.
Lo stage si è concluso ottimamente con la realizzazione finale dei due prodotti Plain.PDFViewer e
dell’interfaccia per Plain.File.Extraction. Entrambi questi moduli si sono integrati senza difficoltà
con il software precedentemente creato in azienda e dal mio collega.
In particolare, ritengo molto importante che Plain.PDFViewer sia già utilizzato all’interno
dell’azienda come modulo per la visualizzazione dei PDF all’interno di plain® documentale.
Un ringraziamento va a tutta l’ASI S.r.l. per la disponibilità e per l’opportunità di crescita

concessami.
Pagina 60 di 60

Carraro Filippo Tesi

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Carraro Filippo Tesi

Caricato da

Copyright:

Formati disponibili

UNIVERSITÀ DEGLI STUDI DI PADOVA

Facoltà Di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea Triennale in Informatica

Anno Accademico 2009/2010

1.1 ASI S.r.l ...................................................................................................................................... 7

2 Descrizione del prodotto ................................................................................................................... 9

2.1 Contesto d’uso del prodotto ...................................................................................................... 9

2.1.1 Plain® Portal ...................................................................................................................... 9

2.1.2 Plain® Documentale ........................................................................................................ 10

2.2 Obiettivo del prodotto .............................................................................................................. 12

3 Strumenti utilizzati .......................................................................................................................... 13

3.1 Tecnologie, linguaggi, software di sviluppo .......................................................................... 13

3.1.1 .NET Framework .............................................................................................................. 13

3.1.3 WPF .................................................................................................................................. 16

3.1.4 Visual Studio Team System 2008 ................................................................................... 18

3.1.5 Microsoft SQL Server ...................................................................................................... 19

3.2 Software per la documentazione ............................................................................................. 19

3.2.1 Microsoft Word 2003 ...................................................................................................... 19

3.2.2 Microsoft Visio................................................................................................................. 19

3.2.3 Poseidon per UML ........................................................................................................... 19

4.1 Studio delle tecnologie ............................................................................................................ 20

4.2 Situazione iniziale e studio del dominio................................................................................. 20

4.3 Descrizione generale ................................................................................................................ 21

4.3.1 Premessa ........................................................................................................................... 21

4.3.2 Contesto d’uso .................................................................................................................. 21

4.3.3 Caratteristiche degli utenti ............................................................................................... 21

4.4 Requisiti .................................................................................................................................... 26

4.4.1 Vincoli generali ................................................................................................................ 28

4.4.2 Assunzioni e dipendenze ................................................................................................. 28

4.4.3 Attributi di prodotto ......................................................................................................... 28

4.4.4 Attributi di processo ......................................................................................................... 30

5 Progettazione e sviluppo ................................................................................................................. 32

5.1 Modello di ciclo di vita adottato ............................................................................................. 32

5.1.1 Il modello evolutivo ......................................................................................................... 32

5.2 Analisi degli strumenti e delle librerie ................................................................................... 33

5.2.2 Strumenti e librerie che si sono rivelati inadeguati ........................................................ 38

5.3 Sviluppo interfaccia grafica per Plain.File.Extraction. ......................................................... 41

5.3.1 Progettazione .................................................................................................................... 42

5.4 Sviluppo Plain.PDFViewer ..................................................................................................... 46

5.4.1 Progettazione .................................................................................................................... 46

6.1 Strumenti, tecniche, metodi adottati ....................................................................................... 52

6.2 Analisi statica ........................................................................................................................... 53

6.3 Analisi dinamica ...................................................................................................................... 53

6.4 Risultati dei test........................................................................................................................ 53

7.1 Pianificazione iniziale e finale ................................................................................................ 55

7.1.1 Fasi del progetto ............................................................................................................... 55

7.1.2 Preventivo ore ................................................................................................................... 56

7.1.4 Consuntivo ore ................................................................................................................. 57

7.2 Conoscenze acquisite grazie al progetto................................................................................. 57

7.3 Considerazioni sull’esperienza lavorativa .............................................................................. 58

7.4 Obiettivi raggiunti .................................................................................................................... 60

Tra i progetti proposti c’erano:

1. Riconoscimento posizionale di testo all’interno di un PDF

1.1 ASI S.r.l

È specializzata nella progettazione e sviluppo di software industrializzato:

- ERP per aziende manifatturiere e commerciali

È partner IBM, Microsoft, Oracle-Hyperion e Juniper.

- Risorse dedicate alla ricerca

2.1 Contesto d’uso del prodotto

2.1.1 Plain® Portal

- Facilità di utilizzo: Il prodotto è dotato di un’interfaccia intuitiva che lo rende facilmente

2.1.2 Plain® Documentale

Permette di gestire il “patrimonio documentale” dell’azienda e si da come obiettivo finale quello di