Scuola di Ingegneria
Dipartimento di Ingegneria dell’Informazione
Corso di Laurea Magistrale in Ingegneria Biomedica
Tesi di laurea
Re-ingegnerizzazione tecnologica e funzionale del portale delle
Delibere della Fondazione Monasterio
Relatore
Prof. Maurizio MANGIONE
Candidato
Francesco DI MURO
2
SOMMARIO
All’interno del contesto della Fondazione Toscana Gabriele Monasterio sono in uso, da parte del personale amministrativo, tre diversi sistemi, utili a gestire i workflow relativi a tre tipologie di documenti: Delibere, Determine e Convenzioni. Gli utenti potranno effettuare diverse operazioni per ognuno di questi atti, tra cui: caricare il relativo file dell’atto stesso, aggiungere degli allegati, legare una Convenzione ad una Determina o ad una Delibera, visualizzare tutti i file caricati in precedenza o modificare lo stato di un documento. Un ulteriore sistema utilizzato riguarda la gestione delle gare di appalto: esse saranno identificate da un Codice Identificativo di Gara, conosciuto con l’acronimo CIG, il quale viene assegnato alle diverse procedure in atto. Tutti questi sistemi sono degli applicativi web basati sulla seconda versione del Biomedical Framework, noto come BMF2.
La suddivisione di questi sistemi comporta una complicazione ed un rallentamento delle procedure amministrative: da qui è nata l’esigenza di accorparli in un unico applicativo web. L’obiettivo del presente lavoro di tesi è stato quindi quello di accorpare alcune delle funzionalità di questi sistemi, programmando un nuovo applicativo web basato sulla terza versione del Biomedical Framework, il BMF3, il quale permette diversi miglioramenti in termini di usabilità, immediatezza e di interfaccia utente. La rivisitazione di questi sistemi è stata anche un’occasione per rivedere i workflow che governano la gestione dei documenti secondo le esigenze del personale amministrativo.
In questo testo verranno quindi trattate le azioni intraprese durante la migrazione di questi sistemi al BMF3, comprensive della progettazione del nuovo Database su cui esso basa le sue fondamenta, oltre che ad una trattazione generica del BMF3 stesso, utile a comprendere le potenzialità di questo strumento di sviluppo.
3
INDICE
1 INTRODUZIONE ... 6
1.1 Il contesto ... 6 1.2 L’evoluzione del SSN ... 6 1.3 Obiettivi e funzionalità ... 72 AMBIENTE DI LAVORO ... 8
2.1 I Database ... 82.2 Architettura del sistema ... 9
2.2.1 Web Layer ... 10 2.2.2 Application Layer ... 10 2.2.3 Database Layer ... 10 2.3 Framework utilizzato: il BMF3 ... 10 2.3.1 Il Database del BMF3 ... 12 2.3.2 I Reports ... 13 2.3.3 I Charts ... 13 2.3.4 I Calendar ... 15
2.3.5 I Menù Item e i Menù Folder ... 15
2.3.6 I Button ed i Group Button ... 15
2.3.7 I Filtri ... 16
2.3.8 Gli Input-Form ... 16
2.3.9 Le Select ... 18
3 PROGETTAZIONE DEL DATABASE ... 19
3.1 Analisi preliminare ... 19
3.2 Sviluppo del nuovo Database ... 20
3.2.1 Analisi dei requisiti ... 20
3.2.2 Vincoli ... 21
3.2.3 Glossario ... 22
3.2.4 Descrizione progettuale ... 23
3.2.5 Analisi concettuale ... 24
3.2.5.1 Definizione entità, attributi e associazioni ... 24
3.2.5.2 Schema concettuale ... 27
4
3.2.7 Implementazione fisica ... 36
4 IMPLEMENTAZIONE DELL’APPLICATIVO ... 38
4.1 HMSDOCUM ... 38
4.2 Workflow delle Delibere ... 45
4.3 Workflow dei CIG ... 60
4.4 Gestione sito: documentale e allegati ... 66
4.5 Gestione sito: utenti e gruppi di lavoro ... 70
CONCLUSIONI ... 76
6
CAPITOLO 1
INTRODUZIONE
In questo capitolo verrà analizzato il contesto in cui è stato svolto il seguente lavoro di tesi, analizzando brevemente l’evoluzione del Sistema Sanitario Nazionale in modo da sottolineare l’importanza del lavoro svolto e di contestualizzarlo. Verranno infine dichiarati gli obiettivi e le funzionalità che verranno introdotte con il nuovo applicativo web.
1.1 Il contesto
Questo lavoro di tesi è stavo svolto grazie alla collaborazione con la Fondazione Toscana Gabriele Monasterio (FTGM): essa è stata costituita dal Consiglio Nazionale delle Ricerche (CNR) e dalla Regione Toscana per la gestione e lo sviluppo delle attività sanitarie specialistiche e di ricerca di interesse del Servizio Sanitario Regionale toscano; la Fondazione costituisce quindi un ente pubblico specialistico del Servizio Sanitario Regionale.
Due sono le sedi delle attività: lo Stabilimento ospedaliero di Pisa, presso l'Area della Ricerca CNR, e quello di Massa, l’Ospedale del Cuore "G. Pasquinucci". La Fondazione costituisce un centro di alta specialità per la cura delle patologie cardiopolmonari, comprese le patologie rare di interesse specifico. Presso di essa, il paziente è al centro di un sistema multidisciplinare che offre i più moderni ed appropriati percorsi preventivi, diagnostico-terapeutici e riabilitativi, grazie all'alto profilo delle competenze disponibili, alla disponibilità delle tecnologie più avanzate per la diagnostica funzionale, d'immagine e di laboratorio ed alla completa informatizzazione delle attività cliniche e di gestione. La Fondazione, inoltre, svolge attività di ricerca in ambito sanitario e delle tecnologie applicate alla sanità, anche in collaborazione con Istituti del Consiglio Nazionale delle Ricerche, primo tra tutti l'Istituto di Fisiologia Clinica, le Università, le Scuole Superiori e con l'Industria. Ogni dipartimento svolge al contempo attività sanitarie specialistiche ed attività di ricerca ad esse correlate, traendo dall'esperienza dell'attività clinica spunti per l'investigazione di ricerca e, dai risultati della ricerca e dell'innovazione, suggerimenti per il miglioramento della pratica clinica. Risulta quindi chiaro che, in un ambito così altamente votato al miglioramento del Sistema Sanitario a livello nazionale, ogni livello di cui è composta l’azienda deve poter lavorare al massimo della propria efficienza, in modo da apportare il proprio contributo.
1.2 L’evoluzione del SSN
Negli ultimi decenni, il Sistema Sanitario Nazionale (SSN), e quindi tutte le strutture sanitarie che lo compongono, hanno subito una forte evoluzione. A partire dalla Legge 833/1978 sono state istituite le Unità Sanitarie Locali (USL), ed il diritto alle prestazioni sanitarie è stato interpretato come un diritto a ricevere cure pagate in prevalenza con il denaro pubblico, basato sul SSN e legato ai principi della “globalità delle prestazioni”, dell’”universalità dei destinatari” e dell’”uguaglianza del trattamento” (art. 1, Legge 833/1978). Questo modello ha retto fino agli anni Novanta, quando a fronte delle sempre maggiori e indilazionabili esigenze di contenimento della spesa pubblica, l’area della gratuità si è ridotta, traducendo il diritto alle prestazioni in un diritto condizionato dalla compartecipazione del beneficiario alla spesa. Inoltre, con il d.lgs. 30 dicembre 1992, n. 502, le USL vennero trasformate in Aziende Sanitarie Locali (ASL), dotate di autonomia propria e svincolate da un'organizzazione centrale a livello nazionale, poiché dipendenti dalle regioni italiane. Le ASL fanno quindi parte del servizio sanitario nazionale e sono aziende con personalità giuridica pubblica,
7
dotate di autonomia organizzativa, gestionale, tecnica, amministrativa, patrimoniale e contabile, nonché centri di imputazione di autonomia imprenditoriale; infatti secondo l'art. 3 d.lgs. 30 dicembre 1992, n. 502:
«in funzione del perseguimento dei loro fini istituzionali, le Unità Sanitarie Locali si costituiscono in Aziende con personalità giuridica pubblica e autonomia imprenditoriale»1
Questa evoluzione ha quindi portato ad una modifica del modo di operare della Sanità Italiana: il rispetto dei vincoli di bilancio e dell’equilibrio tra costi e ricavi risulta adesso un aspetto fondamentale. In questo contesto risulta chiaro che i responsabili delle strutture sanitarie dovranno monitorare in modo puntuale il controllo di costi, dei rendimenti e dei risultati al fine di garantire una corretta ed economica gestione delle risorse disponibili, mantenendo al tempo stesso la massima qualità del servizio fornito in termini di:
• Prestazioni sanitarie erogate;
• Personalizzazione e flessibilità dell’assistenza; • Diritto all’informazione e prevenzione delle malattie; • Rispetto della normativa sulla privacy;
• Rispetto degli indicatori di qualità sotto l’aspetto gestionale ed imprenditoriale.
Tutto ciò si concretizza in diversi modi, tra cui l’implementazione di applicativi e programmi efficienti e funzionali, i quali dovranno garantire un corretto svolgimento del lavoro delle diverse figure professionali all’opera all’interno delle strutture sanitarie.
Per tutta questa serie di motivi si è scelto di accorpare i sistemi in uso dal reparto amministrativo e di svilupparli tramite il BMF3: ciò permetterà al personale operativo di poter lavorare con più semplicità ed immediatezza, garantendo celerità ed efficienza nelle scelte economiche ed organizzative da attuare.
1.3 Obiettivi e funzionalità
L’applicativo web sviluppato, denominato HMSDOCUM, è un sistema open source con interfaccia web: sarà quindi utilizzabile da tutti i dispositivi connessi ad una rete e su qualsiasi sistema operativo semplicemente
accedendovi tramite un browser web.
L’obiettivo principale è quello di porsi come strumento di supporto al personale amministrativo in fase di creazione, consultazione, verifica e monitoraggio di tutti gli atti relativi alle Delibere, alle Determine, alle Convenzioni ed ai CIG. Questo è possibile grazie alle funzionalità sviluppate con il sistema BMF3, il quale mette a disposizione una moltitudine di oggetti web e di personalizzazioni, utili a rendere l’applicativo web il
più semplice ed efficiente possibile.
Le funzionalità messe a disposizione degli utenti saranno molteplici, e verranno approfondite nei relativi paragrafi.
Questa interfaccia web si appoggerà ad un Database: in esso verranno caricati tutti i dati e gli utenti potranno quindi visualizzare e modificare, in base ai propri diritti, i diversi atti presenti. Gli utenti apparterranno a dei gruppi di lavoro e quindi potranno visualizzare, ed eventualmente modificare, tutti gli atti che sono stati creati soltanto da altri gruppi di lavoro ad essi collegati; faranno eccezione alcune tipologie di profili, i quali potranno visualizzare tutti gli atti caricati, e che saranno quindi associati a tutti i gruppi presenti.
8
CAPITOLO 2
AMBIENTE DI LAVORO
In questo capitolo verranno presentati i diversi elementi su cui si basa questo lavoro di tesi: i Database, dichiarandone la definizione e le principali funzionalità. l’architettura del sistema utilizzato, specificandone le diverse componenti, ed il BMF3, esplicitandone il Database che lo compone e i diversi oggetti astratti che mette a disposizione.
2.1 I Database
Il termine Database (DB) serve a denotare una raccolta di grandi quantità di dati archiviati secondo regole precise e generali; esso permetterà agli utenti di accedere molto velocemente, tramite un calcolatore, ai dati di interesse:
«una base di dati è una collezione di informazioni omogenee e strutturate che possono essere reperite rapidamente»2
Per estensione, il termine DB viene riferito sia alla raccolta dei dati che al sistema software per la generazione e per la consultazione della struttura in cui i dati sono contenuti. La definizione di DB a cui noi faremo riferimento è la seguente:
«un Database è una collezione di dati integrati ed auto descrivente»3
La struttura dei dati deve essere connessa ad un Database Management System (DBMS), un software progettato per consentire agli utenti di aggiungere, eliminare ed aggiornare i dati del DB, oltre che ad interrogarlo in modo da ottenere delle informazioni, con la possibilità di includere dei criteri di ricerca. Le interrogazioni saranno formulate con un linguaggio di interrogazione (o Query Language), di cui il più diffuso
è l’SQL (Structured Query Language).
Esistono diverse tipologie di DB, classificate in base all’approccio di modellazione dei dati implementati; noi utilizzeremo il modello relazionale: in esso il legame fra i dati verrà stabilito da delle relazioni, associando i file in base al contenuto di alcuni campi definiti campi chiave. Questi DB saranno composti da serie di dati, denominate tabelle o entità, che conterranno informazioni omogenee; ogni tabella sarà costituita da un insieme di righe, dette record, e da colonne, dette attributi o campi. Una tabella dovrà soddisfare le seguenti condizioni per essere definita tale:
• Ogni cella potrà contenere un singolo valore;
• Tutti i valori sulle stesse colonne devono essere della stessa tipologia; • Ogni colonna sarà caratterizzata da un singolo nome;
• L’ordine delle righe e delle colonne non è significativo; • Due righe non possono essere uguali.
Un’entità è anche caratterizzata da un livello di normalità: esso indica quanto l’entità è vulnerabile alle anomalie da modifica. Le diverse classi di normalità sono:
➢ Prima forma normale (1NF); ➢ Seconda forma normale (2NF); ➢ Terza forma normale (3NF);
➢ Forma normale di Boyce Codd (BCNF); ➢ Quarta forma normale (4NF);
➢ Quinta forma normale (5NF);
➢ Domain Key Normal Form (DK/NF).
Tutte le forme normali sono annidate tra loro, quindi una 3NF sarà anche in 2NF e 1NF.
2 M. Mangione, Informatica Medica, 9 3 M. Mangione, Informatica Medica, 13
9
L’intersezione di riga e colonna di una tabella riporta il valore di un determinato attributo, ovvero un’istanza. I campi chiave sono chiamati chiavi primarie o Primary Key (PK): essi sono un insieme di attributi che permettono di individuare univocamente una riga all’interno della tabella; di conseguenza due righe non
possono avere lo stesso identificativo.
Le relazioni, utili a legare diverse entità, saranno di diverse tipologie, e saranno suddivise in base a quella che viene detta la cardinalità massima:
• Associazione 1:1, quando ad una singola istanza di un’entità è associata una singola istanza di un’altra entità;
• Associazione 1:N, quando una singola istanza di un’entità è in relazione con molte istanze della seconda entità coinvolta;
• Associazione N:M, quando una singola istanza è in relazione con molte istanze della seconda entità e viceversa.
Le associazioni avvengono attraverso l’uso delle cosiddette chiavi esterne o Foreign Key (FK): esse servono a collegare in maniera univoca due righe di due tabelle (o di una nel caso in cui l’associazione di un’entità sia
con sé stessa).
Un altro aspetto relativo alle associazioni è la cosiddetta cardinalità minima: essa indica se un’istanza deve necessariamente essere associata ad un’altra istanza per poter esistere o meno.
Inoltre, una base di dati conterrà anche le relazioni che esistono tra i dati stessi, consentendo: • L’eliminazione dei dati duplicati in modo da evitare le ridondanze;
• Una migliore gestione dei dati;
• L’indipendenza dei dati rispetto ai programmi che li gestiscono; • La disponibilità di un linguaggio di interrogazione.
Le principali operazione che verranno svolte su un DB saranno quindi: ricerca, eliminazione, aggiornamento
di record ed aggiunta di campi.
Il DBMS metterà a disposizione due tipi di linguaggi utili per la creazione e la gestione di una base di dati: • Il DDL (Data Description Language), il linguaggio per la definizione della struttura dei dati;
• Il DML (Data Manipulation Language), il linguaggio utilizzato per la manipolazione dei dati che consente l’estrazione delle informazioni e la loro eventuale modifica.
Risulta inoltre importante notare che i DB sono composti da quattro elementi principali: i dati utente, i metadati, ovvero la descrizione di come è strutturata la base di dati, gli indici, utili per migliorare l’efficienza e l’accessibilità, e le applicazioni ai metadati, le quali vengono utilizzate per memorizzare la struttura e le maschere dei componenti applicativi.
2.2 Architettura del sistema
Come detto in precedenza, le applicazioni web relative alla gestione di Determine, Delibere, Convenzioni e CIG ad ora in uso sono state sviluppate con il BMF2, uno strumento open source sviluppato all’interno della FTGM, capace di realizzare applicazioni web dinamiche. Con il passare degli anni si è reso necessario un suo aggiornamento, ed è stata quindi sviluppata una nuova versione di esso: il BMF3, il quale risulta più versatile, performante e personalizzabile. L’applicativo è capace di gestire uno o più DB, dai quali preleva i dati richiesti tramite interrogazioni (QUERY) in linguaggio SQL. L’utilizzo del BMF è vantaggioso in quanto mette a disposizione dei tool capaci di semplificare il lavoro dello sviluppatore, il quale non dovrà necessariamente conoscere un linguaggio di programmazione ad oggetti per utilizzarlo: basterà, infatti, la conoscenza approfondita del linguaggio SQL e del framework stesso. L’architettura del BMF3 presenta una netta separazione tra la parte server e quella client, in modo da ottimizzare i tempi di risposta ed avere una parte client facilmente personalizzabile. Il client si frapporrà tra l’utente e il server: è attraverso di esso che l’utente potrà accedere ai servizi e alle risorse messe a disposizione dal server. Al client sarà quindi demandata la gestione della visualizzazione dei dati e delle pagine attraverso le quali l’utente potrà interfacciarsi ai dati del DB.
10
La parte server è basata su una piattaforma a tre livelli in grado di eseguire codice Java, composta da: Web Layer, Application Layer e Database Layer. Questi tre livelli comunicheranno tra di loro tramite il protocollo TCP-IP.
Analizziamo ora brevemente questi elementi che compongono la nostra piattaforma.
2.2.1 Web Layer
Il Web Layer è l’elemento con cui interagisce l’utente. L’utente infatti, utilizzando un client, manderà, tramite il protocollo HTTP o HTTPS, delle richieste al Web Layer, il quale si occuperà di incanalarle all’Application Layer. Tramite questo livello l’utente potrà quindi interagire con il DB effettuando ricerche ed inserendo o aggiornando dati in base ai diritti del profilo con cui
ha eseguito l’accesso.
Queste funzioni sono svolte dall’Apache Tomcat, un software Java dell’Apache Software Foundation.
2.2.2 Application Layer
L’Application Layer è l’elemento che si interpone tra il Web Layer ed il Database Layer, quindi tra l’interfaccia
web ed i dati memorizzati.
Esso svolge il compito di interpretare le richieste dell’utente ricevute dal Web Layer e di interrogare il DB. In questo livello sarà presente un’area di memoria, chiamata sessione, in cui vi saranno memorizzate le informazioni di sicurezza e dei diritti relativi all’utente attivo; questi dati saranno forniti dal DB soltanto se, in fase di accesso tramite client, l’utente ha inserito un nome utente ed una password corretti. Queste funzioni sono svolte anch’esse dall’Apache Tomcat.
2.2.3 Database Layer
Il Database Layer è l’elemento in cui sono conservati i dati. All’interno di questo livello è necessario che siano presenti le informazioni inerenti al login dei vari utenti, oltre ai dati stessi, in quanto nel momento in cui l’utente effettua il login l’Application Layer deve controllare nel DB se le credenziali sono corrette e, in caso positivo, avviare la sessione memorizzando le informazioni di sicurezza.
I DB utilizzati in questa fase sono forniti dell’azienda Oracle.
2.3 Framework utilizzato: il BMF3
Il Biomedical Framework è un tool di sviluppo software che permette di realizzare applicazioni web dinamiche, ossia applicazioni costruite su uno o più database relazionali utili a memorizzare e a gestire i dati di interesse. Attraverso le pagine web di tali applicazioni sarà possibile effettuare operazioni di ricerca, visualizzazione ed inserimenti di dati sulle tabelle del DB, permettendo una completa gestione dei dati stessi da parte dell’utente finale. Queste operazioni vengono eseguite tramite interfaccia web utilizzando un comune browser.
Come detto in precedenza, per utilizzare questo strumento non è necessario conoscere un linguaggio di programmazione ad oggetti: risulta sufficiente la conoscenza approfondita del linguaggio SQL e del framework stesso; tuttavia l’architettura del BMF permette anche ai programmatori esperti di lavorare utilizzando JavaScript (JS), in modo tale da apportare modifiche e personalizzazioni alla sua struttura base. Queste personalizzazioni verranno implementate nei diversi oggetti astratti specificandone il nome tramite il parametro di customizzazione: esse permetteranno di ridefinire i comportamenti propri del BMF aggiungendo delle funzionalità inedite, rendendo quindi l’applicativo completamente personalizzabile.
11
Il BMF3 permetterà quindi di creare diversi oggetti astratti tramite un apposito modulo composto da diversi campi:
• ID, il codice identificativo dell’oggetto (progressivo numerico gestito direttamente dal BMF); • Nome, il nominativo che verrà assegnato all’oggetto;
• Tipo, la tipologia dell’oggetto;
• Descrizione, una nota descrittiva libera dell’oggetto;
• DB, il pool su cui si vuole eseguire la query (se questo campo viene lasciato vuoto, sarà utilizzato il DB di default del framework);
• Link, nel caso di oggetti di tipo Menù Item, questo parametro rappresenta il link invocato; • Link Params, generalmente non utilizzato;
• Ordine, l’ordine di visualizzazione degli oggetti di tipo Menù Folder e Menù Item all’interno del menù laterale di navigazione;
• QUERY, istruzione query per il caricamento dei dati da DB; • JSON, il codice JSON di configurazione dell’oggetto.4
Anche i controlli di integrità sui dati inseriti sono demandati al BMF, che li implementa lato client utilizzando codice JS standard, e lato server utilizzando un particolare naming ed il linguaggio DDL del database. La parte client del BMF3 è stata interamente realizzata utilizzando codice JS mediante il supporto delle seguenti librerie, di cui si include una sintetica descrizione:
• jQuery, utile a rendere più sintetico il linguaggio JS, di semplificare la gestione degli eventi e le animazioni di elementi nelle pagine HTML e di implementare le funzionalità Ajax per comunicazioni con il server;
• Backbone.js, che fornisce strutture utili a migliorare l’organizzazione del codice garantendo scalabilità e manutenibilità dell’applicazione sviluppata;
• Marionette.js, che estende la libreria Backbone.js mettendo a disposizione viste e soluzioni architetturali che semplificano il codice;
• Underscore.js, che aggiunge funzioni e metodi utili a risparmiare un grande numero righe di codice; • Handlebars.js, utile a tradurre oggetti JSON in HTML;
• Require.js, che permette il caricamento di moduli JS in caso di necessità seguendo un ordine prefissato, gestendo le loro dipendenze e permettendo la condivisione di funzionalità tra diversi script.
Il BMF3 utilizza il formato JSON (JavaScript Object Notation): i servizi web, tramite il Tomcat, comunicano con la parte client inviando risposte proprio in formato JSON. Questo formato è stato scelto in quanto è facilmente utilizzabile da qualsiasi linguaggio di programmazione e consente di mantenere la separazione logica tra il client e il server così da poter cambiare interamente, all’occorrenza, l’implementazione lato client senza dover intervenire su quella server e viceversa. Il formato JSON nasce dal linguaggio JS, tuttavia è un formato testuale completamente indipendente, perciò può essere utilizzato ed interpretato correttamente anche da altri linguaggi come PHP, Java, C, Python e molti altri.
I dati sono rappresentati sotto forma di coppie nome-valore separate mediante il simbolo dei due punti, il quale
svolge il ruolo di operatore di assegnazione.
I tipi di dati supportati dal formato JSON sono: • Booleani (true e false);
• Numeri (interi, reali, a virgola mobile); • Stringhe;
• Array (sequenze ordinate di valori, separati da virgole e racchiusi in parentesi quadre); • Oggetti (sequenze non ordinate di coppie chiave-valore racchiuse in parentesi graffe);
12 • Null, ovvero dati nulli.
Nella configurazione degli oggetti astratti del BMF bisognerà, per alcuni di essi, compilare il campo JSON, in maniera tale da specificare quale comportamento dovrà avere all’interno dell’applicazione web. Vediamo ora com’è composto il DB del BMF3 e, successivamente, verranno elencati i principali oggetti astratti messi a disposizione da esso.
2.3.1 Il Database del BMF3
Il DB del BMF3 si compone di diverse tabelle create, di norma, nello stesso schema del DB dell’applicativo; esso verrà rappresentato partizionato in due moduli: il primo sarà il modulo che rappresenta la gestione degli oggetti e dei profili, mentre il secondo sarà il modulo che rappresenta la gestione degli alberi.
Vediamo quindi il modulo per la gestione degli oggetti e dei profili. Esso sarà composto dalle seguenti tabelle:
• T_OBJECT, che contiene tutti gli oggetti che costituiscono il front end, con le relative informazioni dichiarate in fase di configurazione nell’apposito modulo, come ID e Nome;
• T_TYPE_OBJECT, che classifica gli oggetti del BMF in base alla loro tipologia; • T_PROFILO, che contiene i profili da associare agli utenti;
• T_UTENTE, che contiene i nominativi degli utenti che possono accedere al sito, definendo in essa login e password di accesso;
• T_PASSWORD, che contiene le password usate dagli utenti che risultano scadute. Viene utilizzata per la gestione delle password degli utenti in conformità con le direttive per la privacy;
• REL_OBJECT_PROFILO, che contiene le associazioni tra oggetti e profili in modo da diversificare le gestioni da rendere accessibili a seconda del profilo dell’utente;
• REL_MENU_FRONTEND, che contiene le associazioni tra oggetti di tipo Menù Folder e oggetti di tipo Menù Folder o Menu Item, utile quindi per la costruzione della navigazione del sito, definendo la struttura del menù principale;
• REL_UTENTE_PROFILO associa ad ogni utente il profilo con cui accedere al sito. 5
L’aspetto della profilazione è molto importante in quasi tutti gli ambiti informatici: la richiesta di diversificare gli accessi alla stessa risorsa fisica in base alle varie tipologie di utenti è molto richiesta. Ogni utente potrà, infatti, accedere ad una diversa quantità di dati o in lettura o in lettura e scrittura. Per realizzare ciò nel BMF esistono i profili, a cui vengono associati degli oggetto tramite la REL_OBJECT_PROFILO, e gli utenti, i quali verranno a loro volta associati ai diversi profili in base ai diritti che posseggono tramite la REL_UTENTE_PROFILO. In fase di accesso al sistema l’Application Layer, come detto in precedenza, andrà a prendere dal DB le informazioni di sicurezza dell’utente stesso, sempre a patto che le credenziali inserite siano corrette; queste informazioni, contenute in alcune tabelle del DB del BMF, sono le seguenti:
• Gli oggetti astratti associati all’utente ed il loro tipo, contenuti nelle tabelle T_OBJECT e T_TYPE_OBJECT;
• Gli attributi dell’utente quali ruolo, funzione, categoria, ed altre caratteristiche personali, contenuti nella tavella V_UTENTE;
• Il profilo dell’utente, contenuto nella tabella REL_UTENTE_PROFILO;
• Le relazioni esistenti fra gli oggetti ed il profilo dell’utente, contenute nella tabella REL_OBJECT_PROFILO.
Vediamo adesso il modulo che rappresenta la gestione degli alberi.
Gli alberi sono delle strutture di navigazione che possono trovarsi in un qualsiasi applicativo. Spesso infatti si necessita di sviluppare navigazioni gerarchiche: il BMF supporta questo modello di navigazione dei dati,
13
permettendo di realizzare interfacce ad albero. Sarà quindi facile creare sia menù ad albero sia qualsiasi altra forma di navigazione gerarchica suggerita dai dati e diversificata per i vari profili applicativi. Per consentire la strutturazione dell’informazione e per ottenere una navigazione sicura si necessita delle seguenti tabelle:
• T_ALBERO_TIPO_RAMO, T_ALBERO_RADICI, T_ALBERO_TIPO, ovvero tabelle dizionario necessarie per identificare i vari componenti;
• T_STRUTTURA, T_TIPO, che servono a memorizzare tutti i nodi, radici e foglie che possono comporre l’albero;
• T_ALBERO, T_ALBERO_LINK per poter personalizzare l’albero definito nella struttura secondo le esigenze applicative;
• REL_UTENTE_ALBERO serve ad associare all’utente i nodi, le radici e le foglie dell’albero che può vedere. 6
2.3.2 I Reports
I Reports sono l’oggetto astratto, messo a disposizione dal BMF, per poter mostrare all’utente una serie di dati in formato tabellare, eventualmente con una paginazione decisa dallo sviluppatore. Per configurare correttamente questi oggetti bisognerà scrivere correttamente il campo QUERY ed il campo JSON.
Nel campo QUERY verrà specificata l’istruzione SQL per il caricamento dei dati dal DB e, quindi, per popolare la tabella che verrà mostrata all’utente. La query restituirà una serie di campi il cui nome dovrà essere coerente con quello specificato nelle chiavi dell’hash map che verranno definite nel JSON. Il campo JSON servirà a specificare alcune proprietà del Report, tra cui:
• Title, il titolo da assegnare al report;
• Collapse (S/N), un attributo che permette di far collassare il report, ovvero di nasconderlo in caso di selezione di un record;
• Display, un attributo che, se non definito, imposterà la visualizzazione per riga mentre, se valorizzato con column, verrà utilizzata la visualizzazione per colonna;
• Customization, il nome del modello personalizzato, implementato lato client, da applicare all’oggetto report che stiamo creando;
• Cols*, l’hash map contenente tutti i campi che si vogliono gestire nel report. La chiave dell’hash map è data dal nome del campo e per ognuno di essi si potranno definire gli attributi:
o Label, l’etichetta della colonna (di default viene usato il nome del campo); o OrderBy (S/N) per attivare l’opzione di ordinamento sul quella colonna;
• Idxs*, un vettore contente l’elenco dei nomi dei campi da visualizzare, in ordine, nella tabella. 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.7
L’asterisco indica le proprietà obbligatorie.
Inoltre, sempre nel campo JSON, bisognerà specificare la tipologia di oggetto mediante l’istruzione: {"type":"report"…}
2.3.3 I Charts
I Charts sono dei grafici forniti allo sviluppatore per mostrare i dati del DB. Vi saranno diversi tipi di chart utilizzabili:
• Pie, un grafico a torta;
6 M. Mangione, G. Alberini, G. Vivoli, Il Framework BMF3, 22 7 M. Mangione, G. Alberini, G. Vivoli, Il Framework BMF3, 34
14 • Donut, un grafico a ciambella;
• Bar, un grafico a barre orizzontali; • Column, un grafico a barre verticali; • Histo, un grafico a istogramma; • Line, un grafico a linee;
• Area, un grafico ad aree; • Geo, un grafico a mappa; • Tachi, un tachimetro;
• Gant, un diagramma di Gant; • BoxPlot, un grafico di tipo box plot; • Candle, un grafico di tipo candlestick.
Per tutte le tipologie sarà necessario compilare sia il campo QUERY che il campo JSON. Nel campo QUERY bisognerà specificare l’istruzione SQL che dovrà prendere i dati desiderati nel DB; è importante che vi sia coerenza tra il nome dei campi restituiti da questa istruzione e quelli utilizzati nella
configurazione degli attributi JSON.
Nel campo JSON si potranno specificare diverse proprietà:
• Type*, che indica il tipo di grafico da realizzare tra quelli disponibili;
• Title, l’oggetto per l’impostazione del titolo del grafico che richiederà la valorizzazione degli attributi: o Label, ovvero il testo visualizzato come titolo del grafico;
o FontSize, ovvero la dimensione del font da assegnare al testo; o Color, ovvero il colore da assegnare al testo;
• Width, la larghezza del grafico; • Height, l’altezza del grafico;
• FontSize, la dimensione del font da assegnare agli assi x e y e alla legenda;
• Legend (S/N, S valore di default), l’opzione che permette la visualizzazione della legenda;
• SeriesColors, un array di colori da utilizzare per le serie (di default saranno impostati quelli scelti come standard dalla libreria Google);
• Xaxis*, l’oggetto che definisce le labels (i gruppi, cioè le variabili indipendenti) del grafico attraverso gli attributi:
o Label*, ovvero l’etichetta;
o Field*, ovvero il campo della query da usare per popolare tale gruppo del grafico;
• Series*, l’oggetto che definisce le possibili n-series (cioè le variabili dipendenti, ciò che per ogni gruppo si vuole rappresentare), attraverso gli attributi:
o Label*, ovvero l’etichetta della serie; o field*, il valore della serie;
o Dynamic (S/N), un attributo che indica se la label è fissa oppure è dinamica (ossia ottenuta come valore risultante dalla query);
• Geo*, l’oggetto che contiene le proprietà obbligatorie nel caso di configurazione di un Geo Chart, e richieste solo per tale tipologia di grafico:
o Region*, che indica la regione che deve essere rappresentata nel grafico; o Resolution*, ovvero la risoluzione dei confini;
o Colors, la scala di colori da utilizzare;
o DisplayMode, cioè il tipo di rappresentazione.8
L’asterisco indica le proprietà obbligatorie.
Inoltre, sempre nel campo JSON, bisognerà specificare la tipologia di oggetto mediante la seguente istruzione: {"type":"chart"…}
diversa dall’istruzione Type che servirà a specificare il tipo di grafico da utilizzare.
15
2.3.4 I Calendar
I Calendar sono degli oggetti che permettono di rappresentare i dati all’interno di un calendario mensile. Anche in questo caso bisognerà compilare i campi QUERY e JSON. Il campo QUERY dovrà rispettare il seguente formato:
SELECT
to_char(DATA, 'DD') as day_of_month, ORA AS time, NOMINATIVO AS note FROM (
select … as DATA, … as ORA, ... as NOMINATIVO from …
where …
and (TRUNC (…, 'MM') = to_date ('<bmf_day>','MM/YYYY')))9
Il primo campo indica il giorno del mese che si sta rappresentando (day_of_month), gli altri due rappresentano le informazioni che si vogliono visualizzare all’interno delle celle del calendario (ad esempio ora e nota). Nella clausola where è necessario specificare il mese da considerare, settato nel parametro <bmf_day>.10
Il campo JSON risulterà molto semplice in quanto bisognerà specificare solo l’attributo title. Inoltre, sempre nel campo JSON, bisognerà specificare la tipologia di oggetto mediante la seguente istruzione:
{"type":"calendar"…}
2.3.5 I Menù Item e i Menù Folder
Questi oggetti permettono di strutturare la navigazione del sito formando il menù laterale, il quale, nell’aspetto standard delle applicazioni BMF, si trova al margine sinistro delle maschere della web-app.
L’oggetto di tipo Menù Item rappresenta un vero e proprio pulsante all’interno del menù di navigazione del sito: avrà pertanto un link associato, invocato dal click sul pulsante stesso, il quale verrà specificato nel campo Link del modulo di configurazione degli oggetti astratti. Al contrario, gli oggetti di tipo Menù Folder sono dei contenitori di oggetti di tipo Menù Item o di altri Menù Folder, per la loro organizzazione gerarchica, e perciò non hanno link associati. In entrambi i casi non sarà necessario compilare il campo QUERY, mentre bisognerà compilare il campo JSON, il quale dovrà semplicemente contenere le Label, ovvero le etichette da visualizzare.
2.3.6 I Button ed i Group Button
Gli oggetti astratti di tipo Button e Group Button sono utili ai fini della navigazione all’interno del sito: essi permettono infatti di passare da una maschera ad un’altra e si differenziano solo per l’aspetto grafico. Questi oggetti richiedono di compilare soltanto il campo JSON, in cui bisognerà specificare:
• Label, ovvero l’etichetta visibile sul bottone;
• Link, ovvero il link della maschera a cui rimanderà il click sulla relativa label. Infine, nel JSON bisognerà specificare la tipologia di oggetto che si intende utilizzare:
{"type":"group_buttons" ...} Oppure:
{"type":"buttons" …}
9 M. Mangione, G. Alberini, G. Vivoli, Il Framework BMF3, 46 10 M. Mangione, G. Alberini, G. Vivoli, Il Framework BMF3, 47
16
2.3.7 I Filtri
I Filtri saranno utili per effettuare delle ricerche personalizzate nel DB: attraverso di essi l’utente potrà definire dei parametri con cui verranno filtrati i dati di un’istruzione SQL. Per questa tipologia di oggetti non è necessario compilare il campo QUERY, mentre sarà necessario compilare il campo JSON. Il campo JSON permetterà di configurare diversi parametri:
• Fields*, la lista dei campi che compongono il filtro, per i quali è possibile specificare i seguenti attributi:
o Id, identificativo html univoco;
o Name*, nome da assegnare al campo, utilizzato per comporre la query; o Label, etichetta descrittiva del campo;
o Type*, tipo del campo, a scelta tra:
▪ Select, in cui il valore è selezionabile all’interno di una lista;
▪ Hidden, ovvero il campo è nascosto, non viene visualizzato, e il suo valore è quello di default;
▪ Text, ovvero del testo libero;
▪ Radio, in cui l’utente può selezionare il valore del campo scegliendo tra quelli presenti all’interno di un elenco di radio-button con una selezione mutuamente esclusiva; ▪ Checkbox, in cui l’utente può selezionare il valore del campo scegliendo tra quelli
presenti all’interno di un elenco chek-list con una selezione non mutuamente esclusiva;
o Session, che indica se il parametro deve essere inserito tra quelli in sessione; o Default, un valore di default del campo;
o Placeholder, un valore visualizzato all’interno del campo fin quando questo rimane vuoto; o Operator, l’attributo che indica l’operatore da utilizzare nella composizione della condizione
della query (valido solo se session=false). Può assumere i seguenti valori: contains, equal (di default), starts, ends, icontains, iequal, istarts, iends, >, <, >=, <=. Gli operatori contains, equal, starts, ends sono case sensitive a differenza di icontains, iequal, istarts ed iends;
• Dynamic (S/N), scegliendo per questo attributo il valore S, attraverso una serie di checkbox sarà possibile decidere in real time quali colonne visualizzare nel report che si sta andando a generare (solo nel caso in cui vi sia un unico report nella pagina); se nessuna checkbox viene selezionata, verranno visualizzate tutte le colonne del report;
• Collapse (S/N), scegliendo per questo attributo il valore S, il filtro si chiuderà automaticamente dopo l’operazione di ricerca, e sarà possibile espanderlo nuovamente per eseguirne un’altra;
• Hidden (S/N), scegliendo per questo attributo il valore S, il filtro sarà completamente nascosto a seguito dell’operazione di ricerca e non potrà essere espanso nuovamente;
• ButtonText, la label del pulsante ricerca.11
Inoltre, nel campo JSON, bisognerà specificare la tipologia dell’oggetto con l’istruzione: {"type":"filter" …}
2.3.8 Gli Input-Form
Gli oggetti astratti di tipo Input-Form permettono di inserire dei dati sulle tabelle del DB, e richiederanno di valorizzare sia il campo QUERY che il campo JSON. Nel campo QUERY verrà definita l’istruzione SQL per il caricamento dei dati da DB e per il loro posizionamento nei vari elementi dell’Input-Form, creando una corrispondenza con i fields che verranno specificato nel campo JSON. Un aspetto fondamentale per questi oggetti è l’aggiunta di una condizione di questo tipo:
WHERE <condizioni>
17
Senza di esso l’oggetto non risulterà correttamente configurato. Nel campo JSON potranno essere specificate le seguenti proprietà:
• Title, il titolo da assegnare all’Input-Form;
• TableName*, il nome della tabella del DB su cui si vuole fare data entry;
• ToUpperCase (S/N), attributo utilizzato per convertire in maiuscolo i valori inseriti nei field del form; • Pk*, attributo per la composizione della PK; è possibile gestire PK automatiche, composte da un unico campo numerico che si auto-incrementa, oppure PK (singole o composte) la cui valorizzazione è demandata all’utente. Questo attributo è un array composto a sua volta dagli attributi:
o Auto (S/N), se il suo valore è S, la chiave viene auto-generata lato server e dovrà essere singola, ovvero composta da un unico campo numerico;
o Fields, nome dei campi del form che andranno a comporre la PK;
• Fields*, oggetto per la definizione dei campi che andranno a comporre l’Input-Form. Per ciascun campo sarà possibile specificare i seguenti attributi:
o Id*, identificativo univoco, deve coincidere con il nome del campo della tabella del DB su cui si intende fare data entry;
o Name*, nome SQL del campo;
o Label, l’etichetta descrittiva del campo (se non valorizzato, viene usato il valore scelto per l’attributo name);
o Type*, tipo del campo; questa proprietà può assumere i seguenti valori:
▪ Select, in cui il valore del campo sarà selezionabile dall’utente tra quelli presenti all’interno di una lista;
▪ Hidden, in cui il campo è nascosto, non viene visualizzato dall’utente nella maschera; ▪ Text, in cui il valore del campo sarà definito da parte dell’utente mediante digitazione
da testiera di un testo libero;
▪ Radio, in cui l’utente può selezionare il valore del campo scegliendo tra quelli presenti all’interno di un elenco di radio-button con una selezione mutuamente esclusiva; ▪ Checkbox, in cui l’utente può selezionare il valore del campo scegliendo tra quelli
presenti all’interno di un elenco chek-list con una selezione non mutuamente esclusiva;
o Session, che indica se il parametro deve essere inserito tra quelli in sessione;
o Default, che indica il valore da attribuire automaticamente al campo nel caso in cui, durante la compilazione del form, questo non fosse valorizzato;
o Validation, attributo attraverso cui impostare i controlli di validazione, ad esempio nel caso in cui debba essere obbligatoriamente inserito un valore nel campo oppure per controllare che il valore inserito sia maggiore/minore di una certa quantità, o che rispetti un certo pattern di validazione;
o Placeholder, il valore visualizzato all’interno del campo ancora vuoto;
• Customization, il nome del modello custom, implementato lato client, da applicare al form di inserimento;
• Buttons, l’elenco dei pulsanti che compaiono nella maschera, in coda all’input-form; oltre ai pulsanti di default (Save, Delete, Clear, Save As) è possibile aggiungerne altri attraverso la procedura di customizzazione. Le proprietà di ogni pulsante comprendono:
o Id*, l’identificativo del pulsante; o Name*, il nome del pulsante;
o Label*, l’etichetta da associare al pulsante; o IconClass, l’icona da associare al pulsante;
o Enabled (S/N), che specifica l’abilitazione del pulsante; se il valore è N, il pulsante è disabilitato.12
Infine, nel JSON bisognerà specificare la tipologia di oggetto con l’istruzione: {"type":"inputForm" …}
18
2.3.9 Le Select
Gli oggetti Select sono utili per memorizzare delle QUERY da utilizzare successivamente, ad esempio per popolare una finestra di scelte in un input form.
Le Select dovranno avere il seguente formato: SELECT
CAMPO AS val, CAMPO AS descr FROM TABELLE WHERE CONDIZIONE
19
CAPITOLO 3
PROGETTAZIONE DEL DATABASE
In questo capitolo verranno esposte le diverse fasi che compongono la progettazione di un Database; è essenziale che questo lavoro sia svolto in maniera corretta: l’applicativo web che verrà sviluppato, infatti, si baserà proprio su di esso, perciò la sua corretta funzionalità si baserà proprio sulla corretta progettazione del suo Database.
Inizialmente verrà effettuata un’analisi preliminare della situazione attuale, per poi entrare più nel dettaglio delle diverse fasi affrontate durante questo lavoro di tesi.
3.1 Analisi preliminare
Al fine di eseguire un lavoro di migrazione che rendesse facile, per gli utenti, il passaggio dal vecchio sistema a quello nuovo, è stato necessario studiare com’erano abituati a svolgere il loro lavoro: è infatti importante, in fase di programmazione, tenere conto di come l’operatore è abituato ad agire, in modo da non stravolgere il suo flusso logico, ma allo stesso tempo di renderlo più efficiente. A seguito di numerose interviste si è potuto evincere il seguente workflow:
➢ Il processo inizia con il caricamento su un server, da parte di un utente definito come Autore, del documento da elaborare, quindi una Delibera o una Determina, il quale sarà in uno stato definito Bozza;
➢ Una volta caricato il documento potranno essere aggiunti diversi allegati da parte degli utenti appartenenti allo stesso gruppo di lavoro;
➢ Separatamente verrà caricata una Convenzione;
➢ Se necessario potranno essere associate, sempre da parte di operatori facenti parte dello stesso gruppo di lavoro, delle Convenzioni ad una Determina o ad una Delibera;
➢ Una volta finite queste operazioni il documento entrerà in uno stato definito Da Revisionare;
➢ A questo punto un utente definito come Revisore effettuerà un controllo dei diversi documenti, decidendo se mandarli avanti nel processo esecutivo o se mandarli in uno stato definito Da Correggere; ➢ Se il documento prosegue il suo iter gli verrà associato, se necessario, un CIG;
➢ Dopodiché il documento passerà in uno stato definito Da Firmare, in cui verrà verificato un’ultima volta da parte di un utente definito come Direttore Generale o Responsabile e, in caso di esito positivo, sarà firmato digitalmente e potrà entrare nello stato Da Pubblicare, altrimenti passerà allo stato Da Correggere;
➢ Infine, un utente definito come Editore potrà pubblicare l’atto completando così l’iter di sviluppo del documento portandolo in stato Pubblicato.
Tutti questi passaggi vengono svolti attualmente da persone diverse sui diversi applicativi; inoltre, il personale amministrativo, per notificare la presenza di documenti da revisionare o da firmare, utilizza avvisi di tipo cartaceo interni, inviati tramite personale di segretaria. Il nuovo sistema sviluppato permetterà di effettuare tutte queste operazioni al suo interno, strutturando il workflow in modo da renderlo simile a quello dei precedenti sistemi.
Una nota importante va spesa in merito alla profilazione: nei vecchi sistemi gli utenti erano raggruppati per Unità Operative (UO), ovvero dei gruppi che effettuavano determinate operazioni; nel nuovo sistema si è invece deciso di raggruppare gli utenti per gruppi di lavoro, i quali possono contenere persone di diverse UO. Questa scelta è stata presa in quanto questa suddivisione risulta più flessibile e quindi più adatta all’organizzazione del reparto amministrativo: non è raro, infatti, che alcuni documenti siano condivisi con utenti di diverse UO, così come non è raro che un utente passi da un gruppo di lavoro ad un altro senza cambiare l’UO. Ogni gruppo potrà lavorare sui documenti che sono in determinati stati: ad esempio, quello relativo agli Autori potrà lavorare sui documenti in stato Bozza ma non su quelli in stato Da Firmare. All’interno del nuovo sistema sviluppato è stata quindi implementata una funzionalità che permette di aggiungere nuovi gruppi di lavoro e di associarci sia degli utenti che degli stati dei documenti su cui potranno lavorare, rendendo il sistema maggiormente flessibile in base alle necessità del reparto amministrativo.
20
Un ulteriore livello di flessibilità è stato introdotto rendendo possibile l’aggiunta di nuovi stati per i diversi documenti: se, infatti, in fase di intervista sono stati definiti i sei macro stati sopra citati, è anche vero che alcuni documenti possono passare per degli stati intermedi, o che nuovi stati si possano aggiungere nel tempo; nell’ottica di rendere il nuovo sistema non solo efficiente e modulare ma anche funzionale nel tempo, si è data la possibilità, per alcuni utenti con determinati permessi, di aggiungere nuovi stati e di poter specificare come questi potranno evolvere, andando di fatto a modificare il workflow dei diversi documenti.
3.2 Sviluppo del nuovo Database
I sistemi utilizzati precedentemente dal reparto amministrativo presentavano diversi DB, ognuno sviluppato per le diverse tipologie di documenti; per poter sviluppare un sistema unico il primo passo intrapreso è stato quello di unirli creando un unico DB in grado di mantenere i precedenti vincoli di integrità e, in alcuni casi, di
poterne aggiungere di nuovi.
Una differenza sostanziale, infatti, riguarda le chiavi esterne delle tabelle dei diversi documenti: esse permettono di legare in maniera univoca due campi di diverse tabelle, come ad esempio nel caso in cui venga caricato un allegato per una Delibera o quando una Convenzione viene associata ad un documento.
Con i precedenti sistemi, a causa della presenza dei diversi DB, l’associazione tra documenti avveniva tramite un inserimento manuale dei dati da parte degli operatori: infatti, le tabelle utilizzate, appartenendo a schemi diversi, non potevano essere legate tramite FK. Risulta quindi chiaro che la possibilità di errore, in questo caso, era alta: questa situazione ha reso necessario organizzare, ad intervalli di tempo prestabiliti, numerose operazioni di controllo, da parte di alcuni operatori, di tutti gli atti pubblicati, in modo da verificare che le associazioni siano state inserite correttamente. Il nuovo sistema, invece, essendo composto da un unico DB, permette di legare i diversi documenti tramite delle FK, abbassando drasticamente la possibilità di errore: gli operatori non dovranno, infatti, inserire i dati relativi alle associazioni a mano, ma dovranno selezionare il documento corretto da una lista, e tutte le operazioni di associazione verranno gestite automaticamente dall’applicativo web. Per la progettazione del nuovo Database si è quindi seguito un workflow composto dalle seguenti fasi:
• Analisi dei requisiti, prima fase in cui si esplicitano tutti i vincoli definiti in fase di intervista con il committente ed il glossario dei termini utilizzati;
• Descrizione progettuale, in cui si descrive il progetto nella sua interezza;
• Analisi concettuale, fase in cui vengono definite le entità con i propri attributi, le diverse associazioni utilizzate e lo schema concettuale che ne deriva;
• Analisi logica, in cui si approfondiscono le diverse entità verificandone lo stato di normalità;
• Implementazione fisica, ultima fase che prevede l’implementazione vera e propria di tutti gli elementi definiti attraverso un client, creando di conseguenza il DB progettato.
Entriamo quindi nel dettaglio delle diverse fasi di sviluppo.
3.2.1 Analisi dei requisiti
A seguito delle diverse interviste effettuate si è definito che il sistema dovrà permettere le seguenti operazioni: • Caricare su un server diversi tipi di documenti;
• I documenti dovranno avere un’indicazione della tipologia, in modo da poterli analizzare separatamente;
• Ogni file caricato dovrà contenere nel suo nome la data e l’ora di caricamento sul server, in modo da poter ricostruire uno storico delle diverse versioni;
• Ogni file caricato dovrà avere associate informazioni quali la data di caricamento, l’operatore che lo ha caricato ed il suo gruppo di appartenenza, e questi dati non devono essere modificabili;
• Ogni documento deve poter essere aggiornato dando la possibilità di caricare una nuova versione del file, di aggiungere un commento e di poterne cambiare lo stato;
• In fase di aggiornamento dovrà essere specificata la data dell’operazione e l’utente che ha effettuato la modifica;
21
• Se un documento subisce più modifiche è sufficiente salvare la data e l’operatore relativi all’ultima operazione effettuata in ordine di tempo;
• Se un documento subisce una modifica dovrà essere visualizzabile soltanto l’ultima versione del file caricato;
• Le nuove versioni dei documenti dovranno rimanere sul server per questioni di sicurezza, ma non dovranno essere visibili agli utenti;
• Deve essere possibile allegare un numero arbitrario di file; • Non è necessario risalire alla data in cui viene allegato un file;
• Non è necessario risalire all’operatore che carica un file come allegato;
• Gli allegati non saranno modificabili, ma se ne potrà caricare una nuova versione; • Tutti gli allegati caricati, anche le versioni precedenti, sono visibili agli utenti;
• Deve essere possibile poter associare ad una Delibera o ad una Determina un numero arbitrario di Convenzioni;
• Non è necessario risalire alla data di associazione di una Convenzione ad una Delibera o ad una Determina;
• Non è necessario risalire all’operatore che ha associato una Convenzione ad una Delibera o ad una Determina;
• Deve essere possibile aggiungere dei CIG, i quali sono forniti da enti governativi; • Deve essere possibile associare ai CIG i Partecipanti al bando di gara;
• Deve essere possibile associare ai CIG gli Aggiudicatari del bando di gara;
• Deve essere possibile associare ad un documento un CIG inserito precedentemente nel sistema; • Dovrà essere possibile fornire una reportistica per tutte le tipologie di documenti;
• La reportistica dovrà essere modificabile in base alle esigenze del personale, il quale potrà decidere come filtrare i documenti;
• Ogni documento dovrà poter essere visibile agli utenti che fanno parte del gruppo di lavoro a cui appartiene l’utente che lo ha caricato;
• Ogni documento dovrà poter essere visibile agli utenti che fanno parte dei gruppi di lavoro che sono stati associati al gruppo di lavoro a cui appartiene l’utente che lo ha caricato;
• Ogni gruppo di lavoro dovrà avere associati degli stati dei documenti a cui potrà accedere in visualizzazione o modifica in base ai propri diritti.
3.2.2 Vincoli
La nostra base di dati presenterà diversi vincoli derivanti dalle richieste dei committenti e, quindi, dalle interviste effettuate:
• Un documento, per essere salvato, deve presentare obbligatoriamente i seguenti dati: o Nome;
o Data dell’atto; o Data di caricamento;
o Utente che ha caricato l’atto;
o Gruppo di lavoro dell’utente che ha caricato l’atto;
o Stato iniziale del documento, il quale sarà, di default, Bozza;
• Un allegato, per essere caricato sul server, deve presentare i seguenti attributi: o Tipologia;
o Livello di privacy;
• Una Convenzione non potrà essere associata a più atti ma un atto può avere più Convenzioni; • Un documento può evolvere soltanto in alcuni stati in base al workflow definito in precedenza; • Un CIG potrà essere associato ad un solo documento;
22
Per il funzionamento corretto del nostro sistema sono stati inoltre imposti i seguenti vincoli progettuali: • Per ogni Delibera e Determina i seguenti campi non potranno essere nulli:
o CIG associato al un documento; o Utente che ha modificato il documento;
• Per ogni Convenzione i seguenti campi non potranno essere nulli: o Utente che ha modificato la Convenzione;
o Documento associato alla Convenzione. • Per i CIG i seguenti campi non potranno essere nulli:
o Tipologia di CIG; o Stazione appaltante; o RUP;
o Tipologia di scelta del contraente;
• Per poter lavorare ogni utente dovrà appartenere ad un gruppo di lavoro. L’associazione tra utenti e gruppi potrà portare al verificarsi delle seguenti situazioni:
• Il gruppo di lavoro associato ad un utente non ne ha associati altri, nemmeno esso stesso: questo comporta che l’utente non potrà visualizzare nessun documento ma potrà crearne in base ai propri permessi;
• Il gruppo di lavoro associato ad un utente non ha associato nessuno stato dei documenti: anche in questo caso l’utente non potrà visualizzare nessun documento, ma potrà crearne di nuovi, sempre in base ai propri permessi.
Queste situazioni sono considerate valide in quanto non è detto che un utente debba poter visualizzare i documenti caricati sul sistema.
3.2.3 Glossario
Vengono ora elencati tutti i termini di cui è necessario fornire una definizione.
Documento/Atto: file di diverse tipologie che contengono le informazioni su determinate procedure giuridiche;
Delibera: una tipologia di documento utile a rendere nota una decisione presa a carattere ufficiale;
Determina: una tipologia di documento che costituisce una manifestazione di un’attività messa in atto;
Convenzione: una tipologia di documento che rappresenta un accordo raggiunto fra due o più parti;
Allegato: file che contiene informazioni aggiuntive per un determinato atto;
Stato di un documento: lo stato rappresenta a che punto del workflow si trova un determinato documento;
Tipologia di allegato: serve a specificare a quale categoria appartiene un allegato;
Livello di privacy: serve a specificare che livello di privacy ha un allegato;
Gruppo di lavoro: un insieme di utenti che lavorano sulla stessa tipologia di documenti;
Utente/Operatore: un utente o un operatore sono delle persone fisiche che effettuano l’accesso all’applicativo web e che vi apporteranno delle modifiche o che ne consulteranno i dati;
Versione: la versione rappresenta un’evoluzione di un documento;
Aggiornamento/Modifica: rappresentano diverse operazioni, tra cui il caricamento una nuova versione, l’aggiunta di un commento o la modifica dello stato di un documento;
23
Commento: il commento sarà un campo testuale che permetterà all’utente che lo aggiunge di lasciare una nota utile a far comprendere l’evoluzione di un documento;
CIG: il CIG è il Codice Identificativo di Gara, ovvero rappresenta il codice relativo ad un bando di gara;
Partecipanti: sono i partecipanti del bando di gara identificato dal CIG;
Aggiudicatari: sono gli aggiudicatari del bando di gara identificato dal CIG;
RUP: il Responsabile Unico del Procedimento;
Stazione appaltante: indica una pubblica amministrazione aggiudicatrice o altro soggetto di diritto, che affida appalti pubblici di lavori, forniture o servizi oppure concessioni di lavori pubblici o di servizi.
3.2.4 Descrizione progettuale
Nella base di dati che si vuole progettare tutte le Delibere e le Determine che verranno caricate sul server saranno registrate all’interno dell’entità Documento; ogni atto avrà un suo codice univoco e, come detto in precedenza, presenterà la data di caricamento, l’utente che lo ha registrato ed il gruppo di lavoro a cui appartiene. In fase di creazione del record verrà impostato automaticamente lo stato iniziale definito come Bozza.
Tutte le Convenzioni che verranno caricate saranno invece registrate nell’entità CNV, e le si potranno associare ai diversi documenti presenti; anche per questa tipologia di documento verranno salvati i dati relativi all’utente che ha caricato l’atto, il gruppo a cui appartiene e la data in cui ha eseguito l’operazione. Per le Convenzioni l’utente potrà scegliere una serie di attributi:
• Dall’entità Tipo_CNV potrà selezionare il tipo di Convenzione;
• Dall’entità AP potrà indicare se si tratta di una Convenzione di tipo passiva o attiva; • Dall’entità CNV_CTR potrà indicare se la Convenzione è un Contratto;
• Dall’entità CNV_CTR_TIPO potrà specificare il tipo di procedura.
Tutti i documenti potranno essere aggiornati: l’utente potrà quindi caricarne una nuova versione, sovrascrivendo la vecchia, aggiungere un commento e cambiarne lo stato; per le Determine e le Delibere il nuovo stato scelto sarà selezionato all’interno di una lista che conterrà tutti gli stati in cui può evolvere il documento selezionato, i quali saranno presenti all’interno della relazione molti a molti che l’entità Stato ha con sé stessa. La vecchia versione del documento rimarrà sul server ma non sarà accessibile agli operatori.
Il sistema dovrà indicare, a seguito di un aggiornamento, l’utente che ha effettuato l’operazione e la data in cui la modifica è avvenuta; nel caso di ulteriori modifiche sarà sufficiente indicare soltanto l’utente relativo all’ultimo aggiornamento effettuato e la data di quest’ultimo. Ad ogni documento potranno essere aggiunti degli allegati: questi saranno registrati all’interno dell’entità Allegato se sono associati ad una Delibera o ad una Determina, oppure all’interno dell’entità Allegato_CNV se sono associati ad una Convenzione. In fase di creazione del record, l’utente dovrà specificare la tipologia di file che sta caricando, scegliendo tra quelle presenti nell’entità Tipo_Allegato, e il suo livello di privacy, scegliendo tra quelli presenti nell’entità Privacy. L’ultima tipologia di documenti che potranno essere caricati sono i CIG: gli utenti potranno aggiungerne di nuovi registrandoli nell’entità CIG; potranno inoltre associare ad ogni CIG dei Partecipanti e degli Aggiudicatari tramite due relazioni di tipo molti a molti che l’entità CIG ha con l’entità Soggetto, la quale conterrà tutte le aziende, gli enti e i soggetti censiti. Infine gli utenti potranno modificare dei dati utili alla gestione dell’applicativo tramite le seguenti operazioni:
• Potranno registrare nuovi stati per i documenti agendo sull’entità Stato, specificandone le possibili evoluzioni tramite la relazione molti a molti che ha con sé stessa;
24
• Potranno aggiungere tipologie di allegati registrandoli nell’entità Tipo_Allegato; • Potranno aggiungere nuovi livelli di privacy registrandoli nella tabella Privacy; • Potranno aggiungere degli utenti agendo sull’entità Utente;
• Potranno aggiungere o eliminare gruppi di lavoro agendo sull’entità Gruppo;
• Potranno associare degli utenti ai diversi gruppi di lavoro, agendo sulla relazione presente tra l’entità Gruppo e l’entità Utente;
• Potranno specificare le relazioni tra gruppi di lavoro, agendo sulla relazione molti a molti presente tra l’entità Gruppo e sé stessa: infatti un gruppo di lavoro potrà lavorare sui documenti caricati da diversi altri, in base alle esigenze del personale;
• Potranno specificare a quali stati dei documenti avranno accesso i diversi gruppi agendo sulla relazione molti a molti presente tra l’entità Gruppo e l’entità Stato.
3.2.5 Analisi concettuale
L’analisi concettuale è divisa in due fasi: la prima fase si occuperà di definire tutte le entità con i propri attributi e tutte le relazioni presenti, mentre nella seconda verrà mostrato lo schema concettuale del DB che ne deriva. Iniziamo quindi con la prima fase.
3.2.5.1 Definizione entità, attributi e associazioni
Verranno adesso elencate tutte le entità necessarie alla progettazione del DB: per ogni entità verranno specificati tutti gli attributi associati, sottolineando quelli utilizzati come chiave primaria e specificando a parte le FK che verranno introdotte.
ALLEGATO (ALLEGATO_CODICE, ALLEGATO_NOME, ALLEGATO_ESTENSIONE, ALLEGATO_UPFILE)
FK: DOCUMENTO_CODICE, TIPO_ALLEGATO_CODICE, PRIVACY_CODICE
ALLEGATO_CNV (ALLEGATO_CNV_CODICE, ALLEGATO_CNV_NOME, ALLEGATO_ CNV_ESTENSIONE, ALLEGATO_CNV_UPFILE)
FK: CNV_CODICE, TIPO_ALLEGATO_CODICE, PRIVACY_CODICE AP (AP_CODICE, AP_DESCR)
CIG (CIG_CODICE, CIG_CIG, CIG_OGGETTO, CIG_IMPORTO, CIG_DATA_VERBALE, CIG_IMPORTO_LIQ, CIG_DATA_INIZIO, CIG_DATA_FINE, CIG_PROV, CIG_VALIDATO, CIG_DATA_FINE_CONTROLLI)
CIG_SCELTA_CONTR (CIG_SCELTA_CONTR_CODICE, CIG_SCELTA_CONTR_DESCR)
CIG_STAZAPP (CIG_STAZAPP_CODICE, CIG_STAZAPP_DESCR)
CIG_STAZAPP_RUP (CIG_STAZAPP_RUP_CODICE, CIG_STAZAPP_RUP_DESCR)
CIG_TIPO (CIG_TIPO_CODICE, CIG_TIPO_DESCR)
CNV (CNV_CODICE, CNV_CONTR, CNV_DTSTIP, CNV_NOTE, CNV_NUM_REP, CNV_POSARC, CNV_PROVV, CNV_UPFILE, CNV_UPFILE_NOME, CNV_UPFILE_EXT, CNV_SCADENZA, CNV_DESC, CNV_COMP, CNV_DTMOD)
FK: TIPO_CNV_CODICE, AP_CODICE, DOCUMENTO_CODICE, CNV_CTR_TIPO_CODICE, CNV_CTR_CODICE, GRUPPO_CODICE, CNV_PERSONA, CNV_UTMOD
25
CNV_CTR_TIPO (CNV_CTR_TIPO_CODICE, CNV_CTR_TIPO_DESCR)
TIPO_CNV (TIPO_CNV_CODICE, TIPO_CNV_DESCR)
DOCUMENTO (DOCUMENTO_CODICE, DOCUMENTO_NOME, DOCUMENTO_DESC, DOCUMENTO_DATA, DOCUMENTO_CODICE_DEF, DOCUMENTO_PROVV_DATA, DOCUMENTO_TIPO, DOCUMENTO_CODICE_PROP, DOCUMENTO_ALBO_SN_NOTE, DOCUMENTO_VIS_CODICE, DOCUMENTO_UPFILE, DOCUMENTO_UPFILE_EXT, DOCUMENTO_UPFILE_NOME, DOCUMENTO_DTMOD)
FK: DOCUMENTO_PERSONA, CIG_CODICE, STATO_CODICE, DOCUMENTO_UTMOD, GRUPPO_CODICE
PRIVACY (PRIVACY_CODICE, PRIVACY_LIVELLO)
STATO (STATO_CODICE, STATO_DESCRIZIONE)
TIPO_ALLEGATO (TIPO_ALLEGATO_CODICE, TIPO_ALLEGATO_DESCR)
GRUPPO (GRUPPO_CODICE, GRUPPO_DESCR)
SOGGETTO (SOGGETTO_CODICE, SOGGETTO_NOME, SOGGETTO_CODFISC, SOGGETTO_CODFISCEST, SOGGETTO_PIVA)
Tra queste entità non è presente la tabella T_UTENTE in quanto è implementata direttamente nel BMF3, come specificato nel capitolo relativo alle tabelle del BMF3.
Elenchiamo ora tutte le associazioni derivanti da questo schema suddividendoli per ogni entità, specificando per ognuna le cardinalità massime e minime:
• Entità Allegato, in cui ogni allegato dei documenti potrà essere associato a: o Un documento, e necessita della sua presenza per poter esistere; o Un livello di privacy, e necessita della sua presenza per poter esistere; o Un tipo di allegato, e necessita della sua presenza per poter esistere.
• Entità Allegati_CNV, in cui ogni allegato delle Convenzioni potrà essere associato a: o Una Convenzione, e necessita della sua presenza per poter esistere;
o Un livello di privacy, e necessita della sua presenza per poter esistere; o Un tipo di allegato, e necessita della sua presenza per poter esistere. • Entità AP, in cui le tipologie presenti potranno essere associate a:
o Più Convenzioni, ma non necessitano della loro presenza per poter esistere. • Entità CIG, in cui ogni CIG potrà essere associato a:
o Più soggetti Partecipanti, e non necessita della loro presenza per esistere; o Più soggetti Aggiudicatari, e non necessita della loro presenza per esistere; o Un documento, e non necessita della sua presenza per esistere;
o Una tipologia di CIG, e necessita della sua presenza per esistere; o Una stazione appaltante, e necessita della sua presenza per esistere; o Un RUP, e necessita della sua presenza per esistere;
o Una tipologia di scelta del contraente, e necessita della sua presenza per esistere.
• Entità CIG_SCELTA_CONTR, in cui le tipologie di scelta del contraente presenti potranno essere associate a:
o Più CIG, ma non necessitano della loro presenza per poter esistere.
• Entità CIG_STAZAPP, in cui le stazioni appaltanti presenti potranno essere associate a: o Più CIG, ma non necessitano della loro presenza per poter esistere.
o Più RUP, ma non necessitano della loro presenza per poter esistere. • Entità CIG_STAZAPP_RUP, in cui i RUP presenti potranno essere associate a:
o Più CIG, ma non necessitano della loro presenza per poter esistere;
