Scuola di Ingegneria
Dipartimento di Ingegneria dell’Informazione Corso di Laurea Magistrale in Ingegneria Biomedica
TESI DI LAUREA
Sviluppo di un Sistema di Governo per Azienda Sanitaria
Utilizzando il Biomedical Framework 3.0
Relatore:
Candidato:
Prof. Maurizio Mangione
Giacomo Corridori
Indice
INTRODUZIONE 1 1 IL CONTESTO 2 2 IL SISTEMA DI GOVERNO 4 2.1 Gli obiettivi . . . 5 2.2 Funzionalità . . . 5 2.3 La struttura . . . 63 IL SISTEMA DI WAREHOUSE E DATA BASE 7 3.1 I Data Base . . . 7
3.2 I Data Warehouse . . . 10
3.3 Confronto Data Warehouse e Data Base . . . 12
4 AMBIENTE DI LAVORO 16 4.1 Architettura e Software utilizzati . . . 16
4.1.1 Web Layer . . . 17
4.1.2 Application Layer . . . 18
4.1.3 Database Layer . . . 19
4.1.4 Framework . . . 19
5 SVILUPPO NUOVO SISTEMA DI GOVERNO 22 5.1 Il DataBase . . . 22
5.2 Gli Oggetti del BMF3.0 . . . 24
5.2.1 Il JSON . . . 26
5.2.2 I Report . . . 29
5.2.4 I Grafici . . . 39
5.2.5 Menu Item e Folder . . . 51
5.3 Il progetto . . . 52
5.3.1 Fase 1 . . . 53
5.3.2 Fase 2 . . . 57
5.3.3 Fase 3 . . . 59
5.3.4 Sorveglianza Igiene delle Mani in Ospedale . . . 59
CONCLUSIONI 67 Appendice 72 A Codice JSP . . . 72
Se insisti e resisti raggiungi e conquisti
INTRODUZIONE
Obiettivo di questo lavoro di tesi è lo sviluppo di un’applicazione web per il monito-raggio amministrativo e clinico delle prestazioni di un’azienda sanitaria.
Un simile strumento all’interno di una struttura - non solo di tipo sanitario - consente di agevolare la presa di decisione dei dirigenti in ambito economico e nella gestione delle risorse.
Il Sistema di Governo - così è denominata questa categoria di applicativi - muove i suoi primi passi a partire da una versione precedentemente sviluppata dal personale informatico interno alla Fondazione Toscana Gabriele Monasterio, luogo di redazione di questo lavoro di tesi; la versione preesistente è stata sviluppata tramite l’uso di una piattaforma Java, il Biomedical Framework 2.0 (anch’esso sviluppato internamente al-l’azienda), con cui è possibile realizzare applicativi web.
Successivamente il Biomedical Framework ha raggiunto la versione 3.0, sia per l’esigen-za di uno strumento più performante che per la necessità di sviluppare applicativi più aggiornati, tra cui il Sistema di Governo.
Nei prossimi capitoli sarà quindi illustrata la strategia seguita per il passaggio dal vec-chio al nuovo sistema e le funzionalità chiave del Biomedical Framework 3.0 che sono state utilizzate nel corso della realizzazione. Poiché i dati utilizzati si riferiscono a pazienti reali, lo sviluppo dell’applicativo è avvenuto seguendo le norme vigenti per la tutela della Privacy.
Parole Chiave:
Biomedical Framework, Sistema di Governo, Aggiornamento, Fondazione Toscana Ga-briele Monasterio
Capitolo 1
IL CONTESTO
In questo capitolo si parlerà della Fondazione Toscana Gabriele Monasterio, la realtà in cui il progetto di tesi si è svolto e sviluppato
Questo progetto è stato realizzato grazie alla collaborazione con la Fondazione To-scana Gabriele Monasterio (FTGM), un ente pubblico specialistico del Servizio Sani-tario Regionale (SSR) Regione Toscana. La FTGM lavora e collabora con l’istituto di fisiologia clinica del Consiglio Nazionale della Ricerche (CNR) e numerose università, occupandosi della gestione e dello sviluppo di attività sanitarie specialistiche e di ri-cerca per interesse del SSR Toscana; ha due sedi: a Pisa presso Istituto di Fisiologia Clinica del CNR e a Massa presso l’Ospedale del Cuore G.Pasquinucci.
Dal punto di vista organizzativo la FTGM è suddivisa in quattro dipartimenti principali: • Dipartimento Cardiotoracico • Dipartimento Pediatrico • Dipartimento di Imaging • Area Critica
L’attività assistenziale combina una impostazione specialistica a livello delle com-petenze mediche e chirurgiche con una impostazione per intensità di cure a livello organizzativo, che si esplica in regime di degenza, ambulatoriale, di day hospital e day service. Presso la Fondazione, il paziente è al centro di un sistema multidisciplinare che offre i più moderni e appropriati percorsi preventivi, diagnostico-terapeutici e riabili-tativi, grazie all’elevata preparazione del personale, alla disponibilità delle tecnologie più avanzate per la diagnostica funzionale, d’immagine e di laboratorio, nonché alla
completa informatizzazione delle attività cliniche e di gestione.1
1
Fondazione Toscana Gabriele Monasterio. La Fondazione Toscana Gabriele Monasterio. url: https://www.ftgm.it/index.php/la-fondazione.
Capitolo 2
IL SISTEMA DI GOVERNO
Vedremo ora come l’evoluzione delle aziende sanitarie abbia reso necessario l’utilizzo di uno strumento adeguato per la giusta amministrazione. Saranno quindi mostrati gli obbiettivi e i vantaggi introdotti dall’utilizzo di un Sistema di Governo.
La trasformazione delle strutture sanitarie in aziende dotate di autonomia impren-ditoriale e personalità giuridica, i meccanismi che regolano i finanziamenti strettamente correlati con i servizi prestati e con le tipologie di pazienti, il rispetto dei vincoli di bilancio e dell’equilibrio tra costi e ricavi sono i principali criteri normativi e incentivi che stanno modificando il modo di operare della Sanità Italiana. Nel nuovo quadro normativo-istituzionale che sta andando delineandosi, i responsabili delle strutture sa-nitarie hanno, tra gli altri, un compito fondamentale da assolvere: monitorare in modo puntuale il controllo di costi, rendimenti e risultati al fine di garantire una corret-ta ed economica gestione delle risorse disponibili: in altre parole gestire il “Governo dell’Organizzazione”.
La massima qualità del servizio deve essere garantita in termini di:
• Prestazioni sanitarie erogate;
• Personalizzazione e flessibilità dell’assistenza;
• Diritto all’informazione e prevenzione delle malattie;
• Rispetto degli indicatori di qualità sotto l’aspetto gestionale ed imprenditoriale.
I dirigenti delle strutture sanitarie (responsabili nell’area clinica o nell’area ammi-nistrativa) devono quindi prendere spesso decisioni, correlando tra loro informazioni di sintesi rese disponibili da diverse fonti. Spesso però la valutazione di efficienza dei servizi sanitari richiede decisioni che possono esser prese solo dopo analisi verticali sui casi di studio. Un efficace sistema di controllo di gestione deve provvedere quindi alla possibilità di approfondire le informazioni di sintesi analizzando fino al dettaglio di ogni
singola transazione (sempre nel rispetto dei diritti di privacy sui dati del paziente)1.
2.1
Gli obiettivi
L’applicativo web sviluppato, HMSSDG, è un sistema open source con interfaccia web; una valida soluzione multipiattaforma - utilizzabile da tutti i dispositivi e su qualsiasi
sistema operativo - necessita soltanto di un browser web1. Questo applicativo può
produrre informazioni di governo sia su dati amministrativi che clinici; ha quindi una funzione sia operativa che organizzativa, e finalità di tipo gestionale e decisionale, ponendosi come strumento di supporto nelle decisioni strategiche dell’azienda. Tra le principali funzioni che il Sistema di Governo (SDG) garantisce, troviamo:
• Raccolta e archiviazione di informazioni puntuali, come report di attività e mi-surazione di performance;
• Ricerche ed analisi personalizzate;
• Un sistema personalizzato e configurabile;
• Possibilità di effettuare confronti inter e intrastruttura.
2.2
Funzionalità
Il sistema mette a disposizione numerose funzionalità tramite le quali l’utente riesce in maniera rapida a valutare gli andamenti dell’azienda. Sono messi a disposizione strumenti di confronto dei risultati, di attività o archi temporali diversi, consente anche
1
Mangione M. et al. Sistema di Governo delle organizzazioni sanitarie. 2012. url: http://bmf. ftgm.it/doc.
di confrontare dati interstruttura e, in generale, navigare tra i dati in modo semplice ed efficiente. Le funzionalità messe a disposizione sono:
• Consultazione dei grafici per i trend economici;
• Pianificazione delle attività (ad esempio attraverso calendari);
• Costruzione di report per la determinazione dei costi (ad esempio, per centro di responsabilità) e dei ricavi (ad esempio le tariffe per prestazione);
• Consultazione in real-time dei dati provenienti da CUP2, cartelle cliniche ed
ADT3;
• Costruzione di report per indagini sulle patologie.
2.3
La struttura
Per il recupero dei dati, il SDG si appoggia a un data warehouse di governo, che viene interrogato tramite QUERY, che restituiscono le informazioni utili alla creazione dei report. All’interno del data warehouse di governo convogliano tutti i dati provenienti dai vari data base più piccoli usati dai vari applicativi dell’azienda, tra cui: G2 (che ospita i dati di CUP e ADT) e i LABPI e LABMS (che ospitano i dati di Laboratorio
rispettivamente per Pisa e Massa). Infine, i dati sanitari relativi ai pazienti sono
collocati nei data base denominati C7 e ARCA (anche se quest’ultimo sta venendo lentamente sostituito da C7)
2Centro Unico Prenotazioni, servizio che consente ai cittadini di prenotare online l’accesso ai servizi
sanitari.
3Accettazione/Dimissione/Trasferimento, è il sistema software che consente la gestione dei flussi
Capitolo 3
IL SISTEMA DI WAREHOUSE E
DATA BASE
Il Sistema adopera diversi contenitori per la raccolta dei dati. Essi possono essere di due tipologie data base e data warehouse, che si distinguono per alcune peculiarità. Vedremo adesso cosa differenzia queste due strutture.
3.1
I Data Base
Per lo storage delle informazioni inerenti ai pazienti e ai loro trattamenti, in un’azienda informatizzata, è necessario disporre di un sistema capace di raccogliere, organizzare e conservare i dati. La struttura dove vengono inseriti questi dati è chiamata data base (DB), una sorgente di dati operazionali, nella quale si inseriscono, aggiornano e modificano record continuamente. Possiamo immaginare un DB come una serie di archivi ben strutturati, tali da fornire dati integrati e facilmente reperibili e, se ne-cessario, modificabili. Tra i classici problemi in cui è possibile incorrere ricordiamo la ridondanza dei dati e l’inconsistenza degli archivi. Il primo si verifica quando in diversi archivi sono memorizzati dati dello stesso tipo (in questi casi, il problema maggiore è quello di dover aggiornare contemporaneamente tutti gli archivi interessati). Il secondo si verifica come conseguenza della ridondanza: quando non tutti gli archivi vengono aggiornati, nascono così incongruenze tra dati nuovi e vecchi.
Per la gestione dei DB vengono utilizzati i Data Base Menagement System (DBMS), software progettati per consentire la creazione, la manipolazione e l’interrogazione ef-ficiente di DB; il linguaggio utilizzato è quello standardizzato e si divide in macro gruppi:
• DDL (Data Definition Language): creazione e modificazione degli schemi di database;
• DML (Data Manipulation Language): inseririmento, modificazione e gestio-ne dei dati memorizzati;
• DQL (Data Query Language): interrogazione dei dati memorizzati;
• DCL (Data Control Language): gestione strumenti di controllo e accesso ai dati.
All’interno del DB è possibile distinguere Dati e Metadati. In particolare, i metadati ci forniscono informazioni sulla struttura dei dati. Ad esempio, per una tabella, i metadati ci diranno il nome della tabella e delle sue colonne, quale tipo di dato si può associare a ogni attributo e qual è la sua chiave primaria. Infine, abbiamo il dato, rappresentato dal valore memorizzato record per record : i dati contenuti all’interno del DB sono di diverso tipo, ma comunque accomunati da una correlazione sufficientemente alta.
Figura 3.1: Esempio di metadati per la tabella T_UTENTE
Grazie alla presenza della struttura fornita dai metadati, il DB è accessibile da qualsiasi applicazione capace di interpretarli, questo perché internamente il DMBS, oltre a saper raccogliere i dati, consente la gestione dei record. Il DMBS utilizza un linguaggio strutturato - Structured Query Language (SQL) - caratterizzato da parole chiave. Queste possono essere usate se si vuole modificare la struttura della tabella, così come per inserire o recuperare dati. In particolare, se volessero interrogare i dati (DQL), la struttura standard sarebbe:
Codice 3.1: DQL 1 S E L E C T [ ALL | D I S T I N C T ] l i s t a _ e l e m e n t i _ s e l e z i o n e 2 FROM l i s t a _ r i f e r i m e n t i _ t a b e l l a 3 [ W H E R E e s p r e s s i o n e _ c o n d i z i o n a l e ] 4 [ G R O U P BY l i s t a _ c o l o n n e [H A V I N G C o n d i z i o n e ] ] 5 [ O R D E R BY l i s t a _ c o l o n n e ];
Nella manipolazione dei dati (DML), le tre strutture standard sono: • Inserimento Codice 3.2: DML insert 1 I N S E R T INTO n o m e _ t a b e l l a ( e l e n c o dei c a m p i i n t e r e s s a t i i n s e r i m e n t o ) 2 V A L U E S ( e l e n c o valori , 3 tutti , 4 r i s p e t t a n d o o r d i n e dei c a m p i d i c h i a r a t i s o p r a ) ; • Aggiornamento Codice 3.3: DML update 1 U P D A T E n o m e _ t a b e l l a 2 SET n o m e _ c a m p o 1 = ‘ v a l o r e 1 _ n u o v o ’, 3 n o m e _ c a m p o 2 = ‘ v a l o r e 2 _ n u o v o ’ 4 W H E R E n o m e _ c a m p o 3 = ‘ v a l o r e ’; • Cancellazione Codice 3.4: DML delete 1 D E L E T E 2 FROM n o m e _ t a b e l l a 3 W H E R E n o m e _ c a m p o = ‘ v a l o r e ’;
3.2
I Data Warehouse
Affiancato ai DB abbiamo un unico grande data warehouse (DW), denominato SDG, del quale l’applicazione web si avvale. Al suo interno vengono inseriti numerosi dati utili alla creazione dei report. I DW nascono infatti con lo scopo di essere utilizzati nelle decisioni di marketing da parte delle strutture. Potremmo definire il DW come un set di viste materializzate che integrano i dati operazionali di più sorgenti; il tutto allo scopo
di un analisi per l’estrazione di indicatori sull’andamento reale dell’azienda.1 E per citare la definizione originaria di William H. Inmon, che per primo parlò esplicitamente di data warehouse:
«Il DW è una collezione di dati statici integrati, organizzata per soggetti, che riguardano una serie di fatti accaduti nel tempo e finalizzata al recupero
di informazioni a supporto di processi decisionali2.»
Con la sua definizione Himmon mette in luce le principali proprietà della struttura di un DW.
• Integrità: requisito fondamentale di un DW è l’integrazione dei dati raccolti. Nel DW confluiscono dati provenienti da più sistemi transazionali e da fonti esterne. L’obiettivo dell’integrazione può essere raggiunto percorrendo differenti strade, vale a dire mediante l’utilizzo di metodi di codifica uniformi, l’omogeneità semantica di tutte le variabili e l’utilizzo delle stesse unità di misura;
• Orientamento al soggetto: il DW è orientato a temi aziendali specifici, alle applicazioni o alle funzioni. In un DW i dati vengono archiviati in modo da essere facilmente letti o elaborati dagli utenti. L’obiettivo quindi non è più quello di minimizzare la ridondanza mediante la normalizzazione, ma quello di fornire dati organizzati in modo tale da favorire la produzione di informazioni. Si passa dalla progettazione per funzioni a una modellazione dei dati che consenta una visione multidimensionale degli stessi;
• Variabilità nel tempo: i dati archiviati all’interno di un DW coprono un oriz-zonte temporale molto più esteso rispetto a quelli archiviati in un sistema ope-razionale. Nel DW sono contenute una serie di informazioni relative alle aree di interesse che colgono la situazione relativa a un determinato fenomeno in un determinato intervallo temporale piuttosto esteso. Ciò comporta che i dati con-tenuti in un DW siano aggiornati fino a una certa data che, nella maggior parte dei casi, è antecedente a quella in cui l’utente interroga il sistema. Ciò differisce da quanto si verifica in un sistema transazionale, nel quale i dati corrispondono 1Lechtenbörger J. Data Warehouse Schema Design. Aka, 2001.
sempre a una situazione aggiornata, solitamente incapace di fornire un quadro storico del fenomeno analizzato;
• Non volatilità: tale caratteristica indica la non modificabilità dei dati contenuti nel DW, che consente accessi in sola lettura. Ciò comporta una semplicità di progettazione del database rispetto a quella di un’applicazione transazionale. In tale contesto non si considerano le possibili anomalie dovute agli aggiornamenti, né tanto meno si ricorre a strumenti complessi per gestire l’integrità referenziale o
per bloccare record a cui possono accedere altri utenti in fase di aggiornamento.3
Va notato che, poiché stiamo trattando dati sensibili dei pazienti, è richiesto dal punto di vista legislativo la conservazione dei dati per lunghi periodi, così da poterli consultare in caso di necessità.
Possiamo quindi dire che la creazione di un DW non comporta l’inserimento di nuove informazioni bensì la riorganizzazione di quelle esistenti. Inoltre, esso implica, l’esistenza di un sistema informativo su cui appoggiarsi e dal quale prelevare i dati.
3.3
Confronto Data Warehouse e Data Base
Parlimo ora delle principali differenze tra i due sistemi:
• Mole di dati;
• Durata del dato;
• Manipolazione del dato.
In particolare, nei DW avremo una grandissima mole di dati, direttamente inserita al suo interno prelevandola dai DB a periodi regolari. Questi dati una volta entrati nel DW non vengono più rimossi o modificati: l’utente che interroga i dati può solo visualizzarli. Il trasferimento degli stessi avviene spostando una mole considerevole di dati dai DB. Pertanto, tale operazione viene svolta quando i vari DB non sono operativi, così da non rallentare le operazioni.
Nei DB invece i dati sono inseribili, modificabili o cancellabili dall’utente. Il dato è aggiornato in tempo reale e solitamente consente la consultazione di un breve periodo temporale, poiché i dati più vecchi vengono spostati sul DW e rimossi dal DB.
Figura 3.2: Schema a Stella di un Data Warehouse
Un’altra differenza sta nel processo di normalizzazione, che per i DB è indispensabile
così da evitare problemi di ridondanza dei dati e l’inconsistenza degli archivi. Al
contrario essa non è rilevante nel caso dei DW che invece presentano su diverse viste gli stessi dati. La struttura principale più adoperata per la creazione di un DW è denominata ‘schema a stella’, composto da una tabella centrale (tabella di fatti) alla quale sono collegate più tabelle satellite (tabelle di dimensione). Questa struttura
caratterizza il data mart4. Ciò che si ottiene è un modello a più dimensioni denominato,
per l’appunto, ‘cubo multidimensionale’, grazie al quale l’utente può ricavare i suoi dati con delle QUERY molto semplici.
4Sottoinsiemi del data warehouse, costituiti da selezioni di dati estratti per settore. Il data mart è
Data mart Data warehouse
Dimensioni <100 GB 100 GB o più
Argomento Unico argomento Più argomenti
Portata Unità aziendale Intera azienda
Sorgenti di dati Poche sorgenti Numerosi sistemi sorgente
Integrazione dei dati Una sola area di interesse Tutti i dati aziendali
Tempo di creazione Minuti, settimane o mesi Più mesi o anni
Tabella 3.1: Caratteristiche Data Mart e Data Warehouse5
Figura 3.3: Relazione Data Mart e Data Warehouse6
Data la differente natura dei due sistemi incontriamo anche una sostanziale diffe-renza nelle tecniche software utilizzate, per i DW abbiamo quelle denominate On-Line Analytical Processing (OLAP), mentre per i DB abbiamo le On-Line Transactional Pro-cessing (OLTP). Possiamo sinteticamente racchiudere le principali differenze in questa tabella:
5
Che cos’è un data mart. URL: https://it.talend.com/resources/what-is-data-mart/
OLTP OLAP
Finalità Supporto all’operatività Supporto al processo decisionale
Utenti Molti Pochi
Utilizzo Guidato, per processi e stadi
successivi
Interrogazione ad hoc
Quantità di dati per operazione
Bassa: centinaia di record per
transazione
Alta: milioni di record per ogni query
Qualità In termini di integrità In termini di consistenza
Orientamento Per processo/applicazione Per soggetto
Aggiornamento Continua, tramite azioni Sporadica, tramite funzioni
espli-footfullcite
Copertura
tem-porale
Dati correnti Storica
Ottimizzazione Per accessi in lettura e scrittura
su una porzione di dati
Per accessi in sola lettura su tutta la base di dati
Tabella 3.2: Confronto Software OLTP e OLAP7
Capitolo 4
AMBIENTE DI LAVORO
In questo capitolo presentiamo gli strumenti utilizzati per lo sviluppo dell’applicazione web.
4.1
Architettura e Software utilizzati
La precedente applicazione web era sviluppata con il BMF2.0, uno strumento open source sviluppato all’interno della FTGM, capace di realizzare applicazioni web di-namiche. Con il passare degli anni si è reso necessario l’aggiornamento del sistema ed è stato sviluppato un nuovo BMF: il 3.0, che risulta più versatile, performante e personalizzabile. L’applicativo è capace di gestire uno o più DB, nei quali preleva i
dati richiesti tramite QUERY in linguaggio SQL1. L’utilizzo del BMF è vantaggioso
in quanto ha lo scopo di mettere a disposizione dei tool capaci di semplificare il lavoro dello sviluppatore, che non deve necessariamente conoscere un linguaggio di program-mazione a oggetti per utilizzarlo: l’unica cosa richiesta è la conoscenza approfondida del linguaggio SQL e del framework stesso.
Dal punto di vista del sistema invece per l’utilizzo del BMF è necessario predisporre una piattaforma a tre livelli (Web-Application Server-Database) in grado di eseguire codice Java.
Figura 4.1: Architettura a 3 livelli2
A seguito, analizziamo gli strumenti utilizzati per la gestione di questi 3 livelli.
4.1.1
Web Layer
Questa prima parte è quella con cui l’utilizzatore interagisce, il client tramite il quale si ha l’interazione con il DB. L’utente si interfaccia con una pagina web dalla quale, in base alla mansione che ricopre e dunque al profilo a lui assegnatogli, può effettua-re ricerche, estrareffettua-re dati o inserirli; l’utente può gestieffettua-re in tutto e per tutto i dati in maniera semplice. La Web App funziona su di un browser web, per il nostro studio abbiamo testato Google Chrome, Mozilla Firefox e Opera. Poichè scritta in HyperText Markup Language (HTML), ad ogni modo, la pagina non creerà comunque problemi di visualizzazione nemmeno con altri browser.
2Scalable And Reliable Solution. URL: https://www.faircom.com/products/c-treertg/
4.1.2
Application Layer
Per questo strato è stato utilizzato Apache TomCat 7.0 sviluppato dall’azienda Apache Software Foundation, un software open source capace di implementare Java Servlet,
JavaServer Pages, Java Expression Language e la tecnologia Java WebSocket3.
Figura 4.2: Logo TomCat4
L’Application è il layer che si interpone tra interfaccia web e i dati. Esso svolge l’arduo compito di interpretare le richieste dell’utente e, di conseguenza, di interrogare il DB per restituire le giuste risposte, generando poi le viste da mostrare al richie-dente. Come comunicano tra di loro questi livelli? Si hanno due diversi protocolli: Web-Application e Application-DB.
Partendo dal primo, la parte Web e l’Application comunicano tramite il protocollo TCP-IP utilizzando la porta 8080, che è quella di default del TomCat. L’utente ri-chiede la vista di un certo dato, che l’Application incapsula in un HTML mostrato successivamente sul browser. A seguito delle richieste dell’utente, l’application server interroga i DB, con il quale comunica tramite protocollo SQL*Net utilizzando la porta 1521.
3
Apache Tomcat. url: https://tomcat.apache.org.
4.1.3
Database Layer
Giungiamo infine all’ultimo strato, dove sono conservati i dati. I DB utilizzati in que-sta fase sono Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 dell’azienda Oracle.
Per la gestione del DB ci siamo affidati a SQL Developer, un Integrated development environment (IDE), per lavorare tramite SQL sulle tabelle, le viste e gli indici del da-tabase Oracle (versione 18.3).
Figura 4.3: Logo Oracle 125
All’interno del Data Base oltre alle informazioni di interesse per l’utente è necessario che siano presenti anche le informazioni inerenti al login dei vari utenti, poiché nel momento in cui l’utente effettua il login l’Application controlla nel DB se le credenziali sono corrette e, in caso positivo, avvia la sessione.
4.1.4
Framework
Definita la struttura di base del sistema, rimane da parlare del BMF, è lo strumento che ci consente di definire in modo semplice la vista da fornire all’utente sull’applicativo web.
5Oracle 12 logo. URL:
Come anticipato all’utente sono fornite pagine HTML dall’Application server che poi vengono interpretate dal browser web; le varie pagine sono definite dallo svilup-patore tramite il BMF. Si ha una struttura di base, che è appunto la pagina HTML,
all’interno della quale sono identificati dei <div>6 e delle <section> tramite ID, che
vengono riempite in maniera dinamica tramite codice JavaScript.
Figura 4.4: Logo JavaScript7
Per questo strumento si è rivelato utile comprendere e studiare la programmazione in JavaScript e le su librerie aggiuntive, utilizzate dal sistema per semplificare lo svi-luppo e aggiungere interessanti funzionalità.
Gli Add-On inseriti sono:
• jQuery • Marionette • Backbone • Require • Underscore • Handlebars 6Document Divisions
Figura 4.5: Add-On JavaScript
Per ottimizzare la vista del dato e della pagina viene definito un file Cascading Style Sheets (CSS) che caratterizza l’aspetto dei vari elementi della pagina.
Capitolo 5
SVILUPPO NUOVO SISTEMA DI
GOVERNO
In questo capitolo si presenterà come si è sviluppato l’applicativo. Prima però si in-trodurranno le tabelle presenti nel DB per il funzionamento del nuovo framework e, successivamente, si caratterizzeranno gli oggetti creabili all’interno del BMF3.0. Verrà fatta mansione degli oggetti più utilizzati nella realizzazione di questa tesi, descriven-done i vari attributi.
Poiché gli oggetti creati all’interno del sistema sono migliaia ne verrà riportato soltanto uno a campione per farne comprendere la struttura.
Infine, ripercorreremo le varie tappe dell’iter di realizzazione dell’applicativo.
5.1
Il DataBase
Le principali differenze tra BMF 2.x e 3.0 sono individuabili nella struttura degli oggetti del BMF, mentre la base di dati è rimasta fondamentalmente quella del BMF2.x con l’aggiunta di alcune tabelle necessarie a configurare gli oggetti realizzati mediante il nuovo framework. Le strutture del DB interessate possono essere suddivise in quattro gruppi: Tabelle, Stored Procedure, Viste e Trigger. Vediamole ora in dettaglio con un approfondimento sulle funzioni di ciascuna.
• T_TYPE_OBJECT contiene i tipi di oggetti disponibili per BMF3.x. Da ora
è possibile scegliere tra menu_folder e menu_item in modo da non essere più
dipendete dal nome da assegnare all’oggetto come veniva fatto nel BMF2.x;
• T_OBJECT tabella contenente gli oggetti di configurazione per il frontend in BMF3.x;
• REL_MENU_FRONTEND tabella contenente gli oggetti di tipomenu_folter e
menu_item che definiscono la struttura del menù;
• REL_OBJECT_PROFILO tabella contenente ACL per il frontend BMF3.x, gestisce i i menù visibili per i vari profili.
Le Viste:
• V_MENU_FOLDER contiene i pulsanti di tipomenu_folderper il menù del sito;
• V_MENU_ITEM contiene i pulsanti di tipomenu_itememanu_folderper il menù
del sito, cioè tutto ciò che può partecipare alla composizione del menù;
• V_MENU_FRONTEND contiene i dati necessari per rappresentare il menù del sito;
• V_OBJECT_BMF3 è la vista degli oggetti creati nel BMF3.x;
• V_OBJECTS_PROFILO contiene la vista degli oggetti del BMF3.x per profilo.
Le Stored procedure:
• P_SALVA_OBJECT_BMF3 è una store procedure per inserire o modificare un oggetto di tipo BMF3;
• P_OBJECT_BMF3_SAVE_AS è store procedure per fare il save as di un og-getto di tipo BMF3.
I Trigger:
• TR_OBJECT trigger per inserire in automatico i diritti sugli oggetti BMF3 per il profilo amministratore del sito che, appena crea un nuovo oggetto, si trova automaticamente assegnato.
5.2
Gli Oggetti del BMF3.0
Il BMF3.0 mette a disposizione diverse funzionalità, che permettono di interagire con le tabelle del DB, in particolare ci consentono di estrarre dati (di fare quindi SELECT) e inserire dati nuovi (INSERT oppure UPDATE), il tutto in maniera trasparente al-l’utente che visualizzerà soltanto dei form da riempire oppure delle tabelle. Le due operazioni descritte sono implementabili tramite la creazione di oggetti, report e input form.
Per facilitare la ricerca e la leggibilità dei report vengono usati i filtri, i quali mettono a disposizione i dati alla QUERY avviandone l’esecuzione. Essi forniscono così i dati in maniera dinamica, a seconda dell’input. È lo sviluppatore a fornire i campi per il filtraggio, pertanto i filtri sono definiti a priori.
Infine, quello che serve è poter navigare attraverso la web app. Ciò è reso possibile dai
pulsanti (o bottoni), che possono essere definiti, ad esempio, comegroup_button.
La creazione degli oggetti può essere fatta da DB oppure internamente alla web app. La seconda opzione è più user friendly, in quanto mette a disposizione un input form da compilare in maniera adeguata oppure una creazione guidata che, step-by-step assiste nella creazione dell’oggetto.
Va ricordato comunque che, anche se fatta tramite interfaccia web la creazione del-l’oggetto, non fa altro che inserire un record con le caratteristiche dell’oggetto stesso dentro alla T_OBJECT.
In figura 5.1 è possibile vedere come si presenta l’interfaccia di creazione oggetti sul sito. Si leggono i vari campi da valorizzare: ‘Nome’, ‘Tipo’, ‘Descrizione’, ‘Link’, ‘DB’, ‘Query’. Degno di nota è l’ultimo, denominato ‘JSON Config’. È il campo più importante in quanto esso consente di configurare e personalizzare i vari oggetti BMF; infatti si passa sempre per la creazione di un JavaScript Object Notation (JSON), all’interno del quale vengono definite le informazioni inerenti al tipo di oggetto, i campi su cui lavorare, le varie label, ecc.
Un attributo di rilievo che è possibile definire nel JSON è customization, che può
essere presente oppure no. Se non presente di default esso prende la configurazione base della pagina e delle funzioni dell’oggetto, altrimenti estrae le funzionalità da noi implementate e salvate con il tag richiamato nella personalizzazione. L’utilizzo del JSON è la principale innovazione rispetto al BMF2.x; l’uso di questo strumento, infatti, rende gli oggetti più versatili e facilmente personalizzabili.
5.2.1
Il JSON
Cerchiamo ora di comprendere meglio la compisizione del JSON che come già detto è il cuore della configurazione e delle personalizzazioni dei vari oggetti. Il JSON è un formato ormai ampiamente utilizzato nel processo di incapsulamento di dati e nello
scambio di dati client/server1. Come suggerisce il nome, il formato deriva dal
Ja-vaScript, ma non è dipendente da questo. Infatti, è ormai possibile utilizzarlo con i linguaggi di programmazione più in uso.
Il JSON ha avuto successo nel mondo della programmazione web grazie alla sua ver-satilità e facilità di composizione.
Grazie all’avvento dei linguaggi di scripting è cambiato notevolmente il meccanismo dietro alla navigazione (in origine a seguito di una richiesta HTTP il server generava la pagina consultabile). Ora invece, con la richiesta, è possibile inviare anche un messag-gio al server, sotto forma di JSON che, sul punto di generare la pagina HTML, andrà
a modificare le parti interessate valutando le informazioni inserite nel messaggio.2
A seguire un esempio base di un JSON:
Codice 5.1: Esempio JSON 1 { 2 " Nome ": " G i a c o m o " , 3 " C o g n o m e ": " C o r r i d o r i " , 4 " D a t a _ n a s c i t a ": { 5 " G i o r n o ": 19 , 6 " Mese ": 10 , 7 " Anno ": 1990 8 } , 9 " L i n g u a g g i _ c o n o s c i u t i ": [ " Java " , " J a v a S c r i p t " , " C ++" ] 10 } 1 url: http://www.json.it. 2 url: https://www.json.org/fatfree.html.
Si può facilmente evincere che la struttura del JSON è semplicemente una collezione di coppie nome-valore poste all’interno di due parentesi graffe.
Il JSON è capace di riconoscere alcuni tipi di dato:
• Booleani (true e false)
• Interi, numero in virgola mobile
• Stringhe racchiuse da doppi apici “ ”
• Array (sequenze ordinate di valori, separati da virgole e racchiusi in parentesi quadre [ ])
• Array associativi (sequenze di coppie chiave-valore separate da virgole racchiuse in parentesi graffe { })
• Null
Sulla base delle regole per la scrittura di un JSON di cui sopra, è possibile compi-lare il campo ‘Json config’. L’oggetto inserito dovrà presentare coppie di nome-valore
corrette per poter essere interpretabili dal server. I campi principali del JSON (type,
cols, title, fields, report, ecc.) sono illustrati di seguito a partire dalla §5.2.2. Vediamo un potenziale metodo di definizione del JSON, utile a creare un oggetto del BMF3.0. Nell’esempio si mostra come definire un report con titolo Ricoveri e che mostra due colonne all’utente (Sede *** e Anno ricovero).
Codice 5.2: Esempio JSON Report 1 { 2 " type ": " r e p o r t " , 3 " r e p o r t ": { 4 " t i t l e ": " R i c o v e r i " , 5 " d i s p l a y ": " c o l u m n " , 6 " cols ": { 7 " S _ T I P O _ R I C O V E R O _ D E S C ": { " l a b e l ": " Sede ***" } , 8 " S _ A N N O _ R I C O V E R O ": {" l a b e l ": " Anno r i c o v e r o "} 9 } , 10
11 " t o t a l s ": { 12 " S _ T I P O _ R I C O V E R O _ D E S C ": { " t o t a l ": 0 } 13 } , 14 " idxs ": [" S _ T I P O _ R I C O V E R O _ D E S C " ," S _ A N N O _ R I C O V E R O "] 15 } 16 }
5.2.2
I Report
Una breve descrizione dell’oggetto report, strumento che consente all’utente di con-sultare l’informazione in vista tabellare. Per il corretto funzionamento dell’oggetto dovranno essere ben strutturati la QUERY e il JSON.
La QUERY andrà ponderata e generata in modo tale da estrarre i dati necessari al report. Allo scopo di estrarre i dati richiesti è necessario conoscere la struttura del DB in maniera approfondita, così da poter costruire una QUERY efficace. Successivamente si definisce il JSON, che esplica i campi da mostrare nel report.
Valutando la struttura del JSON report per report possiamo individuare una ricorrenza
nella struttura: typeper indicare il tipo di oggetto e successivamentereportper definire
l’oggetto da configurare. Mostriamo ‘Prestazione per posizione ticket’ report preso a campione dall’applicazione.
Per la generazione del report in Figura 5.2 serve configurare il JSON nel modo seguente:
Codice 5.3: JSON creazione oggetto Report 1 { 2 " type ": " r e p o r t " , 3 " r e p o r t ": { 4 " t i t l e ": " P r e s t a z i o n e per p o s i z i o n e t i c k e t " , 5 " cols ": { 6 " S _ P O S T I C K _ R E G I M E ": { 7 " l a b e l ": " P o s i z i o n e T i c k e t " 8 } , 9 " S _ Q U A N T I T A ": { 10 " l a b e l ": " Q u a n t i t à " , 11 " c l a s s ": " i n t e g e r " 12 } , 13 " S _ Q U A N T I T A _ P E R C ": { 14 " l a b e l ": "%" , 15 " c l a s s ": " p e r c e n t a g e " 16 } , 17 " S _ I M P O R T O ": { 18 " l a b e l ": " I m p o r t o " , 19 " c l a s s ": " n u m e r i c " 20 } , 21 " S _ I M P O R T O _ P E R C ": { 22 " l a b e l ": "%" , 23 " c l a s s ": " p e r c e n t a g e " 24 } 25 } , 26 " t o t a l s ": { 27 " S _ I M P O R T O ": { 28 " t o t a l ": 0 29 } , 30 " S _ Q U A N T I T A ": { 31 " t o t a l ": 0
32 } 33 } , 34 " c a l c s ": { 35 " S _ Q U A N T I T A ": [{ 36 " col ": " S _ Q U A N T I T A _ P E R C " , 37 " type ": " perc " 38 }] , 39 " S _ I M P O R T O ": [{ 40 " col ": " S _ I M P O R T O _ P E R C " , 41 " type ": " perc " 42 }] 43 } , 44 " idxs ": [" S _ P O S T I C K _ R E G I M E " , " S _ Q U A N T I T A " , " S _ Q U A N T I T A _ P E R C " , " S _ I M P O R T O " , " S _ I M P O R T O _ P E R C "] 45 } 46 }
Si individua immediatamente la struttura ricorrente,‘type’:‘report’, successivamente
ci sono altri campi di interesse: cols con la sequenza di valori, da prelevare dalla
QUERY, label definisce l’etichetta da associare alla colonna, idxs riporta l’ordine
delle colonne da mostrare e calcs utile se si vuole calcolare la percentuale relativa
alla colonna. Valutando la QUERY, sempre utile alla creazione del report precedente, possiamo riscontrare una corrispondenza tra i campi estratti e quelli riportati nel JSON. Questo riportato di seguito è il codice SQL per l’estrazione dei dati.
Codice 5.4: QUERY per dati Report 1 S E L E C T * 2 FROM 3 (S E L E C T ‘ < a href ="# d i s p a t c h e r / i d O b j e c t = V _ A t t i v i t a V a l i d a t o P r e s t E D e t t & n a m e 1 = S _ P O S T I C K _ R E G I M E & v a l u e 1 = ’ || S _ P O S T I C K _ R E G I M E || ‘ " > ’ || S _ P O S T I C K _ R E G I M E ||‘ </ a > ’ AS S _ P O S T I C K _ R E G I M E , 4 SUM( S _ Q U A N T I T A ) S _ Q U A N T I T A ,
5 SUM( S _ I M P O R T O ) S _ I M P O R T O 6 FROM S _ V A L I D _ A T T I V I T A _ P R E S T _ E 7 W H E R E S _ A N N O = < P _ A n n o _ I n i z i o > 8 AND S _ M E S E D A L >= < P _ M e s e _ I n i z i o _ D a l > 9 AND S_MESEAL <= < P _ M e s e _ I n i z i o _ A l > 10 AND E X I S T S 11 (S E L E C T 1 12 FROM r e l _ u t e n t e _ a l b e r o 13 W H E R E t _ a l b e r o _ c o d i c e = V _ r e p _ c o d i c e 14 AND t _ a l b e r o _ t i p o _ c o d i c e = < a l b e r o T i p o C o d i c e > 15 AND v _ u t e n t e _ c o d i c e = < c o d U t e n t e >) 16 AND < c o n d i z i o n i > 17 G R O U P BY S _ P O S T I C K _ R E G I M E ) 18 O R D E R BY S _ I M P O R T O DESC
Capiamo, quindi, come QUERY e JSON, nonostante siano due oggetti distinti, vadano definiti l’uno in relazione dell’altro.
Riportiamo infine tutti i possibili attributi presenti nel JSON per definire un report (si contrassegnano con un * i campi obbligatori):
• title: definisce il titolo da assegnare alla tabella;
• titleClassName: da inserire il css da legare al titolo (la classe css deve essere correttamente inserita nel file myCustomization.css);
• collapse: (S/N) attributo che ha senso usare in caso di data entry in quanto permette di "chiudere" il report in caso di selezione del record;
• className: esprime uno stile custom, se non definito viene impostato il valore di default che definisce la grafica standard del framework;
• customUrlBase: se per il recupero dei dati non si vuole utilizzare il servizio standard del BMF ma si vuole invocare qualcosa ad hoc è possibile specificare qui l’url da invocare. Ovviamente il json che deve restituire deve essere conforme alla struttura standard altrimenti la visualizzazione dei dati non potrà funzionare regolarmente;
• display: se valorizzato con column verrà utilizzata la visualizzazione per colonna altrimenti se non definito quello a tabella tradizionale;
• cols*: hash map3 che contiente tutti i campi che si vogliono gestire nel report.
La chiave del hash è data dal nome del campo poi internamente ad ogni campo è possibile definire:
– label: etichetta da impostare per la colonna, se non definito viene usato il nome del campo;
– orderBy: indica se si vuole impostare l’order by nella colonna, il campo può essere S/N;
– class: definisce il tipo di dato da rappresentare, al momento può essere integer per gli interi, numeric per i valori con la virgola oppure se assente il dato viene gestito come stringa.
• totals: hash map che contiene tutti i campi di cui si vuole calcolare il totale. Anche in questo caso la chiave del hash è data dal nome del campo;
• calcs: hash map che contiene tutti i campi calcolati, al momento è disponibile solo la percentuale ma in modo analogo in futuro potranno essere configurati altri possibili campi calcolati. Anche in questo caso la chiave del hash è data dal nome del campo su cui si vuole attuare il campo calcolato. Per definirlo sarà obbligatoriamente necessario definire:
– col: indica il nome della colonna adibita a contenere il campo percentuale;
– type: indica la formula da applica, per adesso è possibile definire solo perc
che sta per percentuale.
• idxs: vettore contente i nomi dei campi da visualizzare nella tabella nell’ordine indicato (la posizione nel vettore da l’ordine del report). I nomi indicati sono i nomi dei vari campi che compongono il risultato della QUERY. Se tale vettore non viene specificato verrà inizializzato posizionando i campi nell’ordine in cui si trovano nella query.
5.2.3
I Filtri
L’utente ha necessità di uno strumento che faciliti la gesitione della ricerca all’interno
dei report: tale strumento è il filtro. Esso si presenta come un insieme di campi
compilabili con valori liberi o suggeriti, che vengono poi forniti alla QUERY in modo tale da filtrare i dati secondo i criteri selezionati dall’utente.
Procediamo ora con una breve descrizione dell’oggetto filtro, prendendo come esempio quello applicabile per la ricerca e la creazione del report di cui sopra. Partendo dalla QUERY è possibile identificare le parti comprese tra le parentesi indicate <> che, se presentano un identificativo proprio, ad esempio <alberoTipoCodice>, sono parametri che vengono salvati in sessione e quindi possono essere utilizzati anche per ricerche successive, fino alla cancellazione della sessione. Invece, <condizioni> è una parola chiave: essa serve a prelevare i parametri inseriti nel filtro, ma non in sessione e li utilizza per eseguire la QUERY. Da notare che nel momento in cui lo sviluppatore definirà dei parametri in sessione, l’utente sarà tenuto a riempire i campi del filtro associati, poiché esplicitati nella QUERY.
Spostiamo ora l’attenzione sul JSON. Come per tutti gli oggetti JSON di configurazione
il primo attributo da definire ètype, che introdurra, in questo caso, il filtro. L’elemento
filterindica appunto la configurazione del filtro stesso.
Codice 5.5: JSON creazione oggetto Filter 1 { 2 " type ": " f i l t e r " , 3 " f i l t e r ": { 4 " t i t l e ": " A t t i v i t à " , 5 " f i e l d s ": [{ 6 " id ": " P _ A n n o _ I n i z i o _ i d " , 7 " name ": " P _ A n n o _ I n i z i o " , 8 " l a b e l ": " Anno " , 9 " s e s s i o n ": " S " , 10 " d e f a u l t ": "" , 11 " p l a c e h o l d e r ": " - - -" , 12 " type ": " s e l e c t " , 13 " s e l e c t ": {
14 " i d O b j e c t ": " S _ A n n o " 15 } 16 } , 17 { 18 " id ": " P _ M e s e _ I n i z i o _ D a l _ i d " , 19 " name ": " P _ M e s e _ I n i z i o _ D a l " , 20 " l a b e l ": " Da " , 21 " s e s s i o n ": " S " , 22 " d e f a u l t ": "" , 23 " p l a c e h o l d e r ": "" , 24 " type ": " s e l e c t " , 25 " s e l e c t ": { 26 " i d O b j e c t ": " S _ M e s e " 27 } 28 } , 29 { 30 " id ": " P _ M e s e _ I n i z i o _ A l _ i d " , 31 " name ": " P _ M e s e _ I n i z i o _ A l " , 32 " l a b e l ": " Al " , 33 " s e s s i o n ": " S " , 34 " d e f a u l t ": "" , 35 " p l a c e h o l d e r ": "" , 36 " type ": " s e l e c t " , 37 " s e l e c t ": { 38 " i d O b j e c t ": " S _ M e s e " 39 } 40 } , 41 { 42 " id ": " a l b e r o T i p o C o d i c e _ i d " , 43 " type ": " h i d d e n " , 44 " name ": " a l b e r o T i p o C o d i c e " , 45 " s e s s i o n ": " S " , 46 " d e f a u l t ": 1 47 }
48 ] ,
49 " b u t t o n T e x t ": " R i c e r c a " 50 }
51 }
Anche in questo caso JSON e QUERY sono definiti tenendo presente i campi su cui agire, poiché è necessaria una corrispondenza. In questo caso, abbiamo tre campi vi-sualizzati dall’utente e a partire dai quali potrà filtrare la ricerca. Tutti i campi inseriti
verranno salvati in sessione, ‘session’:‘s’, utilizzando il nome (name) assegnatogli.
L’oggetto sopra definito genera il filtro mostrato in Figura 5.3, che una volta compilato ed eseguita la ricerca restituisce il report di Figura 5.2.
A seguire, gli attributi disponibili per l’oggetto filter (tutto ciò che è marcato con *
è obbligatorio):
• type*: nome della tipologia di oggetto che vogliamo creare (select, hidden, text);
• name*: nome del campo. (usato per comporre successivamente la QUERY);
• collapse: indica se una volta fatto il submit del pulsante di ricerca, il filtro debba essere ridotto a icona;
• hidden: indica se una volta fatto il submit del pulsante di ricerca il filtro debba essere reso invisibile;
• session: indica se il parametro va gestito come parametro in sessione oppure utilizzato per comporre una condizione sql;
• default: indica il valore di default da impostare;
• label: etichetta descrittiva del campo che stiamo rappresentando (se non
valo-rizzato viene usato il valore inserito in name);
• placeholder: mostra un valore fittizio nello spazio selezionabile;
• id: identificativo univoco a livello di JavaScript, se non valorizzato il sistema lo imposta di default a <name>_id;
• operator: indica l’operatore da utilizzare nella composizione della condizione
della QUERY (valido solo se il campo è definito comesession = false). Può
as-sumere i seguenti valori: contains, equal, starts, ends, icontains, iequal,
istarts, iends, >, <, >=, <=. Di default, se non definito, viene
valoriz-zato come =. Gli operatori contains, equal, starts, ends ragionano in case
sensitive mentre i rispettivi icontains, iequal, istarts, iends non lo sono.
Figura 5.3: Esempio di Filtro BMF3
Poniamo ora l’attenzione sull’attributo dynamic nella configurazione di filter,
op-zionale e può essere omissibile. Se valorizzato a S, viene data la possibilità di scegliere le colonne da visualizzare nel report che si genera. Al momento della visualizzazione del filtro vengono forniti una serie di checkbox che mostrano le colonne definite nell’og-getto report. Prima di eseguire la ricerca è possibile selezionare le colonne di interesse. Se non ne viene selezionata alcuna di default, viene visualizzato tutto il report (fun-zionalità utilizzabile solo in presenza di un unico report per pagina).
5.2.4
I Grafici
Per facilitare la lettura dei dati da parte dell’utente è comodo affiancare al report, un grafico, decisamente più esplicativo e immediato. Per la realizzazione dei grafici all’interno del modulo di reportistica BMF3 ci si avvale della libreria Google Charts poiché è gratuito, di semplice integrazione e ricca di tipologie di grafici. Vediamo dunque come configurare un grafico.
I grafici a disposizione nel BMF sono:
• pie (grafico a torta);
• bar (grafico a barre);
• column (equivalente del grafico a barre ma con una visualizzazione verticale);
• histogram (istogramma);
• line (grafico x/y);
• gauge (tachimetro).
Fatta eccezione per l’ultimo, che segue una logica completamente differente dagli altri, i rimanenti si configurano tutti nello stesso modo.
Gauge/Tachimetro
Il grafico ‘tachimetro’ è diverso da tutti gli altri e richiede, pertanto, una diversa con-figurazione.
Codice 5.6: JSON creazione oggetto Tac Chart 1 { 2 " type ": " c h a r t " , 3 " c h a r t ": { 4 " t i t l e ": { 5 " l a b e l ": "( R i c a v i / C o s t i ) ;0 ,210; Allarme ,0 ,100 , RED ; A t t e n z i o n e ,100 ,110 , Y E L L O W ; Normale ,110 ,210 , G R E E N ;" 6 } , 7 " type ": " Tac " , 8 " d a t a T a c ": { 9 " l a b e l ": "% R / C " , 10 " f i e l d ": " I N D I C E " , 11 " min ": "0" , 12 " max ": " 2 1 0 " 13 } , 14 " a l a r m T a c ": { 15 " c o l o r ": " red " , 16 " from ": 0 , 17 " to ": 100 18 } , 19 " a l e r t T a c ": { 20 " from ": 101 , 21 " to ": 109 22 } , 23 " n o r m a l T a c ": { 24 " from ": 110 , 25 " to ": 210 26 } 27 } 28 }
Anche all’interno di questo oggetto è presente type, che indica appunto, per
l’ap-punto, che stiamo configurando un grafico, mentre l’elemento chart, identifica la
con-figurazione del grafico stesso.
Figura 5.5: Esempio di Tachimetro BMF3
Il tachimetro è utile per rappresentare dati sulla base di specifiche soglie di interesse definite dallo sviluppatore, la Figura 5.5, in particolare, riporta in valore percentuale il rapporto ricavi-costi. È lo sviluppatore che definisce i limiti, individuabili nel JSON
dagli attributi,alertTac,alarmTacenormalTac. Il dato estratto viene dunque
confron-tato con le soglie e ci viene mostrato il grafico.
Passiamo a descrivere i singoli elementi della configurazione (tutto ciò che è marcato con * è obbligatorio):
• title: titolo. Può contenere i seguenti tre attributi (al momento questo campo ancora non è gestito dalla libreria di Google quindi, anche se inserito, non ha effetto);
– label → titolo da assegnare al grafico;
– fontSize → dimensione del font del titolo, che è un dato di tiponumeric; – color → colore da assegnare al titolo.
• widh: largezza del grafico che è un dato di tipo numeric;
• heigh: altezza del grafico che è un dato di tiponumeric;
• dataTac*: oggetto che serve a indicare la composizione dei dati del grafico. In funzione di questo, si definiranno più grandi o strette le zone evidenziate in diverso colore;
– label*: etichetta;
– field*: campo della QUERY da legare come valore di posizionamento del
grafico (è un valore numeric);
– min*: valore minimo possibile (è un valore numeric);
– max*: valore massimo possibile (è un valore numeric);
– dynamic: indica se la label è fissa oppure è dinamica e se si è ottenuta
come valore della QUERY come per il valore. In questo caso se la QUERY restituisce più record verranno creati tanti gauce queste sono le label, il valore del campo può essere N/S. Se non definito, il grafico si intende non dinamico.
• alarmTac*: oggetto che descrive il range di allarme;
– color: colore assegnato al range;
– from*: valore di partenza soglia di allarme (valore di tipo numeric);
– to*: valore di arrivo soglia di allarme (valore di tipo numeric).
• alertTac*: oggetto che descrive il range di attenzione;
– color: colore da assegnato al range;
– from*: valore di partenza soglia di attenzione, valore di tipo numeric;
– to*: valore di arrivo soglia di attenzione, valore di tipo numeric.
• normalTac*: oggetto che descrive il range di normalità;
– color: colore da assegnare al range;
– from*: valore di partenza soglia di normalità, valore di tipo numeric;
Altri Grafici
Come per il caso precedente riportiamo un esempio di configurazione, anche questo presente su SDG. In realtà la configurazione che vedremo è valida per tutti gli altri grafici indicati in questa sezione. Nello specifico l’esempio riportato genererà un grafico a torta (Pie), questa tipologia richiede sull’asse X le label da assegnare ai vari valori e sull’asse Y i valori restituiti dalla QUERY.
Codice 5.7: JSON creazione oggetto Pie Chart 1 { 2 " type ": " c h a r t " , 3 " c h a r t ": { 4 " t i t l e ": " P r e s t a z i o n i per p o s i z i o n e t i c k e t " , 5 " type ": " Pie " , 6 " x a x i s ": { 7 " l a b e l ": " Tipo " , 8 " f i e l d ": " S _ P O S T I C K _ R E G I M E " 9 } , 10 " s e r i e s ": [{ 11 " l a b e l ": " R i c o v e r i " , 12 " f i e l d ": " S _ Q U A N T I T A " 13 }] 14 } 15 }
Come per gli oggetti precedenti descriviamo in dettaglio gli attributi disponibili:
• title: titolo del grafico. Può contenere i seguenti tre attributi;
– label: titolo assegnato al grafico;
– fontSize: dimensione del font del titolo (valore di tipo numeric);
– color: colore assegnato al titolo.
• widh: largezza del grafico (numeric);
• type*: indica la tipologia di grafici e può assumere valori:
Bar, Pie, Line, Area, Column, Histogram, Donut, Candle, BoxPlot;
• fontSize: dimensione del font delle assi X/Y e legenda (è un valore di tipo numeric);
• legend: se valorizzato a N viene omessa la legenda. Se valorizzato a S o se non è presente, la legenda compare;
• seriesColors: palette dei colori attraverso cui è possibile personalizzare le varie serie e nel caso in cui i colori preimpostati dalla libreria google non vadano bene;
• geo*: oggetto contenente gli attributi necessari per configurare il Geo Chart, obbligatorio solo per perquesto tipo di grafico:
– region*: indica la regione rappresentata nel grafico. Se volessimo rappre-sentare le regioni d’Italia, sarà sufficiente valorizzarlo con IT mentre, se si volesse rappresentare l’Europa, con ‘150’. Per maggiori dettagli sui valori possibili da assegnare a tale valore si fa riferimento alla documentazione dei Geo Google Charts visto che viene utilizzata questa libreria;
– resolution*: indica il tipo di rappresentazione desiderata. Nel caso delle
regioni dovrà essere valorizzata con provinces mentre se vogliamo
rappre-sentare gli stati con countries;
– colors: contiene la palette dei colori;
– displayMode: indica il tipo di rappresentazione e, può assumere valori (regions, omarkers).
• xaxis*: oggetto che definisce l’asse X ;
– label*: etichetta che identifica l’asse X ;
– field*: campo della QUERY da usare per popolare tale asse del grafico.
• series*: oggetto che definisce le possibili serie legate alle etichette del grafico;
– label*: etichetta la serie;
• style: colore da assegnare alla serie/etichetta;
• annotation: annotazione da assegnare alla serie/etichetta;
• dynamic: indica se la label è fissa oppure è dinamica e se si ottiene come valore della QUERY, così come per il valore field.
Figura 5.6: Esempio di diagramma a torta BMF3.0
Osservando la QUERY vediamo che non è molto diversa, nella struttura, da quella definita per il report. La differenza sostanziale, infatti, sta nel JSON che definisce l’oggetto da generare.
Codice 5.8: QUERY per dati Pie Chart 1 S E L E C T SUM( S _ Q U A N T I T A ) S _ Q U A N T I T A , 2 S _ P O S T I C K _ R E G I M E 3 FROM S _ V A L I D _ A T T I V I T A _ P R E S T _ E 4 W H E R E S _ A N N O = < P _ A n n o _ I n i z i o > 5 AND S _ M E S E D A L >= < P _ M e s e _ I n i z i o _ D a l > 6 AND S_MESEAL <= < P _ M e s e _ I n i z i o _ A l > 7 AND E X I S T S 8 (S E L E C T 1 9 FROM R E L _ U T E N T E _ A L B E R O 10 W H E R E T _ A L B E R O _ C O D I C E = V _ r e p _ c o d i c e 11 AND T _ A L B E R O _ T I P O _ C O D I C E = < a l b e r o T i p o C o d i c e >
12 AND V _ U T E N T E _ C O D I C E = < c o d U t e n t e >) 13 AND < c o n d i z i o n i >
Geo Chart
Per i grafici di tipo Geo è obbligatorio esplicitare l’oggetto geo. Fra i suoi quattro
attributi due sono necessari: region eresolution.
La struttura dell’oggetto Geo sarà dunque:
Codice 5.9: Esempio JSON Geo Chart 1 " geo ": { 2 " r e g i o n ": " IT " , 3 " r e s o l u t i o n ": " p r o v i n c e s " , 4 " c o l o r s ": [" o r a n g e " , " red "] , 5 " d i s p l a y M o d e ": " r e g i o n s " 6 }
L’attributo regionindica il tipo di geo-mappa da rappresentare. Se volessimo
rap-presentare le regioni italiane andrà inserito il tag IT, per la Francia FR e così via (si fa riferimento allo standard ISO 3166-1 alpha-2 codes, codifica per la rappresentazione delle regioni). Nel caso invece volessimo rappresentare macro-aree come l’Europa e l’Africa (rispettivamente 150 e 002) si raccomanda di consultare i dettagli
nell’apposi-ta libreria Google Charts. L’altro attributo obbligatorio, resolution, può assumere i
valoricountrieseprovinces. Esso va sempre definito in relazione all’attributoregion.
Ed è la combinazione dei due attributi, region e resolution, che porta alla corretta
rappresentazione del grafico. Per cui, come nell’esempio, se volessimo proiettare le
re-gioni d’Italia sarà necessario valorizzarlo con provinces mentre per gli stati d’Europa
Figura 5.7: Esempio di grafico Geo BMF3.0
L’attributo displayMode indica il tipo di rappresentazione che si vuole realizzare,
se si desidera colorare l’intera regione all’interno delgeo chart dovrà essere valorizzata
con regions (oppure è possibile non definire proprio l’attributo visto che di default è regions). In altrernativa si scelgamarkersse si descrivere una rappresentazione a place markers.
Per ottenere una vista come quella in Figura 5.7 il JSON sarà così strutturato:
Codice 5.10: JSON creazione oggetto Geo Chart 1 { 2 " type ": " c h a r t " , 3 " c h a r t ": { 4 " type ": " Geo " , 5 " t i t l e ": { 6 " l a b e l ": " A t t r a z i o n e a t t i v i t à per r e g i o n e " , 7 " c o l o r ": " # 0 0 0 0 0 0 " 8 } , 9 " geo ": { 10 " r e g i o n ": " IT " , 11 " r e s o l u t i o n ": " p r o v i n c e s " ,
12 " c o l o r s ": [ " # 8 0 bfff " , " # 0 0 5 9 b3 "] 13 } , 14 " w i d t h ": "1000" , 15 " x a x i s ": { 16 " l a b e l ": " R e g i o n i " , 17 " f i e l d ": " T _ R E G I O N E _ A L I A S " 18 } , 19 " s e r i e s ": [{ 20 " l a b e l ": " R i c o v e r i " , 21 " f i e l d ": " S _ Q U A N T I T A " 22 }] 23 } 24 }
I campi T_REGIONE_ALIAS e S_QUANTITA sono ottenuti tramite QUERY, mo-strata successivamente. Nella compilazione della QUERY si deve prestare particolare attenzione al campo T_REGIONE_ALIAS, poiché per il corretto funzionamento si deve seguire la codifica ISO 3166_2.
Codice 5.11: QUERY per dati Geo Chart 1 S E L E C T T _ R E G I O N E _ A L I A S , 2 SUM( NVL ( S _ Q U A N T I T A , 0) ) S _ Q U A N T I T A 3 FROM S _ V A L I D _ A T T R A Z I O N E _ R I C , 4 T _ R E G I O N E 5 W H E R E S _ R E G I O N E _ C O D I C E = t _ r e g i o n e _ c o d 6 AND S _ A N N O = < P _ A n n o _ I n i z i o > 7 AND S _ M E S E D A L >= < P _ M e s e _ I n i z i o _ D a l > 8 AND S_MESEAL <= < P _ M e s e _ I n i z i o _ A l > 9 AND E X I S T S 10 (S E L E C T 1 11 FROM r e l _ u t e n t e _ a l b e r o 12 W H E R E T _ A L B E R O _ C O D I C E = V _ r e p _ c o d i c e 13 AND T _ A L B E R O _ T I P O _ C O D I C E = < a l b e r o T i p o C o d i c e > 14 AND V _ U T E N T E _ C O D I C E = < c o d U t e n t e >)
15 AND < c o n d i z i o n i > 16 G R O U P BY T _ R E G I O N E _ A L I A S , 17 T _ R E G I O N E _ C O L O R E , 18 S_TITOLO , 19 S _ R E G I O N E _ C O D I C E , 20 S _ R E G _ N O M E , 21 S _ R E G I M E _ C O D I C E
5.2.5
Menu Item e Folder
Rimane da mostrare come navigare tra i vari menù. Gli oggetti adibiti, in questo caso,
sono imenu_item e i menu_folder. La configurazione di questi oggetti è molto semplice
per la parte JSON in quanto va solo definita l’etichetta ed eventualmente la classe CSS da impostare per un eventuale personalizzazione.
Codice 5.12: JSON oggetto menu_item o menu_folder con e senza CSS 1 { " l a b e l " : " A t t r a z i o n e " ," c l a s s N a m e " : " r e d B o l d "}
1 { " l a b e l " : " A t t r a z i o n e "}
La classe css deve essere correttamente inserita nel file myCustomization.css.
Figura 5.8: Esempio di menu_item e menu_folder BMF3
Nel caso si voglia collegare un evento al click, si dovrà definire il link e inserirelo nel campo Link apposito:
Codice 5.13: Campo link
1 # d i s p a t c h e r / i d O b j e ct = F C _ A t t r a z i o n e V a l i d a t o & i d O b j e c t =
T R E E _ A t t r a z i o n e V a l i d a t o & i d O b j e c t = V _ A t t r a z i o n e V a l i d a t o & tree = S
La differenza fra menu_item e menu_folder sta nella definizione dell’attributo link
5.3
Il progetto
In questa sezione andremo a ripercorrere gli step seguiti per la realizzazione dell’appli-cazione web così come è ad oggi.
Per lo sviluppo, ci siamo avvalsi della collaborazione della Dott.ssa Gianna Alberini,
la sviluppatrice del BMF3.0, che ci ha guidato nelle varie fasi. Come prima cosa
abbiamo delle linee guida da seguire, suddivise in tre fasi utili per il corretto sviluppo della web app.
L’idea di fondo è stata quella di mantenere la struttura del vecchio SDG ponendo attenzione, però, soltanto agli oggetti realmente in uso nel sistema. Si è rigenerato menù, grafici, etichette ecc. in modo più conforme possibile alla vecchia versione, così da non influire sull’esperienza dell’utente.
Vediamo come è stata impostata la tabella di marcia:
• FASE 1:
– Abbiamo verificato quali menù vengono effettivamente utilizzati nel SDG in produzione.
– Sono stati generati dei nuovi oggetti e analizzati quelli già esistenti.
– È seguita la verifica delle funzionalità presenti sul vecchio SDG vecchio affinchè fossero nella nuova versione.
– È stato dunque verificato che i report tra SDG differenti fornissero gli stessi risultati.
• FASE 2:
– Dopo aver creato tutti i menù necessari abbiamo controllato la profilazione.
• FASE 3:
– Terminati i profili, sono stati associati a tutti gli utenti abilitati all’uso del vecchio SDG i diritti di accesso per poter utilizzare il nuovo.
(a) Login BMF3.0 (b) Login BMF2.X Figura 5.9: Confronto schermate di Login
5.3.1
Fase 1
Come vediamo la prima fase è suddivisa in sottofasi che abbiamo svolto in sequenza. Iniziamo analizzando la prima: la verifica dei vecchi menù. Per questa, è stato neces-sario estrarre una lista dei menù in uso tra gli utenti e per poi cerare di capire quali degli oggetti fosse necessario ricreare sul nuovo SDG.
L’estrazione di queste informazioni è stata semplice dato che su DB, in una tabella dedicata, la T_LOGGING, sono scritte le operazioni svolte dai vari operatori così da poterne tenere traccia. Quindi, fissato un periodo temporale da analizzare (che in que-sto caso è stato circa un anno) tramite QUERY è stato facile individuare estrarre gli utenti attivi e i menù utilizzati.
Codice 5.14: QUERY estrazione utenti e URL 1 S E L E C T D I S T I N C T T _ L O G G I N G _ L O G I N , 2 T _ L O G G I N G _ U R L 3 FROM T _ L O G G I N G 4 W H E R E T _ L O G G I N G _ D A T A >= T O _ D A T E (‘ 0 1 / 0 1 / 2 0 1 8 0 0 : 0 0 : 0 0 ’, ‘ DD / MM / YYYY HH24 : MI : SS ’) 5 O R D E R BY T _ L O G G I N G _ L O G I N
Le informazioni estratte dalla QUERY sono due: T_LOGGING_LOGIN, che iden-tifica l’utente loggato, e T_LOGGING_URL, che individua l’url utilizzato, il quale riporta al suo interno l’oggetto con cui l’utente interagisce. Di conseguenza, reso noto l’url, possiamo visualizzare le operazioni e gli oggetti in uso. A partire dai dati estratti si è stilata una lista dei menù da riproporre. Una volta individuati i menù siamo pas-sati alla sottofase due, cioè la creazione dei vari oggetti necessari per la riproduzione delle viste. Come anticipato in generale si è cercato di mantenere la stessa struttura delle viste della versione precedente. In alcuni casi però, grazie al nuovo BMF siamo riusciti a rendere la vista più snella. Tra le migliorie apportate, citiamo la sostituzione dei sottotitoli, che ora mostrano gli stessi dati all’interno del breadcrumbs e della vista del filtro, rendendo la visualizzazione più pulita e il sito più navigabile.
(a) Sottotitolo BMF2.0
(b) Breadcrumbs BMF3.0
Altro elemento di innovazione è l’utilizzo del carousel per la visualizzazione delle immagini, che in precedenza richiedevano invece la creazione di una pagina HTML dedicata dove inserirle.
Figura 5.11: Esempio di carousel
Il carousel è posizionato in testa alla pagina ed è scorrevole, il che consente di visualizzare una o più immagini senza dover cambiare pagina o uscire dalla vista del report.
Per la creazione degli oggetti abbiamo seguito le direttive illustrate negli esempi dei paragrafi precedenti. Le uniche che differiscono sono ovviamente le QUERY (che sono specifiche per ogni oggetto) e di conseguenza il JSON (per la definizione dei campi). La terza e quarta sottofase sono state portate a termine in concomitanza con la seconda, poiché il controllo dell’allineamento e delle funzionalità disponibili dei vari menù è stato svolto progressivamente. Al termine della prima fase la struttura dell’applicativo era definita e ben funzionante. Diamo però uno sguardo alla struttura realizzata, che ricalca quella del SDG precedente.
Sono stati definiti i menu_folder:
• Attività sanitaria;
• Indicatori rischio clinico;
• Controllo di gestione;
• Top Ten;
• Dizionari.
All’interno di questi, che sono i primi menù con cui l’utente può interagire, si trovano gli strumenti (sottomenù, report, grafici) necessari per gli studi amministrativi. La suddivisione in diverse classi di menù è stata realizzata basandosi sull’ambito di com-petenza dei dati forniti da report e grafici. Diamo adesso una descrizione dei menù realizzati. ‘Attività sanitaria’ è composto a sua volta da tre sottomenù:
• Dati archiviati, contiene report e grafici eseguiti su dati amministrativi. Que-sto menù è utile all’amministrazione per l’analisi prestazionale e dell’andamento finanziario dell’azienda.
• Dati in linea, contiene dati che non sono stati ancora archiviati. I dati in questa sezione sono prelevati direttamente dai DB (C7, ARCA, LABPI, LABMS) e contengono sia dati clinici che amministrativi;
• Report, contiene indicatori per lo studio di qualità del servizio fornito e delle attività svolte.
Nel menù ‘Controllo di gestione’ è possibile selezionare diverse voci (Performance, At-tività, Pisa, Massa, Ambulatori, ecc.) dedicate all’analisi costi-ricavi, indicatori econo-mici e statistiche raggruppate per ambito di interesse e sede.
Il menù ‘Processi clinici’ contiene statistiche ricavate dalla Scheda dimissione ospeda-liera (SDO) sulla base dei risultati di alcune metodologie di intervento cardiaco. Nel menù ‘Indicatori rischio clinico’ individuiamo gli indicatori legati al rischio clinico, e vengono elaborati dati che consentono all’amministratore sanitario di prendere ini-ziative di gestione dei rischi.
Tra i vari sottomenù, sono stati estrapolati quelli più in uso, inserendoli in ‘Top Ten’ Infine, ‘Dizionari’ è un’appendice consultabile, che riporta informazioni utili all’utiliz-zatore del sistema per la comprensione dei dati forniti dal sistema. Dalla Figura 5.12
si legge anche ‘Configurazione sito’, un menù dedicato agli sviluppatori dal quale è possibile creare gli oggetti e gestire l’applicazione web.
Figura 5.12: Albero di navigazione
5.3.2
Fase 2
Terminata la prima fase siamo passati alla seconda, che prevede la profilazione dei vari utenti all’interno del sistema. Anche per la creazione dei profili ci siamo basati su quelli esistenti sul vecchio SDG. In questo caso abbiamo rimosso i profili non più associati a utenti. Il BMF consente di gestire la profilazione in due modi: in locale oppure accedendo al Gestione Utenti Accesso Sistemi Informativi (GUASI). La FTGM utilizza il metodo di autenticazione e profilazione legato al GUASI poiché è il sistema dedicato alla gestione degli utenti.
Si è reso necessario allineare i seguenti profili:
