Università degli Studi di Trieste

Facoltà di Ingegneria

Corso di Laurea Triennale in Ingegneria Informatica

Progettazione e realizzazione di un’applicazione per la gestione dei privilegi

di accesso ad applicazioni software

Relatore Laureando

Chiar.mo Prof. Maurizio Fermeglia Riccardo Gulin

A.A. 2008/2009

1. INTRODUZIONE.............................................................................................................................................3

2. ANALISI........................................................................................................................................................4

2.1 – Situazione di partenza.........................................................................................................................4

2.2 – Requisiti...............................................................................................................................................4

2.2.1 – Strutturazione dei requisiti in gruppi di frasi omogenee...............................................................6

2.2.2 – Glossario dei termini.....................................................................................................................8

3. PROGETTAZIONE DELLA BASE DI DATI..........................................................................................................9

3.1 – PROGETTAZIONE CONCETTUALE.........................................................................................................9

3.1.1 – Analisi delle entità......................................................................................................................11

3.1.2 – Analisi delle relazioni e delle cardinalità.....................................................................................12

3.2 – PROGETTAZIONE LOGICA...................................................................................................................14

3.2.1 – Tabelle dei volumi.......................................................................................................................14

3.2.2 – Tabelle delle operazioni..............................................................................................................15

3.2.3 – Tabelle degli accessi....................................................................................................................15

3.2.4 – Ristrutturazione del diagramma E-R...........................................................................................17

3.2.4 – Traduzione verso il relazionale...................................................................................................20

4. SVILUPPO DEL PROTOTIPO DELLA BASE DI DATI.........................................................................................22

5. REALIZZAZIONE DELLA BASE DI DATI..........................................................................................................24

5.1 – Esportazione verso SQL Server..........................................................................................................24

5.2 – Trigger e Stored Procedures..............................................................................................................24

5.2.1 – Trigger.........................................................................................................................................25

5.2.2 – Stored Procedures......................................................................................................................27

6. REALIZZAZIONE DELL’INTERFACCIA UTENTE...............................................................................................29

6.1 – ADO.NET............................................................................................................................................29

6.2 – REALIZZAZIONE DEL FRONT-END.......................................................................................................29

2

1. INTRODUZIONE

Questa tesi riguarda la progettazione e lo sviluppo di un’applicazione software richiesta dall’Ufficio del Servizio Informativo dell’Azienda per i Servizi Sanitari N°2 “Isontina” di Gorizia.

L’obiettivo finale è lo sviluppo di un prototipo software per la gestione dei dipendenti degli ospedali di Gorizia e Monfalcone e delle abilitazioni all’utilizzo di applicativi, che i dipendenti utilizzano internamente all’ospedale. Al momento attuale la raccolta e la gestione di questo tipo particolare di informazioni avviene principalmente su supporto cartaceo; lo scopo perciò di questo progetto è quello di automatizzare queste operazioni.

Da una prima analisi si è stabilita la mancanza di una base dati pre-esistente ed utilizzabile; quindi lo svolgimento del progetto è iniziato con la progettazione e lo sviluppo di un prototipo di database, per passare solo in seguito all’interfaccia utente. Inoltre non è stata rilevata l’esistenza di alcun prodotto software esistente che possa soddisfare i vincoli organizzativi ed economici dell’azienda, perciò è stato necessario realizzare un applicativo ad hoc.

Le fasi principali dello sviluppo sono state:

Analisi della situazione per identificare le esigenze del cliente e degli utenti e per la definizione di obiettivi e funzionalità

Progettazione della base di dati Sviluppo del prototipo della base dati Realizzazione della base dati finale Progettazione e sviluppo dell’interfaccia utente

Nei capitoli successivi vengono trattati più a fondo questi passaggi.

3

2. ANALISI

2.1 – Situazione di partenza

L’Ufficio del Servizio Informativo dell’ASS (Azienda per i Servizi Sanitari) di Gorizia si occupa di più attività, una di queste è la gestione delle abilitazioni all’utilizzo dei programmi interni all’ospedale, abilitazioni che vengono definite come ruoli. Agli impiegati dell’ufficio possono arrivare richieste di aggiunta o rimozione di ruoli per i dipendenti dell’ospedale; tali richieste possono essere inoltrate all’azienda Insiel, responsabile dell’attivazione dei permessi all’accesso ad una parte degli applicativi, oppure mantenute in sede in quanto l’assegnazione di ruoli per una seconda parte degli applicativi può essere effettuata direttamente dall’ufficio stesso. La richiesta di sviluppo dell’applicativo software trattato in queste pagine è stata commissionata da parte del responsabile dell’ufficio per poter immagazzinare in una base dati informazioni riguardanti i dipendenti, i ruoli e di conseguenza gli applicativi ai quali essi possono accedere o meno. Gli utenti del sistema finale, definiti come operatori, sono gli impiegati dell’ufficio stesso.

2.2 – Requisiti

La fase di analisi è una fase di notevole criticità nel processo di sviluppo; in essa il fornitore si reca dal cliente per capire ed interpretare quali siano i bisogni di quest’ultimo. Lo svolgimento dell’ attività di analisi dei requisiti è avvenuto tramite interviste ai futuri utenti del sistema finale. Questa fase ha richiesto notevole tempo per ottenere un’inquadratura migliore possibile delle esigenze, in modo da evitare che errori dovuti a un’errata interpretazione dei bisogni del committente si potessero ripercuotere in tutte le successive fasi di lavoro.

