| Date post: | 18-Nov-2014 |
| Category: |
Technology |
| Upload: | luca-bressan |
| View: | 2,626 times |
| Download: | 0 times |
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
ANNO ACCADEMICO 2009/2010
Laureando:
Luca Bressan
Relatore:
Prof. Alberto Bartoli
Correlatori:
Prof. Eric Medvet
Ing. Giorgio Davanzo
Dedicato a mamma e papà,
a nonna Silvana, a nonna Armanda,
al nonno Nini, al nonno Massimo
ed al “barba” Luciano.
Grazie.
I
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
Sommario
II
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
Introduzione
1
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
Introduzione
2
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.
Introduzione
3
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.
Scenario
5
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.
Scenario
6
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”.
Scenario
7
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
Scenario
8
(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.
Scenario
9
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.
Analisi
11
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 :
Analisi
12
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.);
Analisi
13
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.
Analisi
14
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.
Analisi
15
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
in ingresso
Ammissibile
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
Analisi
16
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.
Analisi
17
Figura 2: Diagramma di stato di un campo
Analisi
18
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
Analisi
19
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.
Analisi
20
3.4 Flowchart applicazione client
Figura 4 : Flowchart applicazione
Analisi
21
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.
Analisi
22
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
Analisi
23
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.
Tecnologie utilizzate
25
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).
Tecnologie utilizzate
26
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;
Tecnologie utilizzate
27
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
Tecnologie utilizzate
28
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
Tecnologie utilizzate
29
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
Tecnologie utilizzate
30
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.
Tecnologie utilizzate
31
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.
Tecnologie utilizzate
32
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.
Interfaccia grafica
33
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.
Interfaccia grafica
34
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
Interfaccia grafica
35
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
Interfaccia grafica
36
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.
Interfaccia grafica
37
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.
Interfaccia grafica
38
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:
Interfaccia grafica
39
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
Interfaccia grafica
40
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.
Implementazione
41
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;
Implementazione
42
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.
Implementazione
43
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,
Implementazione
44
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.
Implementazione
45
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.
Implementazione
46
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
Implementazione
47
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
Implementazione
48
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
Implementazione
49
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.
Implementazione
50
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.
Implementazione
51
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;
Implementazione
52
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.
Implementazione
53
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.
Implementazione
54
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.
Implementazione
55
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.
Implementazione
56
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.
Implementazione
57
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.
Implementazione
58
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
Implementazione
59
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).
Implementazione
60
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.
Implementazione
61
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.
Implementazione
62
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.
Implementazione
63
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.
Implementazione
64
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.
Implementazione
65
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.
Implementazione
66
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.
Conclusioni
67
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
Conclusioni
68
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.
Conclusioni
69
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.
Riferimenti
71
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
Riferimenti
72
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/)
73
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.
