Tecniche per la rilevazione e correzione di errori nell'elaborazione automatica di documenti cartacei

  • 470 views
Uploaded on

Tesi di laurea specialistica in Ingegneria Informatica. …

Tesi di laurea specialistica in Ingegneria Informatica.
Autore: Gazzin Matteo.
Laboratorio di reti di calcolatori
Dipartimento di ingegneria industriale e dell'informazione
Università degli studi di trieste
Aprile 2011.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
470
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica Tesi di Laurea in RETI DI CALCOLATORITecniche per la rilevazione e correzionedi errori nellelaborazione automatica di documenti cartaceiLaureando: Relatore:Matteo GAZZIN Prof. Ing. Alberto BARTOLI Correlatori: Prof. Ing. Eric MEDVET Ing. Giorgio DAVANZO Anno Accademico 2009/2010
  • 2. SOMMARIOSOMMARIO……………………………………………………………………………………………IINDICE DELLE FIGURE……………………………………………………………………………IIIINDICE DELLE TABELLE………………………………………………………………………….IVINDICE DEI GRAFICI……………………………………………………………………………….VINTRODUZIONE........................................................................................ 1ANALISI E PROGETTAZIONE ..................................................................... 2 CLASSIFICAZIONE DEGLI ERRORI COMMESSI DAGLI OCR ...................................... 3 SCENARIO: IN CHE CONTESTO SI INSERISCE IL LAVORO SVOLTO .............................. 5 IL RUOLO DI SINTASSI E SEMANTICA ............................................................. 10 PROGETTAZIONE ..................................................................................... 14REALIZZAZIONE...................................................................................... 15 TECNOLOGIE UTILIZZATE ........................................................................... 15 SCENARIO FIXER SINGOLO .................................................................. 16 ALGORITMO................................................................................... 16 SCENARIO FIXER AGGREGATO ............................................................ 21 ALGORITMO APPROSSIMATO ......................................................... 22 ALGORITMO: L’ESEMPIO CONSIDERATO PER QUESTA TESI .............. 23 VALUTAZIONI QUALITATIVE E QUANTITATIVE ..................................... 29IMPLEMENTAZIONE ............................................................................... 32 INTERFACCIA JAVA ............................................................................. 32 ORGANIZZAZIONE DEL CODICE .................................................................... 33VALUTAZIONE SPERIMENTALE ............................................................... 36 RISULTATI .......................................................................................... 37 SENZA FIXER .................................................................................. 37 CON I FIXER .................................................................................... 38 CONSIDERAZIONI GLOBALI ............................................................. 44PRESTAZIONI ......................................................................................... 47 I
  • 3. CONCLUSIONI ........................................................................................ 49APPENDICE A: DOCUMENT GENERATOR ................................................ 50 SPECIFICHE TECNICHE .............................................................................. 50 FUNZIONAMENTO ................................................................................... 53APPENDICE B: FILE DI CONFIGURAZIONE SUBSTITUTIONPAIRS .............. 57RINGRAZIAMENTI .................................................................................. 61BIBLIOGRAFIA ........................................................................................ 63 II
  • 4. INDICE DELLE FIGUREFIGURA 1 - SCREENSHOT DELLINTERFACCIA DI DOCUMENT GENERATOR ..................... 7FIGURA 2 - DIAGRAMMA DI FLUSSO DEL SISTEMA DI ELABORAZIONE AUTOMATICA DI DOCUMENTI ........................................................................................ 9FIGURA 3 - DIAGRAMMA DI FLUSSO SEMPLIFICATO DEL SISTEMA DI ELABORAZIONE AUTOMATICA DI DOCUMENTI ................................................................. 10FIGURA 4 - ERRORE DI INDIVIDUAZIONE DEL CONTENUTO. IL SOFTWARE DOVRÀ ESSERE IN GRADO DI ESTRARRE LA PORZIONE CONTENENTE LA DATA SULLA QUALE APPLICARE LA CORREZIONE SE NECESSARIA. .............................................................. 10FIGURA 5 - ERRORE DI SEGMENTAZIONE ........................................................... 11FIGURA 6 - ERRORE DI PUNTEGGIATURA, LA VIRGOLA DECIMALE È STATA SOSTITUITA DA UNO SPAZIO ...................................................................................... 11FIGURA 7 - ERRORE DI AMBIGUITÀ DI CARATTERE E DI SEGMENTAZIONE .................... 11FIGURA 8 - VALORI SINTATTICAMENTE CORRETTI ................................................. 12FIGURA 9 - DIAGRAMMA DELLE CLASSI ............................................................. 14FIGURA 10 - DIAGRAMMA DI FLUSSO DATI DI UN FIXER SINGOLO ............................ 17FIGURA 12 - PACKAGE E CLASSI DEL PROGETTO ................................................... 33FIGURA 13 - DIAGRAMMA FISICO DEL DB USATO PER I TEST ................................... 36FIGURA 14 - DOCUMENT GENERATOR: GENERAZIONE FATTURE DA NUOVI MODELLI ..... 53FIGURA 15 - DOCUMENT GENERATOR: GENERAZIONE FATTURE DA MODELLI PREESISTENTI. ...................................................................................................... 55FIGURA 16 – ESEMPIO DI FATTURA GENERATA DA DOCUMENT GENERATOR ............... 56 III
  • 5. INDICE DELLE TABELLETABELLA 1 - SUBSTITUTION PAIRS ................................................................... 18TABELLA 2 – POSSIBILI STATI ALL ’USCITA DI ERRORFIXER ....................................... 29TABELLA 3 – POSSIBILI VALORI DI QUALITY ALL’USCITA DI ERRORFIXER ..................... 30TABELLA 4 - RELAZIONE TRA STATUS E QUALITY .................................................. 31TABELLA 6 - SITUAZIONE GROUND-TRUTH SENZA LAPPLICAZIONE DEI FIXER................ 37TABELLA 7 - SITUAZIONE GROUND-TRUTH DOPO 1° TEST ....................................... 38TABELLA 8 - ERRORI RESIDUI DOPO 1° TEST ....................................................... 41TABELLA 9 - AGGIORNAMENTO SUBSTITUTIONPAIRS ............................................ 42TABELLA 10 - SITUAZIONE GROUND-TRUTH DOPO LAPPLICAZIONE DEI FIXER .............. 42TABELLA 11 - ERRORI RESIDUI DOPO 2° TEST ..................................................... 43 IV
  • 6. INDICE DEI GRAFICIGRAFICO 1 - SITUAZIONE GROUND-TRUTH SENZA LAPPLICAZIONE DEI FIXER ............... 38GRAFICO 2 - SITUAZIONE POST-FIXER 1° TEST ..................................................... 40GRAFICO 3 - SITUAZIONE DOPO LAPPLICAZIONE DEI FIXER ..................................... 43GRAFICO 4 – PERCENTUALE DI ERRORI SENZA L’APPLICAZIONE DEI FIXER .................... 44GRAFICO 5 – PERCENTUALE DI ERRORI DOPO L’APPLICAZIONE DEI FIXER .................... 44GRAFICO 6 – PERCENTUALE CORREZIONI FATTE RISPETTO AL TOTALE ........................ 45GRAFICO 7 – PERCENTUALI CORREZIONI FATTE O SUGGERITE RISPETTO AL TOTALE DI ERRORI SE NON FOSSERO PRESENTI I FIXER ................................................. 46 V
  • 7. INTRODUZIONENegli ultimi anni è emerso un interesse sempre più crescente versola digitalizzazione di documenti cartacei, operazione che nepermette una migliore conservazione nel tempo e apre le porte atutti i benefici offerti dal formato digitale.Volendo andare oltre al semplice immagazzinamento di immagini,che ha l’unico vantaggio di ridurre lo spazio fisicamente occupatodagli archivi cartacei, l’interesse si è spostato verso l’estrazione dicontenuti con tipo, operazione che permette di valorizzare i dati diinteresse contenuti nel documento ed inserirli in un database; adesempio per una fattura potrebbero essere la data di emissione, ilnumero della fattura, la partita iva del fornitore o altri. Il vantaggioprincipale di questo approccio è dato dalla possibilità di gestire idocumenti con un sistema informativo.L’estrazione di contenuti testuali da un’immagine è affidata asoftware OCR (Optical Character Recognition) che hanno comeprincipale limitazione il fatto di commettere errori nellaconversione dell’informazione da immagine a testo.L’obiettivo di questa tesi è l’implementazione di un sistema dirilevazione e correzione degli errori generati da un OCR.Il primo capitolo è dedicato all’analisi del problema; vienepresentata una descrizione degli errori comunemente commessi daisoftware OCR e come si è pensato di risolverli; in seguito trovaspazio una descrizione dello scenario in cui si inserisce ilcomponente software realizzato.Nel capitolo Realizzazione vengono descritti in dettaglio glialgoritmi realizzati e le scelte effettuate.Infine nel capitolo Valutazione sperimentale vengono descritti i testeffettuati e i risultati ottenuti sulla ground-truth di test. 1
  • 8. ANALISI E PROGETTAZIONEIl primo passo per trasformare un archivio cartaceo in uno digitale èla scansione dei documenti. Il passo successivo prevedel’applicazione di un software OCR che traduce il contenuto di ognipagina in caratteri ASCII interpretabili da un calcolatore. Questisoftware tentano di imitare l’effetto combinato di cervello e occhioumano che permette all’uomo di distinguere facilmente i caratteristampati in un documento e aggregarli in parole.L’uomo è in grado di riconoscere rapidamente il layout di unapagina, le sezioni, i titoli e leggere correttamente il testo di undocumento anche in presenza di porzioni dello stesso fortementedegradate o addirittura mancanti. I moderni OCR riescono a faretutto questo abbastanza bene fino ad arrivare ad una precisione del99% nel riconoscimento dei caratteri in stampe recenti, come adesempio stampe ad alta qualità e perfettamente conservate di fileWord o PDF. Questi risultati calano considerevolmente nelmomento in cui si prende in considerazione un vecchio giornale,una vecchia stampa a getto d’inchiostro o ad aghi. A tal proposito,un recente studio(Holley, 2009), ha evidenziato che prendendo inconsiderazione 45 pagine di giornale prese a caso da un insiemeappartenente al periodo che va dal 1803 al 1954, l’accuratezzaraggiunta oscilla tra il 71% e il 98%. Nel caso peggiore, questosignifica che ci sono 145 caratteri errati in un paragrafo di 500.Questi risultati possono essere migliorati in post-processing inmodo manuale, semiautomatico o completamente automatico. Nelcaso manuale, la correzione è lasciata alla pazienza certosina di unrevisore che manualmente confronta il testo originale con quelloacquisito. Un sistema di correzione semiautomatica invece, rilevagli errori e propone un insieme di correzioni ad un operatore che hail compito di scegliere quale sia la proposta corretta. Un sistema dicorrezione automatica infine, non prevede l’intervento umano ed è2
  • 9. in grado di rilevare e correggere autonomamente gli errori sullabase di criteri a massima verosimiglianza.CLASSIFICAZIONE DEGLI ERRORI COMMESSI DAGLI OCRPrima di poterli correggere, gli errori vanno necessariamenteidentificati e classificati. Esiste in letteratura una classificazioneuniversalmente impiegata che divide gli errori in 2 classi (Kukich,1992): NON-WORD ERROR: un errore non-word avviene quando la parola rilevata non appartiene a nessun vocabolario (ad esempio “tho” al posto di “the”) . Questo è un errore molto comune che può essere rilevato con un controllo dell’ortografia. REAL-WORD ERROR: un errore real-word avviene quando la parola rilevata è corretta da un punto di vista ortografico ma è usata in un contesto sbagliato (ad esempio “peace of paper” invece di “piece of paper”). Questo tipo di errori sono rilevabili e correggibili solo in base al contesto della frase.Questa separazione in due gruppi non è ovviamente esaustiva, inparticolare per quanto riguarda l’ambito in cui si inserisce il lavorosvolto per questa tesi, quindi è necessario arrivare ad unaclassificazione più articolata che prevede: ERRORI DI SEGMENTAZIONE: si verificano quando avviene la separazione in più parti di una stringa originariamente unica, o l’unione di più stringhe originariamente separate (ad esempio “spaghetti””spa g hetti” oppure “la pizza”“lapizza”). ERRORI DI SILLABAZIONE: comuni in articoli di giornale, aumentano il fenomeno della segmentazione (ad esempio “piz- za”). 3
  • 10. RICONOSCIMENTO ERRATO DI CARATTERI: il deterioramento del documento o alcuni stili di scrittura particolari, possono indurre ad una errata interpretazione dei caratteri (ad esempio “suoiio” anziché “suono” ma anche “&-$tat’e” al posto di “Estate”). ERRORI DI PUNTEGGIATURA: il deterioramento del documento può esserne la causa. Questo può significare ad esempio scambiare punti con virgole o, più frequentemente, l’inserimento di uno spazio vuoto al posto di un segno di punteggiatura. ERRORI DI AMBIGUITÀ DI SIGNIFICATO: Il riconoscimento errato di alcuni caratteri potrebbe generare nuove parole corrette dal punto di vista ortografico ma semanticamente fuori contesto (Ad esempio “quest’auto fa le pizze” anziché “quest’auto fa le bizze”). DISTRUZIONE DEL CONTENUTO: La contemporaneità di più errori all’interno di un’unica stringa potrebbe portare infine ad un errore di distruzione del contenuto (ad esempio “| | 4 ç i c0” al posto di “Magico”).Appare quindi evidente che alcuni degli errori elencati sonocorreggibili, altri potrebbero esserlo adottando tecniche atte averificare la correlazione tra caratteri successivi o la semantica dellafrase, altri infine non lo sono. Richiamando le 3 tipologie dicorrezione in post-processing viste in precedenza, l’unica soluzioneper il caso di errori non correggibili è la tediosa procedura manuale.Fino ad ora sono stati discussi documenti contenenti testosemplice, eventualmente formattato, costituito da parolericonducibili ad un determinato linguaggio; l’appartenenza ad unvocabolario noto all’OCR è una conditio sine qua non affinché sianoapplicabili le metodologie di correzione semiautomatiche edautomatiche legate al contesto e alla semantica della frase.4
  • 11. Per questo motivo utilizzare software OCR per elaborare documenticontenenti un insieme di campi strutturati, aventi una precisasintassi e semantica non afferente ad una lingua parlata, non portaa risultati soddisfacenti con le normali tecniche di correzioneautomatica d’errore.SCENARIO: IN CHE CONTESTO SI INSERISCE IL LAVORO SVOLTOOggetto di studio di questo elaborato, è la realizzazione di uncomponente software con finalità di rilevazione e correzione dierrori basate su proprietà sintattiche e semantiche del contenutoatteso.Tale componente è parte di un progetto per la digitalizzazione eclassificazione automatica di informazioni contenute in documenticartacei, sviluppato all’interno del laboratorio di “Reti diCalcolatori” dell’Università degli studi di Trieste.Uno dei possibili scenari di utilizzo di un sistema di questo tipo è ladigitalizzazione delle fatture da parte di un’azienda. In questomodo, anziché catalogare manualmente tutte le fatture ed inserire icampi di interesse all’interno di un sistema di gestionedocumentale, o più in generale di un database, l’operatore develimitarsi a scannerizzare il documento originale.L’immagine scannerizzata viene elaborata dal sistema che estraeautomaticamente le informazioni di interesse e salva tutto in unabase dati.Le informazioni estraibili dipendono dal tipo di documento: adesempio quelle estraibili da una fattura sono diverse da quelleestraibili da uno scontrino fiscale.Documenti che afferiscono alla medesima tipologia definiscono unaclasse di documenti. Una classe può essere quindi quella dellefatture, o quella degli scontrini fiscali. 5
  • 12. Documenti appartenenti alla stessa classe contengono le stesseinformazioni divise in campi: ad esempio in una fattura sonopresenti i campi “Data”, “Partita Iva”, “Totale”, etc. Tuttavia ladisposizione di questi campi può variare, si definisce quindi modellol’insieme dei documenti che condividono classe di appartenenza elayout grafico. Gli scontrini stampati da un certo registratore dicassa ad esempio, hanno lo stesso layout e per trattarli si dovràapplicare lo stesso modello.Sotto la guida del Prof. Alberto Bartoli, tesisti e dottorandi hannocontribuito in diversa misura alla realizzazione di questo progettoche ha già portato a varie pubblicazioni scientifiche internazionali.La prima di queste è arrivata per merito del lavoro realizzato dalProf. Eric Medvet, culminato con la pubblicazione dell’articolo “AProbabilistic Approach for Printed Document Understanding”(Medvet, Bartoli, & Davanzo, 2010) nella rivista di riferimento per ilsettore specifico “International Journal of Document Analysis andRecognition”. In questo articolo si propone un approccio perl’estrazione di informazioni da documenti cartacei multi pagina, neiquali il set di possibili classi di documenti può evolvere nel tempo ediversi documenti possono condividere contenuti e layout simili.Nella pratica l’utilizzatore finale di questo software educa il sistemaproponendo un set di fatture di Test ed individuando per esse leposizioni in cui si trovano i vari campi di interesse, ad esempio datao partita iva, semplicemente localizzandole con il mouse. A questopunto il sistema sarà in grado di trovare i campi di interesse pertutte le fatture appartenenti ai modelli noti.Relativamente alla fase di test di questo modulo, l’autore di questatesi di laurea ha realizzato come attività di tirocinio, un software,Document Generator, per la generazione automatica di k fattureafferenti a n diversi modelli grazie al quale è stato possibile testareil classificatore su larga scala senza dover acquisire centinaia difatture con lo scanner. In appendice A una descrizione sintetica6
  • 13. relativa a questo software di cui si propone uno screenshot dellaschermata principale qui di seguito. Figura 1 - Screenshot dellinterfaccia di Document GeneratorUna fase cruciale di quanto appena illustrato è la classificazione deidocumenti in base al contenuto, dev’esserci quindi a monte unmodulo in grado di discriminare una fattura Fastweb da una diTelecom Italia e così via. Questo compito, apparentemente banalema nella pratica particolarmente complicato, è assolto dal modulorealizzato dall’Ing. Enrico Sorio. Anche per questa componente nonè mancato il riconoscimento internazionale con la pubblicazionedell’articolo “Open World Classification of Printed Invoices”(Sorio,Bartoli, Davanzo, & Medvet, 09-2010).La complessa infrastruttura software che garantisce ilfunzionamento di tutte le componenti descritte, è stata realizzata invarie misure dagli Ingegneri Giorgio Davanzo, Marco Mauri edEnrico Sorio.Oggetto di studio di questa tesi è dunque la realizzazione di unmodulo software atto a rilevare e correggere in post-processing glierrori commessi dall’OCR in campi con una particolare sintassi e 7
  • 14. semantica. In particolare si è scelto di concentrarsi sulla rilevazionee correzione di errori in documenti afferenti alla classe dellefatture, ma il componente sarà comunque estendibile a qualunquealtra classe.Tale modulo si inserisce nel workflow immediatamente dopo ilblocco demandato all’estrazione dei campi.Come accennato nel capitolo precedente, le prestazioni degli OCRin documenti strutturati come questi, non possono certamenteavvicinarsi ai risultati ottenibili con testi semplici, non essendopossibile l’applicazione di algoritmi standard di correzione d’errorein post-processing.La situazione fin qui descritta è schematizzata nella seguente figura.8
  • 15. Figura 2 - Diagramma di flusso del sistema di elaborazione automatica di documentiIl componente realizzato per questa tesi è identificabile con ilblocco verde con bordo rosso.Una versione semplificata di quanto appena visto è data dalseguente diagramma: 9
  • 16. Figura 3 - Diagramma di flusso semplificato del sistema di elaborazione automatica di documentiAnche in questo caso il blocco realizzato è evidenziato con un bordorosso.Si vedranno ora gli errori più comuni legati a questo ambitospecifico e come si è pensato di risolverli.IL RUOLO DI SINTASSI E SEMANTICAIl software per l’estrazione dei contenuti identifica in modoestremamente accurato la posizione dell’informazione desiderata,ma non riesce ad estrarre correttamente il contenuto atteso.Poiché l’OCR suddivide in blocchi il documento, è possibile che iltesto contenuto in un blocco contenga del rumore costituitofondamentalmente da caratteri aggiuntivi che non c’entrano conquanto cercato. Figura 4 - Errore di individuazione del contenuto. Il software dovrà essere in grado di estrarre la porzione contenente la data sulla quale applicare la correzione se necessaria.Pertanto si dovrà far in modo che il software riesca a focalizzare lasua attenzione sullo specifico contenuto di interesse.10
  • 17. In aggiunta, il degrado del documento potrebbe, come visto inprecedenza, portare a diversi tipi di errore. Di seguito si vedrannoalcune immagini di esempio che evidenziano in che modo la stringaattesa, “19.556,25 euro”, possa venir mal interpretata. Si supponeche il rumore aggiunto dato dalla stringa ”euro” sia stato giàrimosso. Figura 5 - Errore di segmentazione Figura 6 - Errore di punteggiatura, la virgola decimale è stata sostituita da uno spazio Figura 7 - Errore di Ambiguità di carattere e di segmentazioneDi fronte a output come questi è evidente che un sistema diarchiviazione automatica di contenuti tipizzati non può funzionare.In prima istanza si dovranno correggere gli errori di ambiguità dicarattere sulla base del tipo di campo considerato. Ad esempio se ilcampo è di tipo numerico, è abbastanza evidente che il simbolo “|”potrebbe corrispondere ad “1” ed “S” a ”5”, pertanto sarànecessario creare una tabella di corrispondenze tra carattere erratoe carattere corretto.Successivamente andrà effettuato un controllo sintattico perverificare che le correzioni effettuate abbiano effettivamente datoluogo a un contenuto formalmente corretto.Data la particolare struttura di alcuni campi, dovrà essere ancheprevisto un controllo semantico. La figura seguente mostra ilrisultato della scansione di una partita iva e due possibili valoriestratti dall’OCR. 11
  • 18. Figura 8 - Valori sintatticamente correttiSintatticamente entrambi i valori sono perfettamente validiessendo formati da 11 cifre consecutive. Tuttavia solo la primasoluzione proposta è semanticamente valida. Si può arrivare aquesta conclusione grazie al checksum fornito dall’ultima cifra che èottenuta effettuando alcune precise operazioni sulle precedenti.Nel capitolo Realizzazione verranno esposti i vari algoritmi dicontrollo semantico utilizzati. Nell’eventualità in cui i valorisemanticamente validi fossero più di uno, la scelta avverrà sullabase di criteri a massima verosimiglianza.Per questo progetto sono stati presi in considerazione i seguenticampi:  Data  Numero Fattura  Partita Iva  Codice Fiscale  Valuta  NumeroOgni campo preso in considerazione ha una sintassi ed unasemantica ben definite e necessiterà quindi di correzioni differenti.Tuttavia buona parte delle procedure è standard, pertanto si èdeciso di creare una classe astratta contenente la logica comune edestenderla con implementazioni specifiche per i vari tipi dicontenuto. Esisteranno pertanto tanti correttori, fixer nel prosieguodella trattazione, quanti sono i campi presi in considerazione.Alcuni campi all’interno del documento, possono essere correlatitra loro. In questo caso, oltre alle correzioni effettuate dai fixersingoli, è possibile sfruttare la correlazione tra i dati edimplementare un controllo semantico aggregato per arrivare ad12
  • 19. ulteriori correzioni. Correttori di questo tipo verranno chiamatiFixer Aggregati. L’esempio preso in considerazione nel caso dellefatture è quello dei quattro campi “Totale”, ”Imponibile”, “Iva” ed“Aliquota”.Il software quindi sarà completamente estendibile: per correggeredati afferenti ad un nuovo campo o ad un insieme di campi, basteràscrivere un fixer con un’implementazione ad hoc per quel formato. 13
  • 20. PROGETTAZIONETutte queste considerazioni hanno portato alla stesura delseguente diagramma delle classi. Figura 9 - Diagramma delle classi14
  • 21. REALIZZAZIONEIl componente realizzato fa parte di quella branca di rilevatori ecorrettori di errore che lavorano in post-processing sui risultatigenerati da un OCR. In particolare l’obiettivo principe è quello di farsì che funzioni in modo completamente automatico, ripiegandoverso la modalità semi-automatica solo quando strettamentenecessario, riducendo così al minimo l’intervento manuale.TECNOLOGIE UTILIZZATEDovendo realizzare un componente aggiuntivo per un softwarepreesistente, la scelta delle tecnologie da utilizzare non è statalibera. Il sistema di elaborazione automatica di documenti presentale seguenti caratteristiche:  Java Enterprise Edition (Oracle - J2EE) 6;  Enterprise Java Bean (Oracle - EJB);  application server GlassFish V3 (Glassfish);  web services con approccio REST (Representational State Transfer);  data storage mediante l’utilizzo di JPA 2.0 (java persistence api).Il modulo realizzato va ad inserirsi all’interno del workflow J2EE edè quindi stato scritto in linguaggio Java.Per allinearsi con l’ambiente di sviluppo adottato nel laboratoriodove si è sviluppato il codice, si è utilizzato l’IDE (IntegratedDevelopment Enviroment) Netbeans di Oracle Corporation(Netbeans).Totalmente libera invece è stata la scelta riguardante il DBMS(DataBase Management System) da adottare per il codice di test.Data la semplicità della base dati da realizzare, si è optato per 15
  • 22. l’utilizzo del DBMS open source MySql di Oracle Corporation(MySql).SCENARIO FIXER SINGOLOUn documento è costituito da un set di campi C={c1,c2,…,cm}. Ognicampo ci è caratterizzato da un tipo t, un valore s rilevato dall’OCRed un valore atteso s0. Il valore atteso, ossia il valoreeffettivamente scritto sul documento, non è noto.La finalità di questo elaborato è quella di proporre unprocedimento per ottenere, a partire da t ed s, un set di soluzionicandidate S={s1, s2, …, sn}. È auspicabile che S contenga il numerominimo di elementi, sperabilmente uno solo, e che fra questi ci sias 0.In secondo luogo si vogliono ottenere una valutazione qualitativaed una quantitativa dell’eventuale correzione apportata. Questiindici sono necessari per discriminare quando il fixer può agire inmodalità completamente automatica, quando in modalità semi-automatica e quando, non potendo applicare alcuna correzione, èrichiesto l’intervento manuale.Senza perdere di generalità, nel prosieguo della trattazione siassume che il set C sia composto da un solo campo c0=<t,s,s0>.ALGORITMOIl diagramma seguente riassume l’architettura di un fixer singolo. Lefrecce rappresentano il flusso dei dati. I dati che transitano sonoindicati sulla porta in uscita. Con la notazione s minuscola siintende una singola stringa mentre con S maiuscola si intende unset di stringhe.16
  • 23. Figura 10 - Diagramma di flusso dati di un Fixer SingoloSi considerano i seguenti input:  s: Stringa in ingresso  ValRegex: una o più espressioni regolari usate dal Syntactic Checker per verificare la correttezza sintattica della stringa che riceve in ingresso.  Checksum: una o più espressioni regolari usate dal Semantic Checker per verificare la correttezza semantica della stringa in input.  SubstitutionPairs: insieme di correttori; ognuno associa StringaErrata ad un insieme di StringaCorretta. 17
  • 24. STRINGA ERRATA SET[STRINGA CORRETTA] TIPO N 11 Multichar 11 N Multichar Il 4 Multichar ~I 4 Multichar o 0 CharNumber O 0 CharNumber / 1 CharNumber I 1,7 CharNumber i 1 CharNumber ! 1 CharNumber G 6 CharNumber Q 0 CharNumber D 0 CharNumber B 8 CharNumber Z 2 CharNumber T 7 CharNumber S 5 CharNumber z 2 CharNumber s 5 CharNumber 0 O,D NumberChar 1 I,l NumberChar 6 G NumberChar 8 B NumberChar 2 Z NumberChar 5 S NumberChar 6 5,8 NumberNumber ? 7 SpecialCharNumber Tabella 1 - Substitution Pairs Le sostituzioni possibili che costituiscono la tabella SubstitutionPairs, sono state generate dall’osservazione degli errori generati dall’OCR in campi appartenenti ad un set di fatture di test.BLOCCHI FUNZIONALI:STRING CLEANER: rimuove dalla stringa s in ingresso i simboli chenon hanno significato ed utilità per lo specifico campo considerato.Implementazioni specifiche per tipo di campo previste.18
  • 25. Es1: campo Partita Iva: s=”012.3 4: 56; 78’ 91”, s’=”01234567891”(rimuove spazi e simboli).Es2: campo Valuta: s=”13 4,76” s’=”134,76” (rimuove solo gli spazi)APPLY SUBSTITUTION: genera un set di stringhe S1 ottenutoiterando tutte le SubstitutionPairs alla stringa di ingresso s’.Le sostituzioni possono essere:  Uno-a-uno: una stringa errata viene corretta con una e solo una stringa corretta;  Uno-a-molti: una stringa errata può essere corretta con più di una stringa corretta.Ad ogni iterazione applica la sostituzione presente alla riga i-esimadella tabella SubstitutionPairs come segue:  Sia k il numero di occorrenze in s’ di StringaErrata.  Sia n il numero di StringaCorretta possibili per StringaErrata considerata.  Sia sp la riga di SubstitutionPairs dell’iterazione corrente.  Il numero di stringhe generate è 2k-1 per sp uno a uno. Queste stringhe vengono aggiunte al set contenente la stringa originale. o Esempio uno-a-uno: s="aibi", S1=[aibi], sp = i-->1. Dopo ApplySubstitution: S1’=[aibi, a1bi, aib1, a1b1]  Il numero di stringhe generate è nk-1 per sp uno-a-molti: Queste stringhe vengono aggiunte al set contenente la stringa originale. o Esempio uno-a-molti: s="aibi",S1=[aibi], sp = i-->1,7. Dopo ApplySubstitution: S1’=[aibi, aib1, aib7, a1bi, a1b1, a1b7, a7bi, a7b1, a7b7] k=2, n =3 => nk-1 = 32 - 1 = 8 19
  • 26. SYNTACTIC CHECKER: elimina dal set di ingresso S1 le stringhe chenon soddisfano nessuna delle espressioni regolari ValRegex iningressoSEMANTIC CHECKER: elimina dal set di ingresso S2 le stringhe chenon soddisfano nessuna delle espressioni regolari Checksum iningressoELEMENT SELECTOR: genera il sottoinsieme di S3 contenente lestringhe a distanza di Levenshtein minima da s. IF (S3.size>1) THEN controlla se s è superstringa di uno dei valori di S3. Se è così, in S3 rimane solo quel valore. Altrimenti non vengono apportate modifiche ad S3. (Questo ulteriore controllo è stato aggiunto in un secondo momento per risolvere uno specifico problema evidenziato in fase di valutazione dei risultati ottenuti per il campo numero fattura. Si veda a tal proposito il capitolo Valutazione Sperimentale.)STATUS UPGRADER: genera una tupla < status , values, quality,errorMessage, content >; content è il valore presente nel fieldprima dell’applicazione del fixer (cioè la stringa estratta dall’OCR)come segue: IF (SelectedItems.size ==1) THEN // Da element selector è uscito un solo valore s*. o status OK o values SelectedItems (ha un solo valore che è s*) o quality 1.0 o errorMessage null o content s* ELSE IF (SelectedItems.size >1) THEN // Significa che dal semantic checker sono uscite più stringhe con distanza di Levenshtein da s minima. o status MULTIPLE_RESULTS20
  • 27. o values SelectedItems o quality 0.5 o errorMessage concatenazione status+values o content Unchanged ELSE IF (SelectedItems vuoto) THEN // Da Element Selector non sono uscite stringhe. o status NOT_FOUND o values empty set o quality 0.0 o errorMessage status o content nullNel capitolo Valutazioni qualitative e quantitative sono presenti tretabelle che esplicitano il significato di status e quality.SCENARIO FIXER AGGREGATOUn documento è costituito da un set di campi C = {c1,c2,…,cm}. Ognicampo ci è caratterizzato da un tipo t, un valore s rilevato dall’OCRed un valore atteso s0. Il valore atteso, ossia il valoreeffettivamente scritto sul documento, non è noto.Esiste il sottoinsieme T di C tale che T = {ci1, ci2, …, cik} per il qualesussiste una relazione logica R(T) che può essere soddisfatta omeno: R(T) = R(ci1, ci2, …, cik)  {Soddisfatta, Non Soddisfatta}.Ad esempio si consideri l’insieme formato dai campi “TOTALE”,”IMPONIBILE”, “IVA” ed “ALIQUOTA”.Sussiste la relazione logica seguente:R(TOTALE,IMPONIBILE,IVA,ALIQUOTA) := [TOTALE = IMPONIBILE + IVA AND IVA = ]. 21
  • 28. Esistono inoltre k funzioni tali per cui fj(Tk≠j) = cij , ossia dati k-1elementi, la funzione fj è in grado di calcolare il j-esimo elementotale che R sia soddisfatta.Ad esempio, considerando nuovamente l’insieme formato daicampi “TOTALE”, ”IMPONIBILE”, “IVA” ed “ALIQUOTA”, si possonodefinire le seguenti funzioni:  fTOTALE = IMPONIBILE + IVA;  fIMPONIBILE = TOTALE – IVA;  fIVA = TOTALE – IMPONIBILE;  fALIQUOTA = .La finalità di questo elaborato è quella di proporre unprocedimento per ottenere, a partire dal set T = {ci1, ci2, …, cik}, unset = {T’1, T’2, …, T’n } di tuple T’n che soddisfano R(T’n). Èauspicabile che contenga un solo elemento T’.In secondo luogo si vogliono ottenere una valutazione qualitativaed una quantitativa dell’insieme T per gli stessi motivi elencati nellatrattazione del fixer singolo.Si propone di seguito un algoritmo approssimato del fixeraggregato.ALGORITMO APPROSSIMATO Vengono eseguiti i fixer singoli per i campi appartenenti a T={ci1, ci2, …, cik}. IF( ) o IF(R(T) è soddisfatta)  Il set T soddisfa R. Pertanto i dati dei campi Cik sono coerenti. o ELSE  I dati ricavati dai campi Cik sono incoerenti.22
  • 29.  ELSE IF( ) o Applica il set di funzioni fj o IF( )  Il valore Cij calcolato ha permesso di trovare un set T che soddisfa la relazione R. o ELSE  I dati ricavati dai campi Cik non sono sufficienti.Per semplificare la trattazione, nel prossimo paragrafo vieneesposta la versione dell’algoritmo specifica per la 4-upla di campicomposta da “TOTALE”, ”IMPONIBILE”, “IVA” ed “ALIQUOTA”.ALGORITMO: L’ESEMPIO CONSIDERATO PER QUESTA TESIPer prima cosa il fixer aggregato esegue i fixer singoli perImponibile, Iva, Totale, Aliquota in sequenza. Se un campo non èpresente, l’elemento è trattato come se il fixer singolo avesserestituito status = NOT_FOUND.  Si definiscono: o originalValue: il valore del campo prima dell’applicazione del fixer Singolo (empty se status = NOT_FOUND). o R: set di FixerOutputList; una FixerOutputList ha 4 elementi FixerOutput ognuno dei quali è l’output di uno dei quattro fixer. All’inizio dell’esecuzione del FixerAggregato, R contiene 1 solo elemento. o numErr: numero di elementi dell’unica FixerOutputList contenuta inizialmente in R con status = NOT_FOUND. IF (numERR == 0) THEN o Sia numMULTI il numero di elementi con status = MULTIPLE_RESULTS. 23
  • 30. o IF (numMULTI >= 1) THEN // (Si suppone per semplificare la descrizione numMULTI=1, ossia 1 solo FixerOutput ha Status =MULTIPLE_RESULTS e values = “un insieme di n stringhe”. )  Crea R1 come segue:  Per ogni stringa n di values viene creata ed aggiunta in R1 una nuova FixerOutputList contenente: o i 3 FixerOutput con status OK o un quarto FixerOutput con values= n ELSE //numMulti ==0, ossia 4 FIxerOutput con status OK. o Crea R1 come segue:  Viene creata ed aggiunta in R1 una nuova FixerOutputList contenente:  i 4 FixerOutput con status OK o Viene effettuato un controllo semantico su R1 e vengono eliminati i FixerOutputList che non lo soddisfano. o IF (R1.size == 0) THEN //nessun FixerOutputList ha passato il controllo semantico  Sia folR l’unica FixerOutputList in R.  Per i FixerOutput di folR con Status = OK  Status INCONSISTENT_RESULTS  Values invariato  quality 0.75  errorMessage concatenazione status+values  content originalValue  Per i FixerOutput di folR con Status = MULTIPLE_RESULTS  status INCONSISTENT_RESULTS  values invariato  quality 0.5  errorMessage concatenazione status+values  content originalValue24
  • 31. o ELSE IF (R1.size == 1) THEN //una sola FixedOutputList ha passato il controllo semantico  Sia folR1 l’unica FixerOutputList in R1.  Per tutti i FixerOutput di folR1:  status OK  values invariato  quality 1.0  errorMessage null  content l’unico elemento di values o ELSE //R1.size > 1 più di una FixerOutputList ha passato il controllo semantico (nella pratica non avviene)  Sia folR l’unica FixerOutputList in R  Per ogni folR1 in R1:  Per i FixerOutput di folR con Status = OK o Status invariato o values invariato o quality 0.75 o errorMessage concatenazione status+values o content originalValue  Per i FixerOutput di folR con Status = MULTIPLE_RESULTS o Status MULTIPLE_RESULTS o Values sottoinsieme di values rimasto in folR1 o quality 0.5 o errorMessage concatenazione status+values o content originalValue ELSE IF (numErr == 1) THEN o Sia r l’elemento di R con Status = NOT_FOUND. 25
  • 32. o Sia numMULTI il numero di elementi con status = MULTIPLE_RESULTS. o IF (numMULTI >= 1) THEN // (Si suppone per semplicità numMULTI=1, ossia 1 solo FixerOutput ha Status =MULTIPLE_RESULTS e values = “un insieme di n stringhe”. )  Crea R1 come segue:  Per ogni stringa n di values: o 2 FixerOutput hanno status OK o un terzo FixerOutput ha values = n o Se è possibile calcolare values del quarto FixerOutput sulla base dei precedenti 3 FixerOutput, viene creata ed aggiunta in R1 una nuova FixerOutputList contenente i 4 fixerOutput qui elencati. In caso contrario non viene aggiunto nulla in R1 per n corrente. o ELSE //numMulti ==0, ossia 3 FIxerOutput con status OK.  3 FixerOutput hanno status OK  Se è possibile calcolare values del quarto FixerOutput sulla base dei precedenti 3 FixerOutput, viene creata ed aggiunta in R1 una nuova FixerOutputList contenente i 4 fixerOutput qui elencati. In caso contrario non viene aggiunto nulla in R1. o IF (R1.size == 0) THEN //non è possibile calcolare un content per r.  Sia folR l’unica FixerOutputList in R  Per i FixerOutput di folR con Status = OK  Status INCONSISTENT_RESULTS  values invariato  quality 0.75  errorMessage concatenazione status+values26
  • 33.  content originalValue  Per i FixerOutput di folR con Status = MULTIPLE_RESULTS  status INCONSISTENT_RESULTS  values invariato  quality 0.5  errorMessage concatenazione status+values  content originalValue  Per r:  status NOT_FOUND  values invariato  quality 0.0  errorMessage concatenazione status+values  content originalValueo ELSE IF (R1.size == 1) THEN // unico valore calcolato per il content di r.  Sia folR1 l’unica FixerOutputList in R1  sia suggestedValue il valore calcolato per r.  Per r:  status SUGGESTED_VALUE  values set contenente suggestedValue.  quality 0.25  errorMessage concatenazione status+values  content originalValue.  Per gli altri FixerOutput di folR1:  status OK  values invariato  quality 0.75  errorMessage null  content l’unico elemento di values 27
  • 34. o ELSE //R1.size > 1 è stato possibile calcolare più di un valore per il content di r (nella pratica non avviene)  Sia folR1 l’unica FixerOutputList in R1  Sia setSuggested l’insieme dei valori calcolati per r.  Per r:  status MULTIPLE_SUGGESTED_VALUES  values setSuggested.  quality 0.125  errorMessage concatenazione status+values  content originalValue.  Per i FixerOutput di folR1 con Status = OK  status invariato  values invariato  quality 0.75  errorMessage concatenazione status+values  content originalValue  Per i FixerOutput di folR1 con Status = MULTIPLE_RESULTS  status MULTIPLE_RESULTS  values sottoinsieme di values rimasto in folR1  quality 0.5  errorMessage concatenazione status+values  content originalValue  ELSE //numErr>1 o Per gli elementi di R con Status = OK  status NOT_CONFIRMED_VALUE  values invariato  quality 0.75  errorMessage concatenazione status+values  content originalValue28
  • 35. o Agli gli elementi di R con Status NOT_FOUND oppure MULTIPLE_RESULTS non viene apportata alcuna modifica ai risultati del fixer singolo.VALUTAZIONI QUALITATIVE E QUANTITATIVELe seguenti tabelle riassumono tutti i possibili output dei fixer. Lacolonna modifiche applicate mette in evidenza i campi che vengonoaggiornati nella map nei vari casi. Con T si intende il campo text,con Q il campo quality e con E il campo errorMessage. STATUS MODIFICHE DESCRIZIONE APPLICATE NOTE VALUE Unico valore semanticamente valido T, Q, E OK trovato. MULTIPLE Più valori semanticamente validi Q, E RESULTS trovati. Nessun valore semanticamente Q, E NOT FOUND valido trovato. Il controllo semantico aggregato è Q, EINCONSISTENT Solo fixer fallito, quindi i risultati dati dai fixer RESULTS aggregato singoli erano incoerenti. Il fixer aggregato ha calcolato il Q, E campo con status NOT_FOUND sulla SUGGESTED base degli altri che avevano status Solo fixer VALUE OK o MULTIPLE_RESULTS. Tale aggregato calcolo ha fornito un risultato univoco. Il fixer aggregato ha calcolato il Q, E MULTIPLE campo con status NOT_FOUND sulla Solo fixer SUGGESTED base degli altri che avevano status aggregato VALUE OK o MULTIPLE_RESULTS. Tale calcolo ha fornito più di un valore. Il fixer aggregato non ha elementi a Q, E NOT sufficienza (più di un campo ha Solo fixerCONFIRMED status NOT_FOUND) per confermare aggregato VALUE il risultato del fixer singolo. Tabella 2 – Possibili stati all’uscita di ErrorFixer 29
  • 36. MODIFICHEQUALITY DESCRIZIONE NOTE APPLICATE Unico valore semanticamente valido T, Q, E 1.0 trovato (eventualmente confermato anche dal fixer aggregato). Il valore corretto trovato dal fixer singolo Q, E Solo fixer 0.75 non è confermabile dal fixer aggregato. aggregato 0.5 Più valori semanticamente validi trovati. Q, E Il fixer aggregato ha calcolato il campo Q, E con status NOT_FOUND sulla base degli Solo fixer 0.25 altri che avevano status OK o aggregato MULTIPLE_RESULTS. Tale calcolo ha fornito un risultato univoco. Il fixer aggregato ha calcolato il campo Q, E con status NOT_FOUND sulla base degli Solo fixer 0.125 altri che avevano status OK o aggregato MULTIPLE_RESULTS. Tale calcolo ha fornito più di un valore. Nessun valore semanticamente valido Q, E 0.0 trovato. Tabella 3 – Possibili valori di Quality all’uscita di ErrorFixer30
  • 37. STATUS VALUE QUALITY DESCRIZIONE NOTE Unico valore semanticamente valido OK 1.0 trovato. Il valore corretto trovato dal fixer Solo fixer OK 0.75 singolo non è confermabile dal fixer aggregato aggregato. MULTIPLE Più valori semanticamente validi 0.5 RESULTS trovati. Nessun valore semanticamente NOT FOUND 0.0 valido trovato. Il controllo semantico aggregato è fallito, quindi i risultati dati dai fixerINCONSISTENT Solo fixer 0.75 singoli erano incoerenti. Per il campo RESULTS aggregato specifico, il fixer singolo aveva trovato un unico valore. Il controllo semantico aggregato è fallito, quindi i risultati dati dai fixerINCONSISTENT Solo fixer 0.5 singoli erano incoerenti. Per il campo RESULTS aggregato specifico, il fixer singolo aveva dato Status MULTIPLE RESULTS. Il fixer aggregato ha calcolato il campo con status NOT_FOUND sulla SUGGESTED base degli altri che avevano status Solo fixer 0.25 VALUE OK o MULTIPLE_RESULTS. Tale aggregato calcolo ha fornito un risultato univoco. Il fixer aggregato ha calcolato il MULTIPLE campo con status NOT_FOUND sulla Solo fixer SUGGESTED 0.125 base degli altri che avevano status aggregato VALUE OK o MULTIPLE_RESULTS. Tale calcolo ha fornito più di un valore. Il fixer aggregato non ha elementi a NOT sufficienza (più di un campo ha Solo fixer CONFIRMED 0.75 status NOT_FOUND) per confermare aggregato VALUE il risultato del fixer singolo. Tabella 4 - Relazione tra Status e Quality 31
  • 38. IMPLEMENTAZIONEINTERFACCIA JAVATutti i fixer implementano l’interfaccia ErrorFixer il cui unicometodo esposto è fixErrors.Un ErrorFixer è un correttore di errori specifico per un determinatotipo di campo. Il metodo fixErrors ha come parametri unaMap<SearchedField, ResultTextBlock> che rappresenta l’insieme dicampi da correggere.L’oggetto SearchedField definisce la singola informazione che vienecercata all’interno del documento. I metodi esposti permettono di:  assegnare il tipo di documento cui fa riferimento;  estrarre il tipo di documento cui fa riferimento;  assegnare un nome identificativo dell’informazione cercata;  estrarre il nome identificativo dell’informazione cercata;  assegnare la tipologia di informazione cercata;  estrarre la tipologia di informazione cercata.SearchedField viene utilizzato come chiave nella mappa dei campitrovati e permette di estrarre il ResultTextBlock.L’oggetto ResultTextBlock rappresenta il campo estratto attraversoi valori di quality, errorMessage e text. I metodi esposti permettonodi:  assegnare il valore di text;  assegnare il valore di quality;  assegnare il valore di errorMessage;  estrarre il valore di text;  estrarre il valore di quality;  estrarre il valore di errorMessage;32
  • 39. Il metodo fixErrors di ErrorFixer può modificare le informazionicontenute nella map sulla base dei risultati delle operazioni dirilevazione e correzione d’errore. La modifica prevedel’aggiornamento dei campi text, quality e errorMessage.ORGANIZZAZIONE DEL CODICELa figura seguente mostra come è stato organizzato il progetto intermini di package e classi. Figura 11 - Package e classi del progettoIl package invoiceinspector.commons contiene:  CombinationIterable: classe che implementa Iterable e fornisce le combinazioni semplici di k elementi presi da un set di n elementi. Ad esempio si consideri il set S = {A,B,C} pertanto n=3. Si consideri k=2, ne consegue che si vogliono generare tutte le combinazioni possibili degli elementi di S presi a due a due, pertanto si avranno m = nk = 9 possibili 33
  • 40. combinazioni: {[A,A], [A,B], [A,C], [B,A], [B,B], [B,C], [C,A], [C,B], [C,C]}.  defaultFieldFixers.xml: file che contiene la tabella delle SubstitutionPairs (il file completo è consultabile in Appendice B). Ogni coppia stringa errata-stringa corretta è così descritta: <fixer> <wrong>stringa Errata</wrong> <right>stringa Corretta</right> </fixer>  FixerLoader: classe adibita all’inizializzazione e alla suddivisione delle SubstitutionPair in categorie: o numerolettera; o letteranumero; o stringastringa; o numeronumero. Questa ripartizione non è strettamente necessaria ma è un’ottimizzazione che permette ai fixer di applicare solamente le sostituzioni che portano verso stringhe sintatticamente corrette. Ad esempio se il campo in questione è una data, una correzione numerolettera che porta “2” a diventare “Z”, non ha senso e, grazie a quest’ottimizzazione, non viene presa in considerazione.Il package invoiceinspector.fixers contiene:  ErrorFixer: è l’interfaccia implementata da tutti i fixer. È estesa da SingleFieldFixer per il caso dei fixer singoli ed è implementata da ImponibileIvaTotaleAliquotaErrorFixer per il fixer aggregato.  AbstractErrorFixer: è l’implementazione standard di tutti i fixer singoli ed implementa SingleFieldFixer. Contiene i34
  • 41. metodi e le rispettive implementazioni di default, comuni a tutti i fixer singoli. Viene estesa da: o CodiceFiscaleErrorFixer o ConcatErrorFixer o CurrencyErrorFixer o DateErrorFixer o NumberErrorFixer o PartitaIvaErrorFixer o PivaCfGlobalErrorFixer o RateErrorFixer.  ErrorFixersFactory: è la classe che verrà utilizzata per scegliere quali fixer vanno caricati per il documento da analizzare.Il package invoiceinspector.test contiene alcune classi utilizzate pertestare l’applicazione. Tale package non verrà inglobato nel modulofinale. 35
  • 42. VALUTAZIONE SPERIMENTALEPer effettuare un test significativo, si è considerata una ground-truth di 76 fatture, per un totale di oltre 500 campi. Ai risultatiottenuti dal software di riconoscimento è stato associato il valoreatteso per ogni blocco, così come definito da un operatore che haanalizzato visivamente ogni singola fattura del dataset.Quest’operazione è di fondamentale importanza in quantopermette da un lato di capire qual è la percentuale di campi giàcorretti prima dell’applicazione dei fixer, dall’altro di verificare chele correzioni effettuate abbiano portato al risultato sperato.L’output generato dal modulo di estrazione dei dati, è costituito da1 file csv (Comma Separated Value) per ogni fattura.Si è pensato pertanto di costruire un semplice database per gestirepiù comodamente una tale quantità di dati. Di seguito se ne riportail diagramma fisico. Figura 12 - Diagramma fisico del DB usato per i test36
  • 43. Il software di test estrae dal database una fattura per volta e, sulset di campi ricavato, esegue i fixer. Dal confronto con i valori attesiviene poi aggiornata la statistica. L’output finale è una tabellariassuntiva dei risultati ottenuti.Si è inoltre verificato che il software sia completamente stateless eche funzioni correttamente anche in ambiente multithread.RISULTATISENZA FIXERLa tabella seguente mostra la composizione della ground-truthsenza l’applicazione del software di correzione. OK NOT_OK TOTALE Data 35 (46%) 41 (54%) 76 P.Iva & C. Fiscale 54 (40%) 81 (60%) 135 N° Fattura 22 (39%) 34 (61%) 56Imponibile, Totale, 0 (0%) 76 (100%) 76 Iva, Aliquota Tabella 5 - Situazione ground-truth senza lapplicazione dei fixerCom’è facilmente intuibile dalle percentuali riportate, l’accuratezzanella rilevazione del contenuto cercato è, per i campi singoli,attorno al 40%. Risultati pessimi invece si hanno per il set aggregatodi Imponibile, Iva, Totale ed Aliquota: nessuna delle 4-uple ècorretta. Tuttavia, questo è giustificabile dal fatto che nella maggiorparte delle fatture uno di questi campi non era presente o eratotalmente illeggibile.Per un’ulteriore visione della situazione descritta, si propone ilseguente grafico: in verde chiaro i valori estratti correttamentedall’OCR, in rosso quelli non rilevati. 37
  • 44. Grafico 1 - Situazione ground-truth senza lapplicazione dei fixerCON I FIXERI risultati ottenuti dall’applicazione dei fixer sono statiparticolarmente soddisfacenti. OK_IN_ OK_FIXED SUGGESTED NOT_ OK MULTIPLE TOTALE _BY_FIXER _VALUE FOUND _RESULTS Data 35 33 (+43%) 1 0 7 76P.Iva & C. 54 66 (+49%) 0 0 15 135 FiscaleN° Fattura 22 20 (+36%) 14 0 0 56 Fixer 0 3 (+4%) 0 22 51 76Aggregato Tabella 6 - Situazione ground-truth dopo 1° testUna prima considerazione apparentemente banale ma significativa,è deducibile dalla prima colonna, etichettata con OK.Confrontandola con la corrispettiva della tabella precedente infatti,non si notano differenze e questo dimostra che il software38
  • 45. realizzato assolve all’importante requisito di non introdurre erroriin campi già corretti.La seconda colonna, “OK_FIXED_BY_FIXER”, evidenzia le correzionieffettuate dai vari fixer. L’incremento di prestazioni è notevole edarriva, nel caso migliore, al 49%.La terza colonna, “OK_IN_MULTIPLE_RESULTS”, conteggia i casi incui il valore atteso non è stato trovato in maniera univoca, ma èpresente nel set di possibili candidati. Pertanto un operatore potràscegliere la soluzione corretta fra quelle proposte.La quarta colonna, “SUGGESTED_VALUE”, è una colonna specificaper il fixer aggregato e sottolinea come il fixer aggregato sia stato ingrado di calcolare e suggerire il valore corretto che completa laquartina.La penultima colonna, “NOT_FOUND”, rappresenta gli errori residuidopo l’applicazione dei fixer.La situazione è quindi completamente mutata e la percentualed’errore di data e partita iva/codice fiscale è attorno al 10% controil 60% rilevato in precedenza. Nel caso del numero fattura, ilmiglioramento è stato del 36% ma si nota che in molti casi ilrisultato corretto fa parte dei risultati multipli proposti dal fixer.Un miglioramento meno eclatante ma comunque degno di nota si èottenuto anche nel caso del fixer aggregato. La cosaparticolarmente interessante è che nel 29% dei casi il fixer è stato ingrado di calcolare correttamente il valore mancante e suggerirloall’operatore. Considerando valide anche queste soluzioni, lapercentuale d’errore è passata dal 100% iniziale al 67%. 39
  • 46. Anche in questo caso si propone un grafico riassuntivo. Grafico 2 - Situazione post-fixer 1° testNonostante i risultati soddisfacenti, si sono volute analizzare letipologie di errori residui per verificare che i fixer abbiano svoltocorrettamente il loro compito.L’analisi ha portato alla stesura della tabella 8 consultabile nellapagina seguente.40
  • 47. TIPO VALORE RILEVATO VALORE NOTE CAMPO ATTESOPartita Iva Cod.fise. e Per (. IVA 00930530324 (1) n.00930630324Partita Iva 00046530323 00048530323 (1)Partita Iva Cod fise e Pari IVA n 0093053032e 00930530324Partita Iva 00048630323 00048530323 (1)Partita Iva I0072016032il 00720160324 (3)Partita Iva 00720‘l6032lù 00720160324Partita Iva "007 20 160 2N" 00720160324Partita Iva 0072016032~I 00720160324 (3)Partita Iva IVA 00663400325 00653400325 (1)Partita Iva IVA 00:1.66300327 00166300327 (4)Partita Iva Cod. Fise. e P. IVA 04209G80168 04209680158 (1)Partita Iva "cc.i.a.a. 28866 - M. 861097 - Iscr. 00045290327 (1) Trib.4111 - Cod. Part. IVA 00046290327"Partita Iva c.c.i.a.a. 28865 - 88. 861097 . iacr. 00045290327 Trib.4111 ~ Ccd. Pari. IVrt 000852903Partita Iva "c.c.i.a.a. 28865 - M. 85109? - Iscr. 00045290327 (2) Trib.4111 - Cod Part. IVA 0004529032?"Partita Iva "c.c.i.a.a 28866 - M 851097 - iscr. 00045290327 (1) Trib.4111 - Cod. Part. IVA 00046290327"Data "dei.‘ 3 j Q ‘i j QI f" 13/01/07Data I G/G i/ 07 10/01/07Data ‘ÙIG I/Q i 20/01/07Data g ;. 3/01/07 23/01/07Data ‘‘lr‘G i/G i 24/01/07Data 17/01/2ùod 17/01/2006 Tabella 7 - Errori Residui dopo 1° testImmediatamente si può notare che i casi (1), (2) e (3) potrebberoessere risolti con il seguente aggiornamento della tabellaSubstitutionPairs: 41
  • 48. STRINGA ERRATA SET[STRINGACORRETTA] TIPO 6 5,8 NumberNumber ? 7 SpecialCharNumber il 4 Multichar ~I 4 Multichar Tabella 8 - Aggiornamento SubstitutionPairsLe ultime righe della tabella errori residui evidenziano, invece,quello che in precedenza è stato chiamato errore di distruzione delcontenuto per il quale nessuna correzione è possibile.Di seguito sono descritte le prestazioni (tabella e graficoriassuntivo) ottenute dopo la modifica alle Substitution Pair. OK_IN_ OK_FIXED SUGGESTED NOT_ OK MULTIPLE _VALUE TOTALE _BY_FIXER FOUND _RESULTS Data 35 34 1 0 6 76P.Iva & C. 54 77 0 0 4 135 FiscaleN° Fattura 22 34 0 0 0 56 Fixer 0 3 0 22 51 76Aggregato Tabella 9 - Situazione ground-truth dopo lapplicazione dei fixer42
  • 49. Grafico 3 - Situazione dopo lapplicazione dei fixerCome ci si aspettava, l’aggiornamento ha dato diversi benefici e latabella errori residui aggiornata risulta così: TIPO VALORE RILEVATO VALORE CAMPO ATTESO Partita Iva Cod fise e Pari IVA n 0093053032e 00930530324 Partita Iva 00720‘l6032lù 00720160324 Partita Iva "007 20 160 2N" 00720160324 Partita Iva c.c.i.a.a. 28865 - 88. 861097 . iacr. 00045290327 Trib.4111 ~ Ccd. Pari. IVrt 000852903 Data "dei.‘ 3 j Q ‘i j QI f" 13/01/07 Data I G/G i/ 07 10/01/07 Data ‘ÙIG I/Q i 20/01/07 Data g ;. 3/01/07 23/01/07 Data ‘‘lr‘G i/G i 24/01/07 Data 17/01/2ùod 17/01/2006 Tabella 10 - Errori residui dopo 2° TestGuardando il grafico 3 inoltre, si nota anche un miglioramento delleprestazioni del fixer per il campo “numero fattura” dovutoall’aggiornamento dell’algoritmo di elementSelector descritto nelcapitolo Algoritmo del fixer singolo. 43
  • 50. CONSIDERAZIONI GLOBALISi vedranno ora alcuni grafici che mostrano da altri punti di vista irisultati ottenuti.I grafici 4 e 5 mostrano rispettivamente la percentuale d’errore( ) senza e con l’applicazione dei fixer.Il calcolo tiene conto anche dei campi già corretti primadellapplicazione del fixer. Grafico 4 – Percentuale di errori senza l’applicazione dei fixer Grafico 5 – Percentuale di errori dopo l’applicazione dei fixer44
  • 51. Nel grafico 5, #sbagliate è uguale a:  per i fixer singoli;  per il fixer aggregato. Pertanto vengono contati come sbagliati anche i risultati suggeriti correttamente dal fixer.In altre parole solo i casi in cui il valore di quality è impostato ad 1.0sono considerati corretti:Il grafico 6 evidenzia la percentuale di correzioni fatte o suggeriterispetto alla totalità dei campi presenti nella ground-truth:  Per i fixer singoli:  Per I fixer aggregati: Grafico 6 – Percentuale correzioni fatte rispetto al totale 45
  • 52. Il grafico 7 rappresenta la stessa situazione del grafico 6 ma rispettoai soli errori prima dellapplicazione dei fixer:  Per i fixer singoli:  Per I fixer aggregati: Grafico 7 – percentuali correzioni fatte o suggerite rispetto al totale di errori se non fossero presenti i fixerQuesto grafico evidenzia quindi l’effettivo miglioramento apportatodai fixer alla ground-truth. Per i fixer singoli la percentuale dicorrezioni applicate è dell’86% per la data, del 95% per partitaIva/codice Fiscale ed arriva fino al 100% per il campo numerofattura.46
  • 53. PRESTAZIONIAppurati gli ottimi risultati ottenuti, ci si chiede come siano leprestazioni complessive del sistema. Per analizzarle si è utilizzato lostrumento di profiling offerto dalla piattaforma di sviluppoNetbeans di Sun Microsystems, che permette di verificare qualimetodi occupano per più tempo la CPU e quanta memoriautilizzano. Per dare un’idea dell’hardware a disposizione, il pcutilizzato per i test è il notebook del tesista dotato di processoreIntel Core 2 Duo T8300 a 2.40GHz e 4GB di ram.L’analisi ha preso in considerazione l’esecuzione del programma ditest su tutta la ground-truth ed evidenzia di conseguenzal’andamento medio del sistema.Un’attenta revisione del codice ha portato ad un sostanzialemiglioramento delle prestazioni, rispetto alle prime versionisviluppate, da vari punti di vista. Sono state realizzate delleimplementazioni alternative più efficienti per le porzioni di codicecritiche. Si è passati in questo modo da poco meno di 1 minutoimpiegato dalla prima versione realizzata, a soli 2 secondi perl’analisi e la correzione dell’intera ground-truth (oltre 500elementi). Anche l’occupazione in memoria è calataconsiderevolmente: dai 200MB necessari prima della revisione, agli11MB della versione finale. Questi dati sono stati ottenuti dallamedia di 10 esecuzioni complete del software e la varianzariscontrata e circa del 4%. Pertanto, mediamente, un fixer è ingrado di correggere un dato in circa 3,5mS.Infine si è verificato che il tutto funzionasse anche in ambientemultithreaded mediante l’uso dell’interfaccia ExecutorService checonsente facilmente di creare un thread pool. Sono stati quindisuddivisi gli esperimenti in 6 thread paralleli che utilizzano in modoconcorrente i fixer. 47
  • 54. I risultati prodotti in ambiente multithreaded sono stati confrontaticon quelli ottenuti in ambiante non concorrente.Non sono stati riscontrati problemi di sorta, tuttavia il tempoimpiegato è all’incirca il medesimo; questa situazione ègiustificabile dal fatto che se uno dei campi contiene una parteconsistente di rumore, questo fa sì che vengano generate un grannumero di combinazioni di possibili risultati; uno dei threadpertanto rimane bloccato ad eseguire una certa correzione facendosalire il tempo di esecuzione.Questo dimostra come la criticità di un sistema di correzione diquesto tipo sia nella generazione di tutte le possibili correzioni perla stringa data.48
  • 55. CONCLUSIONICome evidenziato nel capitolo Valutazione sperimentale, i risultatiottenuti dal componente software realizzato sono statiparticolarmente soddisfacenti sia dal punto di vista dellefunzionalità, sia da quello delle prestazioni in termini di risorse dicalcolo. Pertanto si può affermare che gli obiettivi preposti sonostati raggiunti.Il principale problema riscontrato è che essendo un progetto incontinuo sviluppo, si sono presentate in itinere parecchie modificherispetto all’idea originale. Le varie componenti per questo motivosono state riviste più volte fino a pervenire alla versione definitiva.Il lavoro svolto mi ha permesso di approfondire le conoscenzeacquisite riguardo alla programmazione ad oggetti, in particolareper quanto riguarda il linguaggio Java. Il fatto di dover creare uncomponente da inserire in una complessa infrastruttura software,ha richiesto di sottostare pedissequamente a specifiche moltorestrittive e a paradigmi di programmazione standard chegarantiscono la manutenibilità e l’affidabilità del software.Per quanto concerne gli sviluppi futuri, si prevede il porting inproduzione del modulo realizzato. Inoltre è facilmenteimmaginabile l’estensione del lavoro realizzato a documentiafferenti ad altre classi sviluppando quindi altri fixer. 49
  • 56. APPENDICE A: DOCUMENT GENERATORDocument generator è un software per la generazione di k difatture afferenti ad n modelli realizzato dal tesista come attività ditirocinio presso il laboratorio di reti dell’Università degli studi diTrieste. Di seguito se ne riportano le specifiche tecniche.SPECIFICHE TECNICHEDefinizione di modelloUn modello di fattura è dato da: 1. un insieme di modello di blocchi 2. un insieme di modello di tabelleOgni modello di blocco ha: 1. id (univoco) 2. tipo (enum: immagine, testo) 3. posizione (x, y) e dimensione (w, h*): o sono 4 distribuzioni numeriche; per ognuna il modello comprende il tipo di distribuzione (normale o uniforme) e i parametri (mu e sigma o min e max) o nota: per la maggior parte si tratterà di distribuzioni fisse, cioè normali con sigma=0 o nota: per blocchi di testo ed immagine non si definisce la distribuzione per h: il valore dellaltezza del blocco dipenderà da dimensione e quantità di testo o dalle dimensioni dellimmagine. 4. pagina (int) 5. probabilità di essere presente 6. circondato da riquadroSolo per i modelli di blocchi di testo: 1. font: o famiglia o dimensione o decorazione (bold, italic, underline)50
  • 57. 2. tipo etichetta (enum: nessuno oppure tipo) o il tipo va scelto tra un elenco finito: totale, imponibile, data, codice fiscale o partita iva cliente, codice fiscale o partita iva emettitore, numero fattura) o deve essere possibile poter aumentare questi tipi in futuro (non per uno specifico modello, ma per il generatore di modelli)3. se il tipo etichetta è diverso da nessuno, tabella di frequenza delle possibili diciture (mappa chiave=tipo, valore=probabilità (float)) o la mappa contiene chiavi prese da un insieme predefinito per ogni tipo, ad esempio per totale: "totale", "tot.", "importo totale", ecc...4. tipo valore (enum: nessuno oppure tipo) o il tipo va scelto tra un elenco finito, stesso discorso del punto 15. se il tipo valore è diverso da nessuno, tabella di frequenza dei possibili formati (mappa chiave=tipo, valore=probabilità (float)) o ad esempio per il totale: "€ ###,##", "###.##", "euro ###,##", ...6. se il tipo valore è diverso da nessuno: o può esserci un riferimento allid di un altro blocco che ha lo stesso tipo valore, che dirà al generatore che va utilizzato lo stesso valore casuale dentro al blocco; o oppure, può esserci un riferimento allid di una tabella che ...7. se tipo etichetta o tipo valore sono entrambi nessuno, tipo testo (enum: fisso, casuale): o se fisso: specificare il testo o se casuale: specificare lunghezza media in caratteri 51
  • 58. Solo per i modelli di blocchi immagine: 1. Contenuto (enum: fisso, casuale): o se fisso: specificare limmagine o se variabile: specificare linsieme da cui scegliere a caso o nota: le dimensioni sono già specificate dai parametri del blocco 2. Presente su ogni pagina (boolean) 3. Rotazione (distribuzione numerica, vedi punto 3 del modello di blocco) 4. Può sovrapporsi (boolean) o nota: se sì, può sovrapporsi ad altri blocchi, serve per rappresentare immagini di timbri o cose similiOgni modello di tabella ha: 1. id (univoco) 2. posizione (x, y) e dimensione (w), vedi punto 3 del modello di blocco 3. distanza media tra le righe 4. pagina 5. header (boolean, indica se è presente o meno) 6. header font (vedi punto 1 del modello di blocco di testo) 7. line font (font del resto della tabella) 8. se header è true, nomi colonne (elenco di stringhe) 9. elenco di tipi colonne (stesso numero delle colonne del punto 6), ogni tipo colonna ha: o tipo (enum: testo fisso, testo casuale, stringa casuale formattata)  se testo fisso: il testo fisso  se testo casuale: lunghezza media in caratteri  se stringa casuale formattata: il formato o probabilità di essere vuota o larghezza in percentuale della tabella52
  • 59. FUNZIONAMENTOPer rendere semplice l’utilizzo del software si è realizzataun’interfaccia grafica che permette anche ad un utente non espertodi generare facilmente modelli e fatture relative.La tab Genera fatture da Nuovi Modelli permette di crearedapprima un certo numero di modelli e poi, sulla base di questi,generare un certo numero di fatture per ogni modello.Nella generazione di un modello è possibile definire che campidevono essere presenti e con che cardinalità. Inoltre possonoessere presenti un logo dell’azienda, preso casualmente da uninsieme di immagini, e dei timbri che possono sovrapporsi ad altrocontenuto. Figura 13 - Document Generator: generazione fatture da nuovi modelliPer ogni campo è possibile definire:  Se può o meno avere un’etichetta (ad esempio Totale) prima del valore;  se quest’etichetta può variare tra una fattura e l’altra;  se può esserci uno spazio bianco tra etichetta e nome; 53
  • 60.  qual è la dimensione minima e massima del carattere usato;  qual è l’intensità del nero, per simulare una stampa degradata.È possibile definire un certo numero di blocchi di testo con questecaratteristiche:  il contenuto è generato casualmente a partire da un file contenente un testo arbitrariamente lungo;  la dimensione dei blocchi di testo è definibile dall’utente.È possibile definire un certo numero di Tabelle caratterizzate da:  numero minimo e massimo di righe;  numero di colonne;  dimensioni delle tabelle;  presenza o assenza di header  presenza o assenza di bordiSulla base dei modelli così generati si possono poi generare uncerto numero di fatture con le seguenti caratteristiche:  Dimensione dell’immagine in pollici e risoluzione in DPI(Dots Per Inch);  Traslazione e Rotazione dell’immagine per simulare l’effetto generato da una rotazione della fattura sul piano dello scanner durante una scansione.È possibile anche salvare i modelli generati.54
  • 61. La tab Genera Fatture da Modelli Preesistenti permette di crearefatture sulla base di modelli generati in precedenza. L’interfacciapermette anche di visualizzare un’anteprima del modello che sivuole utilizzare. Si possono impostare dimensione, traslazione erotazione dell’immagine. Figura 14 - Document Generator: generazione fatture da modelli preesistenti.È possibile anche eliminare un modello precedentemente salvato.Nella figura seguente un esempio di fattura generata: 55
  • 62. Figura 15 – esempio di fattura generata da Document Generator56
  • 63. APPENDICE B: FILE DI CONFIGURAZIO NE SUBSTITUTIONPAIRS<?xml version="1.0" encoding="UTF-8"?><!-- Document : defaultFieldFixers.xml Created on : 16 ottobre 2010, 11.50 Author : GazzinMatteo Description:--><typeoffield> <fixer> <wrong>N</wrong> <right>11</right> </fixer> <fixer> <wrong>11</wrong> <right>N</right> </fixer> <fixer> <wrong>o</wrong> <right>0</right> </fixer> <fixer> <wrong>O</wrong> <right>0</right> </fixer> <fixer> <wrong>/</wrong> <right>1</right> </fixer> <fixer> <wrong>I</wrong> <right>1</right> </fixer> <fixer> <wrong>I</wrong> <right>7</right> </fixer> <fixer> <wrong>i</wrong> <right>1</right> </fixer> <fixer> <wrong>l</wrong> <right>1</right> </fixer> 57
  • 64. <fixer> <wrong>!</wrong> <right>1</right> </fixer> <fixer> <wrong>G</wrong> <right>6</right> </fixer> <fixer> <wrong>Q</wrong> <right>0</right> </fixer> <fixer> <wrong>D</wrong> <right>0</right> </fixer> <fixer> <wrong>B</wrong> <right>8</right> </fixer> <fixer> <wrong>Z</wrong> <right>2</right> </fixer> <fixer> <wrong>T</wrong> <right>7</right> </fixer> <fixer> <wrong>S</wrong> <right>5</right> </fixer> <fixer> <wrong>z</wrong> <right>2</right> </fixer> <fixer> <wrong>s</wrong> <right>5</right> </fixer> <fixer> <wrong>0</wrong> <right>o</right> </fixer> <fixer> <wrong>0</wrong>58
  • 65. <right>O</right></fixer><fixer> <wrong>1</wrong> <right>I</right></fixer><fixer> <wrong>1</wrong> <right>i</right></fixer><fixer> <wrong>1</wrong> <right>l</right></fixer><fixer> <wrong>1</wrong> <right>!</right></fixer><fixer> <wrong>6</wrong> <right>G</right></fixer><fixer> <wrong>0</wrong> <right>D</right></fixer><fixer> <wrong>8</wrong> <right>B</right></fixer><fixer> <wrong>2</wrong> <right>Z</right></fixer><fixer> <wrong>5</wrong> <right>S</right></fixer><fixer> <wrong>6</wrong> <right>5</right></fixer><fixer> <wrong>6</wrong> <right>8</right></fixer> 59
  • 66. <fixer> <wrong>il</wrong> <right>4</right> </fixer> <fixer> <wrong>~I</wrong> <right>4</right> </fixer> <fixer> <wrong>&#63;</wrong><!--"?"--> <right>7</right> </fixer></typeoffield>60
  • 67. RINGRAZIAMENTIAncora una volta il primo e più grande ringraziamento va aglisponsor mamma Cela e papà Gigi che con infinita pazienza hannosaputo attendere questo importante momento. Non potrò mairipagare quanto mi è stato incondizionatamente dato in questianni. Grazie di cuore.Ringrazio il mio fratellone Massimo per avermi sopportato quandogli sbalzi d’umore mi rendevano intrattabile, per tutti gli annipassati insieme in taverna giocando Barcellona – Real Madrid con ilFIFA di turno e per esserci sempre, in generale… il fratellone èsempre il fratellone! Lo ringrazio anche per la questione dei 50euro… anche se solo in pochi potranno capire a cosa mi riferisco… :)Ringrazio il Prof. Ing. Alberto Bartoli che mi ha dato la possibilità direalizzare questo elaborato. Lo ringrazio in particolare per le e-maildi incoraggiamento, che in qualche occasione mi ha inviato, e chemi hanno spronato a proseguire con entusiasmo il lavoro.Un doveroso ringraziamento va ai ragazzi del laboratorio: Giorgio inprimis per avermi seguito passo passo nella realizzazione delprogetto, Eric per la correzione della tesi all’ultimo minuto, Marco,Enrico ed Andrea per essere stati sempre disponibili.Ringrazio la nonna Maria che purtroppo non sta attraversando unperiodo facile. La ringrazio per avermi sempre sostenuto, per avercercato sempre qualche parola di conforto nei momenti difficili eper quel “Forti Sempre” che ormai è un motto per noi cugini. Speroche la felicità che deriva dal conseguimento di questo traguardopossa in qualche modo aiutarla a superare le recenti difficoltà. Unabbraccio forte forte e mi raccomando, Forti Sempre! 61
  • 68. Ringrazio la zia Paola e quel “ eh, a coa a crigoa ciuti”, anche leipurtroppo non attraversa un bel momento, ringrazio la nonnaMariucci e mi scuso con lei se ultimamente sono passato pochevolte a trovarla.Ringrazio gli zii dee gafaree Fausti e Stefy che mi chiamanoIngegnere da quando ho 15 anni! Finalmente ce l’abbiamo fatta!!!Ringrazio la zia Mari, approfitto per farle anche gli auguri :), e lo zioGuido. Ringrazio lo zio Paolo per le strette di mano, gli zii Andrea eDaniela.Ringrazio i cugini dee gafaree: il cugino grande Andrea, miomentore in fatto di scelte di studio; il fratello del cugino grande,Daniele e gli sconti alla SME :); Davide che era un bambino quandoho iniziato l’università ed ora è un quasi un uomo… ma questacredo sia colpa mia :); Filippo che sa a memoria il programmi dellamia dockbar :). Ringrazio anche i cugini deà del punt Alberto eChiara.Ringrazio gli amici senza nominarne nessuno, chi sa di essereimportante per me non ha bisogno d’esser nominato, chebrinderanno e festeggeranno con me questo traguardo raggiunto.Ringrazio i vecchi compagni d’appartamento: Andrea, Fabio, Nicola,quel papavero dell’Enz e il rito della pizza al martedì-mercoledì-giovedì-quandocapita, Claudia ma soprattutto Epsilon, Willy e il fuBasilio! Ringrazio infine tutti quelli che la fretta mi ha fatto dimenticare inqueste poche righe e che si meritavano un grazie…62
  • 69. BIBLIOGRAFIAGlassfish. (s.d.). GlassFish - Open source application server. Tratto ilgiorno 03 2011 da http://glassfish.java.net/Holley, R. (2009, Marzo/Aprile). How Good Can It Get? Analysingand Improving OCR Accuracy in Large Scale Historic NewspaperDigitisation Programs. Retrieved 03 09, 2011, fromhttp://www.dlib.org:http://www.dlib.org/dlib/march09/holley/03holley.htmlKukich, K. (1992). Techniques for Automatically Correcting Wordsin. ACM Computing Surveys , 24(4):377–439.Medvet, E., Bartoli, A., & Davanzo, G. (2010). A probabilisticapproach to printed document understanding. INTERNATIONALJOURNAL ON DOCUMENT ANALYSIS AND RECOGNITION .Ministero delle Finanze. (1977, Gennaio 13). Decreto del 23dicembre 1976 n. 13813. Tratto il giorno Ottobre 2010 da CeRDEF -Documentazione economica e finanziaria:http://dt.finanze.it/DocTribFrontend/RS1_HomePage.jspMySql. (s.d.). MySql - The worlds most popular open sourcedatabase. Tratto il giorno 03 28, 2011 da http://www.mysql.com/Netbeans. (s.d.). Netbeans. Tratto il giorno 03 28, 2011 dahttp://netbeans.org/Oracle - EJB. (s.d.). Enterprise JavaBeans Technology. Tratto ilgiorno 03 2011 da Oracle Technology Network:http://www.oracle.com/technetwork/java/javaee/ejb/index.htmlOracle - J2EE. (s.d.). Java EE at a Glance. Tratto il giorno 03 2011 daOracle Technology Network:http://www.oracle.com/technetwork/java/javaee/overview/index.html 63
  • 70. Sorio, E., Bartoli, A., Davanzo, G., & Medvet, E. (09-2010). OpenWorld Classification of Printed Invoices. The ACM Symposium onDocument Engineering. Manchester.64