Dall’analisi delle informazioni raccolte si è stabilito che per ogni dipendente

4

utente degli applicativi si vuole memorizzare un’anagrafica contenente Nome, Cognome, Matricola (o Codice Identificativo), Data di Nascita, Codice Fiscale, Sede di Appartenenza con relativo Reparto ed eventuale Data di Cessazione.

Per ogni Reparto si vuole poter inserire nel database, oltre al nome di questo, un Numero di telefono interno e la Sede dove esso è locato, sede che sarà contraddistinta da nome, indirizzo e numero di telefono.

Per quanto riguarda gli Applicativi ai quali un utente può accedere, essi sono circa trenta, divisibili tra quelli abilitati dall’ufficio informativo stesso e quelli abilitati da Insiel; ogni applicativo fornisce da uno o più di un centinaio di ruoli. Ogni dipendente può ottenere anche un numero elevato di abilitazioni, gli viene cioè assegnato un ruolo per ogni applicativo che egli può utilizzare. Un operatore del Servizio Informativo o utente della base di dati, può ricevere una richiesta di modifica delle abilitazioni di uno o più dipendenti; in questo caso egli vuole poter effettuare una modifica nel database, modifica che può riguardare più abilitazioni e più utenti ma che deve essere contrassegnata da un singolo numero di protocollo (o numero di pratica), dalla data di modifica e dall’operatore che l’ha effettuata. In caso di abilitazioni ad applicativi fornite da Insiel , ogni nuovo protocollo dovrà poi essere inoltrato a tale azienda; è stata perciò richiesta la funzionalità di stampa di un modulo contenente tutte le informazioni sui ruoli, modulo che preferibilmente dovrà essere adattato a una singola pagina. Il sistema dovrà distinguere tra abilitazioni fornite dall’azienda esterna e abilitazioni direttamente effettuate dagli operatori del database; solo nel primo caso è richiesta la stampa di un modulo.

Una richiesta particolare che può arrivare all’operatore è la cancellazione rapida di tutte le abilitazioni di una persona per il singolo applicativo, perciò il sistema finale dovrà fornire anche questa opzione. Nel caso venga inserita una data di cessazione nei dati personali di un dipendente, dovuta al fatto che una persona ha terminato l’attività lavorativa presso l’ospedale, il sistema dovrebbe preparare, previa conferma da parte dell’operatore, la possibilità di rimozione istantanea di tutte le sue precedenti abilitazioni, elencandole a una a una in un modulo stampabile.

Il sistema deve permettere agli utilizzatori la possibilità di inserire nuovi utenti con i relativi dati, cancellarli o aggiornarli; può sussistere inoltre l’esigenza dell’inserimento di nuovi reparti e nuove sedi di appartenenza con tutti i dati a loro correlati.

5

Oltre alle già sopracitate operazioni sulle abilitazioni, ci può essere la necessità di inserire nel database anche nuovi applicativi e nuovi ruoli.

Deve inoltre essere fornita la possibilità di effettuare ricerche filtrate per dati anagrafici, numero di matricola, applicativo, numero di protocollo.

Per quanto riguarda l’interfaccia utente definitiva essa deve essere il più semplice e sobria possibile secondo le preferenze degli utenti.

Non sono stati espressi particolari vincoli riguardanti sicurezza e prestazioni del sistema finale.

2.2.1 – Strutturazione dei requisiti in gruppi di frasi omogenee

Si è voluta eseguire una strutturazione dei requisiti in maniera da poter più facilmente identificare entità e relazioni che andranno a costituire il primo schema utilizzato per la progettazione del database: lo schema E-R (Entity-Relationship).

Frasi di carattere generale

Si vuole progettare e realizzare una base dati che possa permettere agli operatori di controllare e modificare l’elenco dei dipendenti dell’ospedale (dell’ordine delle migliaia di persone) che hanno ottenuto l’abilitazione o meno ad accedere a numerosi applicativi utilizzati a lavoro.

Frasi relative ai dipendenti

Per ogni dipendente si vuole memorizzare un’anagrafica contenente Nome, Cognome, Matricola (o Codice Identificativo), Data di Nascita, Codice Fiscale, Sede di Appartenenza con relativo Reparto ed eventuale Data di Cessazione e Abilitazioni che egli ha ottenuto per l’accesso agli applicativi.

6

Frasi relative alla sede

Per quanto riguarda la Sede si vuole memorizzare Nome della Sede, Città, CAP, Indirizzo e Numero di Telefono.

Frasi relative al reparto

Per quanto riguarda il Reparto si vuole memorizzare Nome del Reparto, Numero di Telefono e Sede di Appartenenza.

Frasi relative agli applicativi

Gli applicativi ai quali un utente può accedere sono circa trenta e suddivisibili in applicativi per i quali è l’ufficio informativo stesso a fornire l’abilitazione e applicativi per i quali è l’azienda esterna INSIEL a fornire l’abilitazione.

Ogni dipendente può avere più o meno privilegi, ma gli viene assegnato uno e un solo ruolo per ogni applicativo che egli può utilizzare.

