Estrazione automatica di informazioni da documenti cartacei: progetto e realizzazione di un sistema di supervisione
Upcoming SlideShare
Loading in...5
×
 

Estrazione automatica di informazioni da documenti cartacei: progetto e realizzazione di un sistema di supervisione

on

  • 2,524 views

 

Statistics

Views

Total Views
2,524
Views on SlideShare
2,524
Embed Views
0

Actions

Likes
1
Downloads
34
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Estrazione automatica di informazioni da documenti cartacei: progetto e realizzazione di un sistema di supervisione Estrazione automatica di informazioni da documenti cartacei: progetto e realizzazione di un sistema di supervisione Document Transcript

  • UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica ESTRAZIONE AUTOMATICA DI INFORMAZIONI DA DOCUMENTI CARTACEI: PROGETTO E REALIZZAZIONE DI UN SISTEMA DI SUPERVISIONE Laureando: Relatore: Luca Bressan Prof. Alberto Bartoli Correlatori: Prof. Eric Medvet Ing. Giorgio Davanzo ANNO ACCADEMICO 2009/2010
  • Dedicato a mamma e papà, a nonna Silvana, a nonna Armanda, al nonno Nini, al nonno Massimo ed al “barba” Luciano. Grazie.
  • Sommario 1 Introduzione ................................................................................ 1 2 Scenario ....................................................................................... 5 2.1 Il sistema di estrazione automatica di informazioni da documenti cartacei ........................................................................... 5 2.1.1 Funzionamento del SEAD .............................................. 5 2.1.2 Contributo apportato al SEAD preesistente ................... 8 3 Analisi ....................................................................................... 11 3.1 Definizione delle funzionalità richieste ............................... 11 3.2 Documento in ingresso ........................................................ 13 3.2.1 Informazioni da validare............................................... 13 3.2.2 Diagramma di stato di un SearchedField ...................... 14 3.3 Definizione delle componenti software da realizzare .......... 18 3.4 Flowchart applicazione client .............................................. 20 3.5 Progettazione dell’interfaccia grafica .................................. 21 3.5.1 Prototipizzazione .......................................................... 21 4 Tecnologie utilizzate ................................................................. 25 4.1 Scelta delle tecnologie ......................................................... 25 4.2 Java Enterprise Edition 6 ..................................................... 26 4.3 Enterprise Java Bean ............................................................ 27 4.4 Java Persistence Api (JPA) .................................................. 28 4.5 Google Web Toolkit 2.0 (GWT).......................................... 28 4.5.1 Caratteristiche principali............................................... 28 4.5.2 Compatibilità con il linguaggio Java ............................ 29 4.5.3 Deferred binding ........................................................... 30 4.5.4 Sviluppo di GUI con GWT........................................... 30 4.5.5 RPC............................................................................... 31 5 Interfaccia grafica ...................................................................... 33 5.1 Come si presenta .................................................................. 33 I
  • Sommario 5.2 Utilizzo ................................................................................. 34 5.2.1 Esempio di utilizzo........................................................ 36 6 Implementazione........................................................................ 41 6.1 Struttura del progetto ............................................................ 41 6.1.1 Struttura del SEAD ....................................................... 41 6.1.2 Struttura del sistema di supervisione ............................ 42 6.2 Business e Data Tier ............................................................. 44 6.2.1 Moduli di interfacciamento ........................................... 44 6.2.2 Entità definite nel business tier ..................................... 46 6.2.3 Moduli di servizio ......................................................... 50 6.3 Web tier ................................................................................ 52 6.3.1 Services : interfacce ...................................................... 52 6.3.2 Services : implementazione .......................................... 53 6.3.3 Entity adapters............................................................... 56 6.3.4 GWT entities .................................................................57 6.3.5 GWT components ......................................................... 61 6.3.6 Client ............................................................................. 61 7 Conclusioni ................................................................................ 67 7.1 Obiettivi raggiunti ................................................................ 67 7.2 Considerazioni personali ...................................................... 68 8 Riferimenti ................................................................................. 71 II
  • Introduzione 1 Introduzione È da ormai quindici anni che è in atto un progressivo processo di digitalizzazione della documentazione cartacea. Inizialmente l’interesse principale era una più efficiente archiviazione in termini di spazio ed una maggiore facilità nella gestione degli archivi. Il passo successivo è stato spostare l’attenzione dalla gestione del documento alla gestione delle informazioni contenute in esso. In letteratura molte delle pubblicazioni riguardanti l’estrazione automatica di informazioni da documenti cartacei sono incentrate sull’applicazione nella gestione di fatture [2, 3, 4] e moduli di raccolta dati [5]. Ciò è dovuto alla rilevanza economica della gestione di questo tipo di documenti sia dal punto di vista dei costi che dei volumi generati. Si stima infatti che la gestione di una fattura cartacea abbia un costo di 13$ mentre [5] riporta che il numero di moduli cartacei gestiti dalla pubblica amministrazione giapponese in un anno sia superiore a due miliardi. I sistemi di document understanding implementano varie tecniche di elaborazione ed analisi delle immagini per estrarne il contenuto informativo; tuttavia, per quanto efficienti possano essere gli algoritmi 1
  • Introduzione sviluppati ed implementati si rende necessario un apporto da parte dell’utente. Le fasi in cui è sicuramente necessaria la supervisione dell’operatore sono l’addestramento del sistema e la validazione del risultato della elaborazione. In questa tesi è stato progettato e realizzato il sistema di supervisione da integrare all’interno di un sistema di document understanding realizzato presso il laboratorio di “Reti di calcolatori” del D.E.E.I. – Università di Trieste. L’interfaccia del sistema di supervisione è una applicazione web eseguita nel browser dell’utente. I dati da presentare, frutto della elaborazione del documento cartaceo da parte del sistema di estrazione automatica di informazioni, vengono forniti all’applicazione tramite un meccanismo di comunicazione client/server basato su servlet. Nell’ambito di questa tesi sono stati realizzati una interfaccia web di supervisione, le componenti software lato server necessarie alla comunicazione client/server e le componenti software necessarie per garantire la persistenza su database delle informazioni validate. La realizzazione del progetto ha previsto le seguenti fasi:  studio del sistema preesistente;  studio delle tecnologie utilizzate;  analisi delle funzionalità da implementare;  definizione delle componenti software da realizzare;  sviluppo;  test. Nel prosieguo del documento verranno trattati più in dettaglio gli aspetti della realizzazione. Nel capitolo 2 viene introdotto lo scenario in cui viene inserito il sistema sviluppato. Nel capitolo 3 viene fatta l’analisi delle funzionalità richieste, del generico documento elaborato e delle componenti software da realizzare. Il capitolo 4 introduce le tecnologie utilizzate. 2
  • Introduzione Il capitolo 5 presenta una descrizione dell’interfaccia grafica ed una guida d’uso. Nel capitolo 6 si descrivono in dettaglio gli aspetti più salienti dell’implementazione. Infine il capitolo 7 contiene le conclusioni sul lavoro svolto. 3
  • Scenario 2 Scenario 2.1 Il sistema di estrazione automatica di informazioni da documenti cartacei Il modulo sviluppato è parte di un Sistema per la Estrazione Automatica di informazioni da Documenti (d’ora in avanti per identificare questo sistema si utilizzerà l’acronimo SEAD). Lo scopo di questo sistema è automatizzare l’estrazione delle informazioni da documenti cartacei inviati e l’inserimento delle stesse in un sistema informativo. Il funzionamento del SEAD si basa su algoritmi di estrazione sviluppati ed implementati presso il laboratorio di “Reti di Calcolatori” del D.E.E.I. – Università di Trieste. Questi algoritmi [1] sono sottomessi per la pubblicazione internazionale. 2.1.1 Funzionamento del SEAD Uno dei possibili scenari di utilizzo del SEAD è la gestione della documentazione fiscale dei clienti da parte di commercialisti. Anziché inserire manualmente le informazioni all’interno di un qualche generico sistema di gestione documentale il commercialista si limiterebbe alla scannerizzazione del documento originale. 5
  • Scenario L’immagine scannerizzata viene passata in gestione al SEAD il quale provvederà all’estrazione delle informazioni di interesse per la tipologia di documento fornito e al salvataggio delle stesse su una base dati. Il contenuto informativo di un documento dipende dalla sua tipologia (ad esempio le informazioni presenti in una fattura differiscono dalle informazioni presenti in un modulo CUD ). Si definisce classe di appartenenza di un documento l’insieme dei documenti che fanno riferimento ad una medesima tipologia. Esempi di possibili classi possono essere la classe delle fatture, la classe delle bolle, la classe degli scontrini fiscali, ecc. Documenti appartenenti alla stessa classe contengono le stesse informazioni. La singola informazione presente in un documento viene definita campo. Ad esempio in una fattura sono presenti i campi “Numero fattura”, “Data emissione”, “partita IVA fornitore”, ecc. Documenti appartenenti alla stessa classe possono presentare una diversa disposizione dei campi. Si definisce modello l’insieme dei documenti appartenenti alla stessa classe che presentano il medesimo layout nella disposizione dei campi. Nel caso della gestione delle fatture, ad esempio, fatture emesse mediante il medesimo software presenteranno la stessa disposizione dei campi; verrà quindi applicato il medesimo modello nel loro trattamento. Queste tre definizioni sono necessarie alla comprensione del seguente diagramma di flusso. Il diagramma si basa sul funzionamento del SEAD sviluppato presso il laboratorio di “Reti di calcolatori”. 6
  • Scenario Figura 1: Diagramma di flusso del sistema di elaborazione automatica di documenti Il documento inviato dall’utente viene inserito in una coda. Cominciata la elaborazione si procede al trattamento dell’immagine 7
  • Scenario (deskew e binarizzazione). Il sistema quindi cerca di capire, in base all’analisi dell’immagine, la classe di appartenenza del documento. Successivamente alla elaborazione da parte del OCR si cerca il modello da applicare al documento. Nel caso in cui il sistema è certo del modello da applicare si prosegue con l’estrazione dei campi . Se il sistema non è in grado di scegliere il modello corretto da applicare (impossibilità di scelta tra due o più modelli oppure non è ancora stato definito un modello adeguato) il documento viene inserito in una coda manuale gestita da un operatore umano. L’operatore umano provvederà se necessario a definire un nuovo modello ed eventualmente a creare un nuovo cluster (insieme di documenti il cui layout è assimilabile) cui associarlo. 2.1.2 Contributo apportato al SEAD preesistente Osservando il diagramma di flusso si può identificare il lavoro svolto per questa tesi nella implementazione dei due blocchi azzurri contornati di rosso “operatore inizializza µ*, estrazione campi” e “operatore umano corregge documento D di modello µ”, dove µ e µ* indicano rispettivamente il modello applicato al documento ed il modello applicato al documento non ancora inizializzato. I due blocchi rispondono ad esigenze diverse, tuttavia condividono l’implementazione in quanto le operazioni da svolgere da parte dell’operatore sono le stesse. Il blocco “operatore inizializza µ*, estrazione campi” rappresenta la fase di inizializzazione del nuovo modello associato al documento in elaborazione. Riceve in ingresso un documento al quale viene applicato un modello non inizializzato. Un modello non inizializzato è un modello che non contiene le informazioni sulla localizzazione dei campi all’interno del documento. In questa fase è necessaria l’estrazione manuale da parte dell’operatore di tutti i campi all’interno del documento. L’estrazione manuale avviene mediante selezione dei blocchi di testo generati dall’OCR. Tramite questa operazione l’operatore fornisce le indicazioni sulla posizione dei campi. 8
  • Scenario Il SEAD, dovendo successivamente gestire documenti basati sullo stesso modello utilizzerà le informazioni fornite tramite il sistema di supervisione per estratte i campi cercati in maniera automatica. Il blocco “operatore umano corregge documento D di modello µ” rappresenta la fase di validazione ed eventuale correzione del responso generato dal SEAD. L’estrazione automatica dei campi si basa sulla valutazione di un indice di qualità. Questo indice di qualità è la probabilità che un campo si trovi in una data posizione e che sia contenuto in un dato blocco di testo estratto dall’OCR. Nelle prime elaborazioni di un nuovo modello è possibile che il SEAD non sia in grado di estrarre il campo o che lo faccia erroneamente (ad esempio il campo cercato è posizionato in una zona con alta densità di testo e quindi di blocchi generati dall’OCR). Tramite il sistema di supervisione implementato l’operatore può dare conferma della correttezza dell’estrazione automatica avvenuta o correggere l’eventuale errore mediante selezione manuale. La conferma o la correzione della estrazione serve ad aggiornare il sistema di estrazione automatica. 9
  • Analisi 3 Analisi 3.1 Definizione delle funzionalità richieste L’obiettivo del lavoro svolto è la realizzazione di un sistema per la supervisione e correzione del risultato della elaborazione del documento cartaceo eseguito dal sistema di elaborazione automatica di documenti. La realizzazione di un sistema di supervisione si rende necessaria per motivi legati sia alla produttività ed all’utilizzo da parte dell’utente finale sia alla necessità di avere un feedback sulla correttezza dei risultati prodotti dal SEAD. Dato un documento cartaceo in entrata al SEAD, ipotizzando che il sistema abbia riconosciuto correttamente la classe cui appartiene il documento originale ed abbia selezionato il modello corretto per la estrazione dei dati, per ogni campo all’interno del documento si può andare incontro a tre possibili scenari : 11
  • Analisi 1. il sistema ha riconosciuto correttamente il campo all’interno del documento sia per quel che riguarda la posizione sia il testo estratto dall’OCR; 2. il sistema ha riconosciuto correttamente la posizione del campo nel documento ma l’estrazione del testo ha prodotto degli errori; 3. il sistema non ha riconosciuto correttamente la posizione del campo (in questo caso la correttezza del testo estratto perde significato). Il modulo da sviluppare deve fornire gli strumenti per risolvere gli scenari 2 e 3 e dare conferma della effettiva correttezza dello scenario 1. Tale operazione non può essere eseguita dal software ma necessariamente da un operatore. Per l’utilizzatore è importante dare conferma della correttezza della estrazione dei campi in quanto consumatore delle informazioni e quindi interessato alla loro esattezza sia riguardo la localizzazione all’interno del documento sia la correttezza del valore estratto. Il tutto deve essere fattibile in maniera estremamente rapida ed intuitiva, in modo da mantenere elevato il grado di automazione e l’efficienza del processo complessivo. Per il sistema è importante avere conferma della corretta localizzazione dei campi all’interno del documento, in quanto tale informazione serve per aggiornare il sistema di selezione dei blocchi nella successiva elaborazione di documenti appartenenti alla medesima classe e che utilizzano il medesimo modello. La correttezza dell’estrazione del testo dal documento è relativamente meno importante in quanto tale operazione è demandata al modulo OCR, il quale viene fornito da terze parti (in ogni caso in fase di sviluppo si è tenuto conto della qualità dell’estrazione per la scelta del software più adatto). In sintesi le funzionalità richieste sono :  caricamento del documento elaborato;  visualizzazione dell'elenco dei campi da estrarre a seconda del modello del documento (ad esempio partita iva, codice fiscale, etc.); 12
  • Analisi  evidenziazione sull’immagine del documento dei blocchi di testo contenenti i campi cercati;  funzione di conferma della correttezza dell'estrazione effettuata;  funzione di modifica e correzione dell’estrazione effettuata. Nello specifico della modifica deve essere possibile :  correggere il valore del testo estratto;  rimuovere blocchi di testo selezionati erroneamente dal sistema;  selezionare il blocco corretto, se presente, nel documento. 3.2 Documento in ingresso Il modulo da sviluppare riceve in input un documento elaborato dal SEAD. Questo documento è un oggetto che espone i metodi per accedere alle informazioni estratte dal documento cartaceo originario. Tra queste informazioni vi sono il proprietario, la data di caricamento, lo stato di elaborazione ed altre che verranno descritte successivamente. 3.2.1 Informazioni da validare Le informazioni che necessitano di essere validate da un operatore sono contenute in una mappa la cui coppia chiave/valore viene definita dal nome del campo cercato (es.: partita iva, numero fattura, ecc.) e da una lista di blocchi di testo estratti dall’OCR che il sistema ha riconosciuto contenere il campo di interesse Per ogni campo cercato all’interno del documento il sistema tenta di associare uno o più blocchi di testo. Vi sono tre possibili casi in cui il sistema non può decidere quale blocco assegnare ad un determinato campo : 1. il sistema non possiede abbastanza informazioni per decidere quale blocco assegnare ad un determinato campo. Dovuto ad un addestramento non sufficiente; 2. il campo cercato è effettivamente assente nel documento; 3. il campo è presente nel documento, ma il software OCR non ha riconosciuto il blocco relativo e quindi il sistema non ha potuto selezionarlo. 13
  • Analisi 3.2.2 Diagramma di stato di un SearchedField Il sistema di supervisione deve essere in grado di gestire tutte le possibili configurazioni in uscita dal SEAD. A sua volta il sistema di supervisione deve produrre un documento validato dall’operatore umano che servirà per il retuning del SEAD. Risulta quindi necessario definire un diagramma di stato in cui si evidenzino tutti gli stati possibili in uscita dal SEAD per il singolo campo cercato, i possibili stati d’uscita dal sistema di supervisione e le azioni che determinano un eventuale passaggio di stato. La necessità di realizzare tale diagramma si è palesata durante lo sviluppo del sistema di supervisione qui descritto. Nelle fasi iniziali del progetto si era semplificato eccessivamente l’insieme dei possibili stati in uscita dal SEAD e dal sistema di supervisione generando quindi delle ambiguità sia nella definizione degli stati possibili sia sulle azioni necessarie al passaggio da uno stato all’altro. Si è quindi reso necessario approfondire in modo considerevole l’analisi di questo specifico aspetto. Per descrivere lo stato di un campo vengono utilizzate quattro variabili booleane. Lo stato di un campo viene determinato da quattro variabili interne. Il valore delle quattro variabili booleane viene definito dalle relazioni tra le variabili interne. Le quattro variabili interne sono :  V_i, Valore del campo nel documento;  R_i, Blocco di testo individuato dall'ocr il contenente il campo;  R_o, Blocco di testo assegnato al campo nel documento in uscita dal sistema di supervisione;  V_o, Valore associato al campo nel documento in uscita dal sistema di supervisione. V_i può assumere un valore oppure essere null. R_i può essere un blocco (rappresentato tramite le coordinate del punto top-left, la larghezza e l’altezza) oppure null. 14
  • Analisi Le quattro variabili booleane sono: 1. input-value-exists (immodificabile): V_i != null; 2. input-textblock-exists (immodificabile): R_i != null; 3. output-textblock-correct: R_o == R_i; 4. output-value-correct: V_o == V_i. Lo scopo del sistema di supervisione è fare in modo che vengano soddisfatte le condizioni V_o==V_i e R_o==R_i. Per soddisfare tali condizioni è possibile agire esclusivamente su R_o e V_o. La seguente tavola di verità illustra tutte le possibili permutazioni delle quattro variabili booleane. Il nome dello stato viene definito dal valore della i-esima variabile booleana in posizione i. Si indica inoltre se un determinato stato è ammissibile in entrata al sistema di supervisione, ammissibile in uscita, ammissibile sia in entrata che in uscita o non è possibile. Stato Ammissibile Ammissibile in ingresso in uscita TTTT v v TTTF v TTFT v TTFF v TFTT v TFTF v TFFT v TFFF v FTTT FTTF FTFT FTFF FFTT v v FFTF FFFT FFFF v 15
  • Analisi A partire da questa tabella è quindi possibile selezionare gli stati ammissibili e costruire un diagramma di stato. Una volta disposti i diversi blocchi si individuano le possibili azioni che permettono il passaggio da uno stato all’altro. Il diagramma di stato risultante è presentato nella figura alla pagina successiva. 16
  • Analisi Figura 2: Diagramma di stato di un campo 17
  • Analisi I blocchi rappresentano gli stati ed al loro interno è possibile visualizzare il valore delle variabili che li determinano. Il blocco verde individua lo stato d’uscita in cui al campo è collegato il blocco di testo corretto ed il valore estratto è corretto. I blocchi in rosso indicano i due stati in uscita per i quali risulta non essere assegnato un blocco di testo. Questi due casi sono risultati problematici nella implementazione. I motivi di tali difficoltà e la soluzione adottata verranno spiegati nel capitolo relativo l’implementazione. 3.3 Definizione delle componenti software da realizzare Il modulo da realizzare può essere scomposto definendo i diversi tier. Ci sarà un client tier, un server tier ed un data tier. Per quel che riguarda il client tier, essendo stata richiesta una interfaccia web, il client è un browser che esegue il rendering di una pagina web generata dal server. Il server tier va suddiviso in due sottostrati. Si introducono un web tier ed un business tier. L’architettura da realizzare è quindi la seguente: Figura 3:Architettura multitier del sistema di supervisione 18
  • Analisi L’implementazione del web tier si deve occupare della generazione delle pagine web dinamiche da inviare al browser e deve fornire gli strumenti, ad esempio delle servlet, per gestire le richieste di dati dal client al server e fornire la risposta. L’interfaccia che si presenterà all’utente dovrà fornire tutte le informazioni riguardanti il documento in esame ed offrire le funzionalità richieste. Vi sono diverse tecnologie a disposizione per il raggiungimento di questo scopo. Come si vedrà successivamente la scelta è ricaduta sul google web toolkit il quale fornisce gli strumenti per gestire sia il client side che il server side. Le servlet per poter fornire una risposta alle request del client dovranno interfacciarsi con gli EJB del SEAD. Molte delle funzionalità necessarie per la gestione dei documenti sono già presenti nella implementazione del SEAD preesistente. Sarà tuttavia necessario apportare delle modifiche ad alcuni di essi ed implementarne alcuni ex-novo per soddisfare le esigenze del nuovo modulo. I moduli EJB descritti vanno a definire il business tier. Dovendo gestire dei documenti è palese la necessità di un data tier. Il SEAD utilizza la tecnologia Java Persistence API (JPA) per eseguire la serializzazione/mappatura dei documenti (ed in generale delle entità necessarie) in un database relazionale. Poiché l’utilizzo di JPA rende trasparente al programmatore l’accesso ai dati, risulta indifferente (salvo qualche piccola modifica a livello di configurazione) quale RDBMS si utilizzi. Di fatto tra le persone che hanno lavorato o lavorano tuttora sul sistema alcuni usano MySql come RDBMS mentre altri PostgreSQL In sintesi quindi il lavoro di sviluppo consiste nella realizzazione di :  interfaccia web dinamica e relativa logica lato client;  implementazione dei meccanismi di trasmissione dati tra server e client (servlet, RPC od altro);  implementazione o modifica dei moduli EJB che implemen- tano la business logic. 19
  • Analisi 3.4 Flowchart applicazione client Figura 4 : Flowchart applicazione 20
  • Analisi Il flowchart evidenzia, senza entrare nel dettaglio delle singole operazioni, il processo logico dell’applicazione sul client. 3.5 Progettazione dell’interfaccia grafica Nella realizzazione dell’interfaccia grafica è stato chiesto di porre particolare attenzione alla usabilità della stessa. Più in dettaglio si è chiesto di porre attenzione nello sfruttamento degli spazi e nella realizzazione degli strumenti utilizzabili dall’operatore. La gestione dello spazio a schermo è critica in quanto il numero di elementi che si rendono necessari essere visibili a schermo sono notevoli. Più esplicitamente devono essere presentati:  pannello di dettaglio contenente le informazioni sul documento in esame;  pannello contenente i campi estratti dal SEAD con relativi valori;  immagine del documento cartaceo;  strumenti per gestire il documento;  informazioni riguardo all’utente attualmente connesso al sistema. L’implementazione delle metodiche di interazione deve rispondere all’esigenza sia di rendere il lavoro da svolgere rapido sia di prevenire gli errori dell’operatore dovuti ad una eccessiva semplificazione. 3.5.1 Prototipizzazione La fase di sviluppo dell’interfaccia grafica è iniziata dopo la conclusione della implementazione della logica del sistema di supervisione. L’interfaccia fino a quel momento era sviluppata ed utilizzata esclusivamente per test. Nelle prossime figure si può vedere come l’interfaccia si presentava. L’immagine del documento era visibile solo eseguendo lo scroll della pagina . Le informazioni nella griglia sono ridondanti rispetto alle necessità di un ipotetico utilizzatore finale. Il difetto più evidente è lo spreco di spazio. 21
  • Analisi Figura 5: Interfaccia di test, scroll up Figura 6: Interfaccia di test, scroll down La realizzazione dell’interfaccia è stata preceduta dalla realizzazione di prototipi statici. I prototipi differivano principalmente per il posizionamento dei diversi pannelli contenenti le informazioni. Nella layout della pagina il punto fermo è l’immagine del documento, il quale occupa la stragrande maggioranza dello schermo. Rispetto all’interfaccia di sviluppo l’immagine del documento deve essere 22
  • Analisi immediatamente visibile. Lo scroll deve essere eseguito sull’immagine e non sulla pagina. La griglia presenta meno colonne e lo snippet del blocco viene visualizzato esternamente ad essa. Dopo svariate iterazioni del processo di realizzazione del prototipo e valutazione dello stesso si è giunti ad una versione finale che è stata utilizzata come riferimento per la realizzazione effettiva dell’interfaccia grafica dell’applicazione. Figura 7: Prototipo statico di riferimento La realizzazione finale come si vedrà nel capitolo sull’interfaccia grafica andrà oltre a questo primo prototipo aggiungendo funzionalità e componenti per gestirle. Rimarrà in ogni caso la disposizione generale dei componenti e dei pannelli. 23
  • Tecnologie utilizzate 4 Tecnologie utilizzate 4.1 Scelta delle tecnologie In fase di stesura delle specifiche di progetto la scelta delle tecnologie da utilizzare non è stata libera. Non trattandosi di un progetto a sé stante ma di un modulo destinato ad integrarsi in un sistema parzialmente preesistente e sviluppato parallelamente si è reso necessario tenere in considerazione i vincoli derivanti da quest’ ultimo. Il sistema di elaborazione automatica di documenti presenta le seguenti caratteristiche:  Java Enterprise Edition 6;  Enterprise Java Bean;  application server GlassFish V3;  web services con approccio REST;  datastorage mediante l’utilizzo di JPA 2.0 (java persistence api). 25
  • Tecnologie utilizzate Il modulo realizzato verrà integrato in questo sistema, di conseguenza per la realizzazione del server tier vengono mantenute le scelte già fatte. Per quel che riguarda il client tier si sarebbe dovuto decidere se realizzare una applicazione stand alone od una web application. Si è optato per una web application per evitare future problematiche di distribuzione ed aggiornamento dei client presso i fruitori dei servizi. In questo modo si realizza inoltre una sicura indipendenza dalle piattaforme, in quanto si potrà usare il browser per poter interagire col sistema. In ogni caso per rendere l’esperienza d’utilizzo da parte dell’utente il più possibile paragonabile all’interazione tramite client è necessario realizzare una rich internet application utilizzando tecniche di sviluppo Ajax. A tale scopo si è deciso di utilizzare per lo sviluppo della web application Google Web Toolkit 2.0 (GWT). La scelta di utilizzare GWT è dovuta al fatto che tramite questo toolkit è possibile realizzare delle web application utilizzando java come linguaggio di programmazione. In questo modo si semplifica notevolmente lo sviluppo, non dovendo utilizzare direttamente javascript. Un altro vantaggio derivante dall’utilizzo di GWT è il poter sviluppare senza dover gestire in prima persona le problematiche relative ai comportamenti non aderenti gli standard W3C da parte dei diversi Browser. Di seguito verrà fatta una breve descrizione delle principali tecnologie utilizzate nello sviluppo. 4.2 Java Enterprise Edition 6 JEE utilizza un modello applicativo multitier e distribuito. La logica applicativa viene divisa in diversi componenti in base alla funzione implementata. I diversi componenti che vengono a formare l’applicazione vengono distribuiti ed installati su diverse macchine a seconda del tier cui appartengono. Generalmente una applicazione JEE è divisa nei seguenti tier:  componenti Client-tier eseguiti dal client; 26
  • Tecnologie utilizzate  componenti Web-tier eseguiti sul server JEE;  componenti Business-tier eseguiti sul server JEE;  data-tier in esecuzione su macchine dedicate. Le componenti client-tier possono essere sia un Web client che application client. Nel caso del modulo sviluppato si tratta di un web client, il quale a sua volta è costituito da pagine web generate dinamicamente dalle componenti in esecuzione sul web tier e dal browser che esegue il rendering delle stesse. Le componenti web-tier possono essere servlet o pagine web costruite utilizzando tecnologie quali JSP, Java ServerFaces o , come nel caso descritto in questo documento, GWT. Le componenti business-tier sono costituite dai bean che implementano la business logic della applicazione e generalmente si occupano di ricevere i dati dai client, processarli se necessario e renderli persistenti inoltrandoli al data-tier. Generalmente si occupano anche di eseguire il percorso inverso, cioè estrarre dati dal data-tier, processarli se necessario ed inviarli al client. 4.3 Enterprise Java Bean Gli Enterprise Java Bean sono una tecnologia che permette lo sviluppo delle business rules di una applicazione all’interno della piattaforma Java EE delegando alcune delle funzionalità all’Application Server su cui vengono installate. Le specifiche Enterprise Java Bean (EJB) definiscono come un application server debba fornire le funzionalità di persistenza, elaborazione delle transazioni, gestione della concorrenza, programmazione ad eventi tramite Java Message Service, servizio di directory per elencare e nominare gli EJB, invocazione di procedure remote. Vi sono tre tipologie di Enterprise Java Bean:  entità: inglobano gli oggetti lato server che memorizzano dati. Viene fornita la persistenza;  session EJB: gestiscono l’elaborazione delle informazioni sul server. Generalmente sono l’interfaccia tramite cui i client comunicano con i componenti sul server. Possono essere 27
  • Tecnologie utilizzate stateless, stateful o singleton (l’EJB viene istanziato una unica volta ed esiste per l’intero ciclo di vita dell’applicazione);  message driven EJB: sono a funzionamento a sincrono. Si iscrivono ad un topic o ad una coda e si attivano al ricevimento di un messaggio inviato al topic o alla coda cui sono iscritti. 4.4 Java Persistence Api (JPA) JPA è un framework per l’object/relational mapping. Utilizza le annotazioni del linguaggio java e/o descrittori xml per definire la mappatura tra oggetti java e database relazionale. Nel SEAD, JPA viene utilizzato per il salvataggio delle informazioni estratte dai documenti cartacei. L’implementazione di JPA utilizzata è EclipseLink, la quale è la reference implementation per JPA 2.0. 4.5 Google Web Toolkit 2.0 (GWT) 4.5.1 Caratteristiche principali La difficoltà maggiore che si incontra nello sviluppo di applicazioni Ajax è la richiesta una conoscenza approfondita di tecnologie eterogenee (Javascript, DHTML, ecc.). Oggigiorno sono disponibili diversi framework il cui scopo è rendere più semplice lo sviluppo di rich web application ma è comunque richiesto un grande investimento in termini di tempo per poter conoscere ed utilizzare tali strumenti. Ulteriori difficoltà nello sviluppo di applicazioni Ajax è dovuto al diverso modo in cui browser differenti offrono supporto a javaScript e DHTML. Si rende necessario uno sviluppo ad hoc dell’applicazione per ogni browser in modo da rendere l’esperienza d’utilizzo uniforme sulle diverse configurazioni. GWT offre una modalità diversa di sviluppo, nascondendo le complessità sopra descritte; si utilizza il linguaggio di programmazione java sia per lo sviluppo server side che client side. GWT fornisce un compilatore che traduce il codice Java in codice JavaScript e DHTML. La semplificazione per il programmatore derivante da questo approccio è notevole in quanto si riduce drasticamente il tempo dedicato all’apprendimento di nuovi linguaggi e per la comprensione 28
  • Tecnologie utilizzate delle problematiche inerenti le diverse tecnologie da utilizzare. Per contro si perde il controllo completo sul codice client side in quanto generato automaticamente e ciò può comportare dei comportamenti non previsti nel caso in cui il compilatore traduca erroneamente il codice java. GWT fornisce supporto per la gestione della GUI, per l’internazionalizzazione e per il parsing xml. La gestione della comunicazione tra client server viene fornita tramite l’implementazione dei principi di Remote Procedure Calls in una generica servlet, la quale può essere specializzata in modo da rispondere alle esigenze dell’applicazione. GWT offre inoltre una interfaccia, chiamata JavaScript Native Interface (JSNI), che permette l’integrazione di codice javascript custom con il codice javascript generato dal compilatore. 4.5.2 Compatibilità con il linguaggio Java Il codice java utilizzato con GWT per la programmazione lato client è soggetto a delle restrizioni poiché javascript non implementa interamente le keywords e le API disponibili in Java ma solo un sottoinsieme. Le differenze riguardano i seguenti elementi :  intrinsic types: Tipi primitivi, Object, String, array, classi user-defined , etc. sono supportate salvo alcuni casi particolari: o JavaScript prevede un unico tipo numerico (64 bit floating point), quindi tutti i tipi primitivi di java (ad eccezione del long) vengono implementati come double; o JavaScript non supporta gli integer a 64 bit. A partire da GWT 1.5 un long viene emulato tramite l’utilizzo di una coppia di integer a 32 bit. Tale soluzione comporta un impatto sulle prestazioni in caso di calcolo intenso su tipi long. Inoltre non è possibile usare il tipo long in codice JSNI in quanto non tipo nativo di javascript.  eccezioni: try, catch, finally e user-defined exceptions sono supportate normalmente. Tuttavia molti tipi di eccezioni prodotte dalla Java VM (NullpointerException, StackOverFlowError, OutOfMemory) non vengono generate in production mode. Al loro posto viene scatenata una 29
  • Tecnologie utilizzate JavaScriptException. Ciò è dovuto al fatto che le eccezioni javascript non sono mappabili con una eccezione java;  multithreading e sincronizzazione: JavaScript è single- threaded, quindi la keyword synchronized non ha alcun effetto reale e viene ignorata dal compilatore. Inoltre i metodi e le librerie relative alla sincronizzazione non sono disponibili e se utilizzati il compilatore non si limiterà ad ignorarli ma genererà un errore;  reflection: per garantire la massima efficenza GWT compila i sorgenti java in uno script monolitico e non supporta il caricamento dinamico delle classi. Per questo ed altri motivi legati all’ottimizzazione del codice generato in GWT non c’è supporto per la reflection;  finalization: JavaScript non supporta la finalizzazione degli oggetti durante la garbage collection, quindi GWT non supporta in Java finalizers in production mode. 4.5.3 Deferred binding Il Deferred Binding è una tecnica usata dal compilatore GWT per creare e selezionare una specifica implementazione di una classe in base a dei specifici parametri. Il deferred binding permette la generazione di diverse permutazioni della stessa applicazione specificatamente personalizzate per essere eseguite in uno specifico browser il quale eseguirà il download della sola permutazione a lui dedicata. I benefici del deferred binding sono :  riduzione delle dimensioni del codice javascript generato che il client dovrà scaricare;  riduzione del tempo di sviluppo in quanto viene generato automaticamente il codice implementativo di una interfaccia o di una classe proxy (è il caso delle RPC);  maggior efficienza rispetto al dynamic binding a runtime. 4.5.4 Sviluppo di GUI con GWT GWT semplifica la realizzazione della GUI per una web application fornendo delle classi dedicate (widget) il cui utilizzo è molto simile all’utilizzo in framework per la realizzazione di UI come SWING o SWT. La differenza consiste nel fatto che il render delle widget avviene tramite DHTML anziché una realizzazione grafica pixel- oriented. 30
  • Tecnologie utilizzate In javascript la realizzazione di una interfaccia dinamica avviene manipolando il DOM (Document Object Model) del Browser. GWT, pur mantenendo la possibilità di accedere al DOM tramite il DOM package, rende molto più facile costruire l’interfaccia partendo dalle Widget a disposizione. Oltre ad un set di widget già preesistente (Button, CheckBox, textBox, etc.) il programmatore ha ampia libertà di estendere componenti, crearne di nuovi, combinarli. L’aspetto delle widget viene gestito tramite fogli di stile CSS. Ovviamente viene fornito supporto alla gestione degli eventi scatenati dalla GUI tramite l’implementazione di specifiche interfacce. A partire da GWT 2.0 è stato introdotta la funzionalità UiBinder; UiBinder permette di dichiarare tramite xml la struttura della pagina web e la disposizione delle widget all’interno della stessa disaccoppiando la definizione dell’interfaccia dalla realizzazione della business logic. I principali vantaggi dell’utilizzo di UiBinder sono :  semplificazione di creazione della UI;  possibilità di creazione ed utilizzo di template;  separazione tra estetica e comportamento programmatico;  maggior efficienza dovuto all’uso di HTML anziché chiamate alle api di widget e pannelli. 4.5.5 RPC GWT fornisce un meccanismo di gestione delle RPC basato sulle java servlet. Questo meccanismo genera automaticamente, tramite deferred binding, il codice sia server che client side per la serializzazione degli oggetti. L’utilizzo del meccanismo di RPC fornito con GWT non è obbligatorio, in quanto lato server (il codice non è soggetto alle limitazioni che si hanno nel caso del codice client side) si ha la massima libertà nella scelta degli strumenti da utilizzare. Tuttavia, non avendo particolari esigenze, nella realizzazione del progetto si è deciso di utilizzarlo in quanto semplice da implementare e pronto all’uso. 31
  • Tecnologie utilizzate L’utilizzo delle RPC è fondamentale nelle applicazioni Ajax in quanto permette di aggiornare dinamicamente le componenti della UI con i dati in ricezione dal server senza dover ricaricare la pagina web in toto. Questo comporta un minor utilizzo della banda ed un minor carico del server. 32
  • Interfaccia grafica 5 Interfaccia grafica 5.1 Come si presenta Il layout della pagina è suddiviso in tre contenitori principali:  un contenitore a sinistra, nel quale vengono inseriti il pannello contenente le informazioni sul documento, il pannello di dettaglio dei campi ed il pannello per la visualizzazione e modifica del singolo campo selezionato;  un contenitore a destra in cui vengono inseriti una barra degli strumenti ed il pannello per la visualizzazione del documento;  un contenitore sul fondo della pagina il quale contiene una barra adibita alla visualizzazione di istruzioni avanzate per l’utilizzo dell’applicazione e l’indicazione dell’utente attualmente connesso. La dimensione, in altezza, del contenitore ai piedi della pagina è fissa mentre gli altri due contenitori hanno dimensioni proporzionali alla dimensione dell’area di visualizzazione. 33
  • Interfaccia grafica L’usabilità della pagina così impostata è stata provata a diverse risoluzioni. La risoluzione minima utilizzabile è 800x600, la risoluzione raccomandata è 1024x768 o superiore. Inserendo l’url del documento da supervisionare il browser mostra una pagina simile a: Figura 8: Presentazione dell'interfaccia 5.2 Utilizzo La schermata presenta, all’interno di una griglia, l’elenco dei campi ed il valore estratto. Per segnalare la presenza di campi per cui il sistema non è stato in grado di creare un collegamento campo-blocco la corrispondente riga viene evidenziata in rosso. L’immagine del documento viene mostrata separatamente in un pannello abilitato allo scrolling. In questo modo l’utente, se le dimensioni dell’immagine del documento lo rendono necessario, può eseguire lo scroll solo sul componente e non sull’intera pagina. Questa 34
  • Interfaccia grafica scelta permette di visualizzare interamente il documento senza perdere la visibilità della griglia. Sull’immagine del documento vengono inoltre evidenziati, tramite etichette colorate, i campi trovati. Le operazioni che l’utente può fare sono: 1. modificare il valore estratto da un campo; 2. modificare una associazione campo-blocco. Questa operazione è necessaria quando il sistema ha generato una associazione errata e non ha individuato il blocco corretto per il campo; 3. eliminare una associazione campo-blocco. Questa operazione è necessaria quando il sistema ha generato una associazione errata e non esiste il blocco corretto per il campo (perché l’OCR non ha generato il blocco oppure perché il campo è assente dal documento); 4. confermare l’assenza di un campo (questa operazione è obbligatoria; il sistema cioè non permette di completare l’elaborazione di un documento nel quale non sono stati trovati uno o più campi se l’operatore non conferma l’assenza di tali campi); 5. annullare le modifiche effettuate ed ancora non rese persistenti; è possibile ripristinare sia un campo singolarmente, previa selezione, sia annullare le modifiche sull’intero documento tramite pressione del bottone dedicato; 6. confermare la correttezza dei campi estratti sia per quel che riguarda i blocchi collegati ad essi sia per il valore estratto. La progettazione dell’interfaccia è stata incentrata sulla minimizzazione dei click da effettuare. Nel caso comune, quello in cui tutti i campi sono stati trovati ed il loro valore è corretto, l’utente deve solo osservare il documento e fare un click per passare al documento successivo. Nell’altro caso comune, quello in cui tutti i campi sono stati trovati ma per alcuni l’OCR ha estratto un valore errato, l’utente deve solo 35
  • Interfaccia grafica selezionare il campo nell’elenco (un click), inserire il valore corretto (uno spostamento di mouse) e poi premere enter. Nel caso in cui si renda necessario correggere un collegamento campo-blocco, l’utente potrà eseguire un nuovo collegamento tramite tre click (selezione del campo, abilitazione della selezione dei blocchi sull’immagine, selezione del blocco). La creazione di un nuovo collegamento campo-blocco può essere eseguita anche tramite un doppio click (selezione del campo nella griglia e abilitazione della selezione dei blocchi sull’immagine) ed un successivo click sul blocco desiderato. La funzionalità di selezione dei blocchi è normalmente inibita durante la normale navigazione sul documento per evitare che accidentali click creino nuovi (ed errati) collegamenti campo-blocco. Nella prossima sezione viene presentato un esempio di utilizzo. 5.2.1 Esempio di utilizzo Nella figura 8 si può vedere che una delle righe della griglia è evidenziata in rosso. Questa segnalazione visiva sta a significare che il sistema non è stato in grado di individuare l’informazione all’interno del documento. Come precedentemente detto ciò può essere dovuto o alla assenza reale dell’informazione o al mancato riconoscimento del blocco di testo da parte del OCR. Si richiede quindi l’intervento dell’operatore. Selezionando la riga del evidenziata in rosso si espanderà un pannello di dettaglio per il campo selezionato. 36
  • Interfaccia grafica Figura 9: Griglia e pannello di dettaglio Nel pannello di dettaglio sono presenti tre bottoni, lo snippet del blocco associato al campo selezionato ed una textbox. Se l’operatore si accorge che il campo è presente nel documento dovrà o eseguire una nuova assegnazione se il blocco è stato generato dal OCR o inserire il valore manualmente tramite textbox. 37
  • Interfaccia grafica Nel primo caso dovrà cliccare sul bottone “Collega Campo-Blocco” (il primo da sinistra) e selezionare uno dei blocchi disponibili. Il bottone è stato inserito per evitare che click accidentali sull’immagine generino assegnazioni non desiderate. Se si esegue un doppio click sulla griglia, oltre a selezionare il campo desiderato si è subito pronti per una nuova assegnazione. Nel caso in cui invece il campo non sia effettivamente disponibile cliccando sul bottone “Scollega Campo-Blocco” si darà conferma della mancata assegnazione. Selezionando un campo nella griglia oltre a mostrarne il dettaglio nel pannello viene evidenziato sull’immagine. Se il blocco associato al campo è all’interno di una pagina diversa da quella attualmente visualizzata viene caricata la pagina corretta ed eseguito l’autoscroll per rendere visibile il blocco selezionato. Figura 10: Selezione di un campo ed evidenziazione nell'immagine Può succedere che il SEAD associ erroneamente un blocco ad un campo nonostante non sia presente nel documento. Per risolvere questa situazione l’utente deve selezionare il campo interessato e cliccare sul tasto “Scollega Campo-Blocco”. In questo modo si rompe l’associazione. Il risultato dal punto di vista dell’interfaccia è il seguente: 38
  • Interfaccia grafica Figura 11: Rimozione di una errata associazione Nel caso in cui l’operatore debba solamente correggere il valore estratto dal OCR si procederà con la selezione sulla griglia del campo richiesto e con l’inserimento del valore corretto nella textbox dedicata. Tutte le operazioni di modifica e correzione sono reversibili fin quando il documento non viene validato. Le modalità per annullare le 39
  • Interfaccia grafica modifiche sono o tramite selezione del singolo record e click sul tasto “undo” (il terzo da sinistra) o tramite click sul tasto annulla. In quest’ultimo caso tutte le modifiche verranno annullate. Una volta terminate le eventuali correzioni tramite il tasto “Accetta” è possibile validare il documento e rendere persistenti sul database le modifiche effettuate. Figura 12: Comandi per validazione e per annullamento modifiche Se la checkbox “Carica Prossimo” è spuntata dopo la validazione ed il salvataggio del documento, se ci saranno altri documenti da validare la pagina verrà ridisegnata e ripopolata con i nuovi dati. In caso contrario la pagina verrà chiusa. 40
  • Implementazione 6 Implementazione 6.1 Struttura del progetto Di seguito viene presentato come è stato organizzato il progetto per quel che riguarda packages e classi. La descrizione che verrà fatta prevede anche l’illustrazione della organizzazione del codice del SEAD. Tuttavia non è interesse di questo documento una descrizione completa ed esaustiva del SEAD. Verranno quindi presentati solo i package direttamente coinvolti nello sviluppo del sistema di supervisione. La elencazione dei package di quest’ultimo sarà invece esaustiva. 6.1.1 Struttura del SEAD I packages di interesse sono:  it.units.pato.ejb: contiene gli EJB che implementano le business rules. Gli EJB di interesse per il sistema sviluppato sono Workflow e FoundFieldEditor. Su Workflow, già preesistente, sono state eseguite lievi modifiche, FoundFieldEditor invece è stato sviluppato ex novo; 41
  • Implementazione  it.units.pato.entities: contiene le entità Document, Page, Request e Response, tutte preesistenti;  it.units.pato.entities.administration: contiene le classi User, AdminUser, AdvisorUser, tutte preesistenti;  it.units.pato.entities.blocks: contiene le classi Block, BlockAbstract e TextBlock, tutte preesistenti ;  it.units.pato.entities.model: contiene le classi Model, SearchedField, TextBlockList e TextBlockWithQualityList, tutte preesistenti;  it.units.pato.entities.pageRepresentations: contiene le classi PageRepresentation, BlockListPageRepresentation e ImagePageRepresentation, tutte preesistenti;  it.units.pato.facades: contiene le classi Database, Documents, SearchedFields e Users, tutte preesistenti. 6.1.2 Struttura del sistema di supervisione Il progetto è costituito dai seguenti packages:  it.units.pato.gwt  it.units.pato.gwt.adapter  it.units.pato.gwt.client  it.units.pato.gwt.client.components  it.units.pato.gwt.client.entities  it.units.pato.gwt.client.exceptions  it.units.pato.gwt.client.services  it.units.pato.gwt.server Il package it.units.pato.gwt contiene un file xml in cui vengono dichiarate le librerie utilizzate, l’entrypoint dell’applicazione ed altre direttive per la compilazione. L’entrypoint preesistente è stato modificato nel corso dello sviluppo. Il package it.units.pato.get.adapter contiene le classi che implementano la conversione dalle entità del SEAD alle entità utilizzate con GWT. Le classi contenute sono DocumentAdapter, DocumentClassAdapter, ResponseAdapter, TextBlockAdapter e UserAdapter. Erano già preesistenti ma sono state modificate ed estese con nuovi metodi nel corso dello sviluppo. 42
  • Implementazione Il package it.units.pato.gwt.client contiene le classi che implementano le pagine del client e relativi file xml utilizzati per il layout. Le classi al suo interno sono AdminMainPageUiBinder, DocumentDetailUI- Binder, MainEntryPoint e TaxAdvisorMainPageUIBinder. Erano tutte preesistenti, MainEntryPoint e TaxAdvisorMainPageUIBinder hanno subito modifiche minore mentre DocumentDetailUIBinder è satta completamente riscritta. Il package it.units.pato.gwt.client.components contiene le classi che implementano i componenti utilizzati all’interno delle pagine web. All’interno del package sono presenti le classi AddCreditPopup, AdminDetailsControl, AdvisorsGridWithFilter, ChangePassword- Popup, CheckPoint, CheckpointStyle, CompletedDocumentsGrid, DocumentGridWithFilter, GridWithFilter, ImageSpriteGridCellRen- derer, NewAdvisorPopup, Pair, QueuedDocumentsGrid, ResourceBundle, StatsPanel, TextBlockLabel e TooltipListener. Le classi non preesistenti sono TextBlockLabel e TooltipListener, mentre sono state modificate nello sviluppo CheckPoint, DocumentGrid- WithFilter e ImageSpriteGridCellRenderer. Il package it.units.pato.gwt.client.entities contiene le classi che implementano le entità utilizzabili con gwt. Le entità implementate sono Document, DocumentClass, DocumentsStatistics, FoundField, Response, TextBlock, TextBlockList e User. Queste classi erano già preesistenti ma sono state modificate nel corso dello sviluppo. Il package it.units.pato.gwt.client.exceptions contiene l’implemen- tazione di alcune eccezioni utilizzate dell’applicazione. Le classi nel package sono AdministrationException, DuplicateKeyException, UnauthorizedException, DocumentNotFoundException e Response- NotFoundException. Queste ultime due sono state definite nello sviluppo, le precedenti erano già preesistenti. Il package it.units.pato.gwt.client.services contiene al suo interno le interfacce sincrone e asincrone. Le interfacce presenti sono BlockListService, BlockListServiceAsync, DocumentService, Docu- mentServiceAsync, ResponseService, ResponseServiceAsync, Ser- vices, UserService e UserServiceAsync. Il package it.units.pato.gwt.client.server contiene le implementazione delle interfacce dichiarate nel package services. Al suo interno vi sono AuthorizationChecker, BlockListServiceImpl, DocumentServiceImpl, 43
  • Implementazione GlobalServiceImpl, ResponseServiceImpl e UserServiceImpl. Queste implementazioni erano preesistenti tranne BlockListServiceImpl. DocumentServiceImpl e ResponseServiceImpl hanno subito modifiche nel corso dello sviluppo. 6.2 Business e Data Tier Il SEAD con cui l’applicazione deve interfacciarsi è implementato mediante l’utilizzo di moduli EJB. Ognuno di questi moduli risponde ad una specifica funzionalità. L’implementazione del SEAD fornisce dei moduli per interrogare il sistema e poter estrarre i documenti su cui lavorare. Tuttavia è stato necessario eseguire alcune modifiche ai moduli già esistenti e implementarne alcuni ex novo. Di seguito verrà fatto un elenco dei moduli EJB utilizzati. 6.2.1 Moduli di interfacciamento 6.2.1.1 Database Questo modulo funge da wrapper per l’oggetto EntityManager e non fa altro che replicare un subset dei metodi dello stesso. Si tratta di un modulo stateless e viene utilizzato per gestire entità di cui si richiede la persistenza su database o la esatrazione dallo stesso. Fornisce i metodi:  per la serializzazione delle entità su database;  per la deserializzazione delle entità da database;  per rendere persistenti eventuali modifiche effettuate;  per la ricerca di una particolare entità all’interno del database;  per la rimozione di una data entità dal database. 6.2.1.2 Users Questo modulo implementa gli strumenti per la gestione degli utenti. E’ un singleton, cioè viene istanziato una unica volta e non vi possono essere altre istanze in contemporanea. Fornisce i metodi:  per la deserializzazione dal database delle entità User;  per la selezione di utenti in base a nome o Id;  eseguire aggiornamento della password;  gestione amministrativa. 44
  • Implementazione Generalmente questo modulo verrà utilizzato dalla applicazione per la gestione delle autorizzazioni e degli accessi ai documenti, in quanto ogni utente (a meno che non si tratti di un amministratore) può accedere ai propri documenti o ai documenti dei propri clienti (se l’utente in questione è un commercialista ad esempio) . 6.2.1.3 Documents Questo modulo fornisce gli strumenti per la gestione delle entità di tipo Document. Anche questo è un singleton. Sono esposti i metodi per :  estrarre i documenti la cui elaborazione è terminata;  estrarre i documenti appartenenti ad un determinato utente la cui elaborazione è terminata;  estrarre i documenti la cui elaborazione non è ancora terminata;  estrarre i documenti appartenenti ad un determinato utente la cui elaborazione non è ancora terminata. 45
  • Implementazione 6.2.2 Entità definite nel business tier Si possono veder nell’immagine sottostante le relazioni che intercorrono tra le entità Request, Document, Response e Page. Figura 13: Diagramma entità business tier 46
  • Implementazione Ecco invece le relazioni che intercorrono tra le entità TextBlock, TextBlockList, BlockAbstract e TextBlockWithqualityList. Figura 14: Diagramma oggetti estratti dal documento 6.2.2.1 Document La entità Document rappresenta l’oggetto documento. Document è l’oggetto che verrà fornito in input all’applicazione e che verrà manipolato dalla stessa. L’oggetto Document contiene tutte le 47
  • Implementazione informazioni relative ad un documento ed espone i metodi per ottenerle. Le informazioni più significative sono:  tipo di documento;  modello del documento;  proprietario del documento;  data creazione;  data inizio elaborazione;  coda di elaborazione in cui è inserito;  stato dell’elaborazione;  data termine elaborazione;  numero pagine del documento;  rappresentazioni del documento disponibili (immagine scannerizzata, immagine processata dal OCR, lista blocchi di testo generata dall’OCR);  response generata al termine dell’elaborazione;  stato della validazione del documento;  indicazione se il documento è stato scaricato o meno dall’utente;  costo dell’elaborazione. 6.2.2.2 Response La entità Response definisce la risposta generata dal SEAD al termine della elaborazione del documento. E’ nella Response che viene inserita la mappa di FoundFields contenente i campi cercati e relativa lista di blocchi selzionati (se trovati). Response espone i metodi per :  impostare il documento a cui fa riferimento;  estrarre il documento a cui fa riferimento;  estrarre la mappa di FoundFields;  assegnare una mappa di FoundFields;  aggiungere un FoundField;  impostare l’indice di qualità;  estrarre l’indice di qualità;  assegnare un commento testuale;  estrarre il commento testuale. 6.2.2.3 SearchedField L’oggetto SearchedField definisce la singola informazione che viene cercata all’interno del documento. Viene utilizzato come chiave nella 48
  • Implementazione mappa dei campi trovati presente nella Response. 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. 6.2.2.4 BlockAbstract L’oggetto BlockAbstract definisce il singolo rettangolo estratto dal OCR. I metodi esposti permettono di :  assegnare la pagina in cui è presente il blocco;  estrarre la pagina in cui è presente il blocco;  assegnare le dimensioni (larghezza e altezza) del blocco  estrarre le dimensioni del blocco;  assegnare la posizione del blocco (coordinate dell’angolo in alto a sinistra);  estrarre la posizione del blocco. 6.2.2.5 TextBlock TextBlock è una estensione di BlockAbstract. Viene inserita l’informazione riguardante il testo contenuto nel blocco. I metodi aggiuntivi permettono di :  assegnare il valore testuale dell’informazione presente nel blocco;  estrarre il valore testuale presente nel blocco. 6.2.2.6 TextBlockList TextBlockList è una implementazione dell’interfaccia List<TextBlock>. E’la struttura dati che contiene i blocchi selezionati per un determinato campo cercato. È una lista in quanto potrebbe capitare che l’informazione sia contenuta in più blocchi generati dal OCR. 49
  • Implementazione 6.2.2.7 TextBlockWithQualityList TextBlockWithQualityList estende la classe TextBlockList. Rispetto alla classe padre fornisce in aggiunta l’indicatore della qualità della associazione tra campo cercato e area di testo nel documento. 6.2.3 Moduli di servizio 6.2.3.1 Workflow Il modulo Workflow implementa la procedura di elaborazione del documento. In questo modulo riceve il documento da indagare e provvede a classificarlo, inserirlo nelle code di lavoro ed infine salvare su database documento e Response. 6.2.3.2 FoundFieldEditor In questo modulo sono implementati i metodi per la modifica dei Foundfield all’interno delle Response. Questo modulo non era presente nel sistema preesistente ed è stato interamente sviluppato nell'ambito di questa tesi. La sua implementazione si è resa necessaria in quanto durante lo sviluppo si sono riscontrati dei comportamenti non previsti al momento di rendere persistenti le modifiche alle diverse entità. Utilizzando la tecnologia fornita dalla Java Persistence API ci si aspettava che la procedura da seguire per modificare una determinata entità fosse la seguente : 1. deserializzazione dal database della entità desiderata; 2. manipolazione delle proprietà dell’entità; 3. chiamata ai metodi merge o persist salvare su database l’entità con le modifiche effettuate. Questa procedura funziona correttamente nella stragrande maggioranza dei casi ed è ciò che ci si aspetta debba succedere. Tuttavia si sono verificati comportamenti anomali nella gestione di entità complesse. Con entità complesse si intendono entità le cui proprietà destinate ad essere serializzate su database non sono semplici tipi primitivi ma strutture dati che contengono a loro volta altre entità che a loro volta devono essere rese persistenti. 50
  • Implementazione Dopo diversi test si è visto che JPA riesce a gestire agevolmente alcune strutture dati (ad esempio gli ArrayList) ma va incontro a problemi di gestione della integrità referenziale con altre. Nel caso specifico i problemi si sono riscontrati con la mappa definita dalla chiave SearchedField e dal valore TextBlockWithQualityList. Se si tentava di modificare la TextBlockWithQualityList assegnando ad esempio un nuovo TextBlock, nel momento in cui si cercava di rendere persistenti le modifiche sulla mappa veniva generata una eccezione dovuta al tentativo di rimozione di una entità cui l’entity manager faceva riferimento. Per aggirare questo problema si è dovuto definire una procedura alternativa, gestendo di fatto manualmente le entità da aggiornare o rimuovere. Un’altra problematica riscontrata è l’impossibilità di rendere persistente una coppia chiave/valore per il quale il valore era null. La mappa veniva mappata sul database tramite una tabella di join. La rimozione del valore (dovuta ad esempio al fatto che il blocco non è presente nel documento) scatenava un catena di eccezioni dovute alla violazione dell’integrità referenziale. Il problema è stato risolto sostituendo il valore null con un blocco fittizio. La procedura per modificare i FoundFields in una Response (ad esempio il SEAD ha selezionato il blocco sbagliato e l’operatore ha eseguito la correzione) è la seguente: 1. Deserializzazione della Response originale da modificare 2. Per ogni FoundField modificato: a) si estrae dalla mappa la textBlockList; b) si deserializza la TextBlockList originale dal database; c) si svuota la lista; d) si rende persistente la lista originale vuota; e) si elimina la lista originale; f) si serializza sul database la TextBlockList aggiornata; g) si inserisce nella mappa della Response la nuova coppia SearchedField / TextBlockList; h) si rendono persistenti le modifiche alla Response; 51
  • Implementazione 6.3 Web tier Il web tier è lo strato dell’applicazione che si occupa della generazione delle pagina dinamiche e della elaborazione delle richieste del client verso il sistema (e viceversa). Vengono definite quindi delle servlet che verranno utilizzate dall’aplicattivo sul client per poter aggiornare i dati forniti all’operatore. 6.3.1 Services : interfacce Il pacchetto service contiene le interfacce delle servlet che verranno implementate. Per ogni servlet vengono definite due interfacce, una sincrona ed una asincrona. La necessità della intrefaccia asincrona è dovuta al fatto che in GWT tutte le operazioni sulla rete sono asincrone, cioè non bloccanti. Quando l’applicazione sul client esegue una richiesta al server il metodo chiamato ritorna subito. Per poter gestire il risultato della richiesta lato client viene utilizzato un callback. Il motivo alla base di tutto ciò è che il javascript engine dei browser è generalmente single-threaded. Se la richesta al server fosse bloccante ciò comporterebbe un blocco anche del thread che gestisce la UI finché non si riceve la response del server. Di seguito vengono presentate le interfacce maggiormente significative per il funzionamento dell’applicazione. 6.3.1.1 UserService UserService è l’interfaccia che espone i metodi per richiedere informazioni ed eseguire operazioni sugli User. I metodi esposti servono a :  gestire il credito dell’utente;  cambiare la password dell’utente;  creare un nuovo utente Advisor;  fornire l’elenco degli Advisor;  fornire i clienti di un Advisor;  ottenere lo User corrente. 52
  • Implementazione 6.3.1.2 ResponseService ResponseService definisce i metodi per la gestione della Response generata dalla elaborazione di un documento. I metodi esposti permettono di :  estrarre dal sistema la Response per un dato documento;  assegnare una nuova classe di appartenenza per il documento;  richiedere una riclassificazione del documento;  assegnare una classe di appartenenza per il documento;  assegnare i FoudField nella Response. 6.3.1.3 DocumentService DocumentService epsone i metodi per la gestione dei Document. Le funzionalità messe a disposizione servono a :  estrarre un Document in base al relativo ID;  estrarre i Document inseriti nella coda manuale;  estrarre le statistiche relativo ad un Document;  estrarre il numero di Document la cui elaborazione è stata completata;  estrarre il numero di Document la cui elaborazione non è ancora terminata;  estrarre i Document la cui elaborazione è terminata appartenenti ad un determinato utente,  estrarre i Document la cui elaborazione non è terminata appartenenti ad un determinato utente;  impostare la validazione di un documento. 6.3.1.4 BlockListService BlockListService viene utilizzato per richiedere la lista completa dei blocchi estratti dall’ OCR. La lista completa serve per poter permettere la scelta di un nuovo blocco nel caso in cui l’associazione eseguita dal sistema venga riconosciuta come errata in fase di supervisione. 6.3.2 Services : implementazione Di seguito vengono illustrate le implementazioni delle interfacce sopra descritte. 53
  • Implementazione 6.3.2.1 UserServiceImpl Implementa l’interfaccia UserService. Espone diversi metodi, tuttavia il metodo più significativo per l’applicazione utilizzata in quanto utilizzato nei controlli sulle autorizzazioni d’accesso ai Documenti ed alle Response è getCurrentUser. 6.3.2.2 ResponseServiceImpl Implementa l’interfaccia ResponseService. I due metodi principali per l’applicazione sviluppata sono getResponse e setFoundFields. Il metodo getResponse permette di estrarre dal sistema la Response relativa ad un dato Document. Per poter estrarre la Response corretta viene passato come parametro il Document interessato. La procedura eseguita è la seguente: 1. estrazione dell’id del Document passato come parametro; 2. deserializzazione del Document originale dal database; 3. controllo delle autorizzazioni dell’utente che effettua la richiesta; 4. estrazione della Response; 5. conversione della Response in una Response Light utilizzabile lato client (il motivo verrà spiegato successivamente); 6. restituzione della Response. Il metodo setFoundFields riceve come parametri la Response che dovrà andare a modificare, una lista FoundField per i quali l’operatore ha assegnato un nuovo blocco ed una lista di FoundFields per i quali l’operatore non ha selezionato un nuovo blocco ma ha effettuato una correzione sul valore estratto dal OCR. La procedura eseguita è la seguente: 1. estrazione dell’id della Response da aggiornare; 2. estrazione dal database della Response originale; 3. controllo delle autorizzazioni dell’utente che effettua la richiesta; 4. costruzione delle mappe di FoundField da editare a partire dalle due liste fornite in ingresso; 5. esecuzione del metodo editFieldFound esposto dall’EJB FoundFieldEditor. 54
  • Implementazione 6.3.2.3 DocumentServiceImpl DocumentServiceImpl implementa l’interfaccia DocumentService. I due metodi più significativi per l’applicazione sviluppata sono getDocumentById e setDocumentValidationAndReturnNextID. getDocumentById permette di ottenere dal sistem un dato Document in base al ID passato come parametro in ingresso. La procedura che viene eseguita dal metodo è : 1. deserializzazione dal database del documento corrispondente al ID fornito; 2. verifica delle autorizzazioni dell’utente che ha effettuato la richiesta; 3. conversione del Documento estratto da Full Entity a Light Entity; 4. restituzione del Document richiesto. Il metodo setDocumentValidationAndReturnNextID viene chiamato per impostare la validazione del documento e restituisce l’id del prossimo documento da validare se ve ne sono. I parametri in ingresso sono una variabile booleana che indica la validazione del documento e l’id del documento in esame. La procedura eseguita è la seguente : 1. deserializzazione del documento originale; 2. verifica delle autorizzazioni dell’utente che effettua la richiesta; 3. validazione del documento; 4. creazione della lista di documenti non ancora validati appartenenti all’utente; 5. restituzione del ID del primo documento in lista. 6.3.2.4 BlockListServiceImpl BlockListServiceImpl implementa l’interfaccia BlockListService. L’unico metodo definito nell’interfaccia e quindi implementato serve ad ottenere l’intera lista di blocchi estratti dal OCR. I parametri in ingresso sono la Response di riferimento e l’ID della PageRepresentation contenente i blocchi richiesti. 55
  • Implementazione La procedura eseguita è la seguente : 1. deserializzazione della Response originale; 2. estrazione del documento cui fa riferimento la Response; 3. verifica delle autorizzazioni dell’utente che effettua la richiesta; 4. deserializzazione della BlockListPageRepresentation; 5. creazione della List di TextBlock; 6. restituzione della lista. 6.3.3 Entity adapters Precedentemente si è fatto riferimento nella descrizione dei metodi implementati alla conversione da entità definite nel business tier (full entity) a entità utilizzabili con gwt (light entity). Tale operazione è dovuta a limitazioni di GWT e del meccanismo di serializzazione. Le entità definite negli EJB del SEAD non possono essere serializzate deserializzate dalle rpc di gwt. Bisogna infatti ricordare che il client è costituito da codice javascript eseguito nel browser. Si deve quindi definire delle entità Light corrispondenti alle entità originali ma utilizzabili dal client. Per poter far ciò sono stati costruiti degli adapters che permettono la trasformazione tra entità full ed entità light. 6.3.3.1 DocumentAdapter La classe DocumentAdapter espone il metodo toLightEntity che permette la conversione di un oggetto Document in un Document compatibile con GWT. Non si tratta di una vera conversione. Di fatto viene istanziato un nuovo Document gwt-compatibile e successivamente si procede popolarne le proprietà con i valori estratti dal Document originale. 6.3.3.2 ResponseAdapter La classe ResponseAdapter permette per la conversione da oggetti Response a Response gwt-compatibile.In questa classe vengono inoltre implementati metodi per la conversione della Map<SearchedField,TextBlockWithQualityList> in una lista di FoundFields e per eseguire l’operazione inversa. 56
  • Implementazione 6.3.3.3 TextBlockAdapter La classe TextBlockAdapter espone il metodo da utilizzare per la conversione di oggetti TextBlock in TextBlock gwt-compatibili ed un metodo per eseguire la procedura inversa. Il metodo di conversione da light a full prevede il passaggio come parametro anche del fattore di scala per calcolare la posizione dei blocchi all’interno dell’immagine scalata. Oltre alla posizione e alle dimensioni calcolate in questa maniera, nel nuovo TextBlock vengono salvati anche i valori originali. Nel procedimento inverso infatti non serve applicare la scala in quanto si utilizzano i valori originali salvati nel TextBlock light. Si è dovuto utilizzare questa procedura in quanto a volte a causa di errori di approssimazione nel passaggio da full a light e nuovamente a full le coordinate e le dimensioni che dovevano fare riferimento al medesimo blocco differivano. 6.3.3.4 UserAdapter UserAdapter permette la conversione dello User definito all’interno del SEAD in un oggetto User semplificato gestibile dal client. Poiché nell’implementazione del sistema vi sono classi che estendono la classe User (AdminUser e AdvisorUser), e non avendo queste classi una controparte gwt-compatibile, l’operazione di conversione verifica se l’oggetto User da convertire è istanza di una di queste classi e setta una variabile boolena utilizzata per identificare quel determinato tipo di utente. 6.3.4 GWT entities Di seguito verranno definite le entità light che è stato necessario implementare. Tutte le seguenti classi sono inserite nel package it.units.pato.gwt.client.entities. Di seguito vengono presentate le relazioni che intercorrono tra le entità Response, Document, FoundField, TextBlockList e textBlock. 57
  • Implementazione Figura 15: Diagramma entità gwt-compatibili 6.3.4.1 Document L’oggetto Document contiene tutte le informazioni relative ad un documento ed espone i metodi per ottenerle. Replica quasi totalmente l’oggetto Document full tranne per alcuni particolari. Una delle differenze è il modo in cui mantiene l’informazione riguardo la rappresentazione delle pagine che costituiscono il documento. Nel full Document la rappresentazione delle pagine è inserita integralmente in una struttura dati apposita. Per un documento cartaceo di tre pagine l’oggetto Document conterrà al suo interno una 58
  • Implementazione List<Page> contenente tre oggetti Page. Ognuno degli oggetti Page conterrà a sua volta una lista di rappresentazioni di quella pagina (immagine scannerizzata, immagine processata, lista blocchi). Il Document light utilizzato lato client invece mantiene solamente una lista degli ID che identificano le PageRepresentation di interesse. Altra differenza è che Document light non contiene alcun riferimento alla relativa Response, ma indica solo se la Response è già stata scaricata dall’utente. Le informazioni più significative cui è possibile accedere tramite l’oggetto Document sono :  tipo di documento;  modello del documento;  proprietario del documento;  data creazione;  data inizio elaborazione;  coda di elaborazione in cui è inserito;  stato dell’elaborazione;  data termine elaborazione;  numero pagine del documento;  lista degli ID delle PageRepresentation disponibili;  stato della validazione del documento;  indicazione se il documento è stato scaricato o meno dall’utente;  costo dell’elaborazione. 6.3.4.2 User La classe User rappresenta un utente del sistema. Le informazioni cui è possibile accedere sono:  ID;  nome utente;  nome reale;  credito disponibile;  ruolo (Admin, Advisor o utente semplice). 59
  • Implementazione 6.3.4.3 FoundField La classe FoundField è una sorta di light entity della coppia chiave/valore (SearchedField/TextBlockWithQualityList). Un FoundField corrisponde dal punto di vista del significato al singolo elemento della Map contenuta nell’oggetto Response. FoundField definisce infatti le seguenti proprietà ed i relativi metodi get e set :  foundBlocks;  searchedField. l’oggetto foundBlocks è una lista di TextBlock, mentre searchedField è una stringa con valore pari al nome del campo cercato. 6.3.4.4 Response La classe Response riproduce quasi esattamente la controparte definita nel SEAD. Le differenze sostanziali consistono nella presenza di una List<FoundField> anziché della Map<SearchedField, TextBlock- WithQualityList> originale. Inoltre il Document cui fa riferimento è la versione light definita all’interno dello stesso package. Response espone i metodi per :  impostare il documento a cui fa riferimento;  estrarre il documento a cui fa riferimento;  estrarre la lista di FoundField;  assegnare una nuova lista di FoundField;  aggiungere un FoundField;  impostare l’indice di qualità;  estrarre l’indice di qualità;  assegnare un commento testuale;  estrarre il commento testuale. 6.3.4.5 TextBlock TextBlock ripresenta le stesse caratteristiche del TextBlock. In questo caso però la classe light contiene più informazioni dell’originale. 60
  • Implementazione Internamente infatti vengono mantenute sia i valori originali così come sono stati deserializzati di posizione e dimensioni del blocco sia i valori riscalati. 6.3.4.6 TextBlockList TextBlockList ripropone esattamente la classe TextBlockWithQualityList, salvo per la possibilità di essere utilizzata lato client. 6.3.5 GWT components Per la realizzazione delle interfacce grafiche sono state realizzati diversi componenti personalizzati, estendendo componenti standard forniti da GWT. Per l’applicazione oggetto di questo documento i due componenti più significativi sono TextBlockLabel e TooltipListener. 6.3.5.1 TextBlockLabel La classe TextBlockLabel estende la Label fornita da gwt. Una TextBlockLabel è una etichetta che contiene al suo interno un TextBlock. L’etichetta viene utilizzata nell’interfaccia grafica per evidenziare i blocchi estratti dal OCR sull’immagine. La sua posizione e le dimensioni corrispondono a quelle del blocco che contiene. 6.3.5.2 TooltipListener Stranamente i componenti gwt non offrono supporto nativo per i tolti. Per poter dare quindi delle rapide indicazioni d’uso all’utente si è dovuto implementarli. TooltipListener è una implementazione delle interfacce di gestione degli eventi MouseOver, MouseOut e Click . Quando il mouse si ferma sopra un elemento viene fatto partire un timer il quale dopo un certo intervallo di tempo fa comparire un popup informativo. Se il puntatore del mouse esce dall’area del componente o l’utente vi clicca sopra il timer viene annullato. 6.3.6 Client In questa sezione verrà illustrata l’implementazione ed il comportamento programmatico del client. Per la descrizione dell’interfaccia grafica e le modalità di utilizzo si vada al capitolo 5. 61
  • Implementazione L’applicazione presenta un EntryPoint. L’EntryPoint, una volta verificate le credenziali d’accesso dell’utente esegue il parsing dell’url alla ricerca di eventuali parametri. Se nella url è presente il parametro “doc” verrà eseguita la chiamata al metodo getDocumentById esposto dal servizio DocumentService. Una volta ottenuto il Document richiesto (si ricordi che in questo momento si sta lavorando lato client e che quindi l’oggetto Document è una istanza della classe light definita appositamente), l’EntryPoint richiama il costruttore della pagina di supervisione passando come parametro il Document stesso. Si procede quindi con la inizializzazione dell’applicazione. 6.3.6.1 Inizializzazione La fase di inizializzazione consiste nella valorizzazione delle variabili interne necessarie a gestire i diversi componenti grafici. Vi sono poi diverse strutture dati che devono essere popolate con gli oggetti restituiti dalle chiamate alle rpc implementate. I passi eseguiti dalla procedura di inizializzazione può essere schematizzata come segue: 1. chiamata al metodo getResponse del servizio ResponseService per ottenere la Response generata; 2. inizializzazione del pannello dettaglio del documento contenente informazioni relative proprietario, data, etc; 3. inizializzazione del pannello destinato a contenere la griglia per la presentazione dei dati; 4. inizializzazione del pannello destinato a contenere lo snippet del blocco di testo associato al campo selezionato nella griglia e la textbox che verrà utilizzata per editare manualmente i valori; 5. se l’operazione al punto 1 è andata a buon fine viene inizializzato il pannello destinato a contenere l’immagine del documento. 6.3.6.2 Presentazione dei dati Come già accennato nel paragrafo precedente la presentazione dei dati estratti dal sistema avviene tramite una griglia. 62
  • Implementazione Nel momento in cui si è sviluppata l’applicazione gwt non forniva supporto per il data presentation. Utilizzare i componenti standard sarebbe equivalso ad avere una tabella standard senza alcun supporto per la gestione,modifica e aggiornamento del dataset. Si è quindi reso necessario cercare una soluzione alternativa, cioè o sviluppare in proprio un componente per la presentazione dei dati o utilizzare librerie fornite da terze parti. Si è scelto di utilizzare il componente Grid fornito dalla libreria Ext Gwt. ExtGwt è una libreria java che fornisce componenti avanzati utilizzabili con gwt. Tale scelta comporta però dei compromessi. Essendo ExtGwt sviluppato da terzi i tempi per l’assorbimento delle novità inserite nelle release della piattaforma gwt possono essere lunghi. Nel caso specifico, pur essendo possibile utilizzare i componenti Ext Gwt con le release 2.x di gwt manca ancora il supporto al layout dichiarativo tramite UiBinder. Si è dovuto quindi rinunciare parzialmente (almeno per i componenti Ext Gwt) alla distinzione tra presentazione e comportamento programmatico inserendo codice per la gestione dell’interfaccia nel codice applicativo. I vantaggi sono invece la possibilità di agganciare la griglia di presentazione con un dataset e poter quindi manipolare i dati nella griglia senza dover implementare esplicitamente la logica di propagazione delle modifiche e le procedure per la reversibilità delle stesse. La Grid fornisce il supporto per gli eventi. Gli eventi implementati sono RowClick, RowDoubleClick e AfterEdit. RowClick e RowDoubleClick servono per la navigazione e selezione degli elementi all’interno della griglia. RowDoubleClick abilità automaticamente la modalità per l’assegnazione di un nuovo blocco alla voce selezionata. AfterEdit serve invece a ridisegnare il componente in quanto il rendering delle diverse righe è condizionato dai valori delle stesse. 63
  • Implementazione 6.3.6.3 Presentazione immagine documento ed evidenziazione dei blocchi estratti L’immagine del documento in esame è fondamentale per permettere all’operatore la correzione dei risultati forniti dal sistema. Poiché l’immagine del documento può avere dimensioni superiori all’area di visualizzazione disponibile su schermo si è deciso di inserire l’immagine in un pannello con possibilità di Scrolling. Poiché si deve dare la possibilità di selezionare i blocchi di testo direttamente dall’immagine si è reso necessario inserire ulteriori componenti nel pannello. Questi componenti sono le TextBlockLabel descritte precedentemente. Il rendering delle TextBlockLabel è condizionato al blocco che esse rappresentano. Tramite l’applicazione di stili diversi si diversificano le Label che identificano blocchi associati a qualche SearchedField nel documento. Il rendering delle label è inoltre sensibile agli eventi MouseOver e MouseOut in modo da rendere facilmente percepibile la loro presenza. Per come è implementato il widget gwt ScrollPanel è possibile inserirvi un solo widget. Dovendo invece noi inserire nel ScrollPanel l’immagine del documento e tutte le label richieste si è reso necessario l’utilizzo di più pannelli. Viene utilizzato quindi un AbsolutePanel (che non presenta invece limitazioni sui componenti figli inseribili) sul quale vengono registrati l’immagine della pagina del documento e tutte le label. L’AbsolutePanel così costruito può quindi essere inserito all’interno dello ScrollPanel. L’implementazione delle operazioni descritte è inserita nei metodo privato buildScroller il quale per eseguire il deploy dei componenti chiama il metodo privato initScroller. 6.3.6.4 Navigazione documento Un documento cartaceo scannerizzato e caricato nel sistema può estendersi su più pagine. Il client deve quindi gestire la navigazione su più pagine appartenenti al medesimo documento. 64
  • Implementazione E’ possibile scorrere le pagine del documento mediante due tasti di navigazione. L’implementazione del gestore dell’evento Click per i due bottoni esegue i seguenti passi: 1. ottiene la lista dei blocchi presenti nella nuova pagina tramite chiamate al metodo getAllTextBlocks fornito dal servizio BlockListService; 2. ottiene l’immagine della pagina da visualizzare tramite servizio rest (l’url è nella forma “/rest/representations/IDRappresentazionePagina”); 3. si aggiorna lo ScrollPanel inserendo la nuova immagine e le nuove label. Si noti che la navigazione tra le pagine del documento non richiede il download dell’intera pagina web ma vengono richiesti e trasferiti i soli dati necessari per aggiornare il componente. In alternativa la navigazione all’interno del documento è implementata anche attraverso la selezione dei campi nella griglia. Il click su di un elemento nella griglia infatti procede all’esecuzione della procedura sopra descritta con l’aggiunta dello scrolling automatico in modo da rendere visibile il blocco selezionato 6.3.6.5 Editing L’applicazione fornisce le funzionalità sia per modificare e correggere il valore estratto dal sistema per un determinato campo sia per selezionare un nuovo blocco dall’immagine e creare una nuova associazione campo-blocco. La modifica e correzione del valore estratto è implementato tramite una TextBox inserita nel pannello di dettaglio testo. La TextBox mostra il valore corrente del testo estratto. Nel momento in cui viene modificato il testo il gestore dell’evento OnChange procede ad aggiornare il corrispondente campo nella Grid. In questo modo la modifica viene propagata verso il dataset collegato alla griglia. L’assegnazione di un nuovo blocco per un campo viene implementata tramite click del mouse sul blocco designato. Per poter eseguire una assegnazione si deve essere in modalità assegnazione. 65
  • Implementazione L’implementazione della procedura di assegnazione richiede i seguenti passi: 1. selezione del campo interessato nella griglia; 2. entrare in modalità assegnazione tramite click sul bottone di attivazione (in alternativa col doppio click sulla griglia si entra immediatamente in modalità assegnazione); 3. il gestore dell’evento OnClick della TextBlockLabel procede a: a. Estrarre dalla TextBlockLabel il TextBlock al suo interno; b. Aggiornare il record nel dataset con il nuovo TextBlock. 6.3.6.6 Validazione e salvataggio modifiche La validazione del documento avviene nel momento in cui l’operatore clicca sul bottone di accettazione. Tale operazione oltre validare il documento renderà persistenti sul database le modifiche effettuate L’implementazione del gestore dell’evento OnClick assegnato al bottone di accettazione esegue la seguente procedura : 1. estrazione dei record modificati dal dataset; 2. costruzione e popolamento di una lista contenente i record la cui modifica è consistita nella sola correzione del valore estratto; 3. costruzione e popolamento di un lista contenente i record la cui modifica ha previsto l’assegnazione di un nuovo blocco; 4. chiamata al metodo setFoundFields del servizio ResponseService fornendo le due liste come parametri; 5. attesa del callback del servizio. In caso di fallimento verrà notificato il mancato salvataggio delle modifiche effettuate. In caso di successo si procederà con la validazione del documento e , se presente e se voluto, al caricamento del succesivo documento tramite chiamata al metodo setDocumenValidationAndReturnNextID esposto dal servizio DocumentService. Si tenga presente che il caricamento del nuovo documento descritto nel punto 5 non necessita di un nuovo download della pagina ma verranno richiesti e trasferiti i soli dati del documento con i quali si potrà eseguire l’aggiornamento dei componenti. 66
  • Conclusioni 7 Conclusioni 7.1 Obiettivi raggiunti Per quel che riguarda l’implementazione delle funzionalità richieste si può dire di aver raggiunto gli obiettivi preposti. Tutte le richieste iniziali sono state esaudite. Tuttavia bisogna considerare che molte delle funzionalità implementate non sono frutto della prima fase di analisi e progettazione. Anche semplicemente confrontando il prototipo di interfaccia e l’interfaccia nella sua versione finale si può vedere che le aggiunte e le modifiche sono notevoli. Ad esempio in un primo momento si era pensato di gestire la modifica dei valori direttamente nella griglia. Successivamente nel corso delle riunioni svolte in laboratorio si è fatto presente il problema dell’usabilità e la necessità di intervenire per facilitare l’utente nel riconoscere l’informazione cercata ed eventuali errori. Ciò a portato all’inserimento dei pannelli di dettaglio. Si può quindi dire di aver raggiunto gli obiettivi base e che il sistema realizzato è effettivamente funzionante. Non si può negare però che 67
  • Conclusioni l’aggiunta di nuove funzioni o nuove modalità di interazione in corso d’opera evidenzino la necessità di un maggior studio dell’interfaccia. In questa ottica probabilmente anche una fase di test su un campione di utenti scelto tra i possibili utilizzatori del sistema sarebbe utile per indirizzare ulteriori miglioramenti. Per quel che riguarda l’interfaccia web sono stati eseguiti test sui diversi browser e si è potuto constatare che il comportamento (salvo alcuni glitch cui è stato posto rimedio con soluzioni ad hoc) è uniforme. Ciò conferma la bontà e l’utilità del framework gwt. 7.2 Considerazioni personali Il lavoro svolto ha permesso di lavorare con tecnologie che in precedenza non avevo avuto modo di utilizzare. Nello specifico sono rimasto favorevolmente colpito dalla utilità e dalla efficacia del Google Web Toolkit. L’utilizzo del linguaggio java ed il meccanismo del DeferredBinding rende possibile lo sviluppo di applicazioni web senza dover imparare da zero un nuovo linguaggio e senza dover affrontare personalmente il problema del supporto agli standard dei diversi browser. Nello sviluppare l’interfaccia web è stato necessario usare componenti forniti da terze parti per il data presentation. Tale scelta è stata dovuta alla mancanza di strumenti adeguati allo scopo nel framework. Tuttavia le novità introdotte nell’ultima release di gwt e la confidenza maturata nell’utilizzo della piattaforma mi fanno pensare che se dovessi cominciare lo sviluppo ex novo utilizzerei i soli componenti standard ed eventualmente provvederei ad una implementazione custom. In questo modo si potrebbe utilizzare il sistema di layout dichiarativo per tutte le componenti garantendo totale distinzione tra presentazione e logica. Probabilmente ciò comporterebbe un maggior lavoro di sviluppo poiché i componenti terze parti utilizzati sono complessi ma ritengo che la maggior pulizia e manutenibilità del codice valgano lo sforzo. Dal punto di vista della realizzazione delle componenti server side sono soddisfatto della esperienza maturata nell’utilizzo delle tecnologie EJB e JPA. 68
  • Conclusioni A posteriori posso dire che le difficoltà tecniche incontrate nello sviluppo e nell’utilizzo di queste tecnologie, per quanto in alcuni momenti fonte di frustrazione, sono state decisamente formative. Lavorando a questa tesi ho inoltre preso atto di quanto rapidamente le tecnologie e gli strumenti informatici si evolvano. Il periodo che intercorre tra la release di una tecnologia e la release successiva è di fatto inferiore al periodo necessario a prendere padronanza della stessa e ad utilizzarla nello sviluppo. La conseguenza di ciò è che scelte precedentemente fatte possono rivelarsi sbagliate o poco efficienti. È tuttavia utopistico pensare di stare continuamente al passo. La necessità di mettere in produzione un dato progetto pone dei limiti e rende obbligatorio congelare la piattaforma tecnologia con cui lavorare. 69
  • Riferimenti 8 Riferimenti 1. Eric Medvet, Alberto Bartoli e Giorgio Davanzo. A new probabilistic approach for information extraction from printed documents. Sottomesso per la pubblicazione internazionale. 2. Y. Belaid e A. Belaid. Morphological tagging approach in document analysis of invoices. In Proceedings of the Pattern Recognition, 17th International Conference on (ICPR'04) Volume 1 - Volume 01, pages 469{472. IEEE Computer Society, 2004. 3. F. Cesarini, E. Francesconi, M. Gori, and G. Soda. Analysis and understanding of multi-class invoices. International Journal on Document Analysis and Recognition, 6(2):102{114, October 2003. 4. Hatem Hamza, Yolande Belaid, e Abdel Belaid. Case-Based reasoning for invoice analysis and recognition. In Case-Based Reasoning Research and Development, pages 404{418. 2007. 5. Hiroshi Sako, Minenobu Seki, Naohiro Furukawa, Hisashi Ikeda, e Atsuhiro Imaizumi. Form reading based on form-type identification and form-data recognition. In Proceedings of the 71
  • Riferimenti Seventh International Conference on Document Analysis and Recognition - Volume 2, page 926. IEEE Computer Society, 2003. 6. Documentazione ufficiale Java Enterprise Edition (http://java.sun.com/javaee/reference/apis/) 7. Pagina ufficiale Glassfish (https://glassfish.dev.java.net/) 8. Documentazione ufficiale JPA (http://java.sun.com/javaee/technologies/persistence.jsp) 9. Developer’s guide GWT (http://code.google.com/intl/it- IT/webtoolkit/doc/latest/DevGuide.html) 10. Pagina ufficiale ExtGwt (http://www.sencha.com/products/gwt/) 11. Documentazione ExtGWt (http://www.sencha.com/deploy/gxtdocs/) 72
  • Ringraziamenti Desidero ringraziare innanzitutto la mia famiglia per il supporto, morale e non, fornito in tutti questi anni. Grazie di cuore. Ringrazio Francesca per essermi sempre stata accanto ed avermi sopportato pazientemente. Ringrazio il Professor Bartoli per l’opportunità offertami e per la costante disponibilità. Ringrazio Giorgio, Eric, Enrico, Marco e più in generale “flora e fauna” che ha popolato in questi mesi il laboratorio di “Reti di calcolatori”. La loro disponibilità e simpatia hanno fatto volar via i giorni trascorsi in laboratorio. Ringrazio Mario, Zibbo, Leonardo, Alan e tutti i compagni di appartamento con i quali ho avuto il piacere di trascorrere tante serate in allegria (un sentito grazie anche al divano di via Marconi). Ringrazio tutti coloro con cui ho condiviso parte di questo lungo percorso. In ordine sparso Fabio, Roberto, Daniele, Daniele “Menion”, Paolo e Jack. Ringrazio i compagni di squadra del Microbirrificio Rio Ospo e tutti i supporters per avermi fatto capire che l’importante non è vincere ma andare a bersi una birra dopo (ed a volte anche prima). Sicuramente ho dimenticato qualcuno, spero basti un sentito grazie a tutti. 73