System Design Document
- System Design Document
1. Introduzione
1.1 Obiettivi generali
Lo scopo del sistema proposto è quello di automatizzare le attività di gestione delle prenotazioni ospedaliere per aggevolare il cittadino e il personale nell’organizzazione delle operazioni desiderate.
1.2 Archittettura software corrente
Come già esposto in fase di analisi dei requisiti, si suppone che all’interno dell’ospedale non venga utilizzato alcun software in grado di compiere le complesse operazioni automatiche proposte da questo sistema, le quali sono al momento svolte manualmente dagli impiegati.
1.3 Obiettivi di progettazione
- Tempo di risposta: il Sistema risponderà alle richieste impartite dall’utente in tempo reale, a meno che la pagina richiesta non sia particolarmente ricca di informazioni. In quest’ultimo caso potrà avvenire un ritardo di pochi secondi.
- Facilità di utilizzo: l’utente effettuerà le proprie prenotazioni o modifiche di queste ultime nel minor numero possibile di passaggi.
- Memoria: il DataBase, escluso il sistema, deve occupare uno spazio su disco inferiore ai 100 MB.
- Estendibilità: il sistema potrà essere esteso e modificato in futuro, secondo le nuove esigenze richieste, agendo sul codice.
- Affidabilità: i risultati prodotti dalle pagine rispecchieranno istante per istante la situazione ospedaliera, in modo da permettere ai vari utenti di non incorrere in errori di sistema e di organizzazione.
- Robustezza: il sistema, tramite dei controlli, deve impedire l’inserimento da parte degli utenti di input non validi.
- Disponibilità: il sistema sarà disponibile ogni qual volta l’utente voglia utilizzarlo.
- Sicurezza: i dati personali non verranno utilizzati a fini diversi dall’organizzazione ospedaliera, vigeranno gli standard dell’industria nel campo della protezione dei dati. La sicurezza è garantita da login e password.
- Portabilità: il sistema è portabile in diverse piattaforme, in quanto realizzato in linguaggio Java.
2. Architettura software corrispondente
Poichè non è presente un sistema corrente da sostituire, si è preso in esame come riferimento il sistema descritto in Implementing standards for the interoperability among healthcare providers in the public regionalized Healthcare Information System of the Lombardy Region, Barbarito et. al..
Il sistema proposto prevede però un campo di applicazione molto più ridotto dovendo operare esclusivamente all’interno di un singolo ospedale per il supporto della gestione delle prenotazioni, sono state quindi prese in considerazione principalmente gli aspetti legati ai servizi di assistenza sanitaria digitale, in particolare il sistema di prenotazione degli esami e il PHR (Personal Health Record, corrispondente al Fascicolo Sanitario Elettronico preso in esame durante l’analisi dei requisiti), ma l’intero funzionamento del sistema è stato considerato come punto di partenza per la progettazione del sistema da sviluppare.
Inoltre dopo un’analisi costi-benefici è risultato che l’adozione di standard per l’interoperabilità quali HL7 fosse troppo onerosa per gli scopi proposti, risultando inoltre dal sistema di riferimento che è possibile implementare questa interoperabilità in un secondo momento senza stravolgere i sistemi informativi preesistenti.
3. Architettura software proposta
3.1 Overview
Per il sistema è stata scelta un’architettura a layer. Essa comporta la suddivisione di un insieme di livelli organizzati in modo tale da fornire specifici servizi in base al loro posizionamento. La gerarchia dei sottosistemi, inoltre, diminuisce la complessità.
3.2 Scomposizione in sottosistemi
Al fine di mostrare al meglio i sottosistemi e la loro funzionalità, sono stati utilizzati i component diagram di UML nel seguente modo:
Procediamo con la descrizione dettagliata dei sottosistemi dall’alto verso il basso e, quindi, dalla parte del sistema più vicina all’utente a quella più basale ed essenziale:
- User Interface » Insieme di interfacce grafiche predisposte per permettere all’utente di interagire con il sistema.
- Funzionalità » Vista la complessità questo sottosistema è stato a sua volta scomposto in sottosistemi a basso coupling, ognuno di questi gestisce la logica di funzionamento di uno dei casi d’uso di alto livello individuati in fase di analisi dei requisiti.
- Invio notifiche » Gestisce la connessione con il server mail, si occupa anche di ottenere le informazioni necessarie a generare i messaggi da inviare tramite posta elettronica ai pazienti.
- Recupero e modifica delle informazioni » Gestisce le connessioni con il DataBase, si occupa anche della conversione tra il formato in cui i dati sono rappresentati nel database e le entity nel sistema.
In fase di progettazione si è deciso di creare una nuova classe appartenente al sottosistema “Recupero e modifica delle informazioni” alla quale assegnare le operazioni che, nei diagrammi delle sequenza in analisi dei requisiti, risultavano essere messaggi mandati al DBMS.
Questa classe di fatto sostituirà il DBMS in tutte le interazioni con il sistema, per completezza si riporta la classe insieme ai suoi metodi.
3.3 Mappatura hardware/software
Nella mappatura si è deciso di concentrare la complessità del sistema sui calcolatori degli utenti per permettere una migliore scalabilità.
Come si evince dal precedente diagramma di deployment, sono presenti due nodi fondamentali:
- PC utente
- Server
Entrambi rappresentano dei device fisici: il primo è un qualunque personal computer adibito all’installazione del sistema proposto, il secondo il Server (o i server).
SPRINT-paziente, SPRINT-medico e SPRINT-amministrativo sono i nodi software contenenti i layer di interfaccia utente, funzionalità e connessioni a database e mail server, questi nodi sono installabili ed utilizzabili su qualunque calcolatore in cui sia presente una Java Virtual Machine.
Nel nodo Server, oltre al nodo software adibito all’invio di notifiche promemoria (SPRINT-server), sono presenti anche un’istanza di MySQL Server, che gestirà i contenuti del DataBase, e di SMTP Server, che gestirà l’invio dei messaggi di posta elettronica in base alle richieste dei nodi software. Le richieste dei nodi software sono gestite tramite protocollo TCP/IP e, a livello applicativo rispettivamente tramite JDBC ed SMTP.
3.4 Gestione dati persistenti
Progetto concettuale
Diagramma entità-relazione:
Vincoli di Tupla
- Ogni attributo delle varie classi sarà vincolato in dimensione e tipo. I vincoli sono espressi nel successivo Progetto Logico.
- Non si potrà effettuare una Prenotazione per un Paziente ad un orario già previsto per altre Prestazioni del medesimo.
- Ogni password dovrà contenere almeno 8 caratteri.
- Una Prenotazione può essere associata ad una Fascia Oraria solo se c’è un Medico che esercita in quella fascia oraria in grado di erogare quella Prestazione.
- Non possono essere presenti più Prenotazioni per la stessa Prestazione all’interno della medesima Ricetta.
Progetto logico
3.5 Sicurezza e controllo degli accessi
Vista la natura sensibile dei dati gestiti dal sistema, per poter usufruire dei servizi proposti è necessario eseguire una procedura di autenticazione. A tal fine ogni utente sarà provvisto di una password e vari identificativi caratterizzanti che potranno permettergli di accedere alle diverse aree del sistema. Alcune funzionalità del sistema, inoltre, saranno accessibili esclusivamente da determinate tipologie di utente.
3.6 Condizioni di boundary
Accensione
Dal momento in cui il sistema verrà avviato per la prima volta, il server rimarrà attivo per tutte le ventiquattro ore giornaliere, senza mai terminare.
Il software usato degli utenti, all’avvio, richiederà sempre di effettuare l’autenticazione e mostrerà la schermata principale soltanto dopo che questa verrà completata con successo.
Spegnimento
Il Server non terminerà la sua esecuzione a meno che non vi siano dei guasti.
Il software usato dagli utenti, invece, cesserà la sua esecuzione quando verrà chiuso il sistema da PC con successivo rilascio di eventuali variabili temporanee.
Fallimento
Il sistema lato Server fallirà in caso di problemi hardware, attacchi esterni o mancanza di elettricità. Stessa cosa potrà dirsi per il sistema da parte client, a meno che non si usino dispositivi non cablati.
3.7 Flusso controllo globale
Quando un utente si logga, vi è un accesso al DataBase, tramite una Query, che permette di controllare l’esistenza del soggetto. Dopo la conferma, l’utente potrà accedere a diverse operazioni messe a disposizione dal sistema, accessibili tramite un’interfaccia grafica.
Il controllo del flusso viene attuato principalmente dal Server MySQL che si occupa di gestire gli accessi concorrenti da parte di più utenti. Ad esempio, durante la prenotazione di una visita intramoenia, al momento della conferma del Medico e dell’orario, MySQL entra in una sezione critica gestendo la concorrenza ed evitando che più utenti scelgano le stesse caratteristiche di Prenotazione.