Frasi relative al protocollo

Un operatore può ricevere richieste di modifica delle abilitazioni, cioè dei ruoli, di uno o più dipendenti; in questo caso egli vuole poter aprire una nuova pratica per poter effettuare una modifica nel database, modifica che può riguardare più abilitazioni e più utenti ma che deve essere contrassegnata da un singolo numero di protocollo, dalla data di modifica e dall’operatore che l’ha effettuata.

Il sistema deve essere in grado di distinguere tra abilitazioni fornite dall’azienda esterna e abilitazioni direttamente effettuate dagli operatori del database; nel primo caso è richiesta la stampa di un modulo contenente tutte le informazioni sui ruoli e dipendenti da modificare; il modulo deve riportare il numero di protocollo e preferibilmente deve essere adattato a una singola pagina.

7

2.2.2 – Glossario dei terminiSi è costruito un glossario dei termini; per ogni termine significativo ricavato dai requisiti si sono inseriti una breve descrizione, relazioni con altri termini del glossario ed eventuali sinonimi.

Termine Descrizione Sinonimi Collegamenti

Dipendenti

Utilizzatori degli applicativi dell’ospedale. Sono coloro ai quali dovranno venire assegnati dei privilegi.

Utenti-applicativi Reparto,Ruolo

Applicativi Sono i software a cui accedono gli impiegati dell’ospedale e per i quali hanno più o meno privilegi.

Software Dipendenti, Ruoli

Operatore E’ un dipendente che è anche utilizzatore del sistema in questione. Responsabile perciò della creazione di nuovi protocolli di modifica abilitazioni.

Protocollo,Dipendenti

Ruolo Ogni utente riceve un ruolo per ogni singolo applicativo a cui ha accesso.

Abilitazione,privilegio

Applicativi,Dipendenti

Protocollo Numero progressivo che va a identificare una richiesta giunta per la modifica delle abilitazioni alcuni utenti.

Numero pratica Dipendenti,Ruolo,Operatore

Sede Ente presso cui gli impiegati lavorano o hanno lavorato.

Dipendenti, Reparto

Reparto Suddivisione interna della sede. Sede, Dipendenti

8

3. PROGETTAZIONE DELLA BASE DI DATI

3.1 – PROGETTAZIONE CONCETTUALE Una volta ottenuta una chiara situazione dei requisiti espressi in linguaggio naturale si è potuto procedere andando a rappresentare la realtà mediante uno schema, il diagramma Entity-Relationship. Questo modello permette di rappresentare i dati a prescindere dal motore database scelto e mette a disposizione degli elementi utili per rappresentare il contesto mediante una simbologia ad essi associata. Una breve spiegazione dei costrutti forniti da questa tipologia di diagramma è la seguente:

Entità: classe di oggetti significativi nel contesto della realtà in esame. Relazione: legame logico tra due o più entità in quanto corrisponde ad

un’interazione esistente tra due o più elementi reali. Attributo: proprietà elementare di un’entità o di una relazione. Cardinalità: coppia di valori che specificano il numero minimo e massimo

di occorrenze della relationship in cui ciascuna occorrenza dell’entità può comparire.

Identificatore: insieme di attributi che consente di individuare univocamente ciascuna occorrenza di un’entità.

Generalizzazione: rappresentazione di una o più entità nei casi dove queste possono essere considerate caso particolare di un’altra entità. Le proprietà del genitore vengono ereditate da tutti i figli.

Tenendo conto di questi aspetti si è riusciti a costruire un diagramma E-R primitivo che viene illustrato nella seguente pagina.

9

–

10

3.1.1 – Analisi delle entità

Si elencano di seguito le descrizioni delle singole entità, i loro attributi e i campi possibili identificatori primari:

Persona

Matricola: È il codice univoco che identifica qualsiasi dipendente dell’azienda sanitaria (tuttora lavorante o meno); è candidato ad essere chiave primaria dell’entità “Persona”.

Nome: Nome proprio della persona Cognome: Cognome della persona Data di nascita: Data di nascita della persona Sesso: Sesso della persona C.F. : Codice Fiscale della persona

Dipendente

Stessi attributi dell’entità padre “Persona”

Ex-Dipendente

Stessi attributi dell’entità padre “Persona” Data di cessazione: Data in cui l’impiegato ha concluso l’esperienza lavorativa

Operatore

Stessi attributi del padre “Dipendente”

Non operatore

Stessi attributi del padre “Dipendente”

Reparto

RepartoID: codice univoco che identifica il reparto di appartenenza di una Persona. Questo campo è candidato a essere chiave primaria dell’entità “Reparto”

Nome Reparto: nome del reparto dell’ospedale Telefono: numero di telefono interno del reparto

Sede

SedeID: codice univoco che identifica la sede nella quale è situato un reparto. Questo campo è candidato a essere chiave primaria dell’entità “Sede”

Nome: nome della sede Città: città dove una sede ha locazione

11

Indirizzo: indirizzo della sede Telefono: numero di telefono della sede

Applicativo

ApplicativoID: codice univoco che identifica gli applicativi software utilizzati dai dipendenti dell’ospedale. Questo campo è candidato a essere chiave primaria dell’entità “Applicativo”

Nome: nome usato per definire l’applicativo Abilitato da: campo che distingue tra applicativi abilitati dall’azienda esterna o dagli

