Gran parte del lavoro necessario per sviluppare e implementare l’applicativo web di cui tratta questa tesi è stato possibile grazie all’ausilio di un particolare framework progettato e implementato dallo stesso settore tecnico informatico della FTGM.
Tale framework prende il nome di Biomedical Framework – più semplicemente indicato come BMF - e la sua versione attuale, la 3.x, che nasce dalle ceneri della versione precedente (2.x) di cui conserva la logica di funzionamento, implementa una serie di tecnologie per lo sviluppo software e pattern architetturali moderni che offrono innumerevoli vantaggi sia in termini di usabilità che di manutenibilità.
In questo capitolo, perciò, andrò a esplorare il funzionamento del Biomedical Framework, noto più semplicemente come BMF, senza addentrarmi eccessivamente in dettagli tecnici ma aprendo una finestra sulle funzionalità e potenzialità messe a disposizione dal framework, sulle tecnologie software implementate e sulla logica di funzionamento utili per creare in maniera semplice degli applicativi per il web. In particolar modo vengono introdotte le dinamiche relative alle applicazioni web dinamiche a “singola pagina”, costruite con un’architettura a tre livelli e basate sul pattern MVC, inoltre sono trattati e approfonditi i temi riguardanti il funzionamento del suddetto BMF3.
3.1 - Applicazioni web dinamiche e pattern MVC
Così come il suo predecessore, anche il BMF3 è un tool usato per la creazione di applicazioni web dinamiche, con lo scopo di fornire a chi avesse una buona conoscenza del linguaggio SQL e altresì non avesse competenze in ambito di sviluppo di applicativi web e non conoscesse i linguaggi di programmazione ad oggetti (Java, C++, ect), uno strumento semplice da usare che gli permetta di creare, una volta imparate le funzionalità messe a disposizione dal tool, delle nuove applicazioni accessibili tramite web.
24
Tali applicazioni, è stato detto, vengono sviluppate secondo il paradigma noto come web dinamico, che fa uso dei cosiddetti linguaggi di scripting (JavaScript) i quali si occupano della creazione della pagina Internet nel momento in cui questa viene visitata dal client, mettendo a disposizioni delle GUI (Graphical User Interface), ossia delle interfacce utente che permettano a quest’ultimo di interagire in modo visuale con la pagina (tipicamente tramite delle form). Queste interazioni vengono elaborate direttamente lato client, tramite il browser, aggiornando solo porzioni della pagina web in background senza la necessità di dover richiedere un ricaricamento integrale da server, questo perché i dati vengono recuperati dal server tramite delle chiamate asincrone (AJAX) senza fare redirect per visualizzare i risultati delle elaborazioni.
Lo schema architetturale implementato prende il nome di pattern MVC (Model-View- Controller) e permette di separare la logica di presentazione dei dati dalla logica di business, la logica applicativa che rende operativa un’applicazione. Sebbene storicamente questo tipo di pattern venisse implementato lato server, con lo sviluppo e la parziale standardizzazione di JavaScript (JS), oggi i framework implementano MVC direttamente lato client in puro JS. Uno dei primi è stato Backbone.js e proprio tale libreria JavaScript viene utilizzata dal BMF3. Il pattern è basato sulla separazione dei compiti fra i componenti software, il model fornisce i metodi per accedere ai dati utili all’applicazione, la view permette di visualizzare i dati contenuti nel model e si occupa dell’interazione con l’utente, mentre il controller riceve i comandi dell’utente e li attua modificando lo stato del model che a sua volta aggiorna lo stato della view.
Backbone.js, per l’esattezza, è basato su un pattern da esso derivato, il Model-View-Presenter (MVP), che si differenzia dal MVC in quanto il presenter permette di gestire il collegamento tra UI e database in maniera più efficiente, ogni interazione tra view e model infatti passa dapprima attraverso il presenter che fa da ponte tra i due componenti.
25
Figura 1: pattern MVC (sinistra) e pattern MVP (destra)
Immediato scorgere i vantaggi legati alla separazione logica delle varie funzionalità del software, suddivise in più strati o livelli software differenti in comunicazione tra loro. Tale architettura fornisce, infatti, un modello per gli sviluppatori per creare un’applicazione flessibile, che consente di modificare o aggiungere funzionalità modificando solo uno specifico livello, nonché scalabile, ovvero è possibile aggiungere ulteriori funzionalità senza doverne modificare le caratteristiche fondamentali.
3.2 - Single Page Application
Le applicazioni web del BMF rientrano nella categoria Single Page Application (SPA), ovvero, come suggerisce il nome, sono delle applicazioni che “vivono” in una singola pagina (tipicamente index.html).
Le SPA hanno un loro sistema di routing interno, la navigazione viene pertanto gestita dal client ed è possibile ripristinare (rehydrating) i singoli stati direttamente dall’url, inoltre è disponibile un “template engine” per generare l’HTML senza dover necessariamente comunicare con il server.
Lo sviluppo della tecnologia Ajax ha permesso al codice Javascript di aggiornare singole porzioni della pagina web in maniera asincrona, grazie poi all’ausilio di librerie JS (una su tutte jQuery) si è arrivati ad ottenere applicazioni web che non hanno bisogno di ricaricarsi mai.
26
Figura 2: ciclo di vita di una pagina web tradizionale (sinistra) e di una single page application (destra)
La pagina viene scaricata nel browser e successivamente comunica via HTTP, Ajax o WebSocket con il server tramite un formato standard (JSON), la cui implementazione ne è completamente indipendente. Dunque l’applicazione risulta essere indipendente dal backend, ossia dall’implementazione lato server, definendo una netta separazione tra server e client cosicché uno possa essere ridefinito senza dover ridefinire anche l’altro, essendo indipendente può dunque essere gestita come un progetto separato, permettendo una migliore manutenzione agli sviluppatori frontend.
3.3 - Architettura a 3 livelli
Per creare delle applicazioni web il BMF fa uso di una architettura a 3 livelli in grado di eseguire del codice Java. In particolare la suddetta struttura è costituita da un Web Server, un Application Server e un Database Server. Qualunque richiesta da parte del client viene presa in carico dal Web Server che ha il compito di mettere in comunicazione client e server e lo fa passando la richiesta all’Application Server il quale dapprima la elabora tramite codice Java, poi genera una nuova richiesta in formato PLSQL che invia stavolta al Database Server, questo infine elaborerà la richiesta ed eventualmente risponderà in PLSQL ripetendo il percorso inverso.
Questi tre componenti possono essere visti come una singola unità costituenti insieme l’implementazione software server side.
3.3.1 - Il Database
Come DBMS (DataBase Management System) viene usato Oracle Database, sistema per la gestione di basi di dati scritto in C, che è tra i più famosi e impiegati al mondo per la costruzione di basi di dati che implementano l’ormai standard modello relazionale.
27
Tale DBMS è alla base del funzionamento del framework in quanto al suo interno vengono salvati dei dati, in apposite tabelle, necessari per configurare gli oggetti che vengono realizzati mediante il tool.
Tra le tabelle più importanti abbiamo:
T_TYPE_OBJECT: la tabella contiene i tipi di oggetti disponibili (es. report, inputForm, filter ect). Diversamente dal BMF2 vengono distinte con oggetti diversi le cartelle del menù di navigazione (menu_folder) dai pulsanti di navigazione contenuti nelle suddette cartelle (menu_item)
T_OBJECT: tabella contenente tutti gli oggetti, sia quelli di configurazione per il frontend del BMF3.x utili per il funzionamento del framework, sia gli oggetti creati dagli utenti per la creazione di applicativi
T_UTENTE: elenco degli utenti, coi dati anagrafici/amministrativi, user e password con cui accedere al proprio account sul BMF3.x
T_PROFILO: elenco dei profili disponibili, di cui ‘AMMINISTRATORE DI SISTEMA’ è quello a cui son garantiti tutti i diritti in lettura/scrittura
REL_UTENTE_PROFILO: relazione che associa i profili ai diversi utenti esistenti
REL_MENU_FRONTEND: relazione che associa gli oggetti menu_item agli oggetti menu_folder definendo la struttura del menù
REL_OBJECT_PROFILO: relazione contenente l’access control list (ACL) per il frontend del BMF3.x
V_MENU_FRONTEND: vista necessaria per rappresentare il menù del sito
P_SALVA_OBJECT_BMF3: store procedure per inserire o modificare un oggetto di tipo BMF3.x
P_OBJECT_BMF3_SAVE_AS: store procedure per fare il “save as” di un oggetto di tipo BMF3
TR_OBJECT: trigger per inserire in automatico i diritti sugli oggetti BMF3.x per il profilo amministratore del sito
3.3.2 - Server Side
La parte server side è stata implementata secondo lo stile architetturale REST (Representational State Transfer), oggi spesso preferito al protocollo SOAP (Simple Object
28
Access Protocol) per la sua efficienza e scalabilità e la sua capacità di conservare ed esaltare le caratteristiche intrinseche del Web senza la necessità di costruire sovrastrutture in aggiunta a quelle già messe a disposizione dal protocollo HTTP, sono stati pertanto creati una serie di Web Services RESTEasy che, tramite il Tomcat, comunicano con la parte client inviando le risposte in formato json. Tale formato è stato scelto per facilitare la separazione logica tra server e client, in quanto utilizzabile facilmente da qualsiasi linguaggio di programmazione, così da poter cambiare interamente all’occorrenza l’implementazione client side senza dover intervenire su quella server e viceversa.
Per la parte di configurazione e accesso al database viene utilizzato il framework di Spring. 3.3.3 - Web Server e Application Server
Come anticipato poc’anzi, la comunicazione tra server e client è presa in carico dal software della Apache Software Foundation, Apache Tomcat, o semplicemente Tomcat. Questa è una piattaforma software open source per l’esecuzione di applicazioni Web basato su Java ed è tra i più utilizzati tanto da essere quasi uno standard, in un’architettura a 3 livelli (DB server – Application Server – Web Server) è in grado di ricoprire ben due ruoli, difatti lavora sia da Web Server, gestendo le richieste di trasferimento di pagine web del client tramite protocollo HTTP o HTTPS, che da Application Server, implementando la logica di business dell’architettura multilivello.
Il Tomcat è inoltre un servlet container capace di gestire le servlet utili alla corretta fruizione dei servizi web e alla creazione delle pagine web dinamiche, queste vengono infatti create a runtime a partire da dei file JavaServer Pages (JSP) che implementano la logica di presentazione, i quali vengono compilati da un apposito motore JSP anch’esso contenuto nel Tomcat. JSP è una tecnologia alternativa rispetto a numerosi altri approcci per la generazione di pagine Web dinamiche, come per esempio PHP, ASP e CGI.
3.3.4 - Client Side
Alle nozioni su discusse della parte client possiamo aggiungere che questa è stata realizzata interamente in javascript mediante il supporto di diversi framework:
jQuery Backbone.js Marionette.js
29 Underscore.js
Require.js Handlebars.js
La parte di template è realizzata in HTML5, mentre viene adoperato il framework Bootstrap per la parte grafica.
3.4 - Gli oggetti BMF
Il BMF mette a disposizione una gamma di funzionalità diverse che permettono di fare reportistica e dataentry sulle tabelle del database. Tra le funzionalità disponibili le più importanti permettono di creare dei report in forma tabellare, di utilizzare in alternativa o in aggiunta ai report grafici di vario tipo (es. istogrammi, grafici a torta, grafici lineari ect), di creare dei filtri di ricerca per fare query sui dati, di usare gli input form per fare INSERT o UPDATE su base di dati, di creare dei pulsanti (buttons o group buttons) che diano navigabilità all’applicazione.
Per aggiungere tali funzionalità all’applicazione è necessario creare e configurare i cosiddetti oggetti BMF (report, inputForm, filter ect), tali oggetti vengono configurati in formato json in quanto è facilmente gestibile via javascript ed è anche molto intuitivo per l’operatore finale che sviluppa l’applicazione. Il BMF, inoltre, mette a disposizione un tool per la configurazione guidata dei singoli oggetti, lasciando all’utente più esperto la possibilità di editare direttamente il json di configurazione.
30
Sono diversi gli oggetti messi a disposizione dal framework che possono essere aggiunti all’applicazione permettendo al programmatore di creare delle interfacce dinamiche con cui è possibile visualizzare il contenuto delle basi di dati, applicare dei filtri sulla ricerca dei dati tramite l’uso di parametri e all’occorrenza modificare le tabelle aggiornando dati esistenti o inserendone di nuovi. Gli oggetti più significativi utilizzati per la costruzione delle maschere che costituiscono l’applicazione di cui tratta questo lavoro di tesi sono i report e i filtri. 3.4.1 - Report
L’oggetto report serve per visualizzare le informazioni estrapolate da una base di dati in formato tabellare. In particolare nella configurazione dell’oggetto è presente un campo in cui va inserita la query che il database deve eseguire in cui nella clausola where, oltre alle condizioni statiche che si desidera soddisfare, è presente una speciale condizione del tipo “where/and <condizioni>”. Questo particolare tag viene elaborato lato client per integrare ulteriori condizioni in maniera dinamica qualora si applicassero ad esempio dei filtri di ricerca. {
"type": "report", "report": {
"title": "Lista Azioni", "className":"",
"collapse":"", "customUrlBase":"",
"customization":"datiAudit", "cols": {
"T_ACTION_OID":{"label":"Action OID"},
"EXTENSION":{"label":"EXTENSION (Schema/Table)"}, "ORG":{"label":"ORG (Schema/Table)"},
"T_MODE_ACTION_DEF_DESCR":{"label":"Azione"}, "DATA_AZIONE":{"label":"Data Azione"}, "ORA_AZIONE":{"label":"Ora Azione"}, "NOTE_AZIONE":{"label":"Note informative"} }, "idxs": [ "T_ACTION_OID", "EXTENSION", "ORG", "T_MODE_ACTION_DEF_DESCR", "DATA_AZIONE", "ORA_AZIONE", "NOTE_AZIONE" ] } }
Per quanto riguarda il json di configurazione, le proprietà più importanti e obbligatorie degli oggetti report sono cols e idxs, il primo è un oggetto javascript con all’interno delle coppie chiave-valore in cui per ogni campo della query che deve essere visualizzato (chiave) sono specificate alcune proprietà, come l’etichetta da mostrare nell’intestazione della tabella, sotto forma di oggetto js (valore), mentre il secondo è un vettore contenente l’intero elenco dei campi della query che devono essere mostrati nella tabella.
31 3.4.2 - Filtro
Il filtro è un oggetto che rende dinamica la visualizzazione del report mettendo a disposizione dell’utente dei campi che facoltativamente o obbligatoriamente vengono valorizzati da questo andando così ad aggiungere dinamicamente delle condizioni alla clausola ‘where’ della query presente nell’report modificandone così la risposta da parte della base di dati.
Una volta che i campi sono stati compilati e che la ricerca è stata lanciata i parametri inseriti vengono passati al tomcat dove sono elaborati attraverso una funzione java che genera dinamicamente una query in PLSQL con tutte le condizioni della clausola ‘where’ immesse dall’utente, questa viene inviata alla base di dati la quale risponde restituendo quei record che collimano con le condizioni imposte.
{
"type":"filter", "filter":{
"title":"Ricerca Operatore", "collapse":"N",
"dynamic":"N",
"buttonText":"Avvia Ricerca", "hidden":"", "customization":"filtroAudit", "fields":[ { "id":"FC_AUDIT_FiltroOperatore_id", "name":"FC_AUDIT_FiltroOperatore", "label":"", "session":"N", "default":"", "placeholder":"", "type":"hidden" }, { "id":"T_GU_UTENTE_CODICE_id", "name":"TAB1.T_GU_UTENTE_CODICE", "label":"Codice Operatore", "session":"N", "default":"", "placeholder":"", "type":"text" }, { "id":"T_GU_UTENTE_COGNOME_id", "name":"T_GU_UTENTE_COGNOME", "label":"Cognome Operatore", "session":"N", "default":"", "placeholder":"", "type":"text" }, { "id":"T_GU_UTENTE_NOME_id", "name":"T_GU_UTENTE_NOME", "label":"Nome Operatore", "session":"N", "default":"", "placeholder":"", "type":"text" } ] } }
Qui abbiamo un esempio del json di configurazione di un filtro la cui proprietà più importante è il campo fields, questo è un vettore contenente degli oggetti javascript all’interno dei quali vi sono le specifiche relative a tutti i campi che vogliamo implementare per eseguire il
32
filtraggio dei dati, ad esempio abbiamo l’identificativo (id) dell’elemento HTML che individua univocamente il campo nel DOM, il nome (name) del campo nella query SQL del report su cui è effettuata la ricerca, il tipo (type) di valore che viene immesso che può essere text, select o hidden a seconda che vogliamo sia l’utente ad immettere un valore oppure che debba sceglierne uno da un menu a tendina o ancora qualora vogliamo il campo resti invisibile nella pagina. Il parametro inoltre può essere salvato nella sessione del Tomcat valorizzando con “S” l’attributo session, possiamo indicare l’etichetta del campo da mostrare con label, definire un valore di default oppure mettere un suggerimento nel campo (placeholder). In caso debba contenere una data è possibile settare un'altra proprietà, non presente nell’esempio, chiamata typeObj con il valore “Date”, in questo modo il campo presenterà un oggetto datepicker in cui sarà possibile selezionare una data grazie all’ausilio di un calendario.
Figura 4: esempio campo di tipo Date con calendario
3.4.3 - Template e helpers
Ad ogni oggetto del BMF è associato uno specifico template scritto in linguaggio HTML che definisce l’aspetto che questo deve avere nella pagina web quando viene effettuato il rendering, in cui vengono specificati gli elementi del DOM che costituiscono l’oggetto nella maschera. Questi template presentano delle componenti statiche che devono essere rappresentate nella pagina sempre con le stesse caratteristiche tuttavia alcuni oggetti necessitano della possibilità di generare alcune delle sue componenti in maniera dinamica, nello specifico sulla base del json di configurazione.
Questa costruzione dinamica della pagina è possibile mediante l’ausilio di una specifica libreria javascript chiamata Handlebars.js che mette a disposizione del programmatore una categoria di funzioni chiamati “helpers” che non sono altro che funzioni javascript che possono essere richiamati, permettendo anche il passaggio di parametri, direttamente dal file HTML. Sfruttando dunque gli helpers, dal template vengono passate le proprietà json di
33
configurazione dell’oggetto di cui si vuole fare il rendering e viene così generato dinamicamente il codice HTML che costituirà la maschera.
3.4.4 - Personalizzazione
Il BMF3.x permette all’utente che voglia personalizzare la propria applicazione di creare delle custom view e di arricchire le funzionalità di alcuni oggetti come i report, gli inputForm e i filtri. L’implementazione di tali oggetti è infatti racchiusa in specifici file javascript (.js), andando ad estendere tali oggetti all’interno di un apposito file per la customizzazione (“js/customization/customization.js”) si possono ad esempio aggiungere dei comportamenti personalizzati agli eventi associati ai vari elementi dell’oggetto customizzato.
Queste funzionalità possono essere create in aggiunta a quelle ereditate dal padre oppure possono sovrascrivere le stesse.
//- Personalizzazione per l'esempio filtro
var MyFilter = Filtro.filtroItemView.extend({ events:function() {
//Eredita gli events dalla view originale, dopodichè la estende
return _.extend({}, Filtro.filtroItemView.prototype.events, { 'submit form':'onFormSubmit'
}); },
onFormSubmit:function(){ console.log('prova');
alert("Questa è una personalizzazione!"); returnfalse;
} });
Nel codice di esempio sopra riportato viene esteso l’oggetto Filtro.filtroItemView andando a modificare la sua risposta all’evento di submit associato all’elemento form della pagina sovrascrivendo la sua funzione onFormSubmit che di norma dovrebbe filtrare i dati e costruire il report desiderato, mentre in questa semplice prova tale funzione viene utilizzata per mandare a video un alert. A livello di applicativo, perciò, tale personalizzazione fa sì che quando viene premuto il tasto di ricerca del filtro venga visualizzato “questa è una personalizzazione!” a video.
Grazie a tali personalizzazioni è stato possibile implementare un gran numero di funzioni custom per la realizzazione della web application di cui tratta questo lavoro di tesi.
In generale è possibile personalizzare l’applicazione anche sotto l’aspetto grafico andando ad aggiungere immagini e personalizzando il css in generale, dai colori alla dimensione del testo ect.
34
3.5 - Conclusioni
Alla luce di quanto trattato in questo capitolo si evince come il BMF sia un framework potente e flessibile per la creazione di applicativi semplici, dinamici e adatti in particolare alla visualizzazione di report e all’inserimento di dati su database senza avere necessario bisogno di conoscere linguaggi di programmazione web bensì avendo una buona conoscenza del linguaggio SQL. Il tool è stato infatti pensato proprio per quei programmatori gestori di base di dati che vogliono mettere a disposizione degli utenti applicativi accessibili dal web che diano modo di interagire col sistema da dei punti di accesso sicuri attraverso i protocolli che la rete ha a disposizione, garantendo al contempo ampia flessibilità e usabilità.
35
CAPITOLO 4 - Il Progetto
Il progetto in cui si inserisce questo lavoro di tesi, relativamente al paragrafo 2.4 sulle linee guida in materia di dossier sanitario visto nel capitolo 2 sui sistemi di Cartella Clinica Elettronica (CCE), riguarda la realizzazione del sistema di audit che consente di tracciare e monitorare gli accessi e le operazioni svolte da parte del personale sanitario sulle cartelle cliniche elettroniche dei pazienti, nello specifico dei pazienti presi in cura presso l’ente