UNIVERSITA’ POLITECNICA DELLE MARCHE
FACOLTA’ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica e dell'Automazione
Dipartimento di Elettronica, Intelligenza Artificiale e
Telecomunicazioni
PROGETTO E SVILUPPO DI UN SOFTWARE IN "JAVA"
PER LA TELEREFERTAZIONE:
SEZIONE AMMINISTRATIVA E FORMATI PER LA
TRASMISSIONE DI DATI BIOMEDICI
Tesi di Laurea di:
Francesco Pongetti
Relatore:
Prof. Aldo Franco Dragoni
Correlatore:
Prof. Paolo Puliti
Anno Accademico 2007-2008
Alla mia famiglia per il suo supporto morale
e per avermi permesso di studiare
A Raffaella perché senza la sua presenza
arrivare fin qua sarebbe stato molto più difficile
Un ringraziamento speciale al Prof. Aldo Franco Dragoni
e a tutti i miei compagni con cui ho svolto il tirocinio
INDICE
INDICE ......................................................................................................... - 2 CAPITOLO 1. Telemedicina & Telerefertazione ......................................... - 4 1.1 Introduzione .......................................................................................... - 4 1.2 Telemedicina ......................................................................................... - 5 1.3 Vantaggi................................................................................................ - 6 1.4 Problematiche........................................................................................ - 8 1.5 Telerefertazione ................................................................................... - 10 CAPITOLO 2. Medical Telereporting System............................................ - 12 2.1 Introduzione ........................................................................................ - 12 2.2 Struttura e funzionamento.................................................................... - 14 2.3 Tecnologie utilizzate............................................................................ - 20 2.3.1 Java............................................................................................... - 23 2.3.1.1 Perché Java ............................................................................ - 26 2.3.1.2 Java Servlet: Tomcat .............................................................. - 28 2.3.2 Google Web Toolkit...................................................................... - 30 2.3.2.1 Funzionamento del GWT ....................................................... - 33 2.3.2.2 GWT-Ext ............................................................................... - 38 2.3.2.3 Altri vantaggi nell’uso del Google Web Toolkit ..................... - 38 2.3.3 MySQL......................................................................................... - 40 2.3.4 Altre librerie e strumenti utilizzati................................................. - 40 CAPITOLO 3. Sezione Amministrativa...................................................... - 42 3.1 Introduzione ........................................................................................ - 42 3.2 Manager & Super-Admin..................................................................... - 43 3.3 Funzionalità......................................................................................... - 45 3.4 Realizzazione tecnica........................................................................... - 48 3.4.1 Struttura, componenti e classi Java................................................ - 48 3.4.1.1 Admin.java............................................................................. - 50 3.4.1.2 Registration.java, RegistrationRMImpl.java ........................... - 54 -
-2-
3.4.1.3 ListaUser.java, ListaUserRMImpl.java................................... - 62 3.4.1.4 ModRegistration.java, ModRegistrationRSImpl.java.............. - 69 3.4.1.5 UserArea.java, UserAreaRSImpl.java..................................... - 70 3.4.2 Struttura dei dati nel database........................................................ - 73 3.4.3 Gestione della sessione ................................................................. - 75 3.5 Problematiche di sicurezza................................................................... - 79 3.5.1 SSL e Login.................................................................................. - 79 3.5.2 Sicurezza del database................................................................... - 80 CAPITOLO 4. Dati Biomedici.................................................................... - 82 4.1 Dati biomedici ..................................................................................... - 82 4.2 DICOM ............................................................................................... - 83 4.2.1 Struttura dei file ............................................................................ - 85 4.3 Software open source........................................................................... - 88 4.4 Standard ECG...................................................................................... - 92 CAPITOLO 5. Conclusioni ......................................................................... - 94 5.1 Migliorare Medtel................................................................................ - 94 5.1.1 Compatibilità con i browsers......................................................... - 95 5.1.2 Velocità di esecuzione................................................................... - 97 5.1.3 Usabilità ....................................................................................... - 99 5.2 Integrazione....................................................................................... - 101 5.2.1 Servizi medici per altri software.................................................. - 101 5.2.2 Visualizzatori di dati biomedici................................................... - 102 5.2.3 Dispositivi medici ....................................................................... - 103 5.3 Conclusioni ....................................................................................... - 103 Bibliografia .................................................................................................- 106 -
-3-
CAPITOLO 1
Telemedicina & Telerefertazione
1.1 Introduzione
Il continuo sviluppo delle tecnologie informatiche e telematiche, nonché il
progressivo allargamento del bacino di utenti in grado di accedere ad esse,
ha aperto ad un gran numero di nuove possibilità e prospettive. A partire
dagli anni ’70 la rivoluzione informatica ha cominciato ad entrare con
prepotenza in un numero sempre maggiore di settori industriali,
commerciali e civili, investendo anche quegli ambienti che, allora,
apparivano concettualmente non adatti ad essere reinterpretati in chiave
informatica.
I dispositivi di calcolo nascono con lo scopo di agevolare l’esecuzioni di
compiti e nel tempo si è visto che esistono innumerevoli ambienti in cui i
computer possono dare un sostanzioso contribuito. Detto questo, non si può
fare a meno di osservare che la “rivoluzione digitale”, utilizzando
un’espressione coniata da Nicholas Negroponte, non ha solamente
permesso di eseguire più velocemente un gran numero di operazioni, ma ha
anche avuto il merito di creare nuove possibilità impensabili in epoca preinformatica.
Durante il lavoro di tirocinio ci si è potuti confrontare proprio con uno di
questi nuovi orizzonti: la telemedicina. Il tirocinio ed il conseguente lavoro
di tesi è stato totalmente incentrato su questa importante tematica e, di
conseguenza, appare naturale spendere questo primo capitolo in
un’introduzione all’argomento. Nei paragrafi successivi verranno quindi
fornite molte informazioni per aiutare il lettore a farsi un quadro completo
-4-
ed accurato di cosa s’intenda oggi per telemedicina, quali siano i suoi
vantaggi e svantaggi, nonché lo stato attuale dei lavori in questo campo.
Nei capitoli due e tre invece verrà descritto il frutto del nostro lavoro di
ricerca in campo telemedico: Medical Telereporting System. Medical
Telereporting System è un software completo, sviluppato da noi durante il
periodo di tirocinio, per risolvere uno specifico problema di telemedicina: la
telerefertazione. Di seguito quindi, verrà trattato nel dettaglio anche questo
specifico tema.
1.2 Telemedicina
Si può cominciare ad affrontare l’argomento dando una definizione intuitiva
del termine: la telemedicina è l'insieme di tecniche mediche ed informatiche
che permettono la cura di un paziente a distanza o più in generale di fornire
servizi sanitari in remoto. La telemedicina è il frutto del connubio di diverse
tecnologie in rapido sviluppo che consentono di trasferire informazioni
mediche a distanza attraverso il telefono, Internet o altri tipi di network, allo
scopo di ottenere consulenze specialistiche o addirittura, a volte, per
eseguire procedure mediche senza che il personale si trovi fisicamente nel
luogo di residenza del paziente.
In generale per telemedicina si possono intendere un’estrema eterogeneità
di situazioni: dalla semplice conversazione telefonica tra due specialisti che
si occupano del medesimo paziente o casi molto più complessi che
coinvolgono tecnologie satellitari, apparati di videoconferenza e bracci
meccanici controllati in real-time. Il concetto più importante che bisogna
tenere a mente, è comunque lo stretto collegamento esistente tra scienza
medica, tecnologia, informatica e telematica che si crea in ambito
telemedico.
-5-
Guardando alla storia e allo sviluppo della telemedicina si può vedere che
dei tentativi di curare pazienti a distanza erano già stati compiuti prima
della rivoluzione informatica. Esiste infatti un lungo elenco di casi
documentati di pazienti dell’800, guariti in seguito alle cure prescritte e
inoltrate tramite la tradizionale posta cartacea, da specialisti risiedenti in
altre città. Attualmente comunque quando si parla di telemedicina, si
sottende sempre l’utilizzo di tecnologie informatiche ed è proprio questa
eccezione del termine che verrà considera valida nel corso della trattazione.
Per sottolineare l’importanza dell’argomento di cui si sta discutendo vale la
pena citare alcuni lavori che la ricerca italiana ha prodotto proprio in tale
ambito. I primi esperimenti di telemedicina sono stati condotti in Italia, per
permettere un’adeguata assistenza nelle aree geografiche più remote o in
situazioni disagiate (perforazioni petrolifere su piattaforma off-shore,
spedizioni artiche) ed in particolare hanno riguardato la trasmissione
sperimentale di elettrocardiogrammi a distanza, iniziata nel 1976,
utilizzando le normali linee telefoniche. In seguito, negli anni ottanta, la SIP
lanciò un vero e proprio “cardiotelefono”. Da allora, gli enti di ricerca, le
università, le società scientifiche, il Consiglio Nazionale Ricerche (CNR) ed
il Ministero della Sanità, lavorando a diversi progetti (ad esempio quelli
strategici/speciali del CNR: “Sistemi Esperti in Medicina”, “Sistemi
Informatici in Biomedicina”, “Robotica in chirurgia”, ecc.), hanno portato
alla crescita esponenziale dei servizi disponibili, con 12.000 pazienti
teleassistiti all’anno e 50 aziende operanti in questo settore (dati del 2002).
1.3 Vantaggi
I vantaggi di cui la pratica medica può beneficiare grazie all’introduzione
delle tecnologie legate alla telemedicina, dovrebbero risultare evidenti fin
-6-
dalla breve analisi iniziale svolta nei paragrafi precedenti. Si vuole fin da
subito mettere in risalto uno degli aspetti che hanno promosso
maggiormente gli investimenti, pubblici e privati, in tecnologie di questo
tipo: i risparmi sui costi. La possibilità di effettuare diagnosi oppure analisi
a distanza infatti, permette di diminuire notevolmente i costi legati alla
delocalizzazione delle strutture sanitarie. Grazie alla telemedicina si può
quindi pensare di concentrare il personale medico in pochi poli più grandi,
avendo così tutti i vantaggi dati da effettive economie di scala. Allo stesso
tempo però, i risparmi non si traducono in una diminuzione dei servizi per i
pazienti, ma anzi, si potrebbe avere una copertura talmente capillare del
territorio, da arrivare fino alle case dell’utenza attraverso i collegamenti a
banda larga sempre più diffusi al giorno d’oggi. Oltre ai risparmi sul
personale, specialmente quello medico, si può ottenere un ulteriori
contenimento dei costi grazie alla minore necessità di complesse macchine
per la diagnosi. Si può infatti decidere di acquistare una strumentazione
magari più complessa, ma in quantità inferiori, ed utilizzando delle
apparecchiature dalle funzionalità e dai costi più ridotti collegarsi alle prime
da postazioni remote.
La telemedicina non offre, naturalmente, solo dei vantaggi legati al
contenimento dei costi, ma esistono molte altre ragioni che dovrebbero
spingere verso una diffusione rapida di queste tecnologie. Ad esempio, si
pensi alla situazione di pazienti affetti da patologie molto rare che non
possono accedere alle cure di specialisti del settore perché impossibilitati a
trasferirsi, anche a causa di ragioni economiche, e che quindi non possono
ottenere un consulto importante. Attraverso la telemedicina, il medico
curante di questi pazienti potrebbero richiedere un consulto a distanza da
parte dello specialista, con evidenti vantaggi per i pazienti stessi.
Ulteriori situazioni in cui si evidenziano i pregi dell’uso delle telemedicina,
sono quelle in cui si deve far fronte alla cura e all’assistenza di persone che
-7-
vivono in paesi economicamente disagiati. Alcuni villaggi africani sono
degli esempi lampanti di come l’introduzione di semplici infrastrutture
telematiche (collegamenti dial-up), hanno permesso un notevole aumento
della qualità di vita delle persone malate. Grazie a queste infrastrutture
iniziali infatti, si è potuto accedere ai servizi di diagnostica sperimentale a
distanza, messi in piedi da alcuni centri di ricerca situati nel ricco
Occidente. In questo modo, zone estremamente povere hanno goduto
dell’assistenza di personale specializzato, notevolmente carente in quasi
tutto il territorio del continente africano.
Il software sviluppato in fase di tirocinio nasce proprio per inserirsi nel
contesto di aiuto ai paesi più deboli. Le soluzioni tecniche adottate sono
infatti, il frutto di precise considerazioni su questo tema e sono state
formulate anche grazie al contributo dato dallo studio in luogo delle
esigenze di determinati ambienti più disagiati.
Per finire la carrellata di ragioni a favore della telemedicina, bisogna
segnalare anche l’utilizzo di questa per scopi didattici, anche se in questo
caso sarebbe più giusto parlare di e-learning. La possibilità di seguire corsi
in teleconferenza o anche di assistere ad operazioni chirurgiche eseguite da
specialisti prestigiosi, è un ottimo modo per poter diffondere le conoscenze
mediche in zone disagiate.
1.4 Problematiche
A fianco dei risvolti positivi che la telemedicina promette di portare con sè,
esistono comunque dei problemi insiti nella pratica telemedica stessa che ne
possono compromettere l’uso su larga scala. L’elenco di problematiche
legate alla medicina è infatti, abbastanza vasto anche se bisogna subito fare
una distinzione tra problemi superabili con maggiori investimenti nel
-8-
settore e problemi invece, che non possono essere del tutto risolti con le
tecnologie attuali.
Le infrastrutture necessarie affinché la telemedicina possa essere messa in
atto, sono il maggior handicap di questa tecnologia. Si è a lungo dibattuto
dei vantaggi di cui i paesi poveri possono godere potendo rivolgersi a
personale medico situato all’altro capo del mondo, ma forse non si è
sottolineato abbastanza che la diffusione di tecnologie informatiche e
soprattutto telematiche in questi paesi è notevolmente carente, impedendo
di fatto un vero sviluppo del settore telemedico. Il problema infrastrutturale
è un problema sostanzialmente economico e potrebbe essere risolto con una
serie mirata di investimenti da parte dei paesi più ricchi. Dall’altro canto
però, rappresenta anche una sfida tecnologica per tutto il mondo
ingegneristico che è chiamato a costruire dei software e delle
strumentazioni capaci di operare anche con risorse estremamente limitate.
Appare chiaro comunque, che se si vuole veramente sfruttare i vantaggi
della telemedicina a favore dei paesi più disagiati, occorre la volontà di
eseguire degli investimenti iniziali. Al contrario si rischierebbe di
aumentare ancora una volta il gap esistente tra chi può permettersi le cure
più all’avanguardia e chi invece si deve accontentare delle briciole.
Il rischio di digital divide e la necessità di expertise complesse rappresenta
un altro problema che affligge la telemedicina e che deve essere affrontato.
Sempre più spesso le persone si dividono tra quelle che sono in grado di
sfruttare i vantaggi legati alle nuove tecnologie e quelle che invece
mancano delle conoscenze per poterlo fare. Questo fenomeno prende il
nome di digital divide ed è un problema sostanzialmente non economico,
ma culturale, anche se spesso le due cose alla fine risultato collegate. La
telemedicina deve quindi offrire la possibilità di accedere alle sue
prestazioni anche a persone che non hanno delle determinate competenze.
Gli studi in questo campo sono stati notevoli e si è arrivati a piattaforme che
-9-
permettono di fruire di servizi sanitari attraverso la tv digitale terrestre o
cellulari, ma comunque resta ancora molto da fare per rendere veramente
godibile a tutti l’esperienza telemedica. Non bisogna dimenticarsi inoltre,
che queste tecnologie dovranno essere controllate da personale medico, a
cui quindi non si può richiedere una competenza informatica troppo elevata.
Altre problematiche sono quelle dovute a standard per il trasporto dei dati
non completamenti maturi oppure all’opposto troppo vecchi e non adatti
allo scopo. Spesso i collegamenti tra due postazioni distanti, si realizzano
tramite i normali networks già esistenti, come per esempio Internet. Le
comunicazione quindi viaggiano tramite protocolli, quali il TCP/IP, che non
sono nati con lo scopo di trasmettere dati sensibili e che soprattutto non
rispettano dei requisiti di QoS (quality of service). Questo porta a scenari
estremamente inquietanti. Da un lato c’è il rischio che persone non
autorizzate intercettino un flusso di dati medici sensibili, attaccando quindi
la privacy dei pazienti o peggio modificandoli per i loro scopi, dall’altro gli
alti tempi di lag e l’assenza di assicurazione circa la qualità dei
collegamenti, impediscono ad esempio di eseguire le pratiche più avanzate
come la chirurgia a distanza.
Le aziende del settore hanno cercato di far fronte a questi problemi
realizzando degli standard ad-hoc adatti ad essere utilizati in situazioni
mission-critical come queste. Il gran numero di soggetti operanti nel settore
non ha però raggiunto ancora uno standard unico e questo fatto rappresenta
l’ultima nota negativa che affligge la telemedicina.
1.5 Telerefertazione
Nell’ambito generale delle telemedicina si vuole a questo punto mettere in
risalto il tema più specifico delle telerefertazione, che è anche l’argomento
- 10 -
di cui ci si è occupati nello sviluppo di Medtel. Come si è visto nei
paragrafi precedenti, la telemedicina è un campo estremamente vasto, in cui
informatica, telecomunicazione, medicina si fondono per raggiungere
un’eterogeneità di scopi differenti. La telerefertazione è proprio uno di
questi scopi.
Per telerefertazioni si intende la possibilità di effettuare diagnosi ed ottenere
consulenze mediche a distanza. E’ quindi uno dei cardini fondamentali di
tutta la telemedicina. La telerefertazione è la pratica telemedica più
semplice da effettuarsi al giorno d’oggi ed è anche probabilmente la più
diffusa. E’ infatti una pratica consolidate, ad esempio, l’invio da parte delle
strutture sanitarie più piccole, di dati clinici ai laboratori di analisi ubicati
nei centri più grandi, affinché questi possano valutarli e dare la loro
opinione.
Medtel nasce proprio per agevolare situazioni come queste ed in particolare
per essere utilizzato in zone disagiate. Lo scopo ultimo dell’applicativo è in
definitiva, mettere in contatto medici e pazienti sfruttando le tecnologie
telematiche, affinché si possa effettuare una diagnosi. Per far questo è stata
allestita un’architettura che permette il trasporto e la memorizzazione dei
dati clinici. Come questa sia stata realizzata è oggetto dei prossimi capitoli.
- 11 -
CAPITOLO 2
Medical Telereporting System
2.1 Introduzione
Nel capitolo 1 si è definito cosa s’intende per telerefertazione e come questa
venga realizzata al giorno d’oggi. In questo capitolo invece si descriverà il
Medical Telereporting System e le tecnologie utilizzate per svilupparlo.
Il Medical Telereporting System (d’ora in avanti semplicemente Medtel)
nasce con lo scopo di creare un software completo per far fronte alle
esigenze di telerefertazione attuali, così come sono state descritte nel
capitolo 1. Nello sviluppo di Medtel si è prestata particolare attenzione a
quelle che sono le problematiche dei software già sviluppati in passato e
quindi si è cercato di realizzare un applicativo il più possibile completo ed
usabile.
Medtel però non è semplicemente un rivisitazione, magari migliorata e
corretta, dei software di telerefertazione già esistenti, ma presenta tratti di
sostanziale novità che lo rendono unico nel panorama attuale. L’idea che sta
alla base del software e che in questo campo non trova altri riscontri, è
l’idea di comunità. Gli utilizzatori di Medtel sono suddivisi in comunità, o
gruppi, che comunicano tra di loro e si scambiano servizi di telerefertazione
attraverso l’infrastruttura tecnologica fornita da Medtel stesso. Questi
gruppi sono essenzialmente tre: medici, richiedenti ed amministratori. A
questi tre gruppi se ne aggiunge un quarto, molto più ristretto, con compiti
di supervisione e di cui si parlerà più in dettaglio nei capitoli successivi.
L’idea di comunità è importante ed
innovativa perché cambia
completamente i paradigmi classici su cui si basa la telerefertazione. Fin
- 12 -
dall’inizio la telerefertazione è nata con lo scopo di essere un surrogato “a
distanza” del rapporto medico-paziente quotidiano a cui tutti siamo abituati.
In questa ottica gli sforzi propesi a migliorare la telerefertazione erano tutti
indirizzati a cercare di ridurre gli effetti della distanza tra medico e paziente
e rendere la diagnosi tramite queste nuove tecnologie, il più possibile simile
a quella che si avrebbe nel caso tradizionale. Medtel invece nasce con lo
scopo di sfruttare fino in fondo le tecnologie telematiche per fornire anche
servizi innovativi, che non si articolino solamente in una rivisitazione a
distanza del rapporto medico-paziente. L’idea di comunità si forma proprio
seguendo questa linea innovativa. Perché fornire solamente un software per
permettere il rapporto medico-paziente a distanza, quando si può fornire ai
pazienti un’intera comunità di dottori? Nei paragrafi successivi sarà
spiegato più in dettaglio lo schema di funzionamento e la struttura del
Medical Telereporting System che si è sviluppato.
Schermata principale
(Screenshot tratto da Medtel)
- 13 -
2.2 Struttura e funzionamento
Come già messo in luce nell’introduzione, l’idea che sta alla base di Medtel
è quella di comunità. In Medtel gli utenti sono suddivisi in tre gruppi
principali: medici, richiedenti ed amministratori. Ogni gruppo riveste un
ruolo all’interno del sistema complessivo e presenta delle caratteristiche
peculiari. I richiedenti rappresentano le strutture sanitarie sparse nel globo
che hanno bisogno di servizi di telerefertazione e telemedicina. I medici
sono, naturalmente, gli individui chiamati a mettere a disposizione la loro
esperienza medica e le loro competenze ai richiedenti. Infine, gli
amministratori sono invece coloro che supervisionano il funzionamento di
Medtel ed hanno il compito di gestire i permessi di accesso ai servizi da
parte degli altri utenti.
I richiedenti sono un tramite tra i pazienti veri e propri ed i dottori. I
richiedenti possono essere degli ospedali che gestiscono un gran numero di
pazienti, oppure semplicemente delle piccole comunità agricole africane. In
generale comunque i richiedenti sono delle strutture sanitarie che
nell’ipotesi più complessa potrebbero aver bisogno di prestazioni per un
gran numero di pazienti. Alla luce di questo, è apparso chiaro fin da subito
che il software di telemedicina in fase di sviluppo, dovesse permettere una
facile gestione di un gran numero di pazienti, e che questa dovesse essere la
più intuita ed agile possibile, soprattutto per permettere la fruizione dei
servizi anche da parte di un personale non molto orientato alle tecnologie
informatiche. La soluzione è stata trovata nella trasposizione informatica
dell’intuitivo concetto di cartella clinica a cui tutti siamo abituati. Medtel
infatti permette ai richiedenti di compilare per ogni loro paziente, una
cartella clinica “virtuale” in cui sono contenuti tutti i parametri fisici e
medici del soggetto in esame. In questa cartella clinica virtuale finiscono
anche i dati storici sulle prestazioni richieste attraverso Medtel per il
- 14 -
paziente stesso. In questo modo i richiedenti possono avere facilmente un
quadro completo dello stato medico del paziente e contemporaneamente
questa strutturazione offre un facile accesso ai dati. Anche con questo tipo
di struttura comunque, l’archivio dei dati clinici può diventare molto esteso
e contenere una mole notevole di informazioni. Con centinaia o addirittura
migliaia di pazienti in archivio, anche il semplice ritrovare di un dato
importante, può diventare un compito arduo. Per far fronte a queste
problematiche, si è pensato bene di mettere a disposizione dei richiedenti
una comoda interfaccia per la ricerca dei pazienti attraverso i dati
anagrafici.
Cartella clinica di un paziente
(Screenshot tratto da Medtel)
Detto come vengano gestiti i dati clinici dei pazienti, bisogna definire come
Medtel gestisca il processo di telerefertazione vero e proprio, cioè come si
articoli il servizio principale per il quale è stato sviluppato. Per far questo
bisogna prima parlare brevemente di come sia stata sviluppata la parte
- 15 -
concernente il personale medico. Medtel parte dal presupposto che i medici
che offrono le loro competenze siano degli specialisti in particolari campi
della medicina e non dei dottori generici di base. Questa ipotesi nasce dalla
constatazione di quelli che sono gli scopi per il quale nasce il software
stesso, cioè offrire dei servizi di telerefertazione e quindi dei consulti
altamente specializzati per particolari problematiche mediche. Quando si
definisco le credenziali di accesso per un nuovo medico quindi, oltre ai
consueti dati anagrafici, viene anche richiesto di specificare quelle che sono
le specializzazioni del medico stesso, come ad esempio medicina interna,
gastroenterologia, ecc..Allo stesso tempo quando le strutture sanitarie
richiedono un servizio di telerefertazione per un loro paziente, devono
specificare il tipo di specializzazione che dovranno avere i medici per poter
rispondere alla richiesta. Questo tipo di approccio comporta naturalmente
dei vantaggi e degli svantaggi. Tra i vantaggi si possono elencare il fatto di
avere delle diagnosi per i casi proposti più precise ed esatte ed in tempi più
brevi. Inoltre si ottimizza la produttività del personale medico che infatti
sarà chiamato a rispondere solo a casi che concernono le proprie specifiche
attitudini. Dall’altra parte lo svantaggio principale, cioè la necessità da parte
dei richiedenti di avere delle competenze mediche basilari per poter
individuare almeno in linea di massima a quale categoria clinica appartenga
un problema di un paziente, può essere facilmente superato inserendo la
possibilità di cambiare nel tempo la categoria scelta per il caso clinico.
L’inserimento di una nuova richiesta di consulto è effettuata compilando un
apposito modulo, disponibile all’interno della cartella clinica del paziente
per il quale si richiedono i servizi. Il modulo richiede di specificare i
parametri biologici e fisiologici del paziente al momento della richiesta,
come ad esempio pressione, ritmo cardiaco, peso ed altezza. A questo punto
si da la possibilità di allegare dei files alla richiesta. Questa possibilità è un
punto di notevole importanza per tutta la struttura del Medical
- 16 -
Telereporting System, perché in questo modo il software non solo funge da
infrastruttura per mettere in contatto medici e richiedenti, ma allo stesso
tempo diventa anche una piattaforma di storage remota per dati medici. Ciò
apre a molte possibilità e problematiche che saranno trattate in maniera più
esaustiva nei prossimi capitoli (cfr. Dati biomedici e Conclusioni). Nei
paragrafi seguenti di questo capitolo saranno comunque trattate le
tecnologie utilizzate per mettere l’upload/download dei files.
I files allegati alle richieste sono essenzialmente dati in formato non testuale
di interesse per la richiesta stessa, come ad esempio tracciati ECG,
ecografie, radiografie, ecc..
Una volta effettuata la richiesta di un consulto, questa viene inserita nel
database centrale ed è disponibile per essere visionata da parte di tutto il
personale medico che, come detto in precedenza, abbia una specializzazione
adeguata alla richiesta effettuata. E’ qui che si vede il vero punto di forza di
Medtel rispetto agli altri software già presenti sul mercato, ed è qui che si
esplicita l’innovativa idea di comunità di cui finora molto si è discusso.
Tutta la comunità medica con una particolare specializzazione può dare il
suo giudizio sui problemi proposti dai richiedenti. In questo modo i
richiedenti possono ottenere molte più opinioni su un particolare problema
rispetto quelle che avrebbero rivolgendosi solamente ad un medico come
avviene nel mondo reale. Le tecnologie informatiche vengono sfruttate fino
in fondo per permettere a molti medici sparsi nel globo di studiare il
medesimo caso e di fornire diversi punti di vista che insieme permettano al
richiedente di avere un consulto completo ed articolato. Inoltre Medtel
mette in comunicazione tra di loro i medici stessi che possono quindi
confrontarsi tra di loro producendo così dei risultati migliori di quelli che si
avrebbero nel caso tradizionale di rapporto uno ad uno tra medico e
paziente.
- 17 -
Modulo per la richiesta di un consulto
(Screenshot tratto da Medtel)
Anche i medici chiamati a dare il loro giudizio su un caso clinico possono
visualizzare la cartella “virtuale” del paziente nella sua interezza allo stesso
modo di come questa è disponibile per i richiedenti.
Una volta inserita la richiesta di un consulto da parte di una struttura
sanitaria, il richiedente detiene comunque il controllo sulla richiesta stessa.
Infatti se il problema è stato risolto o il richiedente si ritiene soddisfatto dei
dati raccolti, può chiudere la richiesta in modo che non sia più disponibile
per ulteriori commenti da parte di altri specialisti. I dati storici rimarranno
salvati nella cartella clinica del paziente, a disposizione per futuri consulti.
I richiedenti possono avere un rapido riassunto dello stato dello loro
richieste attraverso un’intuitiva interfaccia. Un’interfaccia molto simile
permette anche ai medici di visualizzare lo stato dei casi clinici di cui si
stanno occupando o di quelli più recenti che sono stati inseriti nel database.
- 18 -
Vista dello stato dei consulti clinici richiesti
(Screenshot tratto da Medtel)
Schema completo della logica di funzionamento di Medtel
- 19 -
2.3 Tecnologie utilizzate
Le tecnologie utilizzate per lo sviluppo di un software, soprattutto se si
tratta di un software complesso e molto articolato, in genere riflettono le
idee che stanno alla base dell’applicativo stesso. Medtel non fa accezione.
Fin dall’inizio si è cercato di valutare con precisione quelli che erano i
requisiti del programma e quindi di fare una scelta equilibrata delle
tecnologie attraverso le quali implementarli. In questa scelta hanno pesato
molto il fatto che Medtel dovesse risultare il più intuitivo possibile
nell’utilizzo e contemporaneamente funzionare su insieme di macchine
molto eterogeneo, sia da un punto di vista di potenza di calcolo che di
ambiente di lavoro. L’attenzione si è quindi rivolta verso gli standard che,
almeno sulla carta, fossero in grado di far fronte a queste problematiche.
Il software più onnipresente e diffuso nei computer di tutto il mondo è
sicuramente il browser Web. Al giorno d’oggi esistono moltissimi tipi di
browser sul mercato, ma tutti sono sostanzialmente caratterizzati da
un’interfaccia abbastanza omogenea a cui la maggior parte delle persone è
abituata. A partire da questa constatazione si è pensato che il modo migliore
per rendere Medtel disponibile ed utilizzabile dalla maggior parte delle
persone, fosse quello di svilupparlo sotto forma di Web Application fruibile
attraverso uno dei tanti browser presenti sul mercato.
Le Web Application sono una novità nel mondo del software, sia da un
punto di vista tecnologico che concettuale, ed attualmente stanno prendendo
sempre più piede nell’informatica moderna. Definire cosa s’intenda per
Web Application non è semplice perché esse presentano molto sfaccettature
e caratteristiche eterogenee, ma comunque si può tentare di riassumere il
tutto guardando al nome stesso: Web Application, cioè applicazione per il
web. Le Web Application sono quindi un tentativo di portare le normali
applicazioni desktop in una dimensione nuova: il web. Questo sforzo
- 20 -
presenta innumerevoli vantaggi e contemporaneamente molte nuove sfide
tecnologiche. Il vantaggio principale, nonché il vero punto di forza delle
Web Application, sta nel fatto che esse necessitano solo di un normale
browser web per poter funzionare (anzi si dice che le Web Application
“girano” all’interno di un browser) e quindi non sono legate a nessun
sistema operativo particolare, rendendo di conseguenza, praticamente nulli i
costi ed i tempi necessari per farle funzionari su O.S. diversi: si tratta
solamente di verificare che per il sistema operativo in esame esista un
browser capace di far girare la nostra Web Application. Altri vantaggi sono
legati all’usabilità. Le Web Application funzionando tramite la normale
interfaccia di un browser, presentano tutte quelle caratteristiche a cui il web
ha abituato le persone, cioè nessuna necessità di installazione,
raggiungibilità 24 su 24, nessuna manutenzione da parte degli utenti,
necessità di un hardware limitato perché il grosso dei calcoli vengono
effettuati alla fonte, lato server, così come la memorizzazione dei files,
minori rischi di perdita dei dati ed infine nessun bisogno da parte degli
utenti di dover aggiornare il software.
Se però le Web Application presentano tutte queste note positive per i loro
utilizzatori, il rovescio della medaglia è rappresentato dai notevoli sforzi
che gli sviluppatori devono fare per realizzarle nel migliore dei modi. Le
Web Application non sono e non vogliono essere semplicemente qualcosa
di più evoluto dei siti web tradizionali, ma invece nascono per essere delle
vere e proprie applicazioni. Tuttavia, il fatto di girare su dei browser,
obbliga gli sviluppatori a confrontarsi con le tecnologie supportate da
quest’ultimi, che in ultima analisi sono state sviluppate proprio per creare
siti internet. Il cuore della questione è quindi in che modo realizzare
applicazioni web che offrano un’esperienza il più possibile simile a quella
dei normali software, utilizzando contemporaneamente tecnologie non
sviluppate per questo scopo. Negli ultimi anni le organizzazioni, i consorzi
- 21 -
e le stesse aziende operanti nel mondo dell’informatica hanno cercato di
coniugare i loro sforzi per risolvere la questione. Le risposte sono state
diverse, tuttavia riassumibili in due categorie principali: l’introduzione di
nuove tecnologie oppure il potenziamento di tecnologie già esistenti. Gli
standard come Adobe Flash, Adobe Air o Microsoft SilverLight rientrano
nella prima categoria. Il potenziamento delle tecnologie di scripting come
Javascript, CSS e Ajax rientrano nella seconda. Nella fase iniziale di
progettazione di Medtel ci si è ritrovati al centro del dibattito che vede
contrapposti questi due diversi approcci e ci si è orientati sulla seconda
soluzione. I motivi di questa scelta di campo così drastica sono da ricercare
nell’osservazione che tecnologie “più vecchie” come il Javascript, CSS e
Ajax, specialmente alla luce delle ultime rivisitazioni, rappresentano una
piattaforma più solida sulla quale sviluppare. Adobe Flash e soprattutto
Microsoft SilverLight presentano sicuramente delle potenzialità maggiori
nel lungo periodo, ma proprio perché così innovativi non rispondono ai
requisiti di stretta compatibilità con hardware e software esistenti che
Medtel si prefigge.
Medtel affonda quindi le proprie radici in tecnologie consolidate quali
Javascript, CSS ed Ajax. Per poter sfruttare fino in fondo il potenziale degli
standard adottati si sono utilizzate delle librerie di codice già esistenti sul
mercato, totalmente gratuite ed open source, cioè il Google Web Toolkit e
la sua estensione GWT-Ext.
Trattandosi di una Web Application, Medtel è naturalmente anche un
software costruito su un’architettura client/server. Di conseguenza esso è
costituito da due parti principali: un’interfaccia grafica client che gira su un
browser web e costruita tramite le tecnologie sopracitate, collegata poi ad
una parte server, che completa il tutto fornendo i servizi di calcolo e di
storage remoto. La parte server è stata sviluppata utilizzando il linguaggio
Java, che inoltre è lo stesso linguaggio sfruttato da GWT e GWT-Ext. In
- 22 -
definitiva quindi Medtel è stato programmato essenzialmente in Java, anche
se l’applicativo finale è il risultato di un connubio che vede uniti tra di loro
Java, HTML, Javascript e CSS. Il perché di tutto questo è spiegato nei
paragrafi successivi in cui si specifica nel dettaglio i vari aspetti delle
tecnologie utilizzate.
Schema completo delle tecnologie utilizzate in Medtel. Si noti la suddivisione
tra la parte client e server del software stesso
2.3.1 Java
Si è già sottolineato come in definitiva Java sia il linguaggio che sta alla
base dello sviluppo di Medtel. In particolare si è visto che sia la parte client
che la parte server sono state scritte in Java, anche se grazie alle tecnologie
utilizzate, cioè Google Web Toolkit, la parte client viene per così dire
tradotta dal linguaggio Java nei linguaggi HTML, Javascript e CSS. Questo
è un punto focale di Medtel perché è proprio questa “trasformazione” da
Java verso gli altri linguaggi che permette all’interfaccia utente del
programma di poter funzionare all’interno di una finestra del browser web.
Nei prossimi paragrafi vengono specificati i motivi che hanno portato a
- 23 -
preferire Java ad altri linguaggi e vengono inoltre illustrate le tecnologie
che permettono di sposare il Java con il web, in particolare verrà trattato lo
standard Java Servlet. In questo paragrafo si vuole invece fornire una breve
panoramica sul linguaggio Java di per se stesso: quali sono le sue
caratteristiche salienti, i suoi punti di forza e di debolezza, con un occhio
infine al suo stato attuale di sviluppo e di supporto da parte delle comunità
mondiale di informatici.
Il linguaggio Java è un linguaggio di programmazione orientato agli oggetti,
derivato dal C++
e creato da James Gosling e altri ingegneri di Sun
Microsystems. Java fu annunciato ufficialmente il 23 maggio 1995 a
SunWorld. La piattaforma di programmazione Java è fondata sul linguaggio
stesso, sulla Java Virtual Machine (JVM) e sulle API.
Java è stato creato per soddisfare tre scopi: essere orientato agli oggetti,
essere indipendente dalla piattaforma e contenere strumenti e librerie per il
networking. La prima caratteristica, si riferisce a un moderno metodo di
programmazione e progettazione, la programmazione orientata agli oggetti
(OOP).
L'idea alla base della OOP è di rappresentare, nella progettazione del
software, le entità reali o astratte che compongono il problema sotto forma
di oggetti. Gli oggetti sono caratterizzati da delle proprietà (definite
variabili o campi di istanza o di esemplare) e di metodi applicabili sugli
oggetti stessi, che possono ad esempio modificarne lo stato o estrarne
informazioni.
Sebbene Java possa operare sia su oggetti che su tipi di dati primitivi, è
considerato un linguaggio ad oggetti puro, ovvero nel quale gli oggetti sono
le entità di base del linguaggio, anziché essere costruiti partendo da costrutti
ad un inferiore livello di astrazione.
La seconda caratteristica, l'indipendenza dalla piattaforma, significa che
l'esecuzione di programmi scritti in Java deve avere un comportamento
- 24 -
simile su hardware diverso. Si dovrebbe essere in grado di scrivere il
programma una volta e poterlo eseguire dovunque. Questo è fattibile con la
compilazione del codice di Java in un linguaggio intermedio, bytecode,
basato su istruzioni semplificate che ricalcano il linguaggio macchina. Il
bytecode verrà quindi eseguito da una macchina virtuale (JVM), ovvero un
software sviluppato dalla Sun Microsystem per un gran numero di ambienti
diversi. Inoltre, vengono fornite librerie standardizzate per permettere
l'accesso alle caratteristiche della macchina (come grafica e networking) in
modo unificato.
Java è un linguaggio meno efficiente dei linguaggi compilati come il C++,
scontando il fatto di possedere degli strati di astrazione in più, e di
implementare una serie di automatismi, come il garbage collector, che se da
un lato fanno risparmiare tempo ed errori in fase di sviluppo dei programmi,
dall'altro consumano memoria e tempo di CPU in fase di esecuzione del
programma finito.
Fra gli argomenti che depongono spesso a favore di Java nella scelta del
linguaggio di implementazione di un progetto software moderno, si deve
certamente contare la vastità delle librerie standard di cui il linguaggio è
dotato, e che in particolare contribuiscono a renderlo altamente integrabile
con le altre tecnologie. Alcuni esempi di funzionalità di libreria di Java
sono: accesso ai database tramite JDBC e ai DBMS con driver ODBC,
potenti strumenti per la programmazione lato server nel contesto Web,
supporto nativo per gran parte dei protocolli della famiglia IP.
Per quanto riguarda il suo stato attuale di sviluppo e il suo livello di
popolarità, c’è solamente da notare che essendo arrivato alla versione 1.5, il
linguaggio Java è un linguaggio altamente maturo e consolidato. Inoltre la
sua popolarità è elevatissima. Java è sicuramente la tecnologia più diffusa
ed utilizzati in ambito commerciale e non, per sviluppare software di ogni
tipo. La sua alta flessibilità, il suo approccio moderno e i continui
- 25 -
aggiornamenti a cui è sottoposto, lo rendono un linguaggio adatto allo
sviluppo di praticamente qualunque tipo di software in qualunque tipo di
situazione. Come già sottolineato in precedenza, Java nasce con l’idea di
essere notevolmente portabile. L’approccio fondato sulla Java Virtual
Machine ed il bytecode lo rendono adatto alla creazione di applicativi che
verranno eseguiti su server mainframe, come anche su cellulari, ed
ultimamente su elettrodomestici ed orologi.
La versione di Java utilizzata per programmare Medtel è stata la 1.4 perché
la libreria Google Web Toolkit al momento dello sviluppo non supportava
ancora la versione più recente del linguaggio. Questo non ha portato a
nessun inconveniente.
2.3.1.1 Perché Java
Nel paragrafo precedente si è illustrato il linguaggio Java e come questo
venga utilizzato all’interno di Medtel. In questo paragrafo si cercheranno di
specificare i motivi che hanno portato alla scelta di Java.
I motivi possono essere riassunti in tre categoria principali: motivi di ordine
logistico, motivi di ordine tecnologico ed infine altri motivi di varia natura
non legati ai precedenti.
I motivi di tipo logistico sono quelli legati a precise richieste che sono
venute dal committente del progetto Medtel stesso, ovvero l’Azienda
Sanitaria Locale di Ancona. Finora non è mai stato messo in luce il fatto
che Medtel non è un progetto nato ex-novo di software per la telemedicina,
ma è invece l’ultima tappa di un percorso che ha visto la creazione di
diversi applicativi basati sugli stessi concetti di Medtel, via via migliorati
costantemente e creati con le tecnologie più disparate. A fronte degli scarsi
risultati avuti con le precedenti versione, si è deciso di cambiare la
tecnologia e di rivolgersi con decisione verso Java.
- 26 -
I motivi di ordine tecnologico nascono invece dalla constatazione che le
caratteristiche di Java, così come sono state illustrate nel paragrafo
precedente, si adattano perfettamente ad un applicativo quale Medtel. Da un
lato la programmazione ad oggetti permette di modellare agilmente le
situazioni che si presentano nello sviluppo di un software di telemedicina,
dall’altro l’estensivo supporto di Java alle tecnologie server per il Web,
l’hanno reso la scelta perfetta. Occorre poi citare il fatto che la
programmazione OOP è nata anche con lo scopo di poter agevolare il
compito di chi sviluppa un software a più mani. Medtel è il frutto del lavoro
di più persone che grazie alle scelta di Java e conseguentemente di OOP,
hanno potuto facilmente suddividere il progetto nelle componenti più
essenziali, poi affidate ad ogni singolo membro del gruppo di lavoro.
Altri motivi che rendono Java preferibile ad altri linguaggi OOP come il
C++, sono intanto la sua semantica molto semplice che permette di avere
una curva di apprendimento molto più rapida e la sua gestione fortemente
tipizzata dei dati che riduce notevolmente il quantitativo di errori che si
producono in fasi di sviluppo, accorciando così i tempi di debug. La
presenza di un gestore automatico della memoria, il garbage collector, non
fa altro che rendere ancora più facile la stesura di applicativi complessi in
tempo breve.
Esistono molte altre ragioni che hanno portato alla scelta di Java e la
maggior parte non sono né di natura tecnologica né di natura logistica, ma
semplicemente legate ai gusti ed alle preferenze del team di sviluppo di
Medtel. Non bisogna poi dimenticare il fatto che il linguaggio Java è anche
oggetto di trattazione durante i corsi di laurea triennale in ingegneria
informatica.
Infine a favore di Java giocano la presenza di potenti strumenti di sviluppo,
utilizzati anche per la creazione di Medtel, come l’ambiente Eclipse di cui
si parlerà brevemente nei paragrafi successivi.
- 27 -
Ci si potrebbe domandare se la scelta di utilizzare il Google Web Toolkit
sia nata conseguentemente all’utilizzo di Java o se invece GWT sia tra
annoverare tra i perché di Java. In realtà si è partiti fin da subito con l’idea
di utilizzare Java, mentre il Google Web Toolkit è un’idea apparsa
successivamente come naturale complemento alla scelta.
2.3.1.2 Java Servlet: Tomcat
Java offre un supporto esteso al Web attraverso diversi standard e metodi
diffusi soprattutto in ambito enterprise.
La parte server come detto in precedenza è stata tutta sviluppata in Java e
senza ulteriori traduzioni verso altri linguaggi cosa che invece avviene per
la parte client. In particolare si è scelto di utilizzare la tecnologia Java
Servlet.
Java Servlet permette agli sviluppatori di aggiungere contenuto dinamico
alle loro pagine web usando la piattaforma Java. Per contenuto dinamico
s’intende tutta una seria di dati ed informazioni che vengono generate in
tempo reale al momento della richiesta da parte di un client e che non sono
già memorizzate in una forma adatta all’invio immediato. Esempi di
contenuto dinamico sono i risultati dell’interrogazioni di un database
oppure le informazioni contenuti nei cookies del browser. Attraverso Java
Servlet si possono creare dei mini-applicativi (cioè delle classi compilate in
bytecode) che possono essere raggiunti ed interrogati come normali pagine
web e che fornisco appunto questo tipo di informazioni dinamiche.
Medtel fa ampio uso delle Java Servlet per gestire tutto il lato server
dell’applicazione. Si è visto in precedenza infatti che tutti i dati (cartelle
cliniche dei pazienti, dati di login) sono contenuti in un database centrale e
quindi possono essere estrapolati solamente utilizzando uno standard quale
Java Servlet.
- 28 -
Per poter utilizzare la tecnologia Servlet è necessario dotarsi di un ambiente
adatto a supportala, cioè un web application server. I web application
server si discostano profondamente dai tradizionale server web quali
Apache, perché nascono per scopi diversi rispetto a quest’ultimi. I server
web tradizionali sono stati sviluppati in un’epoca in cui ancora il contenuto
delle pagine era sostanzialmente statico e non dinamico (nell’eccezione
spiegata in precedenza) e quindi la loro funzione è essenzialmente quello di
spedire ad un client che fa richiesta una pagine web memorizzata da
qualche parte nel server attraverso il protocollo HTTP. In un’epoca di
contenuti dinamici, questo modello tradizionale di server web ha dovuto
essere rivisto: tecnologie quali Java Servlet non prevedono il semplice invio
di una pagine web, ma addirittura la creazione in tempo reale della pagine e
quindi l’esecuzione di veri e propri programmi, che hanno come risultato la
produzione di informazioni, spedite poi al client in vari modi, tra i quali
anche quello banale, di pagine web (si vedrà che essendo Medtel una vera e
propria applicazione, non gestisce il flusso di dati in questo modo). Accanto
ai tradizionali server web quindi si sono affacciati i moderni web
application server che sono in grado di gestire un’architettura di questo tipo.
In Medtel si è scelto di affidarsi ad uno dei più diffusi ed apprezzati, nonché
open source, cioè Apache Tomcat.
Apache Tomcat offre un ambiente di esecuzione lato server per le Java
Servlet e contemporaneamente tutta l’infrastruttura necessaria a mettere in
collegamento il server con il client attraverso il protocollo HTTP. Allo
stesso tempo Apache Tomcat racchiude al proprio interno anche un
tradizionale server web.
Alla luce di tutto questo si può affermare che l’accoppiata Apache Tomcat e
MySQL DB, che verrà trattato nei prossimi paragrafi, rappresentano
completamente l’ambiente di esecuzione necessario per il funzionamento di
Medtel.
- 29 -
2.3.2 Google Web Toolkit
Google Web Toolkit è una libreria open source sviluppata da Google per
agevolare la costruzione di applicazioni web complesse, quali ad esempio lo
stesso Medtel. Google Web Toolkit (d’ora in avanti semplicemente GWT) è
allo stesso tempo un toolkit grafico, un compilatore Javascript ed un
framework di sviluppo. Di seguito verranno definiti questi concetti nel
dettaglio.
GWT è un toolkit grafico, cioè una libreria di codice che mette a
disposizione dei componenti (chiamati widgets) per permettere la
costruzione di interfacce grafiche. Sotto questo punto di vista GWT può
essere visto come un analogo della libreria SWT, che fa parte delle API
Standard di Java, ma mentre SWT nasce con lo scopo di consentire lo
sviluppo delle normali applicazioni desktop, GWT serve, come già messo
in luce in precedenza, per scrivere software che sarà eseguito in una finestra
di un browser. Tutta l’interfaccia grafica di Medtel è costruita attraverso i
componenti del toolkit grafico di GWT. Esempi di questi componenti sono
toolbar, menu a tendina, message box, pulsanti e campi di testo. La
programmazione di GUI attraverso GWT è di tipo event-driven, in perfetta
analogia con quello che avviene nelle applicazioni desktop. Questo
significa che si possono definire eventi associati ai vari componenti della
GUI, quali ad esempio il click di un bottone o la modifica di un campo di
testo, che andranno poi ad attivare specifiche porzioni di codice.
GWT è anche un compilatore Javascript. Questo è un punto molto
importante su cui vale la pena fermarsi a riflettere. Tutto il codice che
sfrutta GWT è scritto in Java. Se GWT si limitasse a fornire degli strumenti
per costruire delle interfaccia grafiche in Java, la sua funzione sarebbe
molto limita e comunque, per quanto potente e versatile, non sarebbe affatto
diverso dalle altre decine di librerie nate per lo stesso scopo che si trovano
- 30 -
al giorno d’oggi in commercio. Quello che differenzia GWT dagli altri
toolkit grafici è appunto il compilatore. Tutto il codice Java che sfrutta le
primitive messe a disposizione da GWT, viene poi tradotto attraverso il tool
presente nel SDK in codice HTML, Javascript e CSS. Le pagine prodotte in
uscita sono quindi pronte per poter essere lette tramite un browser web. Qui
sta tutta la potenza e l’innovazione di GWT rispetto ai competitors già
presenti sul mercato. Prima dell’introduzione di questa libreria la prassi per
la creazione delle web application era questa:
si scriveva la GUI del client direttamente in HTML, Javascript e CSS, al più
avvalendosi di strumenti visuali e di librerie di codice già pronto
si scrivano le classi Java Servlet per svolgere i compiti di manipolazione ed
estrazione di informazioni dinamiche lato server
si scrivevano dei metodi che permettessero alla parte client di comunicare
con la parte server. In particolare quest’ultima fase prevedeva spesso di
dover mischiare pezzi di codice stesi in linguaggi diversi con conseguenti
problemi di leggibilità e di debugging.
GWT rivoluzione completamente questa situazione fornendo la possibilità
di utilizzare un unico linguaggio di programmazione durante tutte le fasi di
sviluppo di un prodotto. In questo modo i programmatori non devono più
abbandonare Java al momento di creare la GUI, ma possono continuare ad
utilizzarlo in tutti gli aspetti del loro software, sia che stia scrivendo la parte
server che la parte client del programma. Penserà poi il compilatore GWT a
fare in modo che la GUI scritta in Java venga tradotta in una serie di formati
adatti ad essere interpretati da un browser, quali sono in effetti CSS, HTML
e Javascript. Dovrebbe apparire chiaro fin da queste poche righe
introduttive quali siano le potenzialità insite in una tecnologia come GWT
ed i perché la scelta di utilizzarlo sia succeduta subito alla decisione di
utilizzare Java. Attraverso GWT scompare definitivamente la separazione
- 31 -
tra i metodi di creazione di una Web Application e di una normale
applicazione desktop.
GWT è infine un completo framework per lo sviluppo di applicazioni.
Accanto al compilatore Javascript e al toolkit grafico, GWT mette anche a
disposizione dei metodi che permettono al programmatore di far dialogare
la parte client, costituita dalla GUI, con la parte server, costituita dalle Java
Servlet, in maniera totalmente trasparente, facendo quasi scomparire la
distinzione tra le due parti dell’applicazione. Le Web Application scritte in
GWT non hanno nulla in comune con i normali siti internet, nemmeno la
tradizionale suddivisione in pagine.
Dovendosi
comportare
come
tradizionali software desktop, non avrebbe avuto alcun senso avere una
divisione in pagine delle Web Application! Per questo tutto il codice della
GUI viene eseguito a partire da un’unica pagina, i widgets vengono
aggiunti e rimossi in tempo reale, senza che l’utente debba sottostare alle
fastidiose attese dovute al caricamento delle pagine.
(Fonte: sito ufficiale del Google Web Toolkit. Vedi sitografia)
- 32 -
2.3.2.1 Funzionamento del GWT
Schema completo del funzionamento di Google Web Toolkit in abbinamento
con una base di dati e delle Java Servlet
L’immagine qui sopra mostra in maniera schematica, ma precisa, in che
modo funzioni un’applicazione web scritta sfruttando la libreria GWT. Si
notano subito tutti gli elementi di cui si è parlato finora: la parte client, la
parte server, il web application server Apache Tomcat, il browser degli
utenti ed il database dei dati. Attraverso questo schema si possono capire
bene quelli che sono i collegamenti vigenti tra le diversi parti
dell’applicazione tra cui in particolare quelli tra la parte client e la parte
server.
All’estrema sinistra dell’illustrazione abbiamo il codice Java della parte
server (più in alto) ed il codice Java che gestisce la GUI (più in basso).
Quest’ultimo come già detto in precedenza è sviluppato a partire dalla API
di GWT. Lato server invece si vede che la tecnologia utilizzata è
naturalmente Java Servlet. Si nota poi che l’interazione tra l’applicazione e
- 33 -
la base di dati (all’estremo in alto a sinistra) avviene, come ci si aspettava,
attraverso le Java Servlet. Uno volta scritte in Java, le servlet si comportano
come normali applicazioni, quindi vengono compilate in bytecode e poi
devono essere eseguite attraverso una Java Virtual Machine. Tutto il
processo è illustrato muovendosi verso destra a partire dal codice Java lato
server fino ad arrivare ad Apache Tomcat, che in questo contesto funge
anche da JVM.
Il codice Java della GUI invece viene dato in pasto al compilatore GWT che
produce in uscita del codice Javascript, HTML e CSS. Questo poi viene di
nuovo passato ad Apache Tomcat perché, come sottolineato nei paragrafi
precedenti,
esso è in grado di comportarsi anche alla stregua di un
tradizionale server web per la distribuzione di contenuti statici.
All’estrema destra del processo troviamo i browser degli utilizzatori finali
che fruiscono dell’applicazione web.
Quello che è interessante notare è come avvenga l’interazione tra il codice
lato client ed il codice lato server. In fase di progettazione della GUI in
Java, GWT mette a disposizione dei metodi che permettono di richiamare
delle funzionalità remote fornite dal codice server-side. Questi metodi
sfruttano una tecnica chiamata RPC, cioè Remote Procedure Call e molte
delle proprietà del linguaggio Java.
In particolare quando si vogliono
attivare alcuni procedure lato server del nostro applicativo, ad esempio per
accedere ad un database, è necessario seguire una serie di passaggi per
rendere questa comunicazione possibile attraverso il GWT. Prima di tutto
bisogna creare un’interfaccia Java che elenchi i metodi che sono messi a
disposizione da una particolare servlet remota. Quest’interfaccia farà parte
del codice lato client e non conterrà le istruzioni necessarie ad eseguire
l’operazione richiesta, ma specificherà solamente il nome della procedura
lato server che esegue il compito vero e proprio ed i parametri necessari a
questa per poterlo eseguire. L’interfaccia è quindi il ponte esistente tra la
- 34 -
parte del client e quella del server ed espone i metodi di quest’ultima alla
prima. Il passo successivo è quello di creare, durante la stesura della GUI,
un oggetto a partire dall’interfaccia definita al passo precedente.
Quest’oggetto avrà i metodi propri dell’interfaccia e quindi in definitiva
della servlet remota. Richiamando i metodi dell’oggetto nel codice clientside si attivano procedure remote server-side. Tutto questo sarebbe vero
solamente se tutto il codice, sia server che client, non venisse tradotto e
rimanesse in Java. In realtà come è stato ribadito più volte, il codice client è
poi tradotto dal compilatore Javascript. Ci si può domandare a questo punto
che fine faccia il paradigma RPC e come avvenga quindi la comunicazione
tra client e server. La risposta è fornita dal compilatore GWT stesso e dalla
tecnologia Ajax.
Ajax, acronimo di Asynchronous JavaScript and XML, è una tecnica di
sviluppo web per creare applicazioni web interattive. L'intento di tale
tecnica è quello di ottenere pagine web che rispondono in maniera più
rapida, grazie allo scambio in background di piccoli pacchetti di dati con il
server, così che l'intera pagina web non debba essere ricaricata ogni volta
che l'utente effettua una modifica. Questa tecnica riesce, quindi, a
migliorare l'interattività, la velocità e l'usabilità di una pagina web.
Ajax è asincrono nel senso che i dati extra sono richiesti al server e caricati
in background senza interferire con il comportamento della pagina
esistente.
Le chiamate a procedure remote scritte in Java in fase di sviluppo della
GUI, vengono poi convertire in chiamate Ajax, e quindi in codice
Javascript, dal compilatore GWT. In questo modo si può realizzare un
intenso scambio di dati tra client e server senza compromettere le
prestazioni dell’applicativo e senza dover mai ricaricare le pagine nel
browser per aggiornarne il contenuto. Tutto il processo avviene in
- 35 -
background, come del resto avverrebbe se si stesse utilizzando un normale
programma desktop.
Lo schema seguente mostra in dettaglio la tecnica di comunicazione
client/server prevista dal GWT.
Schema di come funziona l’attivazione di una procedura remota utilizzando i metodi
messi a disposizione dal Google Web Toolkit
(Fonte: sito ufficiale del Google Web Toolkit. Vedi sitografia)
Il codice qui di seguito invece mostra come si possano implementare
effettivamente le tecniche viste finora. Creiamo una Java Servlet che ha un
solo metodo (myMethod). Il metodo accetta una parametro stringa in
ingresso e non fa altro che restituirlo in uscita.
- 36 -
package com.example.foo.server;
import
com.google.gwt.user.server.rpc.RemoteServiceServlet;
import com.example.client.MyService;
public class MyServiceImpl extends RemoteServiceServlet
implements
MyService {
public String myMethod(String s) {
return s;
}
}
Il codice dell’interfaccia di comunicazione tra client e server è il seguente:
package com.example.foo.client;
interface MyServiceAsync {
public void myMethod(String s, AsyncCallback<String>
callback);
}
Il codice che effettua la chiamata vera e propria a partire dall’interfaccia è il
seguente:
MyServiceAsync methodService = (MyServiceAsync)
GWT.create(MyEmailService.class);
AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Void result) {
// fai qualcosa con result
}
public void onFailure(Throwable caught) {
// si è verificato un errore
}
};
methodService.MyMethod(new String(‘ciao’), callback);
- 37 -
Prima di concludere la trattazione sui principi di funzionamento di GWT,
non rimane altro che dire in che formato vengano scambiati i dati tra le
procedure client e quelle server. GWT permette di trasferire dati sotto
forma di oggetti Java. Affinché questo sia possibile però è necessario che
gli oggetti siano serializzabili, cioè trasformabili in un formato adatto ad
essere trasferito via HTTP. Praticamente tutti gli oggetti standard forniti
dalla libreria di Java sono serializzabili, compresi quindi gli oggetti String e
compresi inoltri dati che in realtà oggetti non sono, come gli interi. Un
programmatore può comunque decidere di trasferire anche altri tipi di
oggetti non standard, magari creati ex-novo per l’applicazione che sta
scrivendo. Anche questi ultimi sono supportati da GWT, l’importante è che
la classe che li definisce implementi l’interfaccia isSerializable.
2.3.2.2 GWT-Ext
GWT-Ext è una libreria open source nata per aggiungere nuove funzionalità
a quelle già presenti nella collezione standard di Google Web Toolkit.
GWT-Ext fornisce moltissimi nuovi widgets da utilizzare per costruire le
proprie web application, nonché molte altre interessanti novità non legate
alla costruzione di interfacce grafiche, come per esempio metodi per la
manipolazione di stringhe e date. Nello sviluppo di Medtel si è fatto ampio
uso degli strumenti messi a disposizione da GWT-Ext in particolare per
quello che riguarda la programmazione della GUI.
2.3.2.3 Altri vantaggi nell’uso del Google Web Toolkit
Oltre ai vantaggi già citati di cui si è potuto beneficiare grazie all’adozione
del Google Web Toolkit, vale la pena sottolineare altre interessanti note
positive sempre legate al GWT.
- 38 -
Il compilatore è estremamente efficiente tanto che il motto di GWT,
riportato nella documentazione ufficiale, è “Faster AJAX than you'd write
by hand”, proprio a sottolineare il fatto di come il codice Javascript
prodotto dal compilatore a partire dal codice Java sia molto più performante
di quello che si sarebbe potuto scrivere a mano. Tutto questo grazie al gran
numero di ottimizzazione automatiche, spesso anche frutto di un’analisi
molto complessa, che vengono apportate al codice e che non sono alla
portate del tradizionale programmatore, specialmente in progetti molto
complessi.
Un altro vantaggio risiede nella compatibilità delle web application scritte
con il Google Web Toolkit, con una vasta gamma di browser web. Nella
documentazione ufficiale viene in particolare specificato che il codice
Javascript prodotto dal compilatore è compatibile con i seguenti browsers:
Internet Explorer 6+, Firefox 2+, Safari ed Opera. Quindi si vede come si
riesca a raggiungere praticamente tutte le quote del mercato dei web
browsers. Nelle conclusione comunque verrà trattato in maniera più
approfondita il tema della compatibilità, portando anche alcuni esempi di
situazioni in cui ciò che viene specificato “su carta”, in realtà non trova
riscontro nei fatti.
L’ultimo vantaggio che è importante mettere in risalto è legato
all’integrazione di Google Web Toolkit con l’ambiente di sviluppo Java più
diffuso al mondo: Eclipse (di cui si parlerà brevemente nei prossimi
paragrafi). Ciò permette di sfruttare tutti gli strumenti messi a disposizione
da quest’ultimo per il debugging del codice. Inoltre l’alto livello di
integrazione ha permesso di testare, compilare ed eseguire tutto il codice,
utilizzando unicamente l’ambiente Eclipse.
- 39 -
2.3.3 MySQL
MySQL è un database management system (DBMS) relazionale, ovvero
un sistema
software progettato
per
consentire
la
creazione
e
la
manipolazione efficiente di database (cioè collezioni di dati strutturati),
solitamente da parte di più utenti. In tutte le applicazioni in cui si fa largo
uso di grandi quantità di dati, come Medtel ad esempio, l’utilizzo di un
DBMS è un fattore imprescindibile per il corretto funzionamento
dell’applicazione stessa. Nella progettazione di Medtel si è scelto di
utilizzare il DBMS MySQL DB per motivi di natura sia tecnica che
commerciale. Per quanto riguarda le ragioni tecniche occorre notare che
MySQL è un prodotto altamente maturo ed utilizzato da una vasta comunità
di sviluppatori. Inoltre supporta tutte le più recenti tecnologie per la
gestione dei dati (InnoDB, transizione atomiche, ecc…) ed allo stesso
tempo è un software estremamente robusto e scalabile, adatto all’utilizzo in
ambienti mission critical in cui si richiede di dover gestire grandi quantità
di dati con sicurezza.
Per quanto riguarda le ragione commerciale c’è solamente da sottolineare il
fatto che MySQL DB è totalmente gratuito ed open source essendo
rilasciato con licenza GPL.
2.3.4 Altre librerie e strumenti utilizzati
Nello sviluppo di Medtel sono stati utilizzati moltissimi altri strumenti che
finora non sono mai stati messi in luce. Il più importante di questi è
sicuramente Eclipse. Eclipse è un completo ambiente di sviluppo per Java
originariamente creato dalla IBM e poi rilasciato come software open
source alla comunità mondiale. E’ totalmente gratuito, ma allo stesso tempo
estremamente potente e versatile. Non a caso è l’ambiente Java più
- 40 -
utilizzato al mondo. Senza le tante funzionalità di Eclipse, lo sviluppo di
Medtel sarebbe sicuramente risultato molto più difficoltoso.
Il Google Web Toolkit Hosted Mode è un comodo tool fornito dal SDK di
GWT che permette di testare le proprie applicazioni in un browser senza
doverle ogni volta compilare, producendo così un notevole risparmio di
tempo.
phpMyAdmin è invece un completo software per la gestione dei database
creati con MySQL DB, totalmente gratuito ed open source.
La libreria Apache Commons File Upload permette infine, una facile
gestione dell’upload dei files verso i server di storage di Medtel tramite il
protocollo HTTP.
- 41 -
CAPITOLO 3
Sezione Amministrativa
3.1 Introduzione
Nel capitolo due si è illustrato il funzionamento del Medical Telereporting
System e si sono descritte le tecnologie adottate in sede di sviluppo. In
questo capitolo si vuole invece parlare nel dettaglio della realizzazione di
una particolare sezione di Medtel: la sezione amministrativa. Come si è
visto in precedenza, Medtel è un software estremamente complesso e
composto da moltissimi componenti, è chiaro quindi che una descrizione
accurata di ogni sua singola parte è un compito che va oltre gli scopi di
questo testo. Si è preferito di conseguenza concentrarsi solamente sulla
parte che ha visto il coinvolgimento diretto dell’autore, che è appunto la
sezione amministrativa.
Quella amministrativa è sicuramente una delle sezioni più importanti e
complesse di tutto l’applicativo, sia per i compiti che svolge, sia per le
problematiche di sicurezza che inevitabilmente affliggono la componente
chiamata a gestire le autorizzazioni degli utenti. Nei paragrafi seguenti
verrà presentata la sezione amministrativa prima a grandi linee, poi via via
più nel dettaglio. Per concludere il capitolo verranno anche proposte alcune
riflessioni sui problemi riscontrati in fase di sviluppo.
Nel capitolo sono presentati molti spezzoni di codice Java che stanno alla
base di Medtel. Tutto il codice elencato qui di seguito è commentato in
modo che anche i passaggi più complessi risultino chiari al lettore. Si tenga
conto comunque, che il codice complessivo di Medtel è molto più vasto di
quello mostrato in queste pagine.
- 42 -
3.2 Manager & Super-Admin
Prima di descrivere nel dettaglio le caratteristiche dell’area amministrativa è
sicuramente importante sottolineare quali siano gli utenti che possono
accedere ad essa ed utilizzarne le funzionalità.
Si sottolinea fin da subito quindi, che solamente gli amministratori di
Medtel possono accedere a questa sezione dell’applicativo. In questa
sezione infatti, è possibile procedere alla creazione di nuovi utenti (di varia
natura), nonché alla eliminazioni di essi. Si tratta di operazioni che possono
con estrema facilità portare alla compromissione del servizio e di
conseguenza dovrebbero apparire chiari i motivi che hanno portato alla
scelta di restrizioni d’accesso di questo tipo.
Come già accennato in precedenza nel testo, gli amministratori non sono un
gruppo omogeneo, ma esiste invece, una divisione netta tra due tipi di
admin chiamati a gestire il funzionamento di Medtel. Nel corso della
trattazione quindi, si farà riferimento distintamente a super-admin e
manager, tenendo a mente però, che ambedue le categorie sono comunque
declinazione dell’insieme degli amministratori.
Quello che differenzia le due classi di amministratori appena presentate, è il
ruolo che esse rivestono all’interno della logica di Medtel. I super-admin e i
manager gestiscono diverse tipologie di utenti. I manager si occupano della
creazione ed eliminazione delle credenziali di accesso per i requester e per
il personale medico, mentre i super-admin debbono gestire l’accesso per gli
stessi manager. Si osserva quindi che nella scala gerarchica delle
responsabilità, i super-admin rappresentano il gradino più alto, i manager
quello subito successivo, ed infine a seguire si trovano sullo stesso livello i
medici ed i requester.
- 43 -
Gerarchia degli utenti di Medtel. Salendo verso l’alto le responsabilità aumentano,
scendendo verso il basso gli utenti aumentano
Restano da illustrare i motivi che hanno portato alla scelta in fase di
progettazione, di due figure diverse di amministratori. In realtà nelle prime
fasi di design dell’applicativo, la distinzione non era stata introdotta.
Successivamente si è evidenziato il fatto che una strutturazione di questo
tipo era eccessivamente rigida e poco scalabile in situazioni in cui il numero
di utenti registrati fosse aumentato esponenzialmente. In particolare con una
configurazione improntata su una sola figura di amministratore e molti
utilizzatori, il carico di lavoro per la prima poteva risultare eccessivo.
Mancava inoltre un elemento di collegamento tra i vari amministratori che
rimanevano troppo isolati tra di loro. Si è pensato quindi di aggiungere un
ulteriore gradino alla struttura gerarchica di Medtel affinché tutto risultasse
più dinamico ed adattabile a scenari complessi. Grazie all’introduzione dei
super-admin, si è potuto moltiplicare il numero dei manager chiamati quindi
a gestire un carico di lavoro minore, senza che la sicurezza generale di
Medtel venisse in alcun modo compromessa, perché i compiti di
supervisione più importanti sono comunque affidati ad numero esiguo di
- 44 -
utenti, non creabili tra l’altro tramite il software stesso, ma solamente
tramite un utility apposita e scollegata dal resto della web application.
Si può evincere da questa semplice descrizione l’importanza, sottolineata
più volte nel corso del testo, di un’attenta fase di progettazione e design,
imprescindibile per lo sviluppo di un software corretto ed esente da bug.
3.3 Funzionalità
L’area amministrativa nasce con lo scopo di permettere una facile gestione
degli utenti da parte degli amministratori del sito. In questo paragrafo
vengono descritte le funzionalità che la sezione di amministrazione mette a
disposizione.
Dopo che un amministratore ha effettuato il login in Medtel, sia esso un
super-admin o un manager, ha la possibilità di creare nuovi utenti, di
visualizzare l’elenco degli utenti già creati con le relative informazioni ed
infine di procedere con l’eliminazione di essi. Si fa notare fin da subito che
un amministratore può visualizzare ed eliminare solamente gli utenti da lui
stesso creati, per ovvie ragioni di sicurezza. Di seguito verranno descritte le
operazioni di creazione, eliminazione e visualizzare, in dettaglio.
Quando un amministratore decide di creare un nuovo utente, deve
compilare un apposito form affinché i dati sul nuovo utente, possano venir
memorizzati nel database principale. I dati che il super-admin o il manager
deve specificare sono essenzialmente di due tipi: dati anagrafici comuni a
tutti gli utenti, oppure informazioni specifiche di una particolare categoria
di utenti. I primi sono: nome, cognome, username, password, indirizzo email, città ed indirizzo di residenza, CAP della città di residenza, nazione,
numero di telefono, numero di fax e tipo di utente. I secondi invece variano
a seconda del tipo di utenti che si sta creando. Nel caso dei requester è
richiesto di specificare il nome della struttura sanitaria alla quale
- 45 -
afferiscono,
nel
caso
dei
dottori
invece
occorre
specificare
le
specializzazioni, infine nel caso di creazione di un nuovo manager non è
necessario fornire ulteriori informazioni. Non è obbligatorio compilare tutti
i campi del modulo di registrazione, ma alcuni devono essere
necessariamente specificati affinché il database centrale risulti coerente e
quindi Medtel funzioni correttamente. I campi obbligatori sono: nome,
cognome, username, password, indirizzo e-mail, tipo di utente, struttura
sanitaria, specializzazioni. C’è da notare poi, che affinché in fase di
creazione non si specifichi per errore una password diversa da quella
desiderata, è richiesto di confermare la password inserita una seconda volta,
compilando un apposito campo. Se le due password inserite sono diverse
non si può procedere con l’inserimento. Vengono effettuati molti altri
controlli sui dati inseriti, sempre per fare in modo che il database risulti il
più coerente possibile nel corso del tempo. Ad esempio si controlla che
l’indirizzo e-mail sia un indirizzo valido, cioè che sia nel formato
[email protected]. Altri controllo riguardo il CAP ed i numeri di
telefono o fax. Siccome questi dati sono necessariamente di tipo numerico,
si impedisce che per errore vengano utilizzati dei caratteri alfabetici.
L’ultima nota importante da aggiungere, riguarda il campo username.
Questo campo insieme alla password, è il più importante di tutti, perché è
solo tramite una combinazione di username e password che è possibile
effettuare il login all’interno di Medtel. Bisogna prestare particolare
attenzione quindi che due utenti non utilizzino la stessa username. Affinché
questo non sia possibile, si è inserito un meccanismo di controllo real-time
ad-hoc. Come si vede il processo di creazione di un nuovo utente, pur nella
sua semplicità concettuale, nasconde diverse caratteristiche interessanti,
soprattutto sotto l’aspetto tecnico. Il paragrafo seguente è infatti dedicato
completamente agli aspetti realizzativi.
- 46 -
Nell’area di amministrazione gli utenti abilitati possono visualizzare un
elenco degli utenti da loro creati e cliccando su un nominativo nella lista,
avere maggiori informazioni sui dati di registrazione. Si è prestata
particolare cura affinché sia possibile ritrovare facilmente un dato
nell’elenco, anche nel caso questo diventi molto vasto. E’ stato quindi
predisposto un motore di ricerca che permette di visualizzare solo i
nomativi corrispondenti ad alcuni criteri, ad esempio si può richiedere di
visualizzare solo gli utenti di un determinato tipo, creati in un particolare
giorno, ecc…Naturalmente è prevista anche la possibilità di cercare per
nome, cognome ed username. Per quanto riguarda l’elenco in quanto tale,
anche questo presenta delle caratteristiche di sicuro interesse. Esso infatti
supporta la paginazione dinamica, quindi l’utente può scegliere quanti
elementi per pagina visualizzare, muoversi all’inizio o alla fine, ecc..Tutte
queste caratteristiche per quanto banali, hanno richiesto notevoli sforzi
tecnologiche perché bisogna ricordarsi che come al solito si sta parlando di
una web application e non di una normale applicazione desktop.
L’ultima possibilità che viene fornita agli amministratori è quella di poter
eliminare gli utenti da loro stessi creati. Nello sviluppo di questa opzione si
è dovuti procedere facendo molta attenzione che l’intero processo risultasse
il più sicuro possibile e che fosse difficile compromettere il funzionamento
di Medtel stesso. Cliccando su un nominativo nell’elenco si apre la finestra
contenente i dati dell’utente e al contempo anche un bottone per procedere
con l’eliminazione. Se si decide di eliminare l’utente bisogna cliccare sul
bottone e subito appare un finestra di dialogo per confermare le proprie
intenzioni. Questo è il primo meccanismo di sicurezza, il più semplice,
affinché risulti difficile eliminare un utente per sbaglio. Il problema
principale che si è dovuto affrontare però, non riguarda gli incidenti dovuti
a cancellazioni casuali, ma quelli dovuti al collegamento tra gli utenti. In
particolare si è visto che ogni utente è creato da un utente posto più in alto
- 47 -
nella scala gerarchica, e questo può arrivare a coinvolgere anche i pazienti,
perché si sa che essi sono creati dai requester. Quando si elimina un utente
c’è quindi il rischio che gli utenti da esso creati rimangano orfani. Nel caso
di pazienti questo è un problema particolarmente serio perché i loro dati
non sarebbero più accessibili e visualizzabili con notevoli ripercussioni sul
funzionamento di Medtel. Per evitare che si presentino situazioni spiacevoli
si è introdotto quindi il meccanismo di ereditarietà. Nel dettaglio significa
fare in modo che al momento di eliminare un utente, venga effettuato un
controllo per verificare che l’utente da eliminare non abbia a sua volta
creato altri utenti o pazienti e nel qual caso, venga richiesto di specificare a
chi riassegnare quest’ultimi. In questo modo si evita che si creino dei dati
orfani nel database. Esiste comunque la possibilità di non riassegnare a
nessuno gli utenti creati, ma viene specificato bene che si tratta di una scelta
molto pericolosa e si richiede di confermare più volte le proprie intenzioni.
Nel caso di dottori non ci sono problemi di eredità ed essi possono essere
semplicemente eliminati senza ulteriori passaggi.
Quella vista finora è una panoramica introduttiva delle funzionalità messe a
disposizione dall’area di admin. Nel prossimo paragrafo verranno discussi
gli aspetti tecnico-realizzativi.
3.4 Realizzazione tecnica
3.4.1 Struttura, componenti e classi Java
La sezione di amministrazione è il risultato della collaborazione di molti
componenti autonomi che svolgono funzioni più elementari e che
nell’insieme formano la struttura di tutta l’area. Essendo Medtel
programmato in Java e quindi con uno stile OOP, l’approccio possibile non
poteva che essere quello scelto. In questo paragrafo si commenterà nel
- 48 -
dettaglio il codice Java che sta alla base della parte amministrativa,
mettendo in risalto però, solamente i passi più interessanti da un punto di
vista tecnico, ed evitando di evidenziare i tratti più manieristici o creati
tramite procedure automatiche.
La struttura della sezione amministrativa è definitiva dalla seguenti classi
Java suddivise tra parte client e parte server:
package com.uni.mirongwt.client
(PARTE CLIENT)
Admin.java
Cntiene le altre componenti
Registration.java
Creazione di nuovi utenti
RegistrationRM.java
RegistrationRMAsync.java
ListaUser.java
Visualizzazione ed Eliminazione
ListaUserRM.java
ListaUserRMAsync.java
ModRegistration.java
Modica del proprio profile
ModRegistrationRS.java
ModRegistrationRSAsync.java
UserArea.java
Metodi comuni a tutto Medtel
UserAreaRS.java
UserAreaRSAsync.java
Package com.uni.mirongwt.server
(PARTE SERVER)
RegistrationRMImpl.java
ListaUserRMImpl.java
ModRegistrationRSImpl.java
UserAreaRSImpl.java
Il codice di ogni singola classe verrà commentato nei prossimi paragrafi.
- 49 -
3.4.1.1 Admin.java
Per accedere alla sezione amministrativa è necessario passare tramite una
procedura di login che controlla che le credenziali di accesso siano corrette
e subito dopo carica il modulo principale che è rappresentato dalla classe
Admin.java (per maggiori dettagli sulla procedura di login e logout vedi il
paragrafo “Gestione della sessione”).
Admin.java è il contenitore che unisce tra di loro tutte le varie componenti
che formano l’area di amministrazione. Esso inoltre si occupa di creare la
struttura a tab utilizzata per la presentazione delle informazioni. Ogni tab è
definita da un titolo e contiene al suo interno un componente tra quelli
elencati tra questi paragrafi. In particolare le tab sono in tutto tre: Home,
New User e Created Users. New User contiene il componente per la
creazione di nuovi utenti, Created Users invece quello per visualizzare ed
eliminare gli utenti già creati. Si può facilmente intuire che grazie ad un
design di questo tipo è facile agire su una sezione della parte amministrativa
senza dover toccare il codice di un’altra area. Questo permette di limitare il
più possibile errori accidentali dovuti a sviste ed inoltre preserva le area già
sviluppate da quelle ancora in programmazione.
Il tab Home non contiene altri componenti Java, ma è semplicemente una
pagina HTML in cui è impostata un’immagine di sfondo e del testo di
presentazione per l’area di admin.
Il codice per la creazione della struttura a tab è il seguente:
// creo un nuovo oggetto TabPanel di GWT
TabPanel tabPanel = new TabPanel();
// costruttore della classe
public Admin() {
// imposta alcune proprietà del TabPanel
tabPanel.setResizeTabs(false);
tabPanel.setMinTabWidth(115);
- 50 -
tabPanel.setTabWidth(135);
tabPanel.setWidth(700);
tabPanel.setHeight(600);
tabPanel.setTitle("Administrator Area");
// creo le componenti
Panel insertedP = new Panel();
Panel newP = new Panel();
Panel homeP = new Panel();
// Tab New User
newP.setTitle("New User");
newP.setPaddings(0);
newP.setSize(699, 699);
newP.add(new
Registration(list,tabPanel,stype));
// Tab Created Users
ListaUser list = new ListaUser();
insertedP.setTitle("Created Users");
insertedP.setPaddings(0);
insertedP.setSize(699, 699);
Panel pan = new Panel();
pan.setBorder(false);
pan.setPaddings(20);
pan.setLayout(new HorizontalLayout(15));
pan.add(list);
insertedP.add(pan);
// aggiungo le tab alla struttura
tabPanel.add(homeP);
tabPanel.add(newP);
tabPanel.add(insertedP);
tabPanel.setActiveTab(0);
Il codice in Admin.java si occupa anche di creare la toolbar presente nella
sezione d’amministrazione. La toolbar è analoga a quelle che si trovano in
quasi tutte le normali applicazioni desktop e contiene al suo interno un
menu a tendina da cui è possibile compiere due distinte operazioni:
effettuare il logout ed accedere alla schermata che consente la modifica del
proprio profilo. Nella toolbar inoltre, è presente un tasto per accedere
all’aiuto contestuale di Medtel (cfr. “Usabilità”, cap. 5). Il codice qui di
seguito illustra il meccanismo di creazione della toolbar:
- 51 -
// creo un nuovo oggetto Toolbar della libreria GWT
Toolbar toolbar = new Toolbar();
// creo un nuovo bottone (HELP)
ToolbarButton help = new ToolbarButton();
help.setIcon("help.png");
help.setTooltip("Help");
// aggiungo un listener di eventi per il click
// sul bottone
help.addListener(new ButtonListenerAdapter(){ public
void onClick(Button button, EventObject e) {
…..
// codice dell’evento click sull’HELP
}
});
// aggiungo il bottone alla toolbar
toolbar.addButton(help);
// aggiungo un separatore visivo
toolbar.addSeparator();
// creo un nuovo menu a tendina
Menu menu = new Menu();
// nuova opzione nel menu
Item profile = new Item("Profile");
// listenr del click sull’opzione
profile.addListener(new
BaseItemListenerAdapter(){
public void onClick(BaseItem item,
EventObject e) {
…
// codice del click sul Profilo
}
});
// aggiungo l’opzione logout
Item logout = new Item("Logout");
// aggiungo il listener
logout.addListener(new
BaseItemListenerAdapter(){
public void onClick(BaseItem item,
EventObject e) {
….
// codice del click su Logout
}
});
- 52 -
// aggiungo le opzioni al menu
menu.addItem(profile);
menu.addItem(logout);
// aggiungo la toolbar alla struttura a tab
tabPanel.setTopToolbar(toolbar);
Anche se le righe di codice finora rappresentate sono un numero molto
esiguo rispetto al totale di quelle che compongono Medtel, si possono
comunque mettere in risalto alcuni passaggi interessanti. Come già detto in
precedenza, Google Web Toolkit è una libreria per la programmazione di
interfacce grafiche di tipo event-driven e quindi il codice viene eseguito in
risposta alle azioni compiute dagli utenti come per esempio il click su un
bottone. Per sfruttare questo approccio in GWT bisogna compiere diversi
passaggi. Per prima cosa bisogna creare un oggetto listener istanziandolo
dalla classe ButtonListenerAdapter(). A questo punto è necessario andare a
ridefinire i metodi ereditati dalla classe madre a seconda dell’azioni di cui si
vuole gestire l’attivazione. Per esempio nel codice precedente viene sempre
definito il metodo OnClick(…) perché quello che si vuole è eseguire una
determinata porzione di codice al click da parte dell’utente su un’area attiva
della GUI. L’ultimo passo da compiere è collegare il listener all’oggetto di
cui si vuole gestire il comportamento. Allo scopo è utile il metodo
addListener che praticamente tutti gli oggetti della libreria GWT
espongono. Si noti che nel codice precedente non è stato creato un oggetto
nel modo standard, ma si è istanziata una classe anonima derivata
direttamente dalla classe madre, contestualmente allla chiamata del metodo
addListener. Questa tecnica è totalmente equivalente al procedura
tradizionale, ma al vantaggio di permettere una scrittura più rapida del
codice e allo stesso tempo permette al garbage collector di liberare la
memoria per gli oggetti creati subito dopo che la loro esistenza non è più
richiesta per l’esecuzione dell’applicazione.
- 53 -
3.4.1.2 Registration.java, RegistrationRMImpl.java
Le classi Registration.java e RegistrationRMImpl.java, insieme alle classi
di servizio RegistrationRM.java e RegistrationRMAsync.java, contengono il
codice del componente che si occupa di gestire il processo di creazione di
un nuovo utente, così come questo è stato descritto nel paragrafo dedicato
alle funzionalità.
Registration.java,
RegistrationRM.java
e
RegistrationRMAsync.java,
appartengono alla parte client di Medtel, mentre RegistrationRMImpl.java è
la Java Servlet che si occupa di fornire i servizi di connessione al database
dalla parte del server. E’ chiaro quindi che la GUI del modulo per
l’inserimento dei dati del nuovo utente, è definita nella classe
Registration.java. Questa classe quindi, contiene tutti i metodi sviluppati
per verificare che il form di registrazione venga compilato in maniera
corretta insieme al codice per il collegamento con la Java Servlet.
Si può cominciare ad illustrare il codice di Registration.java e
RegistrationRMImpl.java, mettendo in risalto la parte che si occupa di
controllare il tipo di utente che si sta creando e modificare il modulo di
registrazione di conseguenza. In particolare, sono interessanti le righe,
segnalate, che instaurano il collegamento con la Java Servlet allo scopo di
ottenere l’elenco delle specializzazioni possibili per un medico,
memorizzate nel database centrale.
Questo è il codice client contenuto in Registration.java:
// pannello con l’elenco delle specializzazioni
final Panel resizablePanel = new Panel();
// setto alcune proprietà del pannello
resizablePanel.setTitle("Doctor Specialization");
resizablePanel.setWidth(200);
resizablePanel.setCollapsible(false);
// creo un oggetto lista
- 54 -
final ListBox lb = new ListBox();
lb.setMultipleSelect(true);
lb.setWidth("200");
lb.setHeight("70");
//
//
//
//
CONNESSIONE ALLA JAVA SERVLET RegistrationRMImpl.java
RICHIAMO IL METODO special DEFINITO NELLA Servlet
QUESTO METODO RESTITUISCE L’ELENCO DELLE
SPECIALIZZAZIONI ESTRAPOLANDOLO DA UN DATABASE
RegistrationRMAsync register = (RegistrationRMAsync)
GWT.create(RegistrationRM.class);
ServiceDefTarget endpoint = (ServiceDefTarget) register;
String moduleRelativeURL = GWT.getModuleBaseURL() +
"RegistrationRM";
endpoint.setServiceEntryPoint(moduleRelativeURL);
AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Object result) {
String[][] dati = (String[][])result;
for (int i =0; i<dati.length; i++) {
// Dati ricevuti dal server
lb.addItem(dati[i][1],dati[i][0]);
}
}
public void onFailure(Throwable caught) {
MessageBox.alert("There was an error
contacting the server. Please try again later");
}
};
register.special(callback);
// aggiungo la lista al pannello
resizablePanel.add(lb);
// inserisco nel modulo il radio box per la scelte
// dell’utente, le opzioni possibili, variano a seconda
// che sia un Super-Admin o un Manager
// se 0 è un super-admin crea manager
if (stype.equals("0")) {
administrator = new RadioButton("userType");
absolutePanel.add(administrator, 253, 531);
}
// se 1 è un manager crea dottori e requester
if (stype.equals("1")) {
hospital = new TextField("Structure");
requester = new RadioButton("userType");
doctor = new RadioButton("userType");
- 55 -
Come si vede nelle righe evidenziate dal commento in maiuscolo, in
Registration.java viene richiamato il metodo special(…) definito nella
servlet remota RegistrationRMImpl.java, di seguito quindi è illustrato il
codice di questo metodo:
public String[][] special(){
// creo una connessione al database MySQLDB
// sfrutto l’oggetto db definito in Database.java
// Questa classe è illustrata nei paragrafi successivi
Database db = new
Database("mironjava","mironjava","abppt_5");
// dati è la variabili di ritorno della funzione
String[][] dati = new String[100][2];
// connessione
db.connetti();
try {
int i = 0;
int rows = 0;
// estraggo i dati
db.query("SELECT * FROM exams ORDER BY name");
while (db.getResult().next()) {
rows++;
}
dati = new String[rows][2];
db.getResult().beforeFirst();
while (db.getResult().next()) {
dati[i] = new
String[]{db.getResult().getString("id"),db.getResult().g
etString("name")};
i++;
}
}
catch (Exception e) {
System.out.println(e.getMessage());
}
return dati;
}
- 56 -
La funzione special(…), è un metodo pubblico che restituisce un array
multidimensionale di tipo String, come si vede fin dall’intestazione della
procedura. L’array può essere visto come una tabella a due colonne, la
prima contiene il codice numerico ed univoco della specializzazione, la
seconda invece il nome vero e proprio. Il numero delle righe dell’array è
naturalmente pari al numero di specializzazioni presenti nel database.
Il codice visto fino a questo punto, permette già di farsi un’idea di come si
possa costruire un’interfaccia grafica in GWT, di come si possano associare
degli eventi agli oggetti della GUI ed infine di come avvenga il
collegamento con le servlet remote. La maggior parte delle operazioni più
comuni svolte in fase di sviluppo di Medtel sono quindi già stati illustrate.
A questo punto è interessante mostrare il codice che si occupa di controllare
che i campi obbligatori siano tutti compilati. Verranno inoltre evidenziati i
meccanismi che consentono di verificare in tempo reale, che l’username
scelta sia libera, che il formato dell’indirizzo e-mail sia corretto, che non si
inseriscano caratteri alfabetici nelle textbox del numeri di telefono, del fax e
del CAP ed infine che la password inserita e la sua conferma, siano
idetiche.
Il controllo della correttezza dell’e-mail è banale perché GWT mette a
disposizione un metodo apposito:
// creo il campo di testo per l’e-mail
final TextField mail = new TextField("* E-mail");
// campo obbligatorio
mail.setAllowBlank(false);
// formato dei dati riconosciuti valida.VType.EMAIL è
// una variabile di istanza statica della classe
// VType di GWT
mail.setVtype(VType.EMAIL);
// Messaggio in caso di formato errato
mail.setVtypeText("Plese enter a valid e-mail");
// Aggiungo il campo e-mail al form
formPanel.add(mail);
- 57 -
Anche fare in modo che non si possano inserire caratteri nei numeri di
telefono, fax e CAP è semplice grazie al fatto che GWT fornisce una classe
da cui istanziare oggetti di tipo NumberField che in automatico disabilitano
i caratteri quando sono attivati:
// creo il campo per il CAP
final NumberField cap = new NumberField("ZIP Code");
// creo il campo per il numero di telefono
final NumberField telephone = new
// creo il campo per il numero di fax
final NumberField fax = new NumberField("Fax");
// aggiungo i campi al form di registrazione
formPanel.add(cap);
formPanel.add(telephone);
formPanel.add(fax);
Leggermente più complesso è verificare la coincidenza tra il campo
password ed il campo conferma password. Allo scopo è necessario creare
un oggetto validator. Questo tipo di oggetto va creato in un formato adatto
affinché GWT possa utilizzarlo per verificare la validità di un campo. Va
quindi creata una classe che implementa l’interfaccia Validator definendo
l’unico metodo esposto dall’interfaccia stessa, cioè il metodo validate(…).
A questo punto, bisogna collegare l’oggetto appena creato con il campo che
si sta definendo, tramite il metodo setValidator(…). Il codice seguente
illustra il funzionamento di tale meccanismo, si noti che la classe che
implementa l’interfaccia Validator è una classe interna del componente
definito in Registration.java:
// campo per la password
final TextField pass = new TextField("* Password");
pass.setPassword(true);
pass.setAllowBlank(false);
// classe da cui instanziare l’oggetto validator e che
// implementa l’interfaccia Validator. Si noti che è
// una classe interna
- 58 -
class validateConfirm implements Validator {
boolean tmp = false;
public boolean validate(String value) {
if (value.equals(pass.getText())) {
tmp = true;
} else {
tmp = false;
}
return tmp;
}
}
// campo per la conferma
final TextField confirm = new TextField("* Confim
Password");
confirm.setAllowBlank(false);
confirm.setPassword(true);
// associo il validatore al campo
confirm.setValidator(new validateConfirm());
// messaggio in caso di non conformità
confirm.setInvalidText("Password mismatch");
Infine la parte più difficile di tutto il processo di verifica del modulo: il
controllo che l’username scelta sia libera. Questo controllo richiede di
estrapolare dei dati dal database e quindi l’interazione con metodi messi a
disposizione dalla servlet remota definita in RegistrationRMImpl.java.
Dalla parte del client il codice è pressoché identico a quello visto per la
conferma della password. Si crea un oggetto validator a partire
dall’interfaccia Validator e si definisce il metodo Validate(…). Quello che
cambia è appunto il contenuto di questo metodo che questa volta deve
effettuare una chiamata al codice remoto ed aspettare il risultato (sotto
forma di un dato di tipo boolean). Ecco il codice commentato della parte
client:
// creo la classe da cui istanziare l’oggetto validator
// si noti che la classe implementa l’interfaccia
// validator
class validateUser implements Validator {
boolean tmp = false;
public boolean validate(String value) {
- 59 -
// mi connetto alla Java Servlet remota tramite una
// chiamata RPC
RegistrationRMAsync register = (RegistrationRMAsync)
GWT.create(RegistrationRM.class);
ServiceDefTarget endpoint = (ServiceDefTarget) register;
String moduleRelativeURL = GWT.getModuleBaseURL() +
"RegistrationRM";
endpoint.setServiceEntryPoint(moduleRelativeURL);
AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Object result) {
if (result.toString().equals("true")) {
tmp = true;
// username libera
} else {
tmp = false;
// username occupata
}
}
public void onFailure(Throwable caught) {
// se si verifica un errore non
// accade nulla
}
};
// chiamo il metodo remoto free. Value è l’username che
// voglio controllare
register.free(value, callback);
return tmp;
}
}
// creo il campo username
final TextField user = new TextField("* Username");
// imposto il testo da visualizzare in caso di errore
// cioè quando la username è già occupata
user.setInvalidText("Not Free");
// associo il validator
user.setValidator(new validateUser());
// aggiungo il campo username al modulo
formPanel.add(user);
Il codice del client mostrato richiama la funzione free(…) sul server. Il
metodo free è così definito:
- 60 -
// metodo richiamato dalla GUI
public String free(String username) {
// nuova connessione al database
Database conn = new
Database("mironjava","mironjava","abppt_5");
conn.connetti();
// query SQL per estrapolare le informazioni dal
// database
String query = "SELECT * FROM users WHERE
username=\""+username+"\"";
// esegui la query e ritorno i risulti in uscita
try {
conn.query(query);
if(!conn.getResult().next()){
return "true";
} else {
return "false";
}
}
// se si verifica un errore stampo un messaggio
// e ritorno comunque il valore false
catch (Exception e) {
System.out.println(e.getMessage());
return "false";
}
}
Come si vede esso richiede di specificare in ingresso una username di cui si
vuole controllare lo stato. In uscita abbiamo due possibili valori booleani:
true se la username è libera, false se è già utilizzata da un altro utente.
Logicamente se viene restituito il valore false non si può procedere con la
registrazione del nuovo utente, senza cambiare prima l’username scelta. Il
controllo viene effettuato in tempo reale mentre si inseriscono uno dopo
l’altro i caratteri nel campo username. Il codice snello della procedura
permette di minimizzare i rallentamenti che questa scelta inevitabilmente
comporta.
- 61 -
3.4.1.3 ListaUser.java, ListaUserRMImpl.java
Le
classi
ListaUser.java
e
ListaUserRMImpl.java,
rispettivamente
appartenenti ai package client e server di Medtel, si occupano di
visualizzare l’elenco degli utenti creati da un amministratore e di permettere
di operare su di esso, ad esempio eliminando un nominativo. Questo
componente è contenuto nel tab Created Users del modulo principale
Admin.java.
Si può cominciare col visionare il codice che si occupa di visualizzare
l’elenco degli utenti. Come detto in precedenza per la visualizzazione è
stato utilizzato un complesso widget messo a disposizione da GWT-Ext che
supporta la paginazione dinamica. Oltre a ciò, esso consente di ordinare i
dati in vario modo, ad esempio per nome, e di effettuare ricerche tra di essi.
E’ quindi un oggetto molto potente, ma che richiede un’attenta
configurazione in fase di programmazione. Di seguito è visualizzato il
codice che lo gestisce. Il codice è commentato in modo che tutti i passaggi
risultino chiari:
// Creo un recordset per contenere i dati estrapolati
// dal database
recordDef = new RecordDef(
new FieldDef[]{
new StringFieldDef("id"),
new StringFieldDef("date_create"),
new StringFieldDef("user"),
new StringFieldDef("name"),
new StringFieldDef("surname"),
new StringFieldDef("type"),
}
);
// chiamata RPC alla funzione view_user contenuta nella
// Java Servlet remota ListaUserRMImpl.java
final ListaUserRMAsync list = (ListaUserRMAsync)
GWT.create(ListaUserRM.class);
- 62 -
ServiceDefTarget target = (ServiceDefTarget) list;
target.setServiceEntryPoint(GWT.getModuleBaseURL() +
"ListaUserRM");
AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Object result) {
// chiamata riuscita. Elaboro i dati ricevuti
// In particolare copio i dati ricevuti dall’arrayList
// result all’array di oggetti multidimensionale data
Object[][] data;
final ArrayList matrice = (ArrayList) result;
if(matrice!=null){
int righe=matrice.size();
int colonne=((ArrayList)matrice.get(0)).size();
Object[][] table = new Object [righe][colonne];
for(int i = 0; i < matrice.size();i++){
for(int j = 0; j < ((ArrayList)matrice.get(i)).size();
j++)
{
table[i][j]=(String)((ArrayList)matrice.get(i)).get(j);
}
}
data= table;
proxy = new PagingMemoryProxy(data);
}
else
{
proxy=null;
}
// college i dati alla grid
ArrayReader reader = new ArrayReader(recordDef);
Store store = new Store(proxy, reader, true);
grid.setStore(store);
// configure le colonne della grid da visualizzare
ColumnConfig[] columns = new ColumnConfig[]{
new ColumnConfig("ID", "id", 30,true, null, "id"),
new ColumnConfig("DATE CREATE", "date_create", 100,
true, null, "date_create"),
new ColumnConfig("USERNAME", "user", 100, true, null,
"user"),
new ColumnConfig("NAME", "name", 100, true, null,
"name"),
};
- 63 -
grid.setTitle("INSERTED USERS");
// Toolbar che contiene il motore di ricerca
Toolbar topToolbar = new Toolbar();
grid.setTopToolbar(topToolbar);
// motore di ricerca
GridSearchPlugin gridSearch = new GridSearchPlugin(
GridSearchPlugin.TOP );
grid.addPlugin(gridSearch);
// toolbar in basso per gestire la paginazione
final PagingToolbar pagingToolbar = new
PagingToolbar(store);
... // setto alcune proprietà visive della toolbar
grid.setBottomToolbar(pagingToolbar);
// Listener per il click su un nominativo nell’elenco
grid.addGridCellListener(new GridCellListenerAdapter() {
public void onCellClick(GridPanel grid, int rowIndex,
int colindex,EventObject e) {
… // click su un nominativo nell’elenco
}
Dal codice riportato qui sopra si evince che per popolare l’elenco degli
utenti è necessario estrapolare i dati di questi ultimi dal database. Quindi
come normalmente accade, bisogna richiamare una funzione definita in una
Java Servlet remota. Quest’operazione viene effettuata dalle righe che
richiamano
il
metodo
view_user(…),
contenuto
nella
classe
ListaUserRMImpl.java. Non verrà riportato il codice della servlet perché
essa si limita ad instaurare una connessione al database principale ed
eseguire una query SQL, con un procedimento analogo a quello visto già
molte altre volte nel corso di questa trattazione. L’unica cosa che è
importante evidenziare, è che i dati vengono passati attraverso un oggetto
- 64 -
che finora non era mai apparso tra questi paragrafi, cioè un ArrayList. Un
ArrayList può essere visto come un normale array, ma con una differenza
importante: mentre gli array tradizionali sono statici e quindi è necessario
specificare le loro dimensioni in fase di creazione, gli ArrayList sono
dinamici e di conseguenza le loro dimensioni variano a seconda dei dati che
sono contenuti al loro interno. Java gestisce in maniera profondamente
diversa i due tipi di dato, anche se per i programmatori il funzionamento è
sostanzialmente identico. Non conoscendo a priori gli utenti da visualizzare,
la scelta di un ArrayList come tipo di ritorno per la Java Servlet, è apparsa
la più sensata.
Nel
codice
precedente
viene
richiama
la
funzione
grid.addGridCellListener(…). Questo metodo permette di associare
all’oggetto grid un listener per la gestione dell’evento generato in seguito al
click su un nominativo nell’elenco. La procedura si occupa quindi di creare
una finestra in cui vengono riportati i dati dell’utente selezionato. Il codice
lato client è il seguente
// Chiamata RPC al metodo getData(…) nella Java
// Servlet per ottenre i dati dell’utente selezionato
ListaUserRMAsync listaUser = (ListaUserRMAsync)
GWT.create(ListaUserRM.class);
ServiceDefTarget endpoint = (ServiceDefTarget)
listaUser;
String moduleRelativeURL = GWT.getModuleBaseURL() +
"ListaUserRM";
endpoint.setServiceEntryPoint(moduleRelativeURL);
AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Object result) {
// imposto i campi della window
String[] dati = (String[])result;
name.setText(dati[1]);
- 65 -
surname.setText(dati[0]);
username.setText(dati[2]);
type.setText(dati[6]);
address.setText(dati[3]);
cap.setText(dati[12]);
email.setText(dati[7]);
telephone.setText(dati[9]);
createddate.setText(dati[10]);
structure.setText(dati[11]);
special.setText(dati[14]);
// se è un medico, non mostro il campo
// struttura, ma quello specializzazioni
if (type.getText().equals("doctor")) {
structure.setVisible(false);
structureL.setVisible(false);
specialL.setVisible(true);
special.setVisible(true);
}
// se è un requester, mostro il campo
// struttura e non quello specializzazioni
if (type.getText().equals("requester")) {
structure.setVisible(true);
structureL.setVisible(true);
specialL.setVisible(false);
special.setVisible(false);
}
// se è un manager non mostro ne struttura
// ne specializzazioni
if (type.getText().equals("administrator")) {
structure.setVisible(false);
structureL.setVisible(false);
specialL.setVisible(false);
special.setVisible(false);
}
}
public void onFailure(Throwable caught) {
// si è verificato un errore, non mostro
// la finestra, ma un messaggio
window.hide();
MessageBox.alert("There was an error
connecting to the remote service. Please try
again");
}
};
// chiamo la funzione per caricare i dati e poi mostro
// la finestra
listaUser.getData(…);
window.show();
- 66 -
Il codice lato server, cioè quello del metodo getData(…), si preferisci non
riportarlo perché sostanzialmente si occupa di eseguire una normale query
SQL sul database e riportare in uscita i dati di un utente attraverso un
normale array di String, alla stregue del codice già visto più volte in
precedenza.
L’ultima procedura che il componente ListaUser,java mette a disposizione
è quella di eliminazione di un utente. I meccanismi di ereditarietà e
sicurezza che regolano il processo sono già stati ampiamente trattati nel
paragrafo dedicato alla funzionalità, quindi in questa sede si mostrerà
solamente il codice che gestisce il tutto, prima quello del package client e
poi quello del package server.
// creo il tasto per eliminare e aggiungo un listener
// per il click
final Button elimina = new Button("Delete user");
elimina.addListener(new ButtonListenerAdapter() {
public void onClick(final Button button) {
// dialog-box di conferma
MessageBox.confirm(""Are you sure?", new
MessageBox.ConfirmCallback() {
// conferma ottenuta
public void execute(String btnID) {
// tipo di utente selezionato
String tt = grid.getAsString("type");
// non è un dottore
if (btnID.equals("yes") && !tt.equals("doctor")) {
…
// codice per la selezione di un nuovo
// padre per gli utenti rimasti orfani
public void onClick(final Button button) {
…
// chiamata RPC per eliminare i dati sul DB
…
// aggiorno l’elenco
refreshGrid();
}
- 67 -
// l’utente da eliminare è un dottore, non devo
// riassegnare nulla
else if (btnID.equals("yes") && tt.equals("doctor")) {
// elimino l’utente e aggiorno la griglia
refreshGrid();
}
public void refreshGrid() {
Panel insertedP = new Panel();
ListaUser list = new ListaUser();
insertedP.setTitle("Created Users");
pan.add(list);
insertedP.add(pan);
tabpanel.add(newP);
tabpanel.add(insertedP);
}
Del codice client qui riportato è interessante evidenziare il meccanismo per
aggiornare l’elenco degli utenti dopo che un nominativo è stato eliminato
dal database. Allo scopo è richiamata la funzione refreshGrid(…) che non
fa altro che rimuovere il tab dalla struttura principale definita in
Admin.java, ricrearlo ed infine aggiungerlo nuovamente. In questo modo la
memoria occupata dal widget originario viene liberata per far posto ad un
nuovo widget, identico, ma proprio perché appena istanziato, aggiornato
all’ultima operazione eseguita. Un procedura analoga è sfruttata per
aggiornare l’elenco anche quando si crea un nuovo utente.
Di seguito invece è mostrata la Java Servlet che elimina l’utente dal
database. Il nome del metodo, contenuto in ListaUserRMImpl.java, è
delete(…), e sostanzialmente esegue solamente una serie di query SQL a
cascata.
public boolean delete(int id, int newid) {
// Connessione al database
Database conn = new
Database("mironjava","mironjava","abppt_5");
// Query SQL per eliminare i dati dalle varie tabelle
- 68 -
String query = "DELETE FROM users WHERE id="+id;
String query2 = "DELETE FROM exams_users WHERE
// l’id dell’utente da eliminare è passato come
// parametro alla funzione
user_id="+id;
String query3 = "UPDATE users SET creator_id ="+newid+"
WHERE creator_id="+id;
String query4 = "UPDATE patients SET user_id ="+newid+"
WHERE user_id="+id;
// eseguo le query una dopo l’altra
try {
conn.connetti();
conn.insert(query);
conn.insert(query2);
conn.insert(query3);
conn.insert(query4);
catch (Exception e) {
return false;
}
return true;
}
3.4.1.4 ModRegistration.java, ModRegistrationRSImpl.java
Il componente ModRegistration.java, insieme alla sua controparte server
ModRegistrationRSImpl.java, si occupa di mostrare un modulo per
permettere ad un manager o ad un super-admin, di modificare parte del
proprio profilo, in particolare i propri dati anagrafici, la propria e-mail e la
propria password. Non è possibile invece cambiare l’username di
registrazione perché grazie a questa scelta si mantiene il database centrale
di Medtel il più coerente possibile. Il componente è attivabile attraverso la
voce presente nel menu a tendina contenuto nella toolbar principale della
sezione amministrativa, così come è stato illustrato nel paragrafo dedicato
alle
funzionalità.
C’è
ModRegistration.java,
da
non
notare
viene
che
utilizzata
- 69 -
la
classe
solamente
definita
nelle
in
parte
amministrativa di Medtel, ma proprio perché a tutti gli utenti
dell’applicazione, siano essi medici, amministratori o requester, è concesso
di aggiornare il proprio profilo, essa viene richiamata in quasi tutti i
contesti.
In questo paragrafo non verrà riportato il codice del componente perché
esso fa uso delle stesse tecniche viste per il modulo di creazione di un
nuovo utente, comprese quelle per il controllo dei campi, e quindi la loro
riproposizione anche in questa sede risulterebbe un’inutile ripetizione.
3.4.1.5 UserArea.java, UserAreaRSImpl.java
Gli ultimi metodi utilizzati nella sezione amministrativa sono quelli messi a
disposizione dalla classe UserArea.java. In realtà questa classe non è un
componente specifico dell’area amministrativa, ma essa si occupa di
definire delle funzioni di uso comune in tutto Medtel. E’ quindi una classe
sicuramente molto importante e di cui vale la pena commentare qualche
stralcio di codice.
UserArea.java fa parte del package client e quindi non fornisce procedure
per la connessione al database, ma in essa sono descritti tre metodi:
1) reload()
2) load_name(…)
3) logout()
Tutte e tre le funzioni vengono utilizzate all’interno del codice dell’area
amministrativa. In particolare load_name(…) si occupa di mostrare il nome
dell’utente loggato in Medtel all’interno della toolbar, logout(…) gestisce il
processo di uscita dall’applicativo e reload() è di supporto per l’esecuzione
di logout(…). Nel suo funzionamento UserArea.java richiede di potersi
interfacciare con il database. Nel packages server è quindi presente la Java
Servlet UserAreaRSImpl.java complementare alla parte client.
- 70 -
Questo è il contenuto completo di UserArea.java, di seguito il codice verrà
commentato:
public class UserArea extends Composite {
public static native void reload() /*-{
$wnd.location.reload();
}-*/;
public static void load_name(){
final UserAreaRSAsync load = (UserAreaRSAsync)
GWT.create(UserAreaRS.class); //crea il servizo
ServiceDefTarget endpoint = (ServiceDefTarget) load;
endpoint.setServiceEntryPoint(GWT.getModuleBaseURL()
+ "UserAreaRS");
final AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Object result) {
String name = (String) result;
options.setText(name);
}
public void onFailure(Throwable caught) {
}
};
load.load(callback);
}
public static void logout(final Panel tab){
final UserAreaRSAsync logout = (UserAreaRSAsync)
GWT.create(UserAreaRS.class); //crea il servizo
ServiceDefTarget endpoint = (ServiceDefTarget) logout;
endpoint.setServiceEntryPoint(GWT.getModuleBaseURL()
+ "UserAreaRS");
final AsyncCallback callback = new AsyncCallback() {
public void onSuccess(Object result) {
tab.getEl().mask("Logging out...", "x-mask-loading");
Timer timer = new Timer() {
public void run() {
tab.getEl().unmask();
reload();
- 71 -
}
};
timer.schedule(2000);
}
public void onFailure(Throwable caught) {
}
};
logout.logout(callback);
}
}
La classe presenta multi spunti interessanti. Tanto per cominciare viene
sfruttata una caratteristica del Google Web Toolkit che finora non era mai
stata messa in rilievo, ovvero la possibilità di inserire codice Javascript
direttamente in quello Java. Nella documentazione del GWT questa tecnica
viene chiamata inline Javascript ricalcando il nome con cui viene chiamata
la procedura utilizzata dai programmatori C per inserire del codice
assembler all’interno dei loro programmi. Per inserire del Javascript
bisogna racchiuderlo all’interno di un commento, in modo che venga
ignorato dal compilatore Java, altrimenti si solleverebbe un’eccezione. A
questo punto è necessario far capire all’interprete GWT che si tratta di
codice Javascript e non di un vero e proprio commento. Allo scopo è
necessario precedere ogni istruzione dal carattere $. La funzione reload(…)
usa l’inline Javascript per aggiornare la pagina, in modo da effettuare il
logout.
Un altro passaggio interessante è quello in cui viene creato un oggetto di
tipo Timer. Gli oggetti timer permettono di eseguire una porzione di codice
ad intervalli regolari che possono essere impostati in fase di creazione. Nel
codice mostrato l’oggetto timer viene utilizzato per mostrare un messaggio
di informazione all’utente che sta effettuando il logout, e per farlo poi
- 72 -
sparire dopo un intervallo di tempo di 2000 millesimi di secondo, ovvero
due secondi.
L’ultima nota che si può aggiungere a quanto appena visto, è il fatto che
tutti i metodi raccolti in UserArea.java sono dei metodi statici. In questo
modo si evita di dover istanziare un oggetto dalla classe per poterli
richiamare.
3.4.2 Struttura dei dati nel database
Si è visto più volte nel corso della presentazione dei componenti utilizzati
per realizzare la sezione amministrativa, che essi richiedono di estrapolare
un gran numero di informazioni memorizzate nel database principale.
Questo è possibile tramite chiamate RPC/Ajax a metodi contenuti nel
package server che si occupano della connessione al database e di lanciare
query SQL.
I dati contenuti nel database sono organizzati con la classica struttura che
viene in genere utilizzata dai Database Management System di tipo
relazionale, ovvero le tabelle di records. In questo paragrafo si vuole quindi
fornire una panoramica delle tabelle che contengono dati di interesse per la
parte amministrativa. In particolare le tabelle utilizzate sono le seguenti:
1) users
2) exams
3) exams_users
La tabella users contiene la maggior parte delle informazioni sugli utenti
registrati a Medtel. Viene quindi utilizzata nella procedura di login, in
quanto in essa sono memorizzate tutte le coppie username/password, e poi
in tutte le procedure di eliminazione, aggiunta ed elencazione degli utenti
che vengono svolte nell’area amministrativa. E’ quindi una tabella molto
- 73 -
importante e che necessità di una cura particolare per quanto riguarda la sua
sicurezza (si veda a questo proposito il paragrafo dedicato alla sicurezza del
database).
La tabella exams contiene invece l’elenco delle specializzazioni dei medici
che sono riconosciute come valide da Medtel. Essa viene utilizzate in fase
di creazione di un nuovo medico oppure quando si visualizzano le
informazioni di un medico già registrato nel database. La tabella exams
lavora a questo scopo con la sua complementare, ovvero la tabella
exams_users, che contiene l’elenco delle specializzazione associate ai
nominativi del personale sanitario.
Per concludere il paragrafo, viene illustrata la struttura delle tre tabelle
utilizzate, ovvero l’elenco dei campi e il tipo di dati in essi contenuti.
Tabella Users
id
Identificativo numerico (INT)
surname
Cognome (VARCHAR)
name
Nome (VARCHAR)
username
Username (VARCHAR)
hashed_password
Password criptata (VARCHAR)
address
Indirizzo di residenza (VARCHAR)
cap
CAP di residenza (INT)
telephone_number
Numero di telefono (INT)
mail
Indirizzo e-mail (VARCHAR)
fax
Numero di Fax (INT)
type
Tipo utente: admim, doctor, requester (INT)
creator_id
Identifico dell’utente padre (INT)
created_at
Data ed ora di creazione dell’utente (DATE)
structure
Struttura per il requester (VARCHAR)
- 74 -
location
Città di residenza (VARCHAR)
state
Nazione di residenza (VARCHAR)
stype
Super-admin o manager (INT)
Tabella exams
id
Identificativo numerico (INT)
name
Nome specializzazione (VARCHAR)
Tabella exams_users
user_id
Identificativo numerico dell’utente (INT)
exam_id
Identificativo numerico dell’esame (INT)
3.4.3 Gestione della sessione
Per gestione della sessione s’intende il modo attraverso il quale vengono
preservate le informazioni di login dopo che un utente si è identificato in
Medtel, inserendo nome utente e password. Durante l’esecuzione infatti,
risulta spesso necessario compiere operazioni che richiedono proprio questo
tipo di informazioni, come ad esempio nel caso l’utente voglia modificare il
proprio profilo. Questi dati devono quindi essere conservati da qualche
parte durante tutto l’arco di tempo in cui l’utente rimane connesso a Medtel.
Allo scopo si è scelto di memorizzate i dati sfruttando dei meccanismi
messi a disposizione dalla tecnologia Java Servlet. In particolari questi
meccanismi permettono di memorizzare degli oggetti Java in alcune
variabili “virtuali”. Virtuali perché questo tipo di variabili saranno gestisce
in maniera totalmente differente rispetto alla tradizionali variabili d’istanza
- 75 -
che si utilizzano in Java. La differenza principale sta nel fatto che, una volta
memorizzati gli oggetti attraverso le procedure per la gestione della
sessione, questi oggetti sono richiamabili da qualunque parte del codice
contenuto nel package server, tramite dei metodi appositi. In questo modo si
può facilmente gestire il passaggio di dati tra le varie componenti.
Alla luce di tutto questo, si evince che per memorizzare i dati di un utente
che si è accreditato presso Medtel, è necessario progettare un oggetto
apposito che li contenga al proprio interno. La classe UserSession.java del
package server definisce proprio questo oggetto. Il codice è il seguente:
public class UserSession implements IsSerializable{
private
private
private
private
private
private
int id;
String user;
String name;
String surname;
String mail;
String type;
public UserSession(int id, String user,String name,
String surname,String mail, String type){
this.id=id;
this.user=user;
this.name=name;
this.surname=surname;
this.mail=mail;
this.type=type;
}
//metodi per impostare i valori
public void setId(int id){
this.id=id;
}
public void setUser(String user){
this.user=user;
}
public void setName(String name){
this.name=name;
}
public void setSurname(String surname){
this.surname=surname;
}
public void setMail(String mail){
- 76 -
this.mail=mail;
}
public void setType(String type){
this.type=type;
}
//metodi per prendere i valori
public int getId(){
return id;
}
public String getUser(){
return user;
}
public String getName(){
return name;
}
public String getSurname(){
return surname;
}
public String getMail(){
return mail;
}
public String getType(){
return type;
}
}
Si vede che la classe implementa l’interfaccia isSerializable affinché gli
oggetti istanziati da essa possano essere trasferiti tramite chiamate a metodi
remoti, così come è già stato illustrato nei capitoli precedenti. Oltre a
questo, la classe definisce delle variabili che conterranno i dati dell’utente,
e dei metodi per leggere il valore di questi variabili nonché di impostarlo.
A questo punto si può illustrare quali siano i comandi che Java Servlet
mette a disposizione per memorizzare delle variabili di sessione e
successivamente per leggerle. Per memorizzare un oggetto all’interno di
una variabili di sessione si utilizzano le seguenti istruzioni:
// Creo un oggetto dalla classe UserSession
// per contenare i dati dell’utente che effettua
// il login in Medtel
UserSession usersession = new
UserSession(id,utente,name,surname,mail,type);
- 77 -
// Creo un oggetto per la gestione della sessione
HttpServletRequest request =
this.getThreadLocalRequest();
HttpSession session = request.getSession();
// Registro nella variabili virtuale us
// l’oggetto UserSession creato in precedenza
session.setAttribute("us", usersession);
Il codice è estremamente semplice, Java Servlet permette infatti di gestire
agevolmente il meccanismo di creazione e distruzione delle variabili di
sessione. A questo punto se si vuole leggere una variabile di sessione creata
con il metodo precedente, bisogna utilizzare questi comandi:
// Creo un oggetto per gestire la sessione
HttpServletRequest request =
this.getThreadLocalRequest();
HttpSession session = request.getSession();
// Ottengo la variabili di sessione contenuta in “us”
UserSession currentPatient=(UserSession)
session.getAttribute("us");
Per concludere il paragrafo non resta altro che specificare dove
effettivamente questi dati vengano tenuti durante l’esecuzione di Medtel.
Gli oggetti memorizzati tramite la tecnica delle variabili di sessione
vengono salvati nel computer dell’utente che utilizza l’applicativo, sotto
forma di cookies. I cookies sono dei files gestiti dal browser su richiesta dei
siti internet, e contenuti in genere nella cartella d’installazione del browser
stesso. Si può quindi affermare che Java Servlet tramite la gestione delle
sessioni permette ai programmatori di sfruttare la tecnologia dei cookies in
maniera poco complessa ed efficace.
- 78 -
3.5 Problematiche di sicurezza
3.5.1 SSL e Login
La procedura di login di un utente all’interno di Medtel rappresenta uno dei
momenti di maggior rischio durante tutta l’esecuzione dell’applicazione per
quanto riguarda la sicurezza dei dati. Infatti è proprio durante la procedura
di accesso che un utente è costretto a fornire le proprie username e
password affinché si possano controllare le sue credenziali. Una volta che i
dati sono partiti dalla postazione client dell’utente, questi viaggiano
attraverso la rete fino ai server di Medtel dove poi vengono elaborati. Il
rischio maggiore sta proprio nel passaggio attraverso la rete, un attaccante
potrebbe infatti inserirsi nel traffico ed andare a leggere le informazioni di
login. Se le credenziali sono di alto livello, mettiamo addirittura di un
super-admin, i problemi diventano molto seri, perché a questo punto
l’attaccante potrebbe sfruttare i privilegi per creare nuovi utenti, modificare
utenti già creati, o più in generale per compromettere il normale
funzionamento di Medtel.
Ora che si è capito qual’è il potenziale di rischio insito nella stessa
procedura di login, ci si deve chiedere quali siano le possibili soluzioni
affinché il funzionamento dell’applicativo sia il più sicuro possibile. Tutto
questo anche alla luce della constatazione che i dati trattati in Medtel sono
dati medici e quindi estremamente sensibili. Le soluzione sono
essenzialmente due: modificare la procedura con cui si accede ai servizi,
oppure rendere
il processo più sicuro,
pur non
modificandone
sostanzialmente la dinamica. Prima di vedere nel dettaglio le due soluzioni,
diciamo subito che Medtel, al momento, non implementa nessuno dei due
meccanismi, perché si tratta di un prodotto ancora non completamente
- 79 -
maturo per essere distribuito sul mercato, e quindi in futuro potranno essere
fatte ancora molte modifiche.
Per quanto riguarda la prima soluzione, si potrebbe pensare di eliminare
direttamente la necessità di inserire una username ed una password,
passando ad un accesso tramite una procedura hardware e non software. In
particolare si potrebbero distribuire insieme all’applicativo dei dispositivi
da collegare ai computer degli utilizzatori, ad esempio delle chiavette USB,
contenenti tutte le credenziali d’accesso. Medtel dovrebbe quindi andare a
leggere in automatico il contenuto di queste smart card senza che all’utente
venga richiesto nulla in fase di avvio. Questa soluzione da un lato offre il
vantaggio di un altissimo grado di sicurezza, ma dall’altro è estremamente
costosa e di conseguenza non adatta agli scopi che Medtel si prefigge, cioè
di diffondersi nei paesi più poveri.
L’altra soluzione prevede invece di utilizzare delle tecniche di criptazione
dei dati in fase di login, in modo che essi non viaggino in chiaro lungo la
rete, ma siano protetti durante il loro tragitto. Per far questo, si potrebbe
quindi utilizzare il protocollo HTTPs invece del normale protocollo HTTP,
perché esso prevede già nella propria architettura la criptazione dei dati
tramite SSL. Questa soluzione appare di gran lunga più fattibile rispetto alla
precedente, perché offre un ottimo rapporto tra vantaggi e costi. Il costo
infatti sarebbe praticamente nullo, legato al più ad un leggero calo di
prestazioni, dall’altro la sicurezza sarebbe comunque elevata e più che
sufficiente per il funzionamento di Medtel.
3.5.2 Sicurezza del database
Un’altra problematica di sicurezza oltre quella presentata nel paragrafo
precedente è quella che coinvolge il database centrale dei dati. Il database è
un elemento ad alto rischio nell’architettura di Medtel perché contiene al
- 80 -
suo interno le informazioni necessarie al funzionamento di Medtel, come ad
esempio le username di accesso, nonché i dati medici dei pazienti. Un
attaccante potrebbe tentare di arrivare ad esso e carpire informazioni
cliniche con un evidente rischio per la privacy degli utilizzatori, oppure
potrebbe tentare di ottenere delle credenziali di accesso. Per cercare di
scongiurare questi eventi, bisogna fare particolare attenzione nel proteggere
il database centrale ed i dati in esso contenuti. Il modo migliore per far
questo sarebbe quello di installarlo su un server diverso rispetto a quello
che ospita Medtel, e fare in modo che questo server sia irraggiungibile
dall’esterno attraverso la rete. Cioè impedirebbe qualsiasi tipo di attacco,
tranne l’ipotesi remota di un accesso fisico diretto ai laboratori
dell’università. Se è impossibile dislocare il database su un altro computer
si può comunque fare in modo che almeno le credenziali di accesso
risultino inutilizzabili da parte di un attaccante che sia riuscito ad
intrufolarsi all’interno della base di dati. Per far questo, Medtel memorizza
le password nella tabella users, non in chiaro, ma in forma criptata. In
particolare si utilizza una criptazione one-way ovvero dalla quale non è
possibile risalire ai dati originali. Un attaccante che anche riuscisse a
visionare la tabella users non potrebbe comunque scoprire la password
degli amministratori e degli altri utenti.
Naturalmente esistono molte altre tecniche che potrebbero venire usate per
compromettere il funzionamento di Medtel a partire dal database centrale.
Si potrebbero ad esempio, cancellare tutti i dati in maniera irreversibile.
L’unica protezione da attacchi di questo tipo, come da molti altri, è quella
di effettuare dei backup frequenti, e controllare costantemente l’attività, in
modo che in caso di danneggiamenti sia facile ristabilire le condizioni
originarie e limitare i danni.
- 81 -
CAPITOLO 4
Dati Biomedici
4.1 Dati biomedici
La crescente diffusione dell’uso delle tecnologie informatiche ed
elettroniche nella pratica medica, ha posto il mondo della ricerca e
dell’industria di fronte a diverse problematiche circa il modo migliore per
gestire ed ottimizzare le grandi quantità di dati digitali prodotti.
Tra le molte problematiche a cui si è dovuto trovare soluzione, quella dei
formati per i dati biomedici è una delle più interessanti. Essa infatti pone
questioni che investono moltissimi settori dell’ICT, a partire dall’hardware
per lo storage fino ad arrivare allo sviluppo di software per la lettura di
questi dati. In questo capitolo ci si occuperà particolarmente proprio di
quest’ultima tematica.
La diagnostica per immagini (o imaging biomedico) è una delle
metodologie mediche più diffuse in tutto il mondo. Attraverso di essa è
possibile osservare un’area dell’organismo non direttamente raggiungibile
dall’esterno, utilizzando dispositivi ed apparecchiature progettate per questo
scopo. Questa strumentazione in genere produce in uscita dei dati in
formato digitale e quindi direttamente manipolabili tramite dei computer.
Affinché sia possibile l’interscambio dei dati tra i dispositivi sanitari ed i
computer però, è necessario che questi siano espressi in un formato
comprensibile ad ambedue i sistemi e quindi, è necessario progettare degli
standard ampiamente riconosciuti a livello internazionale ed industriale.
Questi formati devono essere per forza molto complessi perché le
problematiche da affrontare nella gestione dei dati medici digitali sono
- 82 -
molto diversificate. Un tipico problema che si deve affrontare è ad esempio
quello della dimensione dei dati in uscita. Spesso infatti le macchine per
l’imaging biomedico, come un endoscopio, produco una notevole quantità
di informazioni non compresse. Il formato dei dati che dovrà gestirle quindi
è chiamato a trovare un modo per memorizzarle in maniera efficiente, senza
però intaccarne la qualità che è imprescindibile per una corretta diagnosi
medica. Un altro problema molto comune è dovuto al fatto che spesso
questi dati sono di natura estremamente eterogenea, ad esempio un
dispositivo potrebbe essere utilizzato per più scopi differenti e quindi, è
necessario che il formato sia abbastanza versatile e scalabile in contesti
differenti. L’ultima problematica che si vuole mettere in evidenza riguarda
la velocità ed i costi. Il formato dei dati dovrebbe essere in grado di lavorare
nel modo più efficiente possibile e con costi abbastanza contenuti.
Tutti questi sono esempi delle difficoltà incontrata dalle aziende e dai centri
di ricerca nell’affrontare lo sviluppo di formati per la gestione dei dati
biomedici. Nonostante tutto però, la forte necessità di uno standard per
l’interscambio dei dati, ha portato allo sviluppo di diverse soluzioni, tutte
con i loro pregi e difetti.
In questo capitolo si illustrerà una di queste soluzioni, ovvero il formato
DICOM. Il formato DICOM è probabilmente lo standard che si è più
affermato nel mondo industriale e medico mondiale grazie alle sue qualità
ed ai suoi punti di forza. Il prossimo paragrafo è dedicato completamente ad
una descrizione delle sue caratteristiche e del suo funzionamento.
4.2 DICOM
Il Digital Imaging and Communications in Medicine (DICOM) è uno
standard per la gestione, la memorizzazione, la stampa e la trasmissione di
immagini mediche provenienti da strumentazioni diagnostiche.
- 83 -
Il DICOM è uno standard estremamente complesso, esso infatti nasce per
far fronte ad esigenze eterogenee e quindi il suo sviluppo ha comportato
scelte di design radicali. Di conseguenza il DICOM non può essere
considerato solo un semplice formato dati ma invece sarebbe più corretto
inquadrarlo come protocollo per l’interscambio di informazioni tra sistemi
differenti, che al contempo definisce al proprio interno anche delle linee
guida per i dati che transitano attraverso esso.
Lo standard DICOM è sostanzialmente suddiviso in due parti principali: la
prima descrive un formato per i file, la seconda invece il protocollo di
comunicazione vero e proprio. Il protocollo di comunicazione è situato al
livello più alto della pila ISO/OSI ed è quindi un protocollo applicativo che
si basa sul TCP/IP per instradare la comunicazione tra le macchine
coinvolte, che possono essere notebook, server mainframe oppure
dispositivi elettromedicali.
Lo standard è stato sviluppato da un comitato tecnico costituito all’interno
della National Electrical Manufacturers Association (NEMA) che
attualmente detiene ancora il copyright sulle specifiche. Il DICOM permette
un’integrazione estesa tra i dispositivi che dichiarano di essere conformi
alle sue linee guide. Occorre notare però, che il DICOM è uno standard
industriale, e non uno standard ISO, quindi universale: ciò comporta una
certa tolleranza nell'implementazione delle specifiche, al punto che
attualmente forse non esistono apparecchiature che possano definirsi
pienamente DICOM compliant, nel senso rigoroso che la definizione di uno
standard
imporrebbe.
Nella
maggior
parte
dei
casi,
infatti,
un'apparecchiatura risulta conforme ad una parte dello standard (ad esempio
la modalità di archiviazione delle immagini), mentre adotta tecnologie
proprietarie per altre funzionalità (ad esempio la gestione delle liste
pazienti).
- 84 -
La compatibilità DICOM deve essere certificata dal costruttore attraverso
un documento autocertificativo, denominato Conformance Statement, che
ne elenchi le funzionalità.
I dati radiologici rappresentabili come immagini o le immagini vere e
proprie che vengono archiviate secondo lo standard DICOM vengono
comunemente chiamate immagini DICOM. L'errore più comune che viene
fatto nell'interpretazione del termine è che queste siano assimilabili ad altri
formati di compressione d’immagine. In verità lo standard DICOM
applicato alla codifica dei file non è nient'altro che un metodo per
incapsulare i dati e per definire come questi debbano essere codificati o
interpretati, ma non definisce alcun nuovo algoritmo di compressione.
L'immagine quindi viene archiviata in forma non compressa, secondo la
codifica con la quale viene prodotta, oppure utilizzando degli algoritmi di
compressione molto comuni, come ad esempio il JPEG.
4.2.1 Struttura dei file
Il DICOM suddivide le informazioni in gruppi chiamati data sets. Questo
significa ad esempio, che un’immagine DICOM di una lastra ad un
ginocchio, in realtà può essere composta da due componenti, l’immagine
stessa e le informazioni sul paziente. In questo modo le informazioni non
saranno mai separate per errore. Come si vede quindi un’immagine DICOM
consiste in un insieme molto più vasto di dati rispetto alla sola immagine di
per se stessa. Di conseguenza sarebbe più opportuno parlare di DICOM
Data Object piuttosto che di immagini DICOM. Un DICOM Data Object
può contenere informazioni sul giorno nel quale l’immagine medica è stata
creata, oppure informazioni sul paziente come il suo nome, cognome ed ID
all’interno di un ospedale, nonché informazioni sull’immagine stessa, come
- 85 -
ad esempio, codifica, rapporto di compressione, dimensioni, risoluzione,
ecc…
Un file in formato DICOM può memorizzare anche più immagini al suo
interno. Questo permette di utilizzare lo standard anche in situazioni in cui è
richiesta una grande accuratteza dei dati e quindi si memorizza l’immagine
totale suddividendola in molte sotto-immagini allo scopo di ottenere una
risoluzione complessiva estremamente elevata. I dati contenuti in un file
DICOM, siano essi immagini (pixel data) che informazioni testuali,
possono essere compressi per ottimizzarne la distribuzione con vari
algoritmi, sia di tipo lossy che che lossless. Esempi di questi algoritmi sono
LZW e JPEG.
Essendo un file DICOM una sorta di contenitore per altri dati in vari
formati, è necessario che lo standard specifichi una serie di metodologie per
informare i visualizzatori software sul tipo di dati che dovranno trattare.
Allo scopo si utilizza quindi uno schema di codifica per segnalare e
descrivere le varie componenti di un file costruito seguendo le linee guide
DICOM.
Di seguito viene fornito un elenco di alcuni istruzioni utilizzate per
codificare le varie sezioni:
DICOM Value Representations
Value Representation
Description
AE
Application Entity
AS
Age String
AT
Attribute Tag
- 86 -
CS
Code String
DA
Date
DS
Decimal String
DT
Date/Time
FL
Floating Point Single (4 bytes)
FD
Floating Point Double (8 bytes)
IS
Integer String
LO
Long String
LT
Long Text
OB
Other Byte
OW
Other Word
PN
Person Name
SH
Short String
SL
Signed Long
SQ
Sequence of Items
SS
Signed Short
ST
Short Text
TM
Time
UI
Unique Identifier
UL
Unsigned Long
- 87 -
UN
Unknown
US
Unsigned Short
UT
Unlimited Text
Le istruzioni elencate in precedenza possono essere utilizzate per formattare
un file DICOM allo stesso modo di come si può costruire una pagina Web
utilizzando i tag HTML. Il processo è quindi molto semplice.
4.3 Software open source
Dopo aver illustrato il formato DICOM ed alcune problematiche legate
all’elaborazione digitale di dati biomedici, si vuole a questo punto offrire un
elenco di software open source per gestire questo formato. Esistono
moltissimi software creati per gestire i file DICOM, moltissimi sono di
ottima fattura e supportano quasi completamente tutte le sfaccettature dello
standard, altri invece sono più limitati e permettono di sfruttare solamente
una minima parte delle possibilità che il protocollo sviluppato dalla NEMA
prevede. In generale comunque tutti i software si suddividono tra
commerciali, gratuiti ed open source. E’ importante sottolineare che open
source non fa rima con gratis, anche se spesso accade proprio questo, e
soprattutto che gratuito non equivale ad open source. Un software è open
source solamente quando è rilasciato con una licenza che ne permette di
vedere e modificare il codice. Esempi di queste licenze sono la LGPL, la
GPL e la BSD.
Si è scelto di mostrare solo dei software open source per gli indubbi
vantaggi che essi presentano a degli utilizzatori accademici. Essi infatti
- 88 -
possono essere utilizzati liberalmente, il più delle volte anche per scopi
commerciali, ed inoltre la possibilità di poter visionare il codice permette di
integrarli molto più facilmente alle proprio esigenze. Lo spirito
d’integrazione è infatti uno dei punti dai quali ha preso spunto lo sviluppo
di Medtel e si vedrà nel capitolo conclusivo, che esistono diverse idee per
integrare il Medical Telereporting System con i visualizzatori DICOM qui
di seguito riportati. Oltre a degli indubbi vantaggi però, i software open
source soffrono spesso di maggiori limitazioni rispetto ai corrispettivi
commerciali ed in generale non offrono nessun supporto tecnico agli
utilizzatori.
AMIDE (Windows, Linux, MacOS)
AMIDE è un programma completamente gratuito ed open source per
visualizzare, analizzare e registrare data sets di immagini mediche
volumetriche DICOM. L’interfaccia grafica con cui è costruito si basa sulle
librerie GTK+.
Caratteristiche:
1) Orientazione, thickness e periodo di visualizzazione arbitrari
2) Si possono visualizzare più data sets contemporaneamente e unirli
insieme per formare un’immagine unica
3) Possibilità di zoom
4) Supporto ad immagini a colori
5) Possibilità di tagliare e pulire solo zone limitate dell’immagine
6) Possibilità di creare video a partire dalla rotazione di immagini DICOM
7) Possibilità di applicare filtri alle immagini: gaussiano, 1D Mediano e 3D
Mediano
Sito di riferimento: http://amide.sourceforge.net/packages.html
- 89 -
(Screenshot tratto dal sito)
MRIcron (Windows, Linux, MacOS)
MRIcron è un software open source gratuito, scritto in Free Pascal, che
permette di visualizzare molti tipi di immagini DICOM. Offre un set di
caratteristiche più limitato rispetto ad AMIDE e l’interfaccia, sempre in
GTK+, è in generale più complessa da utilizzare. Ha comunque molte
opzioni interessanti come per esempio la possibilità di convertire i file
DICOM in molti altri formati oppure la possibilità di estrarre delle
statistiche dai file che vengono visualizzati.
Sito di riferimento: http://www.sph.sc.edu/comd/rorden/mricron/index.html
(Screenshot tratto dal sito)
- 90 -
MRIcro (Windows, Linux)
MRIcro permette di visualizzare immagini mediche in sistemi Windows e
Linux. E’ un programma standalone, ma include al proprio interno alcuni
tool per gestire i file SPM utilizzati nella neurologia.
MRIcro permette di visualizzare in maniera efficace immagini del cervello
ed inoltre permette ai neurologi di identificare regioni di interesse (ROI)
all’interno di un’immagine.
Caratteristiche:
1) Converte immagini DICOM nel formato SPM
2) Supporto per le codifiche big o little endian
3) Possibilità di creare regioni di interesse in 3D
4) Possibilità di ruotare ed ingrandire le immagini
5) Esportazione delle immagini nei formati BMP, JPEG, PNG e TIFF
Sito di riferimento: http://www.sph.sc.edu/comd/rorden/mricro.html
(Screenshot tratto dal sito)
- 91 -
DICOMscope (Windows, Linux, MacOS)
DICOMscope è un programma gratuito ed open source, scritto in Java, per
visualizzare immagini DICOM.
Le immagine che è possibile visualizzare sono quelle non compresse e
monocrome. L’ultima versione permette di gestire anche un server di
stampa, i file DICOM criptati, firmi digitali e la calibrazione dei monitor
così come specificata nel capitolo 14 del protocollo DICOM.
Sito di riferimento: http://dicom.offis.de/dscope.php.en
(Screenshot tratto dal sito)
4.4 Standard ECG
In calce al capitolo si vuole parlare brevemente degli standard utilizzati
nell’industria medica per gestire i dati prodotti dalle strumentazioni per
l’elettrocardiogramma.
L’elettrocardiogramma è uno strumento non invasivo che fornisce una
rappresentazione grafico-visiva dell’evoluzione dei potenziali cardiaci nel
tempo.
- 92 -
Rispetto allo standard DICOM che nasce per gestire i risultati dell’imaging
biomedico, un formato file per l’ECG deve presentare delle caratteristiche
sostanzialmente diverse. Le immagini DICOM sono infatti molto più
complesse, spesso contengono al proprio interno dati per la visualizzazione
in 3D e volumetrica, dati sul paziente, statistiche avanzate, ecc…I dati
prodotti dall’ECG invece sono molto più semplice consistendo in una serie
di forme d’onde sinuosidali poste su un sistema di assi cartesiani. Risulta
evidente quindi che è possibile trattare questi valori non come
un’immagine, ma invece come una serie storica di dati rappresentabili in
formato alfanumerico. Sarà poi il visualizzatore che si occuperà di
ricostruire la grafica dell’ECG.
Purtroppo al momento non esiste uno standard unico per memorizzare i
tracciati ECG, anche se esistono diverse soluzioni tutte molto valide e con
specifiche aperte. Una di queste è l’HL7 (Health Livel 7), uno standard
basato sull’XML per lo scambio di dati medici creato dall’omonima
associazione no-profit americana che appunto si occupa di definire standard
in medicina. Un’altra soluzione molto interessante è quella portata avanti
dal consorzio europeo che ha sviluppato lo standard OpenECG. Esso
permette di creare file con i dati sulle forme d’onda prodotte dagli
elettrocardiogrammi, di dimensioni molto contenute ed inoltre fornisce
diversi tool open source per gestirli. Inoltre esso è compatibile col DICOM
nel senso che i file in formato OpenECG possono essere convertiti in
immagini DICOM con appositi tool.
In generale non esiste uno standard universalmente accettato e soprattutto
non esiste uno standard ISO e quindi al momento si sente ancora l’esigenza
di uniformità per quanto riguarda i dati prodotti dagli elettrocardiogrammi.
Non bisogna dimenticare poi, che molte aziende forniscono delle soluzioni
basate sullo stesso standard DICOM con opportune modifiche.
- 93 -
CAPITOLO 5
Conclusioni
5.1 Migliorare Medtel
In quest’ultimo capitolo si vuole offrire una serie di spunti su cui lavorare
per poter migliorare il lavoro fin qui sviluppato. Come detto più volte in
precedenza infatti, Medtel nasce come evoluzione di altri software prodotti
in passato e quindi nel suo sviluppo si è cercato di correggere ed arginare la
maggior parte delle lacune che essi presentavano. Nonostante questo, anche
lo stesso Medtel presenta delle problematiche irrisolte al momento della
presente trattazione. In particolare questo problematiche discendono per la
maggior parte, dalle scelte effettuate in fase di progettazione, come ad
esempio l’utilizzo del Google Web Toolkit. Quando si valutano delle
soluzioni in fase di design di un prodotto, sia esso software oppure no,
bisogna sempre tenere a mente che ogni scelta comporta irrimediabilmente
dei pro e dei contro. La libreria fornita da Google non fa eccezione. Finora
si sono messi in luce principalmente gli aspetti positivi di cui si è potuto
beneficiare grazie alla sua adozione, in questi paragrafi conclusivi invece,
si vogliono evidenziare anche i contro che questa scelta ha portato con se.
Tutto questo viene fatto nella speranza che le sfide tecnologiche di seguito
riportate, vengano accolte da altri gruppi di lavoro, nel tentativo di migliore
il software da noi prodotto in fase di tirocinio.
Detto questo, si vuole sottolineare che anche con i suoi inevitabili problemi,
Medtel rappresenta comunque un software completo e capace di assolvere
egregiamente ai compiti per cui è stato sviluppato. I tratti negativi messi in
evidenza nei prossimi paragrafi, in definitiva, non compromettono il
funzionamento dell’applicativo stesso.
- 94 -
5.1.1 Compatibilità con i browsers
Uno dei motivi per cui si è scelto di sviluppare il Medical Telereporting
System utilizzando il Google Web Toolkit è stato quello di sfruttare una
delle sue principali potenzialità, ovvero quella di produrre codice Javascript
compatibile con la maggior parte dei browsers. Come si è detto in
precedenza infatti, Medtel nasce con lo scopo di diffondersi rapidamente ed
inoltre uno dei vantaggi principali dello sviluppo di web application è dato
dal fatto che esse sono eseguibili su un gran numero di sistemi diversi. In
realtà, questo è vero, solamente facendo particolare attenzione al codice che
dovrà essere eseguito dalla parte del client, e quindi dal browser
dell’utilizzatore, affinché questo non nasconda delle problematiche legate
all’incompatibilità con taluni browsers e/o sistemi. Il codice lato server,
girando invece su delle macchine predisposte non presenta questi
inconvenienti.
Il linguaggio Javascript che viene prodotto in uscita dal compilatore GWT,
almeno sulla carta, non dovrebbe presentare nessun problema di
incompatibilità con la totalità dei browsers oggi in circolazione. Quando
però si passa dalla teoria ai fatti, si nota che queste promesse, non sono
completamente mantenute. Questo è in parte inevitabile perché nel corso
degli anni, le diverse software house produttrici di browsers (Microsoft,
Apple, Mozilla, …) hanno sviluppato interpreti Javascript per i propri
applicativi notevolmente differenti tra di loro e questo ha portato a notevoli
grattacapi per chiunque si trovi a dover affrontare la progettazione di una
web application.
Si è detto che Google Web Toolkit mantiene solo in parte le proprio
promesse, perché durante la fase di test di Medtel su macchine differenti, si
sono riscontrate discrepanze di funzionamento tra le varie configurazioni
provate. Questo discrepanze sono comunque risultate notevolmente
- 95 -
marginali, confermando ancora una volta la bontà della scelta di utilizzare
GWT. Le principali differenze hanno riguardo il rendering dell’interfaccia
grafica dell’applicazione. In particolare si è visto che in alcuni browsers, i
widgets apparivano di colori leggermente differenti, oppure spostati rispetto
alla posizione scelta in fase di sviluppo. Si sottolinea con forza però, che ciò
non incide minimamente sul normale funzionamento dell’applicativo, che
quindi raggiunge gli obbiettivi di compatibilità che si erano fissati durante
l’analisi dei requisiti.
A questo punto, dopo aver parlato della problematiche in maniera più che
altro speculativa, si vuole fornire al lettore dei dati sperimentali su cui
riflettere. In particolare la tabella seguente mostra un elenco dei browsers
più diffusi con a fianco i risultati di compatibilità ottenuti da Medtel:
BROWSER
COMPATIBILITA’ RAGGIUNTA
Mozilla Firefox 2
Compatibilità Piena
Mozilla Firefox 3
Compatibilità Piena
Internet Exploter 6
L’interfaccia grafica non risulta
centrata nel browser, per il resto piena
compatibilità
Internet Explorer 7
L’interfaccia grafica non risulta
centrata nel browser, per il resto piena
compatibilità
Apple Safari
Compatibilità Piena
- 96 -
Google Chrome
Alcuni campi non vengono compilati
automaticamente, il problema può
essere aggirato facilmente
compilandoli a mano.
Come si vede Mozilla Firefox 2 e Mozilla Firefox 3 rappresentano i
migliori candidati per l’esecuzione di Medtel, ma comunque apparte lievi
errori di rendering, il funzionamento risulta ottimale in tutti i browsers.
Particolarmente significativo è il fatto che Medtel possa essere eseguito in
maniera corretta anche in un browser piuttosto datato, ma ancora
diffusissimo nei paesi più poveri, come Internet Explorer 6.
Per quanto riguarda invece problematiche di compatibilità in correlazione al
sistema operativo in uso dall’utente, e non ad un browser specifico, si sono
effettuati test sia su macchine equipaggiate con Linux, che con Winows XP,
Vista e MacOS X. In tutti i casi la visualizzazione non è risultata dipendere
dal sistema operativo, ma solo dal browser scelto per la prova.
Per concludere il paragrafo si vuole sottolineare che molto probabilmente
un’attenta analisi del codice HTML e Javscript che compone Medtel,
potrebbe risolvere anche i pochi difetti di visualizzazione di cui si è parlato
in precedenza. Questo dovrebbe essere uno dei primi punti da affrontare
nello sviluppo delle successive versioni.
5.1.2 Velocità di esecuzione
Con i termini velocità di esecuzione si intende definire in un unico concetto
tutta una serie di caratteristiche di un applicativo, sia esso desktop o come
nel caso di Medtel, web, quali ad esempio i tempi di risposta in seguito a
comandi impartiti dall’utente, i tempi di caricamento dell’interfaccia
grafica, ecc…In generale non è affatto semplice dare un giudizio sintetico
- 97 -
riguardo la velocità di esecuzione di un software, perché nel definirla
concorrono moltissimi fattori, non ultimo la potenza della macchine stesse
su cui l’applicativo gira. Quello che si può fare invece, è definire i requisiti
minimi che dovranno avere le macchine sulle quali andrà a funzionare il
software ed effettuare quindi dei test su delle configurazione di prova per
verificare che la velocità in questi contesti sia accettabile.
Diciamo subito, che la velocità di esecuzione è il vero e proprio tallone di
achille di Medtel. Aldilà di questa premessa negativa si possono fare però
diverse osservazioni per ridimensionare il quadro negativo che a prima vista
parrebbe essere stato tracciato. Prima di tutto comunque bisogna specificare
quali sono le cause della carenza di prestazioni mostrata da Medtel. La
causa principale va quindi ricercata in Google Web Toolkit e di
conseguenza nel Javascript. Come visto in precedenza infatti, Javascript
non è un linguaggio di tipo compilato, ma invece è un linguaggio di
scripting. Questo significa che il browser esegue l’istruzioni Javascript che
costruiscono l’interfaccia grafica, una dopo l’altra senza apportare delle
ottimizzazione quali ad esempio il Just-in-time Compiler che viene
utilizzato dalla macchina virtuale Java. Inoltre gli interpreti Javascript
inclusi nei più diffusi browsers in commercio non hanno mai brillato per
prestazioni.
Medtel quindi non può essere definitivo un prodotto performante. Nei
computer più moderni sicuramente si, ma in macchine più datate, che sono
poi il target del software, i rallentamenti sono abbastanza vistosi.
A stemperare questo quadro negativo ci sono però diversi fattori. Tanto per
cominciare negli ultimi mesi si è assistito ad una vera e propria corsa alle
prestazioni per quanto riguarda il mercato browser e questa evoluzione ha
sicuramente toccato molto profondamente anche gli interpreti Javascript.
Firefox 3.1, Internet Explorer 8 e Google Chrome promettono prestazioni in
esecuzione di istruzioni Javascript, migliorate anche del 50%-80%. Questo
- 98 -
non farà altro che rendere l’esecuzione di Medtel con questi browsers,
notevolmente più veloce e rapida, venendo in contro anche alle esigenze dei
paesi più poveri. Seconda punto, si sta assistendo ad un ricambio
tecnologico anche nei paesi del terzo mondo, questo porta alla diffusione di
PC più potenti anche in zone disagiate. Appare chiaro che entro breve i
problemi di prestazione di Medtel, potrebbero risolversi da soli, grazie al
lavoro sinergico di questi fattori. Ciò nonostante, i successivi sviluppi di
Medtel dovrebbero tenere conto con maggior efficacia del lato
performance, oltre che del lato funzionalità.
5.1.3 Usabilità
Un’altra problematica molto importante riscontrata in fase di sviluppo del
Medical Telereporting System, questa volta non legata alla scelta di
utilizzare Google Web Toolkit, è quella dell’usabilità. Per usabilità
s’intende il modo con il quale un applicativo si presenta agli utenti da un
punto di vista della facilità di utilizzo. Essa coinvolge quindi la struttura
della GUI, come anche la scelte circa i passaggi che un utente deve
compiere per eseguire un’operazione.
L’usabilità è un punto sul quale si è prestata una particolare attenzione in
fase di progettazione perché, come messo in luce in precedenza,
l’applicativo nasce per essere utilizzato da personale medico e requester in
zone disagiate. Questo tipo di target in genere non presenta un alto grado di
alfabetizzazione informatica e quindi è stato necessario costruire un
applicativo che fosse il più intuitivo possibile.
Andando a vedere la GUI di Medtel si può notare fin da subito che la
struttura a tab permette una facile gestione delle operazioni. Infatti essa
suddivide razionalmente i vari ambiti e quindi permette di accedere
rapidamente alle opzioni volute. Inoltre la scelta di un colore diverso per
- 99 -
ogni sezione (requester, amministrativa, medica), agevola ulteriormente la
navigazione all’interno dell’applicazione.
Sono stati sfruttati molti altri accorgimenti per semplificare ancora di più il
tutto. Per esempio si sono scelte dell’icone allo scopo di esemplificare
l’azione eseguita da un pulsante. In questo modo l’utente può familiarizzare
rapidamente con Medtel e la curva di apprendimento risulta notevolmente
appiattita.
L’ultimo accorgimento da sottolineare consiste nella guida in linea presente
in ogni sezione dell’applicativo. Essa è raggiungibile semplicemente
cliccando sul simbolo del punto interrogativo, in genere posto in alto a
destra, e fornisce un aiuto contestuale ed immediato riguardo le operazioni
che è possibile eseguire.
Per
versione
future
di
Medtel
si
è
pensato
di
provvedere
all’internazionalizzazione dell’applicativo. Al momento infatti, esso è
disponibile solo in lingua inglese, ma è molto sentita l’esigenza di versioni
localizzate
in
altre
lingue.
L’internazionalizzazione
non
consiste
semplicemente in una mera traduzione, ma richiede anche uno sforzo di
programmazione e tecnologico, per rendere questo processo, quanto più
possibile automatizzabile e rapido. Allo scopo la libreria GWT mette a
disposizione diverse classi e funzioni, ad esempio per rilevare in fase di
avvio dell’applicazione, la lingua del sistema dell’utente.
Per concludere il paragrafo, si vuole sottolineare come solo il feedback
della comunità di utilizzatori di Medtel, potrà fornire una adeguata base di
partenza per migliorare l’usabilità dell’applicativo stesso in versioni
successive.
- 100 -
5.2 Integrazione
In questo paragrafo si cercheranno di delineare alcune linee guida da
seguire per cercare di integrare il lavoro svolto con Medtel con altri
applicativi e dispositivi.
Integrare significa fare in modo che Medtel possa dialogare con altri
software oppure con particolari macchinari hardware che vengono utilizzati
nella pratica clinica. Lo scopo di tutto questo è come sempre, cercare di
offrire un software più completo e flessibile possibile, capace di adattarsi a
contesti sanitari estremamente eterogenei e allo stesso tempo però,
mantenere una struttura familiare per gli utilizzatori.
Non si tratta assolutamente di un obbiettivo facile da perseguire per molti
ordini di motivi: tecnologici, logistici e commerciali. Allo stesso tempo
inoltre non è un contesto che si è potuto approfondire molto nel limitato
tempo a disposizione del tirocinio. Qui di seguito quindi si forniranno
solamente degli spunti, affinché in futuro questi argomenti possano venir
sviluppati meglio.
5.2.1 Servizi medici per altri software
Alcune applicazioni mediche potrebbero ad un certo punto aver bisogno di
fornire ai proprio utilizzatori delle possibilità di telerefertazione. Le scelte
in questo caso sarebbero essenzialmente due: scrivere ex-novo delle
procedure adatte allo scopo, oppure evitare di reinventare l’acqua calda e
vedere se sul mercato esistono già dei software specifici per lo scopo. E’
qui che entra in gioco Medtel, si potrebbe pensare infatti di esternalizzare i
metodi che esso utilizza internamente, in modo che di essi possano
usufruire anche altri applicativi. Ad esempio Medtel potrebbe fornire una
libreria di classi che permettano ad altri programmi di interfacciarsi con
- 101 -
esso. Oppure si potrebbe progettare un servizio web (web service), ovvero
una serie di routine a cui ci si può collegare attraverso la rete, in generale
tramite il protocollo HTTP, e che ugualmente nascono con lo scopo di
permettere di sfruttare le potenziale di Medtel a soggetti esterni.
Logicamente tutte queste possibilità implicano la necessità di fare notevoli
considerazioni legate alla sicurezza prima di compiere qualsiasi passo.
Comunque sono degli esempi validi di come si potrebbe aprire al mondo
esterno un applicativo quale Medtel.
5.2.2 Visualizzatori di dati biomedici
Allo stesso modo di come altri software potrebbero beneficiare
dell’integrazione con i servizi messi a disposizione da Medtel, così Medtel
stesso potrebbe ottenere notevoli vantaggi se fosse in grado di sfruttare le
funzionalità di altri applicativi. In particolare un’integrazione con
visualizzatori di specifici formati dati utilizzati in medicina, farebbe
guadagnare moltissimi punti in termini di usabilità a Medtel. Allo scopo si
potrebbe rivolgere l’attenzione verso applicativi open source capaci di
leggere i file DICOM che, come è stato già messo in luce nel capitolo 4,
stanno acquisendo una diffusione via via maggiore in tutto il mondo
medico. Purtroppo la struttura a web application non rende affatto facile
quest’integrazione, perché in genere i visualizzatori sono invece delle
applicazioni desktop. Una soluzione sarebbe quella di scrivere applet Java
che fungano da ponte di interscambio tra i due mondi. Un’altra sarebbe
invece quella di scrivere specifici plugin per i browser. Quest’ultima
opzione è forse la più complessa, anche perché bisognerebbero scrivere
molti plugin diversi se non si vuole limitare la scelta dell’utenza sul
browser, dall’altra però offre le migliore garanzie di funzionalità.
- 102 -
5.2.3 Dispositivi medici
L’ultima integrazione che si può tentare non è di tipo software, ma di tipo
hardware. Sebbene infatti molto complessa nella realizzazione tecnica,
sarebbe comunque apprezzabilissima la possibilità di far interagire Medtel
con apparecchiature elettromedicali in uso nelle varie strutture sanitarie. Si
potrebbe pensare ad esempio di fare in modo che collegando il portatile ad
un’apparecchiatura per l’ECG, i file prodotti in uscita dalla strumentazione,
finiscano
direttamente
nel
database
centrale
di
Medtel,
contemporaneamente all’apertura di un nuovo problema clinico. Cioè
comporterebbe dei notevoli aumenti di produttività, nonché un uso ancora
più semplificato dell’applicativo.
Da un punto di vista tecnico la realizzazione può avvenire solo tramite la
scrittura di plugin appositi che devono gestire il flusso di dati attraverso le
porte di comunicazione del PC. Le politiche di sicurezza applicate dai
browsers inoltre, rendono il processo ancora più difficoltoso, se non
impossibile.
5.3 Conclusioni
Il lavoro svolto in fase di tirocinio ha permesso di approfondire molte
tematiche interessanti e ricche di spunti. Da un lato lo sviluppo di un
applicativo complesso come Medtel, ha permesso di toccare con mano le
problematiche che riguardano la progettazione ed il design di un software,
nonché la gestione del lavoro di gruppo. Dall’altro la scelta di utilizzare il
Java ed il Google Web Toolkit, ha permesso di studiare in maniera
dettagliata tecnologie moderne e di successo, acquisendo in questo modo un
bagaglio culturale sicuramente spendibile sia nel mondo del lavoro che in
quello accademico.
- 103 -
Web Application, Java, Javascript e Ajax sono tutti termini che stanno
diventando di uso comune all’interno della comunità informatica mondiale.
L’aver approfondito tali concetti nel periodo di tirocinio è sicuramente stata
un’imperdibile possibilità di entrare in un mondo innovativo e ricco di
stimoli.
Non bisogna dimenticarsi poi, che si è lavorato sul progetto di un software
reale, destinato ad essere utilizzato in zona disagiate in cui quindi, si sente
veramente l’esigenza di risolvere le problematiche mediche presentate in
queste pagine. Questo è sicuramente motivo di orgoglio e allo stesso tempo
accresce la sensazione di aver prodotto qualcosa di positivo nel corso delle
ore spese nei laboratori dell’università.
Come si dovrebbe aver capito leggendo questa trattazione, su Medtel si
concentrato molte idee ambiziose che noi speriamo vengano tutte realizzate
nel corso della varie versioni che saranno sviluppate. Il mio desiderio più
grande è sicuramente di aver contribuito, con gli altri miei compagni, a
sviluppare non solamente un software finito ed utilizzabile, ma anche una
solida base dalla quale partire per apportare un gran numero di migliorie.
Noi speriamo che le scelte fatte in fase di progettazione con l’aiuto di tutti
quelli che ci hanno assistito, sia in sede universitaria che all’interno
dell’Asur n.7 di Ancona, abbiamo permesso di imboccare la giusta
direzione all’interno del mare di possibilità che l’informatica moderna
mette a disposizione.
In questo ultimo capitolo infine, si sono forniti diversi percorsi da seguire
per migliorare il lavoro fin qui svolto, prestando particolare attenzione alle
tematiche dell’integrazione. Spero che alcuni idee tra quelle presentate
vengano riprese in futuro.
Per concludere ci si augura che Medtel riesca veramente a dare un proprio
contributo nel migliorare le condizioni sanitarie delle popolazioni più
disagiate della Terra, come quelle africane. Se questo ambizioso obbiettivo
- 104 -
sarà anche solo in minima parte raggiunto, si sarà potuto dimostrare ancora
una volta, che la speranza di una vita migliore passa attraverso il lavoro di
tutti noi.
- 105 -
Bibliografia
- TELEMEDICINA -
Telemedicine at Wikipedia
http://en.wikipedia.org/wiki/Telemedicine
American Telemedicine Association
http://www.americantelemed.org
- JAVA & JAVA SERVLET -
Java SE APIs & Documentation
http://java.sun.com/javase/reference/api.jsp
Primi passi con le Servlet Java
http://java.html.it/articoli/leggi/1943/primi-passi-con-le-servlet
- GOOGLE WEB TOOLKIT -
Google Web Toolkit 1.5 Developer's Guide
http://code.google.com/docreader
Google Web Toolkit Official Blog
http://googlewebtoolkit.blogspot.com
DeveloperLife GWT Tutorials
http://developerlife.com/tutorials
- 106 -
Working with GWT, ONJava.com
http://www.onjava.com
GWT-Ext Wiki
http://www.gwt-ext.com/wiki/index.php/Main_Page
- APACHE TOMCAT & MYSQL -
Apache Tomcat 6.0 Documentation
http://tomcat.apache.org/tomcat-6.0-doc
MySQL Official Documentation
http://dev.mysql.com/doc
- DATI BIOMEDICI -
DICOM Homepage
http://medical.nema.org
DICOM Introduction and free software list
http://www.sph.sc.edu/comd/rorden/dicom.html
OpenECG Portal
http://www.openecg.net
Health Level 7
http://www.hl7.org
- 107 -