operatori dell’ufficio informativo stesso

Ruolo

RuoloID: codice univoco che identifica il ruolo o abilitazione che una persona ha per il singolo applicativo. Questo campo è candidato a essere chiave primaria dell’entità “Applicativo”

Nome: nome dell’abilitazione che un dipendente può ottenere per un applicativo

Protocollo

ProtocolloID: numero univoco e progressivo che identifica una pratica di modifica delle abilitazioni dei dipendenti.

Data di modifica: data in cui è stata aperta la nuova pratica Operatore: colui il quale ha aperto la pratica

3.1.2 – Analisi delle relazioni e delle cardinalità

La fase successiva è stata dedicata ad un aspetto fondamentale nella progettazione delle basi di dati, ossia lo studio delle cardinalità nelle relazioni. Ponendosi alcune semplici domande sui legami intercorrenti tra le entità si è giunti alla definizione delle cardinalità per tutte le relazioni presenti nello schema; di seguito si possono osservare delle tabelle contenenti le descrizioni delle singole relazioni e i ragionamenti che hanno portato all’identificazione delle varie cardinalità:

12

RELAZIONE CARDINALITA’

Assegnazione

Collega l’entità “Persona” con l’entità “Ruolo”; definisce tutti i ruoli per i quali un dipendente ha ottenuto l’abilitazione all’utilizzo.

Molti a molti: ogni dipendente può avere ottenuto l’abilitazione a uno o a più ruoli e viceversa un ruolo può essere stato assegnato a numerosi dipendenti.

Autorizzazione

Collega l’entità “Applicativo” con l’entità “Ruolo”; stabilisce quali ruoli fornisce un singolo applicativo.

Uno a molti: ogni applicativo può avere a disposizione molti ruoli da assegnare all’utente, ma ogni ruolo appartiene a uno e un solo applicativo.

Appartenenza

Collega l’entità “Persona” con l’entità “Reparto”; identifica il reparto di appartenenza del dipendente dell’azienda.

Uno a molti: ogni dipendente ha uno e un solo reparto di appartenenza. Un reparto però può avere numerosi dipendenti.

Locazione

Collega l’entità “Reparto” con l’entità “Sede”; definisce la sede di appartenenza del singolo reparto.

Uno a molti: un reparto ha una sola sede di appartenenza ma una sede ha più di un reparto.

Modifica

Collega l’entità “Ruolo” con l’entità “Protocollo”; il numero di protocollo caratterizza una pratica arrivata in azienda che richiede la modifica di privilegi.

Molti a molti: ogni volta che viene aggiunto o rimosso un ruolo di un dipendente, la modifica riceve un numero di protocollo. Un numero di protocollo invece corrisponde ad uno o più ruoli modificati.

Creazione

Collega l’entità “Protocollo” con l’entità “Operatore”; ogni protocollo è creato da un operatore.

Uno a molti: un protocollo ha uno e un solo operatore, ma un operatore può aver creato numerosi numeri di protocollo.

Abilitazione

Collega l’entità “Protocollo” con l’entità “Persona”; sotto un numero di protocollo si trovano i dipendenti ai quali sono stati aggiunti o rimossi dei ruoli con l’apertura di una nuova praticaMolti a molti: un dipendente può avere ricevuto più modifiche ai propri ruoli identificate da diversi numeri di protocollo in quanto avvenute con pratiche differenti. Viceversa un singolo protocollo può identificare numerosi dipendenti ai quali sono state effettuate modifiche dei ruoli.

13

3.2 – PROGETTAZIONE LOGICA

Dopo aver ottenuto uno schema E-R con attributi e cardinalità, è stata effettuata come prima cosa una scelta sul modello dei dati, ovvero come sono organizzati i dati dal punto di vista dell’elaboratore. La scelta è ricaduta sul modello relazionale dei dati, attualmente il più diffuso, il quale permette di sistemare i dati in strutture tabellari fisse. Una volta scelto il modello, si è passati alla traduzione dello schema logico nello schema relazionale, schema meno astratto del precedente e più ottimizzato per l’utilizzo finale; non si è trattato di una semplice traduzione perché questa fase deve necessariamente tenere conto di prestazioni e aspetti realizzativi.

3.2.1 – Tabelle dei volumiUna prima indagine di questo tipo ha portato alla costruzione di tabelle dei volumi riguardanti i numeri di occorrenze sia per quanto riguarda le entità che le relazioni.

Tabelle dei volumi per entità e relazioni

14

Concetto Tipo Volume

Persona E 10000

Dipendente E 5000

Ex-Dipendente E 5000

Operatore E 10

Non Operatore E 5000

Applicativo E 100

Ruolo E 1000

Reparto E 150

Sede E 20

Protocollo E 1000

Concetto Tipo

Volume

Locazione R 20

Appartenenza R 150

Assegnazione R 250000

Autorizzazione R 100

Creazione R 1000

Abilitazione R 5000

Modifica R 10000

3.2.2 – Tabelle delle operazioni

Oltre a tenere in considerazione i volumi dei dati sono state effettuate analisi anche sulle operazioni tipiche sulla base dati, operazioni raccolte nella seguente tabella:

Operazione Tipo Frequenza

Inserimento nuovo dipendente Interattiva 100 /anno

Aggiornamento dati dipendenti Interattiva 10 /mese

Inserimento nuovi applicativi Interattiva 1 /anno

Visualizzazione elenco dipendenti Interattiva 50/giorno

Inserimento data di cessazione di un dipendente e conseguente cancellazione di tutti i ruoli dello stesso

Batch 100 /anno

Visualizzazione ruoli dipendente Interattiva 10/giorno

Modifica abilitazioni dei dipendenti Interattiva 50 /settimana

Creazione numero di protocollo Interattiva 10 /settimana

3.2.3 – Tabelle degli accessi

E’ stata effettuata infine un’analisi sugli accessi prendendo in considerazione le tre operazioni sulla base di dati considerate più frequenti e più importanti di altre:

15

Operazione in esame: visualizza tutti gli applicativi e ruoli per i quali un dipendente ha le abilitazioni

Concetto Costrutto Accessi Tipo

Persona Entità 1 L Ruolo Entità 10 L

Assegnazione Relazione 10 L

Applicativo Entità 10 L

Autorizzazione Relazione 10 L

Operazione in esame: visualizza elenco dipendenti dell’ospedale

Concetto Costrutto Accessi Tipo

Persona Entità 10000 L

Operazione in esame: creazione nuova pratica

Concetto Costrutto Accessi Tipo

Operatore Entità 1 L

Creazione Relazione 1 L

Protocollo Entità 1 S

Abilitazione Relazione 5 S

Persona Entità 5 L

Modifica Relazione 25 S

Ruoli Entià 25 L

3.2.4 – Ristrutturazione del diagramma E-R

16

Una volta ricavate queste informazioni si è potuti passare alle operazioni per la ristrutturazione del diagramma E-R.

Eliminazione degli attributi composti

L’unico attributo composto rilevato nello schema iniziale è quello riguardante l’attributo indirizzo dell’entità sede.

Si sono presentate due possibili soluzioni:

Eliminazione dell’attributo composto in modo da farlo diventare attributo semplice

Modifica dei sottoattributi in attributi separati dell’entità

La prima soluzione è stata ritenuta più adatta in quanto nel sistema finale è sufficiente accedere all’informazione complessiva e non ai campi separatamente. Scegliendo questa soluzione il campo indirizzo diventa un campo stringa contenente tutti i precedenti attributi.

Eliminazione degli attributi multi-valore

17

Nel caso in questione è l’attributo telefono ad essere multi-valore in quanto sia l’entità sede che l’entità reparto possono avere più di un numero di telefono.

E’ stata scelta la soluzione di creare una nuova entità collegata da una relazione alle vecchie entità che avevano l’attributo multi valore.

Eliminazione delle generalizzazioni

Il modello di struttura dei dati scelto, il modello relazionale, non è in grado di rappresentare le generalizzazioni, pertanto si cerca di eliminare queste ultime sostituendole con altri concetti dove possibile.

Ci possono essere tre soluzioni al problema:

La prima soluzione prevede l’accorpamento dei figli nel padre: le entità figlie vengono eliminate e le loro proprietà (attributi, associazioni, generalizzazioni) vengono aggiunte al padre, che deve avere un attributo in più per distinguere le entità figlie.

La seconda soluzione prevede l’accorpamento del padre nei figli: l’entità padre viene eliminata e per ereditarietà i suoi attributi, identificatori e relazioni vanno ai figli.

La terza soluzione prevede che la generalizzazione si trasformi in associazioni uno ad uno che legano padre e figli.

In questo progetto la soluzione adottata è stata la prima per tutti i casi di generalizzazione, in quanto essa, a differenza delle altre due, non richiede la creazione di ulteriori tabelle; è principalmente questa caratteristica di semplicità che ha portato a questa scelta.

18

Le generalizzazioni che si è dovuti eliminare da questo progetto sono le seguenti:

- La prima generalizzazione riguarda i dipendenti che ormai non lavorano più presso l’azienda. Per essi viene inserita una data di cessazione che perciò può diventare un attributo direttamente dell’entità persona eliminando quindi la generalizzazione.

- Nel secondo caso la generalizzazione distingue tra dipendenti che sono identificati come operatori del database e i dipendenti che non hanno questa autorizzazione. Come nel caso precedente anche questa generalizzazione può essere eliminata andando ad aggiungere un attributo all’entità dipendente, eliminata nel precedente passo di ristrutturazione; perciò viene aggiunto l’attributo Operatore Si/No direttamente all’entità persona.

- L’ultima generalizzazione è quella che specifica se un ruolo è stato modificato o meno. In questo caso però ci si è trovati di fronte a una situazione di vincolo non esprimibile, cioè una limitazione imposta dal contesto. La soluzione al problema può avvenire tramite la scrittura di opportune procedure del programma che accede al database, oppure prendendo in considerazione l’utilizzo di un DBMS che può fornire funzionalità utili alla risoluzione del problema, quali “trigger” che

19

permettono di eseguire azioni, come riempimenti di tabelle, in corrispondenza di determinati eventi. La scelta è ricaduta su quest’ultima soluzione. Per quanto riguarda la fase di progettazione logica si è proceduto ad eliminare l’ultima generalizzazione tramite l’inserimento di un’ulteriore un’entità chiamata dettaglio-protocollo, contenente al suo interno informazioni riguardanti le persone alle quali sono stati modificati dei ruoli nei singoli protocolli.

Parte del diagramma E-R ristrutturato con cardinalità e attributi

Si è giunti pertanto a uno schema E-R ristrutturato e pronto per il passaggio al relazionale.

3.2.4 – Traduzione verso il relazionale

Sono stati scelti gli identificatori primari in maniera che fossero unici per ogni entità:

Persona (Matricola, Cognome, Nome, Sesso, Data di Nascita, Codice Fiscale, OperatoreSi/No,Data di Cessazione, Reparto)

20

Ruolo (RuoloID, Nome Ruolo, Applicativo)

Applicativo (ApplicativoID, Nome Applicativo, Abilitato da)

Reparto (RepartoID, Nome Reparto, Sede, Numero di telefono)

Sede (SedeID, Nome Sede, Indirizzo, Numero di telefono)

Protocollo (ProtocolloID, Data Modifica, Operatore)

Dettaglio-Protocollo (DettaglioID, Matricola, Ruolo, Protocollo)

E’ stato così possibile effettuare la traduzione verso lo schema relazionale; da notare in particolare l’aggiunta di una “tabella di sponda” per la relazione molti a molti tra le tabelle Persona e Ruolo:

21

4. SVILUPPO DEL PROTOTIPO DELLA BASE DI DATI

Questa fase è consistita nella realizzazione di un prototipo sviluppato tramite Microsoft Access 2007, prototipo che è stato poi portato in visione al cliente per accertarsi di aver colto per intero le richieste sue e dei futuri utenti.

Per quanto riguarda questo prototipo, sono state dapprima create tutte le tabelle e le relative relazioni, seguendo le indicazioni dello schema relazionale come si può notare dall’immagine sottostante:

Diagramma delle relazioni in Access

Sono stati creati anche vincoli di tipo intra-relazionale e inter-relazionale, e successivamente si è potuti passare alla creazione di query sulle quali sono state costruite delle maschere di lettura, aggiornamento o inserimento di dati.

Esempio di maschera in lettura, viene visualizzato a schermo l’elenco dei dipendenti

22

Esempio di maschera di inserimento, viene offerta la possibilità di creare un nuovo dipendente

Una volta create alcune funzionalità base, questo prototipo è stato portato in visione al cliente, il quale, confermando che i requisiti individuati in partenza erano corretti, ha permesso la continuazione del progetto.

23

5. REALIZZAZIONE DELLA BASE DI DATI

5.1 – Esportazione verso SQL Server

Poiché software come Access sono limitati per vari aspetti e non offrono la possibilità di utilizzare strumenti avanzati come i trigger, è stata effettuata la scelta di migrare da Microsoft Access 2007 al ben più completo Microsoft Sql Server 2005 Express. E’ stata effettuata una scelta di questo tipo soprattutto per la possibilità di implementare i vincoli non esprimibili tramite l’utilizzo di trigger e non tramite procedure create ad hoc. Questa scelta è stata effettuata poichè se un vincolo è implementato nel DBMS viene rispettato comunque si acceda al database; al contrario se invece il vincolo dovesse venire implementato nel programma che accede alla base dati, esso sarà rispettato solo se l’accesso viene effettuato tramite tale programma. Pertanto è stata effettuata la migrazione a Sql Server sfruttando dei tool appositi per l’esportazione di struttura e dati da Access.

5.2 – Trigger e Stored Procedures

Una volta completata con successo l’esportazione, si è scelto di procedere con la creazione di tutte le viste che poi saranno utilizzate dal programma di accesso alla base dati.Sono state prodotte otto viste in base alle necessità rilevate per lo sviluppo delle funzionalità del prototipo finale dell’applicativo:

- View_Abilitazioni- View_DettaglioDipendente- View_DettaglioProtocollo- View_ListaDipendenti- View_Operatori- View_Reparti- View_RuoliAssegnati- View_Ruolo

24

5.2.1 – Trigger

Dopo aver creato le viste tramite codice Sql si è deciso di potenziare il database tramite la scrittura dei già citati trigger.Questi strumenti sono particolari tipi di stored procedures, ovvero procedure memorizzate nel database stesso e scritte in linguaggio Transact-Sql; l’ esecuzione dei trigger è data dallo scatenarsi di un evento particolare, come la modifica dello stato della base dati, secondo una condizione specificata.In questo progetto è stato utilizzato un particolare tipo di trigger, i trigger instead of che verranno illustrati nelle seguenti righe.

Sono stati utilizzati numerosi trigger di tipo instead of; essi sono stati creati direttamente sulle viste per non dare all’utente dell’applicativo diretto accesso alle tabelle della base dati; perciò sono stati scritti trigger instead of per ogni vista del database nella quale ci fosse bisogno di inserire nuovi dati, aggiornare o eliminare i dati preesistenti nelle tabelle.

Pertanto sono stati creati 15 trigger di tipo instead of per le seguenti viste aggiornabili:

- View_DettaglioDipendente(trg_InsertDettaglioDipendente, trg_UpdateDettaglioDipendente, trg_DeleteDettaglioDipendente)

- View_Reparti (trg_InsertReparto, trg_UpdateReparto,trg_DeleteReparto)- View_Sede(trg_InsertSede,trg_UpdateSede,trg_DeleteSede)- View_Ruolo(trg_InsertRuolo, trg_UpdateRuolo, trg_DeleteRuolo)- View_Applicativo(trg_InsertApplicativo,trg_UpdateApplicativo,trg_DeleteA

pplicativo)

Di seguito viene illustrato il codice esempio per un trigger utilizzato per l’inserzione nella base di dati di un nuovo dipendente:

25

Codice del trigger trg_InsertDettaglioDipendente

Un secondo esempio riguarda il trigger adibito all’aggiornamento automatico dei dati anagrafici di un dipendente esistente:

Codice del trigger trg_UpdateDettaglioDipendente

Con la creazione di questi particolari tipi di trigger, ogni modifica effettuata dagli utenti da programma di front-end sulle viste disponibili può venire gestita in modo da andare a modificare in maniera controllata le tabelle della base dati.

26

5.2.2 – Stored Procedures

Di seguito sono state create tre stored procedures per l’assegnazione e rimozione dei ruoli e per la creazione di un nuovo numero di protocollo nell’apposita tabella.

La prima di queste spAssegnaRuolo è stata creata per memorizzare nella tabella di sponda tbl_PersonaRuolo le persone e i ruoli ad esse assegnati tramite creazione di una nuova pratica; inoltre il compito di questa procedura è anche quello di tracciare la modifica effettuata andando a scrivere nella tabella tbl_DettaglioProtocollo, inserendo in essa Ruolo e Matricola aggiunti e il numero di Protocollo ad essi collegato, oltre che inserire la stringa ‘Aggiunta’ nel campo Operazione Effettuata della stessa tabella. Alla procedura sono passati come parametri in ingresso l’ ID del protocollo, la Matricola e l’ID del ruolo in questione.

Codice della procedura spAssegnaRuolo

La seconda procedura spRevocaRuolo è stata creata in maniera molto simile alla precedente; esse differiscono per il fatto che quest’ultima sia di rimozione dei ruoli invece che di assegnazione. Di seguito ne viene illustrato il codice:

27

Codice della procedura spRevocaRuolo

L’ultima stored procedure creata è la spNuovoProtocollo la quale si occupa della creazione di un nuovo numero di protocollo andando a inserire nella tabella tbl_Protocollo la data attuale e la matricola dell’operatore che ha creato il nuovo protocollo; la matricola viene passata come parametro alla procedura.

Codice della procedura spNuovoProtocollo

Tutte queste procedure verranno chiamate in maniera opportuna all’interno del programma che accede alla base dati.

28

6. REALIZZAZIONE DELL’INTERFACCIA UTENTE

Per la realizzazione dell’interfaccia utente si è scelto di utilizzare il linguaggio di programmazione C# e la stesura del codice è avvenuta sfruttando la suite Microsoft Visual Studio 2008 Professional, in quanto perfettamente compatibile con il lato server dell’applicativo. Il componente per l’accesso ai dati che si frappone tra Sql Server e l’interfaccia utente è ADO.NET facente parte del frame-work .NET.

6.1 – ADO.NET

ADO.NET è costituito da vari componenti; fondamentali sono il DataProvider e il DataSet.

Il primo serve a mantenere la connessione con la base dati fisica ed è specifico per ogni fonte dati; sono disponibili infatti DataProvider per connessioni di tipo OleDb, Oracle e quello utilizzato per l’applicativo trattato in questo progetto, specifico per le connessioni a Sql Server.

Per quanto riguarda il secondo componente, esso può essere visto come la rappresentazione dei dati contenuti in memoria centrale, dati che sono nient’altro che la copia della data source fisica con tutte le tabelle e le relazioni. Fondamentale è che il DataSet lavori in maniera “disconnessa” rispetto alla fonte dati in quanto non è connesso direttamente ad essa; a fare da ponte tra le due componenti è l’oggetto DataAdapter, il quale fornisce metodi per trasferire informazioni contenute nel DataSet alla base dati e viceversa.

6.2 – REALIZZAZIONE DEL FRONT-END

Sfruttando le nozioni riguardanti ADO.Net si è proceduto creando un nuovo progetto con Visual Studio 2008 e associando il DataSet alla sorgente dati costituita dal database; così facendo è stato possibile creare sette windows-form:

29

- AssegnazioneRuoli.cs- Dipendente.cs- ElencoDipendenti.cs- Home.cs - Reparti.cs- RiepilogoAssegnazioneRuoli.cs- Ruoli.cs

Nelle form sono stati utilizzati prevalentemente oggetti del tipo DataGridView, che è stato possibile popolare con i dati del database grazie al metodo Fill fornito dal TableAdapter, pulsanti contenenti codice da scatenare all’evento onclick e combo-box legate a viste del database. Qui di seguito vengono illustrate più a fondo le form fondamentali del prototipo:

- La form Home.cs è stata creata per essere la prima ad aprirsi con l’esecuzione del programma; essa contiene il logo dell’azienda e i pulsanti per accedere alle altre form:

Home.cs

- La form Dipendente.cs fornisce la possibilità agli utenti di inserire nella base dati i dati anagrafici di nuovi dipendenti o modificare e cancellare quelli pre-esistenti; questa form contiene un DataGridView con l’elenco dei dipendenti prelevato dalla vista view_DettaglioDipendente tramite il metodo fill del tableadpater, autogenerato da Visual Studio; inoltre contiene i campi in dettaglio del dipendente selezionato dall’elenco, sempre ricavati dalla medesima vista; è presente anche un controllo combo box che fornisce la possibilità di selezionare il reparto di

30

appartenenza del dipendente da un elenco, anche questo popolato dal metodo fill.

Dipendente.cs

Per quanto riguarda la parte di codice non autogenerato, c’è stato il bisogno di definire i comandi di tipo update, insert e delete affinchè poi potessero essere utilizzati dal metodo update del tableadapter, responsabile della propagazione delle modifiche dal dataset alla base dati dopo la pressione del pulsante Salva.

Di seguito viene illustrata una porzione di codice riguardante la definizione del comando update; la sintassi per i comandi insert e delete è molto simile:

31

Codice esempio per la definizione del comando UPDATE per l’aggiornamento dell’anagrafica di un dipendente nel database.

Il pulsante Salva contiene all’interno del proprio evento OnClick due righe di codice utilizzate per il corretto salvataggio delle modifiche nel database.

Nel dettaglio il comando EndEdit serve per l’aggiornamento del dataset con i contenuti dei vari controlli della form; il comando Update invece chiama le istruzioni update, insert e delete definite in precedenza in maniera da aggiornare il database.

Codice del pulsante Salva

- Per quanto concerne la parte riguardante la creazione di una nuova pratica e pertanto dell’assegnazione/rimozione di ruoli ai dipendenti si sono andate a creare due form: AssegnazioneRuoli.cs e

32

RiepilogoAssegnazioneRuoli.cs.La prima delle due form contiene un elemento DataGridView, riempito dalla vista view_RuoliAssegnati, e più combo box per la scelta dell’operatore, dei ruoli e dei dipendenti ai quali assegnare le abilitazioni, oltre che pulsanti per salvare le modifiche; per rimuovere i ruoli di un dipendente basta selezionare la riga desiderata dal DataGrid e cancellarla.

AssegnazioneRuoli.cs

Per la parte riguardante il pulsante Abilita modifiche si è andati a scrivere codice che, dopo aver controllato se dalla combo box apposita è stato scelto un operatore, crea un comando per l’esecuzione della stored procedure spNuovoProtocollo, la quale si occupa della creazione di un nuovo numero di pratica:

Codice di Abilita modifiche

33

Per la rimozione dei ruoli si è creato un nuovo comando delete, il quale si occupa della chiamata alla stored procedure spRevocaRuolo passandole in ingresso gli appositi parametri idProtocollo, Matricola e Ruolo in maniera che essa gestisca la rimozione dei ruoli selezionati dalla tabella corretta e aggiunga al dettaglio protocollo l’operazione di rimozione effettuata.

Codice per la rimozione dei ruoli

Il pulsante Assegna invece, dopo aver controllato che entrambi i controlli combo box della scelta dipendente e ruolo abbiano dei valori selezionati, si occupa della chiamata alla stored procedure spAssegnaRuolo passandole come parametri oltre all’ idProtocollo anche i valori selezionati dalle due combo box in questione:

Codice del pulsante Assegna Ruoli

34

Infine il pulsante Salva sfrutta il metodo Update per aggiornare il database e il pulsante Riepilogo Modifiche va ad aprire un’altra form contenente il dettaglio dei protocolli come da figura seguente:

RiepilogoAssegnazioniRuoli.cs

35

7. CONCLUSIONI

Lo sviluppo della base dati e del prototipo software per la sua gestione si è concluso con esito positivo.

Le funzionalità principali dell’applicazione disponibili agli operatori sono:

Gestione delle anagrafiche dei dipendenti e relativi reparti e sedi. Gestione degli applicativi e dei ruoli correlati ad essi. Possibilità di creazione di nuove pratiche di modifica ruoli dei dipendenti.

Il vantaggio principale ottenuto dall’utilizzo di questo applicativo per gli operatori dell’azienda sanitaria è la tracciabilità delle operazioni di modifica dei ruoli effettuate, oltre che la memorizzazione dei ruoli assegnati ai dipendenti.

Il lavoro svolto può essere quantificato principalmente in: Progettazione e creazione di un database contenente 9 tabelle. 8 viste create in Sql Server. 15 trigger implementati in Sql Server. 3 stored procedures create. 500 righe di codice non autogenerato in Visual Studio.

Lo sviluppo futuro del progetto riguarderà, dopo presa visione del prototipo da parte del cliente, aggiunta di ulteriori funzionalità utili per il prodotto finale, miglioramenti per quanto riguarda i vincoli non funzionali del prodotto, una fase di test e collaudo in sede seguita da installazione e messa in opera dell’applicativo finale.

36

8. BIBLIOGRAFIA

Atzeni, Ceri, Paraboschi, Torlone “Basi di dati: modelli e linguaggi di interrogazione”, Mc Graw-Hill

Groh, Stockman, Powell, Prague, Irwin, Reardon “Microsoft Office – Access 2007 Bible” , Wiley Publishing

M. Fermeglia “Slides del corso di complementi di basi di dati”

Google Home Page, http://www.google.com

Microsoft Developer Network, http://msdn.microsoft.com

37