Porting evolutivo dell'applicazione per la gestione dei dispositivi del Comune di Trieste

UNIVERSITÀ DEGLI STUDI DI TRIESTE

Dipartimento di Ingegneria e Architettura

Corso di laurea triennale in

Ingegneria Informatica

PORTING EVOLUTIVO DELL’APPLICAZIONE PER LA GESTIONE DEI DISPOSITIVI MOBILI DEL COMUNE DI TRIESTE

Laurenado: Relatore:

Omar Zacchigna Chiar.mo Prof. Maurizio Fermeglia

Anno Accademico 2012/13

SOMMARIO

1 Introduzione..................................................................................................................4

2 Analisi............................................................................................................................6

2.1 Base di dati.............................................................................................................6

2.1.1 Considerazioni Preliminari..............................................................................9

2.2 Client pre-esistente..............................................................................................11

2.3 Raccolta dei requisiti............................................................................................13

2.3.1 Requisiti sui dati............................................................................................13

2.3.2 Operazioni sui dati........................................................................................14

2.3.3 Requisiti applicazione client..........................................................................15

3 Riprogettazione della base di dati...............................................................................16

3.1 Progettazione concettuale...................................................................................17

3.1.1 Glossario dei termini.....................................................................................17

3.1.2 Strutturazione dei requisiti...........................................................................17

3.1.3 Schema scheletro..........................................................................................19

3.1.4 Schema ER finale...........................................................................................22

3.1.5 Analisi entità.................................................................................................22

3.1.6 Analisi associazioni e cardinalità...................................................................25

3.1.7 Business rules................................................................................................29

3.1.8 Schema E-R finale con attributi e cardinalità................................................30

3.2 Progettazione Logica............................................................................................31

3.2.1 Tavola dei volumi..........................................................................................31

3.2.2 Tavola delle operazioni.................................................................................32

3.2.3 Analisi delle ridondanze................................................................................32

3.2.4 Eliminazione delle gerarchie.........................................................................34

3.2.5 Partizionamento/accorpamento di concetti.................................................35

3.2.6 Partizionamento relazioni molti a molti........................................................36

3.2.7 Scelta degli identificatori principali...............................................................36

2

3.2.8 Schema E-R ristrutturato...............................................................................37

3.2.9 Schema logico finale.....................................................................................38

3.3 Documentazione aggiuntiva................................................................................39

3.4 Adeguamento della base dati..............................................................................41

4 Progettazione e Realizzazione dell’applicazione.........................................................42

4.1 Strumenti Utilizzati...............................................................................................42

4.2 Attori del sistema e casi d’uso.............................................................................43

4.2.1 Attori del sistema..........................................................................................43

4.2.2 Casi d’uso......................................................................................................43

4.3 Diagramma di attività per il caso d’uso “Assegnazione Dispositivo”...................47

4.4 Interfaccia utente.................................................................................................48

4.5 Strutturazione dell’applicazione..........................................................................49

4.6 Implementazione.................................................................................................50

4.6.1 Caso d’uso Assegnazione Dispositivo............................................................50

5 Conclusioni..................................................................................................................54

6 Bibliografia..................................................................................................................55

3

1 Introduzione

La tesi consiste nello sviluppo di un’applicazione web per la gestione dei dispositivi mobili (cellulari, smartphone, tablet…) e delle SIM telefoniche assegnate ai dipendenti del Comune di Trieste.

L’applicativo dovrà far uso di una base di dati pre-esistente, gestita dal DBMS Oracle. Allo stato attuale la gestione avviene per mezzo di un’applicazione sviluppata con tecnologia Microsoft VBA.

Lo sviluppo di una nuova applicazione nasce dall’esigenza di:

Rendere l’applicazione indipendente dall’installazione e configurazione di driver e software quale Microsoft Access .

Implementare la multi-utenza per mezzo di un sistema di autenticazione e autorizzazione basato su ruoli.

Implementare nuove funzionalità.

Il risultato a cui si è giunti è una parziale riprogettazione della base di dati esistente e lo sviluppo di un prototipo dell’applicazione.

Le principali fasi del lavoro svolto possono venir riassunte nel seguente modo:

Analisi della base di dati e dell’applicazione esistente Raccolta ed analisi dei requisiti Modifiche alla base di dati esistente Progettazione e sviluppo del nuovo applicativo client

Vincoli progettuali

L’applicazione dovrà far uso della base di dati esistente, che dovrà venir modificata per soddisfare i nuovi requisiti.

L’applicazione client dovrà venir sviluppata con il linguaggio di programmazione PHP versione 4.2. Il web server a disposizione sarà Apache.

Non ci sono particolari vincoli riguardanti la sicurezza in quanto l’applicativo verrà reso disponibile alla sola rete intranet del Comune.

Non ci sono particolari vincoli sulla velocità dell’applicazione.

4

Analisi dei capitoli

Nel secondo capitolo viene trattato lo studio della situazione iniziale, vengono messi alla luce gli errori commessi durante la progettazione della base di dati pre-esistente e si procede con la raccolta dei requisiti.

Il terzo capito affronta la ri-progettazione della base di dati in funzione dei nuovi requisiti e delle problematiche emerse nella fase di analisi.

Nel quarto capitolo viene esposta la progettazione e realizzazione della nuova applicazione.

5

2 Analisi

La fase di analisi ha avuto inizio con lo studio delle realizzazioni pre-esistenti (base di dati e applicativo client) e la consultazione dello sviluppatore interno alla struttura ospitante.

Individuate tutte le caratteristiche dell’applicazione pre-esistente è stato possibile procedere con la raccolta dei nuovi requisiti per mezzo di interviste al committente.

2.1 Base di dati

La base di dati relazionale pre-esistente, realizzata nel 2008, è gestita dal DBMS Oracle 9.2.

Essa contiene tutti i dati inerenti le SIM e i dispositivi in possesso dal Comune di Trieste nonché le informazioni riguardanti i dipendenti (sia quelli attualmente assunti che quelli non attivi).

La base di dati pre-esistente fa parte di uno schema più ampio, condiviso tra diverse applicazioni. Nel seguito di questo capitolo verranno documentate soltanto le 19 tabelle rilevanti ai fini del progetto. Esse vengono accedute dal client per la gestione delle SIM e dispositivi (documentato nel capitolo 2.2) e dall’applicativo intranet dell’ente ospitante.

A quest'ultimo viene affidata la gestione dei dipendenti (inserimento e modifica, variazione dell’ufficio di afferenza, visualizzazione di informazioni riguardanti il ruolo ricoperto …) e la visualizzazione delle sim attualmente assegnate ad un dato referente.

Allo stato attuale gli accessi in lettura e scrittura avvengono direttamente sulle tabelle, non sono presenti viste sui dati, procedure ne trigger.

In figura 1 viene riportato lo schema logico mentre in figura 2 viene riportata una rappresentazione concettuale con il modello Entità-Relazione, ricostruita a partire dalla base di dati relazionale preesistente.

Nel glossario del capitolo 3.1.1 vengono descritti in linguaggio informale i concetti rappresentati da ciascuna entità.

6

Figura 1

8

Figura 2

9

2.1.1 Considerazioni Preliminari

Lo studio della base di dati, unito all’osservazione delle singole occorrenze ha portato alla luce diversi errori di progettazione che hanno dato origine alle seguenti problematiche:

Abuso dei campi nota per far fronte a necessità di cui il progettista non ha originariamente tenuto conto.

Violazione delle business rules. Disallineamento dei dati.

Nella seguente tabella vengono riportate alcune importanti osservazioni preliminari:

DWH_SIM , DWH_DISPOSITIVI

Non è possibile risalire alle informazioni relative alle precedenti assegnazioni di un dato dispositivo o SIM se non ricorrendo al contenuto del campo NOTA (ammesso che l’informazione sia stata in esso riportata).

Per revocare un dispositivo (o SIM) , esso viene assegnato al referente con ID pari a 0 (nome referente ‘NON DEFINITO’ che afferisce all’ufficio ‘U0000’).

Nella base di dati risultano esserci SIM e dispositivi assegnati a dipendenti non più attivi.

Nella base di dati risultano esserci SIM e dispositivi di cui non è noto il codice IMEI

DWH_DISPOSITIVI

Il campo nota è stato utilizzato in più del 70% dei record per memorizzare informazioni riguardanti:

date di assegnazione e revoca stato fisico del dispositivo (es. rotto, perso) posizione fisica del dispositivo (es. magazzino) precedente assegnatario.

Il campo STATO è usato per rappresentare informazioni disomogenee. I possibili valori sono: (NON DETERMINATO, Assegnato, Magazzino, Magazzino 202, Magazzino 226, Rotto-Magazzino, Distrutto, Rubato/Perso, In riparazione).I tre concetti rappresentati sono:

Assegnazione del dispositivo (informazione ridondante e disallineata) Posizione fisica del dispositivo (Magazzino 202, Magazzino 226, Rubato/Perso …) Stato fisico del dispositivo (esempio: rotto, distrutto)

Il valore dell’attributo MODELLO determina il valore dell’attributo MARCA (Dipendenza funzionale MODELLO->MARCA). Ciò comporta ridondanza e anomalie di aggiornamento.

Gli attributi DATA_SCADENZA, MOTIVO_RICONSEGNA e ACESSORI non sono mai stati utilizzati.

DWH_SIM

Il campo nota è stato utilizzato in più del 70% dei record per memorizzare informazioni riguardanti:

date di assegnazione e revoca

precedente assegnatario date di attivazione, dismissione e sospensione.

A ciascuna SIM può venir associato più di un piano tariffario, ma questo viola le regole dei gestori telefonici (che impongo al massimo un piano tariffario per SIM).

Le date di attivazione, dismissione, sospensione sono spesso incongruenti con il valore del campo stato.

DWH_CEC_NON_UTIL

La tabella DWH_CEC_NON_UTIL è stata introdotta in previsione di un’ulteriore gerarchizzazione (non ancora avvenuta) dell’ente ospitante. Nonostante sia del tutto inutile ed appesantisca le query, una sua eventuale rimozione comprometterebbe il funzionamento dell’applicativo intranet.

Tabella 1

11

2.2 Client pre-esistente

Il client per la gestione dei dispositivi e SIM consiste in un’applicazione sviluppata in ambiente Microsoft Office VBA (Visual Basic for Applications).

Nella prima schermata figurano le seguenti 5 voci: Referenti, SIM Dispositivi, Tabelle e Rapporti. Selezionando ognuna di esse viene aperta la corrispettiva schermata.

Schermata Referenti

Questa schermata consente di visualizzare le informazioni relative ad un dato referente (qualifica, servizio svolto e ufficio di afferenza) e tutte le SIM e i dispositivi ad esso assegnati.

Di ogni SIM si visualizza numero, tipo, IMEI e se visibile all’interno della rete intranet.

Di ogni dispositivo si visualizza ID, IMEI, marca e modello.

È possibile cercare un referente per nome e cognome oppure per codice ID.

Schermata Gestione DISPOSITIVI

Questa schermata visualizza tutte le informazioni relative ad un dato dispositivo (eventuale referente, marca, modello, stato e le date di scadenza, inserimento, assegnazione, consegna e riconsegna).

Si può risalire ad un dispositivo per codice ID oppure IMEI.

Sempre da questa schermata è possibile inserire nella base dati un nuovo dispositivo.

12

Schermata Gestione SIM

Analogamente a quanto visto per i dispositivi, questa schermata visualizza tutte le informazioni relative ad una data SIM, tra le quali figurano anche il piano tariffario e i servizi di SIM attivi.

Si può risalire ad una SIM per codice ID, IMEI oppure numero telefonico. Sempre da questa schermata è possibile inserire nella base dati una nuova SIM.

Rapporti

Selezionando la voce rapporti è possibile accedere ai report “SIM non assegnate” e “dispositivi non assegnati”. Tali report non risultano di nessuna utilità in quanto i dati all’interno della base dati sono disallineati.

Tabelle

Questa parte dell’applicazione consente l’inserimento di dati nelle tabelle: DWH_GRUPPI, DWH_TIPI, DWH_STATI, DWH_SERVIZI, DWH_CONTRATTI, DWH_STATI_DISPOSITIVI, DWH_PIANI_TARIFFARI, DWH_MODELLO_DISPOSITIVO, DWH_MARCA_DISPOSITIVO, DWH_GRUPPO_DISPOSITIVO.

13

2.3 Raccolta dei requisiti

Le considerazioni espresse nel capitolo 2.1.1 evidenziano l’inadeguatezza della realizzazione pre-esistente a far fronte ai requisiti iniziali e a garantire l’integrità dei dati.

Alla luce di questi fatti si è proceduto con un’intervista al committente, al fine di stabilire con certezza tutti i requisiti e le business rules che la nuova applicazione dovrà soddisfare.

2.3.1 Requisiti sui dati

Si vuole realizzare una base di dati per la gestione di dispositivi mobili e SIM telefoniche.

Di ogni SIM si vuole memorizzare il numero telefonico, il codice ICCD, la memoria, la data di acquisizione, la classe, la visibilità, il gruppo di appartenenza, il tipo di SIM, il contratto di fornitura, lo stato, il piano tariffario, il codice dell’eventuale referente, i servizi attivi ed opzionalmente il numero breve ed una nota.

Per ogni stato (gli stati possibili sono: attiva, non attiva, dismessa, sospesa) rappresentiamo la data in cui è avvenuta la modifica dello stato.

Per ogni contratto rappresentiamo la denominazione del contratto ed opzionalmente la data di inizio, di fine e di proroga.

Di ogni dispositivo si vuole memorizzare il codice IMEI, la data di inserimento, il modello, il gruppo di appartenenza del dispositivo, lo stato fisico del dispositivo ed opzionalmente una nota. Gli stati fisici sono: funzionante, rotto (riparabile), distrutto (non riparabile), in riparazione.

I dispositivi possono essere assegnati oppure non assegnati. Dei dispositivi non assegnati interessa la posizione fisica del dispositivo (es.: Magazzino, Magazzino 202, Magazzino 226 (…) Perso/Rubato).

Ad ogni revoca di un dispositivo si deve stabilirne la posizione fisica.

Per ogni modello di dispositivo si vuole memorizzare la fascia (alta, media, bassa) ed il tipo di dispositivo (cellulare, tablet, smartphone …) Di ogni modello si vuole memorizzare la marca.

Di ogni Referente si vuole memorizzare il cognome ed il nome, l’ufficio a cui afferisce, la matricola, l’indirizzo Email e opzionalmente una nota.

I referenti possono essere direttori di area, direttori di servizio, amministratori oppure non avere un ruolo specifico.

14

Di ogni ufficio si vuole memorizzare una descrizione e il codice dell’ufficio. Ogni ufficio deve afferire ad un servizio.

Ogni servizio deve afferire ad un’area. Di ogni servizio si vuole memorizzare una descrizione e il codice del servizio.

Di ogni area si vuole memorizzare il codice dell’area e una descrizione.

A ciascun referente possono venir assegnate zero o più SIM.

A ciascun referente possono venir assegnati zero o più dispositivi.

Di ciascun referente si vogliono sapere le SIM e i dispositivi attualmente assegnati (data di assegnazione) e le SIM e i dispositivi assegnati in passato (data di assegnazione e revoca).

Una SIM (o dispositivo) non può essere assegnata contemporaneamente a più di un referente.

Una SIM (o dispositivo) in passato può essere stata assegnata più di una volta allo stesso referente.

Dispositivi e Sim non devono venir assegnati a referenti che afferiscono all’ufficio avente codice ‘U0000’.

I referenti ai quali risultino assegnate SIM e/o dispositivi non devono poter afferire all’ufficio avente codice ‘U0000’.

2.3.2 Operazioni sui dati

Nella seguente tabella vengono riportate le operazioni da effettuare sui dati e la frequenza (stimata) delle operazioni. Tali informazioni saranno determinanti nella fase di progettazione logica.

OPERAZIONE FREQUENZA

OP1 Inserimento di un nuovo Dispositivo 8/SETTIMANA

OP2 Inserimento di una nuova SIM 6/SETTIMANA

OP3 Assegnazione di un Dispositivo 11/SETTIMANA

OP4 Assegnazione di una SIM 8/SETTIMANA

OP5 Revoca di un Dispositivo 6/SETTIMANA

OP6 Revoca di una SIM 4/SETTIMANA

OP7 Modifica di un Dispositivo 10/MESE

OP8 Modifica di una SIM 15/MESE

OP9 Visualizza tutte le SIM (NUMERO, ICCD, STATO) a cui risulta 10/MESE

15

attivo un dato piano tariffario

OP10 Visualizza tutte le SIM (NUMERO, ICCD, STATO) a cui risulta attivo un dato servizio di SIM

15/MESE

OP11 Visualizza tutti i referenti a cui risulta assegnato un dato modello di dispositivo

5/MESE

OP12 Visualizzare tutte le SIM (NUMERO, ICCD) e i dispositivi(IMEI, MARCA, MODELLO, FASCIA ) attualmente assegnati ad un dato referente

5/SETTIMANA

OP13 Visualizzare tutte le SIM (NUMERO) attualmente assegnate ad un dato referente assunto

50/GIORNO

OP14 Visualizza tutti i dati di una SIM, incluse le informazioni relative all’assegnazione corrente ed alle assegnazioni passate

15/GIORNO

OP15 Visualizza tutti i dati di un dispositivo, incluse le informazioni relative all’assegnazione corrente ed alle assegnazioni passate

15/GIORNO

OP16 Dato il codice di un’area(servizio/ufficio) visualizzare i dispositivi (IMEI, MARCA, MODELLO, NOTA, REFERENTE) che risultano attualmente assegnati ai referenti che afferiscono a tale area(servizio/ufficio)

5/MESE

OP17 Dato il codice di un’area(servizio/ufficio) visualizzare le sim (ICCD, NUMERO, NOTA, REFERENTE) che risultano attualmente assegnati ai referenti che afferiscono a tale area(servizio/ufficio)

5/MESE

OP18 Visualizzare tutti i dispositivi ( MARCA, MODELLO, FASCIA) non assegnati, funzionanti e non rubati/persi

1/SETTIMANA

OP19 Visualizzare tutte le sim (NUMERO, ICCD, PIANO TARIFFARIO) non assegnate e non disattivate

1/SETTIMANA

Tabella 2

2.3.3 Requisiti applicazione client

Le operazioni sui dati dovranno essere accessibili ai soli utenti con ruolo di direttore di area, direttore di servizio o amministratore.

Per poter effettuare una qualsiasi operazione sui dati i referenti dovranno autenticarsi inserendo indirizzo E-mail e password, sfruttando uno script di login pre-esistente.

Il referenti con ruolo di amministratore avranno accesso alle tutte le operazioni di visualizzazione, inserimento, modifica, assegnazione e revoca di dispositivi e SIM.

I referenti con ruolo di amministratore dovranno poter modificare il ruolo degli altri referenti.

16

I referenti con ruolo di direttore di area e servizio avranno accesso alle sole funzionalità di visualizzazione.

I dati visibili al direttore di area saranno solo quelli riguardanti SIM e dispositivi attualmente assegnati a referenti che afferiscono alla sua stessa area.

I dati visibili al direttore di servizio saranno solo quelli riguardanti SIM e dispositivi attualmente assegnati a referenti che afferiscono al suo stesso servizio.

Si vuole agevolare l’inserimento di un numero indefinito di dispositivi e SIM che differiscono unicamente per il codice IMEI.

Si vuole dare la possibilità di esportare il risultato dei report (operazioni 16, 17, 18 e 19 di tabella 2) in formato Microsoft Excel, anche in forma tabellare.

3 Riprogettazione della base di dati

Nota Metodologica

I vincoli di progetto imporrebbero modifiche mirate a soddisfare i nuovi requisiti, senza stravolgere quanto già esistente. Un approccio di questo tipo risulta tuttavia in conflitto con la necessità di colmare le problematiche espresse nel capitolo 2.1.1.

In accordo con il committente si è perciò deciso di rivedere la base di dati seguendo una linea per quanto possibile conservativa.

Per la ri-progettazione verrà adottata una strategia mista, che consiste nel suddividere i requisiti in componenti separate ed allo stesso tempo creare uno schema scheletro contente i concetti principali dell’applicazione.

Durante ogni fase di raffinamento dei componenti verrà confrontato il diagramma E-R di figura 2, con lo scopo di ripercorre, per quanto possibile, le scelte iniziali.

In particolare:

Dove possibile, verranno mantenuti gli attuali nomi di tabelle e campi. Per le eventuali nuove tabelle verrà seguita la convenzione (non scritta) attuale.

Dove possibile verranno mantenute le chiavi primarie attuali. Tra le varie soluzioni che si presenteranno durante la fase di ri-progettazione

dovrà venir scelta quella percorsa in precedenza, purché non risulti palesemente errata.

Per agevolare la lettura, durante tutta la fase di progettazione concettuale e logica il prefisso DWH_ verrà omesso in tutte le entità e relazioni.

17

3.1 Progettazione concettuale

La progettazione concettuale consiste nella costruzione di uno schema E-R in grado di descrivere al meglio le specifiche sui dati.

3.1.1 Glossario dei termini

Viene di seguito riportato un glossario dei termini allo scopo di eliminare possibili ambiguità relative ai concetti emersi durante la raccolta dei requisiti.

TERMINE TABELLA * DESCRIZIONE SINONIMI COLLEGAMENTI

REFERENTE REFERENTI Dipendente a cui possono venir assegnate SIM e dispositivi.

Dipendente, Assegnatario

SIM, DISPOSITIVI, CEC_CEC

SIM SIM SIM Card a cui è associato un numero di telefono.

REFERENTI

DISPOSITIVO DISPOSITIVI Dispositivo mobile (es. cellulare, tablet...)

REFERENTI

UFFICIO CEC_CEC Ordinamento amministrativo elementare (es. affari esteri)

CEC_SERVIZIO, REFERENTI

SERVIZIO CEC_SERVIZIO Ordinamento amministrativo che raccoglie uffici di interesse comune.

CEC_CEC, CEC_AREA

AREA CEC_AREA Ordinamento amministrativo che raccoglie servizi di interesse comune.

CEC_SERVIZIO

3.1.2 Strutturazione dei requisiti

Nella tabella seguente le frasi vengono raggruppate per concetti comuni.

FRASI DI CARATTERE GENERALE

Si vuole realizzare una base di dati per la gestione di dispositivi mobili e SIM telefoniche.

FRASI RELATIVE AI REFERENTI

Di ogni Referente si vuole memorizzare il cognome ed il nome, l’ufficio a cui afferisce, la matricola, l’indirizzo Email ed opzionalmente una nota.I referenti possono essere direttori di area, direttori di servizio, amministratore oppure senza ruolo specifico.A ciascun referente possono venir assegnate zero o più SIM.

18

A ciascun referente possono venir assegnati zero o più Dispositivi.Di ciascun referente si vogliono sapere le sim attualmente assegnate (data di assegnazione) e le sim assegnate in passato (data di assegnazione e revoca). Di ciascun referente si vogliono sapere i dispositivi attualmente assegnati (data di assegnazione) e i dispositivi assegnati in passato (data di assegnazione e revoca). I referenti ai quali risultino assegnate sim non devono poter afferire all’ufficio avente codice ‘U00000’.I referenti ai quali risultino assegnati dispositivi non devono poter afferire all’ufficio avente codice ‘U00000’.

FRASI RELATIVE ALLE SIM

Di ogni SIM si vuole memorizzare il numero telefonico, il codice ICCD, la memoria, la data di acquisizione, la classe, la visibilità, il gruppo di appartenenza, il tipo di sim, il contratto di fornitura, lo stato, il piano tariffario, il codice dell’eventuale referente, i servizi attivi ed opzionalmente il numero breve ed una nota.

Per ogni stato (gli stati possibili sono: attiva, non attiva, dismessa, sospesa) rappresentiamo la data in cui è avvenuta la modifica dello stato.

Per ogni contratto rappresentiamo la denominazione del contratto ed opzionalmente la data di inizio, di fine e di proroga.Una SIM non può essere assegnata contemporaneamente a più di un referente.Una SIM in passato può essere stata assegnata più di una volta allo stesso referente.Le SIM non devono venir assegnate a referenti che afferiscono all’ufficio avente codice ‘U0000’.

FRASI RELATIVE AI DISPOSITIVI


I dispositivi possono essere assegnati oppure non assegnati. Dei dispositivi non assegnati interessa la posizione fisica del dispositivo. (es.: Magazzino, Magazzino 202, Magazzino 226 (…) Perso/Rubato).

Ad ogni revoca di un dispositivo si deve stabilirne la posizione fisica.

Per ogni modello di dispositivo si vuole memorizzare la fascia (alta, media, bassa) ed il tipo di dispositivo (cellulare classico, smartphone, tablet …) Di ogni modello si vuole memorizzare la marca.Un dispositivo non può essere assegnato contemporaneamente a più di un referente.Una dispositivo in passato può essere stato assegnata più di una volta allo stesso referente.Dispositivi non devono venir assegnati a referenti che afferiscono all’ufficio avente codice ‘U0000’.

19

FRASI RELATIVE AGLI UFFICI

Di ogni ufficio si vuole memorizzare una descrizione e il codice dell’ufficio. Ogni ufficio deve appartenere ad un servizio.

FRASI RELATIVE AI SERVIZI

Ogni servizio deve appartenere ad un’area. Di ogni servizio si vuole memorizzare una descrizione e il codice del servizio.

FRASI RELATIVE ALLE AREE

Di ogni area si vuole memorizzare il codice dell’area e una descrizione.

3.1.3 Schema scheletro

Raffinamento entità Referente parte 1

Di ogni Referente si vuole memorizzare il cognome ed il nome, l’ufficio a cui afferisce, la matricola, l’indirizzo Email e opzionalmente una nota.

(*) Si dividono in direttori di area, direttori di servizio, amministratore e senza ruolo specifico.

20

I referenti possono essere direttori di area, direttori di servizio, amministratore oppure senza ruolo specifico (*)generalizzazione totale ed esclusiva

Di ogni ufficio si vuole memorizzare una descrizione e il codice dell’ufficio. Ogni ufficio deve afferire ad un servizio. Di ogni servizio si vuole memorizzare una descrizione e il codice del servizio. Ogni servizio deve afferire ad un’area. Di ogni area si vuole memorizzare il codice dell’area e una descrizione.

NOTA: L’entità CEC_NON_UTIL è stata introdotta per non corrompere il funzionamento dell’applicativo intranet. (si veda tabella 1 cap. 2.1.1).

Raffinamento entità Referente parte 2

A ciascun referente possono venir assegnate zero o più SIM e zero o più Dispositivi.

Di ciascun referente si vogliono sapere le SIM attualmente assegnate (data di assegnazione) e le SIM assegnate in passato (data di assegnazione e revoca).

Di ciascun referente si vogliono sapere i dispositivi attualmente assegnati (data di assegnazione) e i dispositivi assegnati in passato (data di assegnazione e revoca).

Raffinamento entità dispositivo

21


I dispositivi possono essere assegnati oppure non assegnati. Dei dispositivi non assegnati interessa la posizione fisica del dispositivo.(es.: Magazzino, Magazzino 202, Magazzino 226 (…) Perso/Rubato).

Per ogni modello di dispositivo si vuole memorizzare la fascia (alta, media, bassa) ed il tipo di dispositivo (cellulare classico, smartphone, tablet …) Di ogni modello si vuole memorizzare la marca.

Raffinamento entità SIM

Di ogni SIM si vuole memorizzare il numero telefonico, il codice ICCD, la memoria, la data di acquisizione, la classe, la visibilità, il gruppo di appartenenza, il tipo di sim, il contratto di fornitura, lo stato, il piano tariffario, i servizi attivi ed opzionalmente il numero breve ed una nota.

Per ogni stato (attiva, non attiva, dismessa, sospesa) rappresentiamo la data in cui è avvenuta la modifica dello stato.

Per ogni contratto rappresentiamo la denominazione del contratto ed opzionalmente la data di inizio, di fine e di proroga.

22

3.1.4 Schema ER finale

3.1.5 Analisi entità

REFERENTI

ID Identificatore numerico univoco (candidato chiave primaria)

REFERENTE Nome e cognome del referente

MATRICOLA Codice aziendale che identifica un referente

MAIL Indirizzo e-mail dell’ente associato a ciascun referente

23

NOTA Note riguardanti il referente (opzionale)

DIRETTORE AREA, DIRETTORE SERVIZIO, ADMIN, SENZA RUOLO

Nessun attributo

CEC_CEC

CEC_CEC Codice univoco che identifica l’ufficio (candidato chiave primaria)

CEC_DESCR Descrizione dell’ufficio

DWH_CEC_NON_UTIL (si veda tabella 1 di cap. 2.1.1)

CEC_NON_UTIL Codice univoco (candidato chiave primaria)

DESCR Descrizione

CEC_SERVIZIO

CEC_SERVIZIO Codice univoco che identifica il servizio (candidato chiave primaria)

DESCR Descrizione del servizio

CEC_AREA

CEC_AREA Codice univoco che identifica l’area (candidato chiave primaria)

DESCR_AREA Descrizione dell’Area

DISPOSITIVI

ID_DISPOSITIVO Identificatore numerico univoco (candidato chiave primaria)

IMEI (International Mobile Equipment Identity), codice numerico che identifica univocamente un terminale mobile

DATA_INSERITO Data in cui il dispositivo è stato inserito nella base dati

NOTA Nota relative al dispositivo (opzionale)

NON ASSEGNATO, ASSEGNATO

Nessun attributo

MODELLO_DISPOSITIVI

MODELLO Modello del dispositivo (es.: Iphone 4) (candidato chiave primaria)

MARCA_DISPOSITIVI

24

MARCA Marca del dispositivo (es.:Nokia) (candidato chiave primaria)

FASCIA ALTA, FASCIA MEDIA, FASCIA BASSA

Nessun attributo

TIPO_MODELLO

TIPO Tipo di dispositivo (es.: cellulare, smartphone, tablet) (candidato chiave primaria)

STATI_DISPOSITIVI

STATO Stato del dispositivo (funzionante, rotto, distrutto …) (candidato chiave primaria)

GRUPPO_DISPOSITIVOID_GRUPPO_DISPOSITIVO Identificatore numerico univoco (candidato chiave primaria)GRUPPO_DISPOSITIVO Gruppo a cui il dispositivo appartiene (es. elezioni, censimento,

fonia mobile …)

POSIZIONE_DISPOSITIVOPOSIZIONE Posizione fisica del dispositivo. (candidato chiave primaria)

SIM

ID_SIM Identificatore numerico (candidato chiave primaria)

NUMERO Numero di telefono associato alla SIM

VISIBILITA Indica se visibile all’interno dell’intranet (Flag vero falso)

ICCD Integrated Circuit Card ID, codice numerico univoco che identifica la SIM.

MEMORIA Memoria della sim (es. 64k, 128k…)

BREVE Numero ‘scorciatoia’ univoco all’interno dell’intranet (opzionale)

DATA_ACQUISIZIONE Data in cui la sim è stata inserita nella base dati

CLASSE Classe di Abilitazione (esempio G,E..)

NOTA Nota riguardante la sim (opzionale)

ID_REFERENTE Codice Identificativo del referente a cui assegnata la sim.

TIPI_SIM

ID_TIPO_SIM Identificatore numerico univoco (candidato chiave primaria)

25

TIPO_SIM Tipo di SIM (es. voce, dati, bis primaria, bis secondaria …)

STATI_SIM

STATO Stato della Sim (SOSTITUITA, NON ATTIVA, ATTIVA, DISMESSA, SOSPESA) (candidato chiave primaria)

GRUPPI_SIM

ID_GRUPPO_SIM Identificatore numerico univoco (candidato chiave primaria)

GRUPPO_SIM Gruppo a cui la sim appartiene (es. NESSUNO, elezioni, censimento, fonia mobile …)

CONTRATTI

ID_CONTRATTO Identificatore numerico univoco (candidato chiave primaria)

CONTRATTO Nome del contratto di fornitura

DATA_INIZIO Data inizio contratto (opzionale)

DATA_FINE Data fine contratto (opzionale)

DATA_PROROGA Data proroga contratto (opzionale)

SERVIZI

ID_SERVIZIO Identificatore numerico univoco (candidato chiave primaria)

SERVIZIO Nome del servizio (es.: internet flat, blackberry chat …)

PIANI_TARIFFARI

ID_PIANO Identificatore numerico univoco (candidato chiave primaria)

DENOMINAZIONE Nome del piano tariffario

3.1.6 Analisi associazioni e cardinalità

AFFERENZA R-U

Collega l’entità REFERENTI con l’entità CEC_CEC (Ufficio)

cardinalità UNO A MOLTI: Un referente afferisce ad un solo ufficio, ma ad un ufficio possono afferire molti referenti

AFFERENZA U-N_U

Collega l’entità CEC_CEC con l’entità CEC_NON_UTIL

cardinalità UNO A MOLTI: Un Ufficio afferisce ad un solo CEC_NON_UTIL, ma ad un CEC_NON_UTIL possono afferire molti uffici

26

AFFERENZA N_U-S

Collega l’entità CEC_NON_UTIL con l’entità CEC_SERVIZIO

cardinalità UNO A MOLTI: Un CEC_NON_UTIL afferisce ad un solo Servizio, ma ad un Servizio possono afferire molti CEC_NON_UTIL

AFFERENZA S-A

Collega l’entità CEC_SERVIZIO con l’entità CEC_AREA

cardinalità UNO A MOLTI: Un Servizio afferisce ad una sola Area, ma ad ogni Area possono afferire molti Servizi

ASSEGNAZIONE-S CORRENTE

Collega l’entità SIM con l’entità REFERENTI

cardinalità UNO A MOLTI: Ad un referente possono essere correntemente assegnate più SIM, ma una sim può essere correntemente assegnata ad un solo referente

DATA_ASSEGNAZIONE Data in cui la SIM è stata assegnata

ASSEGNAZIONE-S PASSATA

Collega l’entità SIM con l’entità REFERENTI

cardinalità MOLTI A MOLTI: Ad un referente in passato possono corrispondere molte assegnazioni e in passato una SIM può essere stata assegnata molte volte

DATA_ASSEGNAZIONE Data in cui la SIM è stata assegnataDATA_REVOCA Data in cui la SIM è stata revocata

APPARTENENZA G-S

Collega l’entità SIM con l’entità GRUPPI_SIM

cardinalità UNO A MOLTI: Una SIM deve appartenere ad un solo gruppo di SIM, ma molte SIM possono far parte dello stesso gruppo di SIM.

CARATTERIZZAZIONE S-S

Collega l’entità SIM con l’entità STATI_SIM

cardinalità UNO A MOLTI: Una sim è caratterizzata da uno solo stato, ma uno stato può caratterizzare più SIM

DATA_STATO Data in cui è avvenuto il cambiamento dello stato

27

RELAZIONI_SIM_SERVIZI

Collega l’entità SIM con l’entità SERVIZI

cardinalità MOLTI A MOLTI: Ad una SIM possono venir associati più servizi di sim e un servizio di SIM può essere associato a più SIM.

APPARTENENZA C-S

Collega l’entità SIM con l’entità CONTRATTI

cardinalità UNO A MOLTI: Una SIM deve appartenere ad un solo contratto e ad un contratto possono appartenere più SIM.

TIPOLOGIA SIM

Collega l’entità SIM con l’entità TIPI_SIM

cardinalità UNO A MOLTI: Una SIM deve essere di un solo tipo e un tipo può caratterizzare più SIM.

RELAZIONE_SIM_PIANI

Collega l’entità SIM con l’entità PIANI_TARIFFARI

cardinalità UNO A MOLTI: Ad ogni SIM deve essere associato un piano tariffario e lo stesso piano tariffario può essere associato a più SIM.

ASSEGNAZIONE-D CORRENTE

Collega l’entità REFERENTI con l’entità DISPOSITIVO ASSEGNATO

cardinalità UNO A MOLTI: Ad un referente possono essere correntemente assegnati più dispositivi, ma un dispositivo può essere correntemente assegnato ad un solo referente

DATA_ASSEGNAZIONE Data in cui il dispositivo è stato assegnato

ASSEGNAZIONE-D PASSATA

Collega l’entità DISPOSITIVI con l’entità REFERENTI

cardinalità MOLTI A MOLTI: Ad un referente in passato possono corrispondere molte assegnazioni e in passato un dispositivo può essere stato assegnato molte volte

DATA_ASSEGNAZIONE Data in cui il dispositivo è stato assegnatoDATA_REVOCA Data in cui il dispositivo è stato revocato

APPARTENENZA M-D

Collega l’entità DISPOSITIVI con l’entità MODELLO_DISPOSITIVI

28

cardinalità UNO A MOLTI: Un dispositivo deve appartenere ad un solo modello ma ci possono essere più dispositivi dello stesso modello.

APPARTENENZA M-M

Collega l’entità MODELLO_DISPOSITIVI con l’entità MARCA_DISPOSITIVI

cardinalità UNO A MOLTI: Un modello può essere di una sola marca, ma una marca può avere più modelli.

TIPOLOGIA MODELLO

Collega l’entità MODELLO_DISPOSITIVI con l’entità TIPO_MODELLO

cardinalità UNO A MOLTI: Un modello deve essere di una solo tipo, ma ad un tipo possono corrispondere più modelli.

CARATTERIZZAZIONE S-D

Collega l’entità DISPOSITIVO con l’entità STATO_DISPOSITIVO

cardinalità UNO A MOLTI: Un modello deve essere caratterizzato da un solo stato , ma uno stato può caratterizzare molti dispositivi.

LOCALIZZAZIONE

Collega l’entità DISPOSITIVO con l’entità DISPOSITIVO NON ASSEGNATO

cardinalità UNO A MOLTI: Un dispositivo non assegnato si deve trovare in una posizione fisica e nella stessa posizione fisica si possono trovare più dispositivi non assegnati

APPARTENENZA G-D

Collega l’entità DISPOSITIVI con l’entità GRUPPO_DISPOSITIVO

cardinalità UNO A MOLTI: Un dispositivo deve appartenere ad un solo gruppo di dispositivi e molti dispositivi possono fare parte dello stesso gruppo

29

3.1.7 Business rules

Vengono di seguito riportate le proprietà dell’applicazione che non è possibile rappresentare con modelli concettuali

BUSINESS RULES

BR1 Dispositivi e SIM non devono poter venir assegnati a referenti che afferiscono all’ufficio avente codice ‘U00000’.

BR2 I referenti ai quali risultino assegnate SIM e/o dispositivi non devono poter afferire all’ufficio avente codice ‘U00000’.

BR3 Una dispositivo (SIM) non può essere assegnata contemporaneamente a più di un referente.

BR4 Una dispositivo(SIM) in passato può essere stata assegnata più di una volta allo stesso referente.

BR5 Ad ogni revoca di un dispositivo si deve stabilirne la posizione fisica.

Si noti che le BR 3 e 4 esprimono implicitamente il seguente vincolo: Qualora una SIM (o dispositivo) risulti attualmente assegnata, una nuova assegnazione dello stessa deve comportare la revoca dell’assegnazione corrente.

30

3.1.8 Schema E-R finale con attributi e cardinalità

Figura 3

3.2 Progettazione Logica

Nella fase seguente si procederà, partendo dallo schema E-R di Figura 3, alla realizzazione di uno schema logico in grado di semplificare la traduzione verso il modello relazionale, tenendo conto, per quanto possibile, delle prestazioni.

3.2.1 Tavola dei volumi

Nella tavola dei volumi vengono riportati tutti i concetti (entità e relazioni) dello schema con il loro volume a regime. I valori relativi ai volumi sono stati ricavati contando, dove possibile, il numero di occorrenze di ciascuna tabella della base di dati pre-esistente.

Per le relazioni ASSEGNAZIONE-D PASSATA e ASSEGNAZIONE-S PASSATA si assume che tutte le SIM e i Dispositivi vengano assegnati almeno una volta e che una riassegnazione di una SIM o dispositivo avvenga con probabilità circa pari al 30%.

ENTITÀ VOLUME RELAZIONE VOLUME

REFERENTI 5000 AFFERENZA R-U 5000

ADMIN 3 AFFERENZA U-N_U 140

DIRETTORE AREA 8 AFFERENZA N_U-S 140

DIRETTORE SERVIZIO 35 AFFERENZA S-A 35

SENZA RUOLO SPECIFICO 5000 ASSEGNAZIONE-D CORRENTE 1250

CEC_CEC 140 ASSEGNAZIONE-D PASSATA 1500

CEC_NON_UTIL 140 LOCALIZZAZIONE 850

CEC_SERVIZIO 35 APPARTENENZA M-D 2100

CEC_AREA 9 CARATTERIZZAZIONE S-D 2100

DISPOSITIVI 2100 APPARTENENZA G-D 2100

NON ASSEGNATO 850 APPARTENENZA M-M 40

ASSEGNATO 1250 TIPOLOGIA MODELLO 40

GRUPPO_DISPOSITIVO 10 ASSEGNAZIONE-S CORRENTE 1000

POSIZIONE_DISPOSITIVO 6 ASSEGNAZIONE -S PASSATA 1000

MODELLO_DISPOSITIVI 40 APPARTENENZA G-S 1500

MARCA_DISPOSITIVI 10 APPARTENENZA C-S 1500

FASCIA_ALTA 700 CARATTERIZZAZIONE S-S 1500

FASCIA MEDIA 700 RELAZIONI_SIM_SERVIZI 3000

FASCIA BASSA 700 RELAZIONI_SIM_PIANI 1500

TIPO_MODELLO 4 TIPOLOGIA_SIM 1500

STATI_DISPOSITIVI 4

SIM 1500

GRUPPI_SIM 15

STATI_SIM 4

CONTRATTI 5

SERVIZI 50

PIANI_TARIFFARI 20

TIPI_SIM 15

3.2.2 Tavola delle operazioni

Di seguito vengono riportate le operazioni di tabella 2, cap. 2.3.2 più onerose oppure effettuate con maggior frequenza. Tutte le operazioni sono effettuate in modo interattivo.

OPERAZIONE FREQUENZA

1 Inserimento di un nuovo dispositivo 8/SETTIMANA

3 Assegnazione di un dispositivo 11/SETTIMANA

4 Assegnazione di una SIM 8/SETTIMANA

6 Revoca di una SIM 4/SETTIMANA

13 Visualizzare tutte le sim (NUMERO DI TELEFONO) attualmente assegnate ad un dato referente assunto.

50/GIORNO

14 Visualizza tutti i dati di una SIM, incluse le informazioni relative all’assegnazione corrente ed alle assegnazioni passate.

15/GIORNO

15 Visualizza tutti i dati di un dispositivo, incluse le informazioni relative all’assegnazione corrente ed alle assegnazioni passate

15/GIORNO

3.2.3 Analisi delle ridondanze

C’è un solo dato ridondante nello schema, l’attributo ID_REFERENTE dell’entità SIM, derivabile dalla relazione ASSEGNASIONE-S CORRENTE. Tale dato serve a garantire il funzionamento dell’applicativo intranet e dovrà venir mantenuto.

In quanto l’operazione numero 13 risulta essere in assoluto la più frequente, di seguito si tenterà di giustificare la presenza del dato derivato (che comporta occupazione di memoria e operazioni aggiuntive per mantenerlo aggiornato) in assenza del vincolo riguardante la compatibilità.

33

Tavole degli accessi in presenza di ridondanza

Tavole degli accessi inassenza di ridondanza

OPERAZIONE 13 OPERAZIONE 13

CONCETTO COSTR. ACC. TIPO CONCETTO COSTR. ACC. TIPO

SIM E 0,25 L ASSEGNAZIONE- R 0,25 L

S CORRENTE

OPERAZIONE 4 SIM E 1 L

CONCETTO COSTR. ACC. TIPO

ASSEGNAZIONE-S R 1 S OPERAZIONE 4

CORRENTE CONCETTO COSTR. ACC. TIPO

SIM E 1 L ASSEGNAZIONE-S R 1 S

SIM E 1 S CORRENTE

OPERAZIONE 6 OPERAZIONE 6

CONCETTO COSTR. ACC. TIPO CONCETTO COSTR. ACC. TIPO

ASSEGNAZIONE-S PASSATA

R 1 S ASSEGNAZIONE-S PASSATA

R 1 S

SIM E 1 L

SIM E 1 S

Assumendo che il codice identificativo di un referente richieda 4 byte, abbiamo che il dato ridondante richiede 4 x 2000 = 8000 byte, ovvero circa 8 kilobytes di memoria aggiuntiva.

Per quanto riguarda il costo delle operazioni, In assenza di ridondanza l’operazione 13 richiede in media 0,4 accessi in lettura alla relazione ASSEGNAZIONE–S CORRENTE (in quanto una SIM è assegnata ad un dipendente assunto con il 40% di probabilità), e qualora sia stata trovata una sim, un’ulteriore lettura all’entità SIM (per ricavare il numero di telefono). In media si hanno circa (0.4+1)x0.4 = 0,60 accessi in lettura, il tutto ripetuto per 50 volte al giorno, per un totale di circa 30 accessi in lettura al giorno. Le operazioni 4 e 6 richiedono entrambe un solo accesso in scrittura da effettuare in media circa 2 volte al giorno. Contando doppi gli accessi in scrittura si hanno in totale circa 40 accessi al giorno.

In presenza di ridondanza l’operazione 13 richiede circa 20 accessi in lettura all’entità SIM (0,4x50) mentre le operazioni 4 e 6 richiedono entrambe 2 accessi in scrittura (uno per modificare le relazioni relative all’assegnazione ed uno per modificare l’entità SIM) ed uno in lettura (per trovare la SIM da modificare) da effettuare in media circa 2 volte al

34

giorno. Contando doppi gli accessi in scrittura si hanno anche in questo caso circa 40 accessi al giorno.

A parità di operazioni giornaliere possiamo concludere che non converrebbe mantenere il dato derivato. Tale conclusione è giustificata dal basso numero di operazioni giornaliere effettuate, dai vincoli di progetto riguardanti le prestazioni generali del sistema e dallo spazio (seppur esiguo) occupato dal dato ridondante.

3.2.4 Eliminazione delle gerarchie

Nello schema sono presenti tre gerarchie, che riguardano le entità Referenti, Dispositivi e Modelli di dispositivo.

Referenti

Per quanto riguarda i Referenti, le operazioni che li riguardano non fanno distinzione tra i vari ruoli e le entità corrispondenti non hanno attributi specifici che li distinguono. Le entità figlie della generalizzazione sono state pertanto accorpate nel padre aggiungendo un attributo RUOLO all’entità REFERENTE che ha un dominio costituito dai simboli 0 (per Senza ruolo specifico), 1 (per Amministratore), 2 (per Direttore di Area) e 3 (per Direttore Servizio).

Modelli

Per quanto riguarda i Modelli di dispositivo, un ragionamento del tutto analogo a quello fatto per i Referenti ha portato all’accorpamento delle entità figlie nel padre aggiungendo un attributo FASCIA all’entità MODELLO_DISPOSITIVI che ha un dominio costituito dai simboli A (per Alta), M (per Media) e B (per Bassa).

Dispositivi

Anche per quanto riguarda i Dispositivi non ci sono attributi specifici che li distinguono e le operazioni più frequenti che li coinvolgono (1,3,15) non fanno distinzione tra dispositivi assegnati e non assegnati. Anche in questo caso le entità NON ASSEGNATO ed ASSEGNATO sono state eliminate e le loro partecipazioni ad associazioni sono state aggiunte all’entità padre. Le relazioni ASSEGNAZIONE-D CORRENTE e LOCALIZZAZIONE hanno ora una cardinalità minima pari a 0 sull’entità DISPOSITIVI.

Si noti che non è necessario introdurre un attributo per distinguere tra dispositivi assegnati e non assegnati in quanto la generalizzazione è totale ed esclusiva e le associazioni che coinvolgono i dispositivi assegnati e non assegnati hanno entrambe cardinalità minima pari ad 1. Si ha pertanto che la partecipazione alla relazione LOCALIZZAZIONE è opzionale solo nel caso in cui il dispositivo risulti assegnato e la

35

partecipazione alla relazione ASSEGNAZIONE-D CORRENTE è opzionale solo nel caso in cui sia specificata una posizione fisica per il dispositivo.

3.2.5 Partizionamento/accorpamento di concetti

Due possibili ristrutturazioni che si può pensare di effettuare sono l’accorpamento delle associazioni ASSEGNAZIONE-D CORRENTE e ASSEGNAZIONE-D PASSATA e delle associazioni analoghe ASSEGNAZIONE-S CORRENTE e ASSEGNAZIONE-S PASSATA.

Si tratta in entrambi i casi di due concetti simili (l’unica differenza è il carattere temporale), tra i quali le operazioni 14 e 15 non fanno distinzioni. In caso di accorpamento tali operazioni risulterebbero meno onerose in quanto richiederebbero la visita di una sola entità.

Un ulteriore beneficio derivante dall’accorpamento consisterebbe nel non dover trasferire occorrenze da una associazione ad un’altra quando avviene una revoca di un dispositivo o SIM.

Si decide pertanto di effettuare in entrambi i casi l’accorpamento delle relazioni, che danno luogo a due nuove associazioni, ASSEGNAZIONE_S e ASSEGNAZIONE_D.

36

3.2.6 Partizionamento relazioni molti a molti

Per consentire la traduzione verso il modello relazionale le associazioni molti a molti (ASSEGNAZIONE_D e ASSEGNAZIONE_S) vengono partizionate. Ogni partizionamento consiste nella creazione di due associazioni uno a molti con l’aggiunta di una nuova entità avente lo stesso nome e attributi dell’associazione partizionata.

Figura 4 - Partizionamento associazione ASSEGNAZIONE_S

3.2.7 Scelta degli identificatori principali

Oltre agli identificatori della base di dati pre-esistente, che come anticipato nella nota metodologica verranno mantenuti, si introducono dei codici per avere degli identificatori sulle entità ASSEGNAZIONE_D e ASSEGNAZIONE_S. Tenendo conto delle precedenti analisi, tale scelta si giustifica osservando che queste due entità sono accedute di frequente e hanno bisogno quindi di identificatori efficaci (in questi casi un identificatore interno è preferibile ad uno esterno che coinvolge più entità ed un identificatore numerico è preferibile ad uno di tipo stringa).

37

3.2.8 Schema E-R ristrutturato

38

3.2.9 Schema logico finale

Figura 5

40

3.3 Documentazione aggiuntiva

Di seguito vengono descritte viste, trigger e procedure create per la gestione dei dispositivi.

Viste

Si espongono le viste atte a soddisfare le seguenti richieste:

VW_REFERENTI - Referenti dell’applicazione VW_DISP - Dispositivi presenti nella base dati VW_ASS_DISP_PASSATE - Assegnazioni dispositivi concluse VW_DISPOSITIVI_ASSEGNATI - Assegnazioni dispositivi correnti VW_DISP_NON_ASSEGNATI - Dispositivi non assegnati

Codice sorgente per creazione della vista VW_DISP _ASSEGNATI:

CREATE OR REPLACE FORCE VIEW "VW_DISPOSITIVI_ASSEGNATI" ("ID_DISPOSITIVO", "MODELLO", "IMEI", "DATA_INSERITO", "NOTA", "STATO", "ID_GRUPPO_DISPOSITIVO", "MARCA", "TIPO", "FASCIA", "GRUPPO_DISPOSITIVO", "DATA_ASSEGNAZIONE", "ID", "REFERENTE", "CEC") AS SELECT "DWH_DISPOSITIVI"."ID_DISPOSITIVO" as "ID_DISPOSITIVO", "DWH_DISPOSITIVI"."MODELLO" as "MODELLO", "DWH_DISPOSITIVI"."IMEI" as "IMEI", "DWH_DISPOSITIVI"."DATA_INSERITO" as "DATA_INSERITO", "DWH_DISPOSITIVI"."NOTA" as "NOTA", "DWH_DISPOSITIVI"."STATO" as "STATO", "DWH_DISPOSITIVI"."ID_GRUPPO_DISPOSITIVO" as "ID_GRUPPO_DISPOSITIVO", "DWH_MODELLI"."MARCA" as "MARCA", "DWH_MODELLI"."TIPO" as "TIPO", "DWH_MODELLI"."FASCIA" as "FASCIA", "DWH_GRUPPI_DISPOSITIVI"."GRUPPO_DISPOSITIVO" as "GRUPPO_DISPOSITIVO", "DWH_ASSEGNAZIONE_D"."DATA_ASSEGNAZIONE" as "DATA_ASSEGNAZIONE", "DWH_REFERENTI"."ID" as "ID", "DWH_REFERENTI"."REFERENTE" as "REFERENTE", "DWH_REFERENTI"."CEC" as "CEC" FROM "DWH_GRUPPI_DISPOSITIVI" "DWH_GRUPPI_DISPOSITIVI", "DWH_MODELLI" "DWH_MODELLI", "DWH_REFERENTI" "DWH_REFERENTI", "DWH_DISPOSITIVI" "DWH_DISPOSITIVI", "DWH_ASSEGNAZIONE_D" "DWH_ASSEGNAZIONE_D" WHERE "DWH_ASSEGNAZIONE_D"."ID_DISPOSITIVO"="DWH_DISPOSITIVI"."ID_DISPOSITIVO" AND "DWH_ASSEGNAZIONE_D"."ID_REFERENTE"="DWH_REFERENTI"."ID" AND "DWH_DISPOSITIVI"."MODELLO"="DWH_MODELLI"."MODELLO" AND "DWH_DISPOSITIVI"."ID_GRUPPO_DISPOSITIVO"="DWH_GRUPPI_DISPOSITIVI"."ID_GRUPPO_DISPOSITIVO" AND "DWH_ASSEGNAZIONE_D"."DATA_REVOCA" IS NULL;

Trigger

TRG_VERIFICA_PRIMA_USCIRE – Se ci sono SIM o dispositivi assegnati ad un referente, non consentire che venga fatto afferire all’ufficio “USCITO” (Dipendenti non attivi).

TRG_POSIZ_DISP - All’inserimento di un dispositivo si deve specificarne la posizione fisica. Ai dispositivi assegnati non deve corrispondere alcuna posizione fisica.

TRG_VERIFICA_ASS_DISP – Non permettere l’assegnazione di un dispositivo se risulta già assegnato. La data di nuova assegnazione deve essere successiva alla data dell’ultima revoca. Non si deve poter assegnare dispositivi a referenti che afferiscono all’ufficio “USCITO” (Dipendenti non attivi).

Codice sorgente per il trigger TRG_VERIFICA_PRIMA_USCIRE

CREATE OR REPLACE TRIGGER "TRG_VERIFICA_PRIMA_USCIRE"BEFOREUPDATE OF "CEC" on "DWH_REFERENTI"FOR EACH ROW WHEN (NEW.CEC = 'U0000') DECLARE NUM_DIPS_ASS NUMBER; NUM_SIM_ASS NUMBER; BEGIN NUM_DIPS_ASS := NUMERO_DISP_REFERENTE(:OLD.REFERENTE); NUM_SIM_ASS := NUMERO_SIM_REFERENTE(:OLD.REFERENTE);

IF NUM_DIPS_ASS > 0 OR NUM_SIM_ASS > 0 THEN raise_application_error(-20501, 'Risultano esserci dispositivi o sim assegnate al referente'); END IF;END;

Il trigger richiama le funzioni NUMERO_DISP_REFERENTE e NUMERO_SIM_REFERENTE che ritornano rispettivamente il numero di dispositivi e di SIM assegnate ad un dato referente. Viene di seguito riportato il codice della funzione NUMERO_DISP_REFERENTE

CREATE OR REPLACE FUNCTION NUMERO_DISP_REFERENTE(id_referente IN NUMBER)RETURN number IS num_disp number := 0;BEGIN SELECT COUNT(*) INTO num_disp FROM DWH_ASSEGNAZIONE_D WHERE ID_REFERENTE = id_referente AND DATA_REVOCA = NULL; RETURN num_disp;END;

42

Stored Procedure

PR_ASSEGNA_DISPOSITIVO – Consente di assegnare un dispositivo ad un referente.

PR_INSERISCI_DISPOSITIVO – Consente di inserire un dispositivo. PR_MODIFICA_DISPOSITIVO – Consente di modificare un dispositivo. PR_REVOCA_DISPOSITIVO – Consente di revocare un dispositivo

precedentemente assegnato.

Codice sorgente per la creazione della stored procedure PR_ASSEGNA _DISPOSITIVO

CREATE OR REPLACE PROCEDURE "PR_ASSEGNA_DISPOSITIVO"( p_id_dispositivo IN DWH_ASSEGNAZIONE_D.ID_DISPOSITIVO%TYPE, p_id_referente IN DWH_ASSEGNAZIONE_D.ID_REFERENTE%TYPE, p_data_ass VARCHAR2) IS data_assegnazione date;BEGIN SAVEPOINT start_tran; data_assegnazione := TO_DATE(p_data_ass, 'DD/MM/YYYY'); -- SE GIA' ASSEGNATO CONCLUDI ASSEGNAZIONE UPDATE DWH_ASSEGNAZIONE_D SET DATA_REVOCA = data_assegnazione WHERE ID_DISPOSITIVO = p_id_dispositivo;

-- NUOVA ASSEGNAZIONE INSERT INTO DWH_ASSEGNAZIONE_D (ID_REFERENTE, ID_DISPOSITIVO,DATA_ASSEGNAZIONE) VALUES(p_id_referente, p_id_dispositivo,data_assegnazione);EXCEPTION WHEN OTHERS THEN ROLLBACK TO start_tran; RAISE;END;

3.4 Adeguamento della base dati

Confrontando lo schema logico ottenuto dalla fase di riprogettazione (figura 5) con quello della base di dati preesistente (figura 1) è possibile notare che l’adattamento non può venir fatto in modo totalmente automatizzato, ossia per mezzo di query di aggiornamento.

Ciò è causato in parte dall’errata modellizzazione iniziale della base di dati (relazione molti a molti tra SIM e piani tariffari) e in parte dall’occasionale mancanza di dati fondamentali, tra i quali figurano i codici ICCD e IMEI. Il compito di trovare i dati mancanti (cercando tra la documentazione cartacea o richiedendoli ai referenti quando

43

non presenti nei campi “note” delle tabelle SIM e DISPOSITIVI) è un’operazione tuttora in atto che può essere svolta solo dall’ente ospitante.

4 Progettazione e Realizzazione dell’applicazione

Ora che la base di dati è in grado di rappresentare con correttezza la realtà di interesse è possibile procedere con lo sviluppo della nuova applicazione.

Verranno di seguito documentate le tecnologie e le principali fasi che hanno portato alla realizzazione del nuovo client per la gestione di SIM e dispositivi.

4.1 Strumenti Utilizzati

Cake PHP

Si è deciso di basare lo sviluppo su un framework PHP che implementa il pattern architetturale MVC (Model View Controller) per ottenere i seguenti benefici:

Separazione della logica di presentazione dei dati dalla logica di business. Adottamento di uno standard di programmazione riconosciuto, noto ad altri

potenziali sviluppatori, che saranno in grado di comprendere il codice con maggiore facilità.

Possibilità di utilizzare librerie e strumenti di supporto forniti per lo sviluppo.

La scelta del framework è ricaduta su CakePHP (http://cakephp.org/) in quanto:

Compatibile con l’attuale configurazione del web server e versione di PHP fornita dall’ente ospitante

Affermato nel panorama dei framework PHP Discretamente documentato e supportato da una comunità molto attiva Rilasciato con licenza MIT.

jQuery UI

Tra le operazioni che coinvolgono gli utenti del sistema con maggior frequenza, è possibile identificare la compilazione di campi per la ricerca di SIM, dispositivi e referenti. Tale operazione può essere fonte di errori specialmente nel caso in cui i dati da inserire siano molto lunghi (si pensi ai codici IMEI e ICCD).

Per ovviare al problema nel progetto si è fatto largo uso del plugin Autocomplete offerto dalla libreria opensource jQuery UI (http://jqueryui.com/) che consente di visualizzare, in un menu a tendina, suggerimenti di completamento automatico della parola che si è iniziata a scrivere.

44

4.2 Attori del sistema e casi d’uso

Con riferimento ai requisiti raccolti nel capitolo 2.3.3 nel seguito di questo capitolo verranno identificati gli attori e descritti i casi d’uso del sistema. Con attore si intende il ruolo che un utente (una persona o un sistema esterno) gioca interagendo con il sistema mentre i casi d’uso sono la formulazione delle funzionalità offerte così come sono percepite dagli attori.

4.2.1 Attori del sistema

L’applicazione dovrà distinguere tra i seguenti tipi di utenti:

Referente (senza ruolo specifico)

Non ha accesso ad alcuna operazione sui dati.

Direttore di Servizio

Può visualizzare i dati delle SIM e dei dispositivi attualmente assegnati ai referenti che afferiscono al suo stesso servizio.

Direttore di Area

Può visualizzare i dati delle SIM e dei dispositivi attualmente assegnati ai referenti che afferiscono alla sua stessa area.

Amministratore

Può visualizzare tutti i dati di tutti i dispositivi, SIM e referenti

Può modificare tutti i dispositivi e le SIM Può assegnare e revocare SIM e dispositivi Può cambiare ruolo ad un referente.

4.2.2 Casi d’uso

Le funzionalità relative alla gestione delle SIM e dei Dispositivi sono molto simili e coinvolgono gli stessi attori. Si è pertanto deciso di descriverli mediante un unico caso d’uso, evidenziando dove necessario le differenze.

45

Figura 6 - Diagramma degli attori

Figura 7 - Diagramma dei casi d'uso

4.2.2.1 Autenticazione

Il caso d’uso inizia quando un referente non autenticato richiede un’operazione al sistema. Al referente vengono richiesti indirizzo e-mail e password. Il sistema invoca lo script di login con i dati forniti dal referente. Se i dati forniti sono corretti viene cercato nella base dati il ruolo ricoperto del referente. Se il ruolo ricoperto è amministratore oppure direttore di area oppure direttore di servizio il referente viene autenticato per la sessione corrente, altrimenti viene notificata la mancanza dei permessi necessari. Se i dati forniti non sono corretti il referente viene invitato a fornire nuovamente indirizzo e-mail e password.

4.2.2.2 Modifica ruolo referente

Il caso d’uso inizia quando un amministratore seleziona l’opzione modifica ruolo. All’amministratore viene chiesto di fornire nome e cognome del referente a cui modificare il ruolo. Il sistema visualizza nome, cognome, matricola, area, servizio e ufficio di afferenza di tutti referenti attualmente assunti che soddisfano il criterio di

46

ricerca. L’amministratore deve poter modificare il ruolo del referente desiderato. Il sistema deve fornire agli amministratori una schermata in cui compaiono nome, cognome, ruolo, area, servizio e ufficio di afferenza di tutti i referenti che ricoprono uno tra i seguenti ruoli: amministratore, direttore di area, direttore di servizio.

4.2.2.3 Visualizzazione SIM / Dispositivo

Il caso d’uso inizia quando un amministratore o un direttore cerca una SIM (dispositivo). La ricerca delle SIM può avvenire per codice ICCD o per numero di telefono. Il sistema visualizza attuale referente, numero di telefono, codice ICCD, piano tariffario e classe di ciascuna SIM che soddisfa il criterio di ricerca. La ricerca dei dispositivi può avvenire per codice IMEI o per modello. Il sistema visualizza attuale referente, codice IMEI, marca e modello di ciascun dispositivo che soddisfa il criterio di ricerca.Se il referente ha ruolo pari a direttore di area (servizio) la ricerca avviene solo sulle SIM (dispositivi) attualmente assegnate a referenti che afferiscono alla sua stessa area (servizio). Data una SIM (dispositivo) gli amministratori devono poter ottenere una vista di dettaglio. La vista di dettaglio riporta tutti i dati della SIM (dispositivo) incluse le informazioni riguardanti le assegnazioni passate.

4.2.2.4 Inserimento SIM / Dispositivo

Il caso d’uso inizia quando un amministratore seleziona l’opzione inserisci SIM (dispositivo). Il sistema richiede i le caratteristiche della SIM (dispositivo) da inserire.Ad ogni inserimento di una SIM l’amministratore può specificare più di una coppia codice ICCD - numero di telefono. Per ogni coppia fornita il sistema inserisce nella base dati una nuova SIM avente le caratteristiche specificate.Ad ogni inserimento di un dispositivo l’amministratore può specificare più di un codice IMEI. Per ogni codice IMEI fornito il sistema inserisce nella base dati una nuovo dispositivo avente le caratteristiche specificate.

4.2.2.5 Modifica SIM /Dispositivo

Il caso d’uso inizia quando un amministratore seleziona l’opzione modifica SIM (dispositivo). Il sistema richiede il codice ICCD (IMEI) della SIM (dispositivo) da modificare. Se la SIM (dispositivo) viene trovato nella base dati il sistema visualizza tutti i dati della SIM (dispositivo) specificata e ne consente la modifica, altrimenti invita a fornire nuovamente il codice ICCD (IMEI).

4.2.2.6 Assegnazione SIM / Dispositivo

Il caso d’uso inizia quando un amministratore seleziona l’opzione assegna SIM (dispositivo). Il sistema richiede il codice ICCD (IMEI) e il Referente a cui assegnare la SIM (dispositivo). Se la SIM (dispositivo) risulta essere già assegnata il sistema revoca

47

la SIM all’attuale referente. Il sistema assegna la SIM (dispositivo) al referente specificato.

4.2.2.7 Revoca SIM / Dispositivo

Il caso d’uso inizia quando un amministratore seleziona l’opzione revoca SIM (dispositivo). Il sistema richiede il codice ICCD (IMEI) della SIM (dispositivo) da revocare. Per concludere la revoca di un dispositivo l’amministratore deve specificarne la nuova posizione fisica.

4.2.2.8 Report SIM / Dispositivi

Il caso d’uso inizia quando un amministratore o un direttore seleziona l’opzione Report. Il sistema dovrà fornire le seguenti funzionalità:1. Visualizzazione del codice IMEI, modello, Stato fisico, data acquisizione di tutti i

dispositivi attualmente non assegnati. 2. Visualizzazione del codice ICCD, numero, tipo, stato, data acquisizione di tutte le

SIM attualmente non assegnate.3. Visualizzazione del codice ICCD, numero, tipo, stato, data acquisizione, referente

di tutte le SIM attualmente assegnate, ordinata per ufficio, servizio e area di afferenza del referente a cui risulta assegnata la SIM.

4. Visualizzazione codice IMEI, modello, stato fisico, data acquisizione, referente di tutti i dispositivi attualmente assegnati, ordinata per ufficio, servizio e area di afferenza del referente a cui risulta assegnato il dispositivo.

Le funzionalità 1 e 2 dovranno essere disponibili ai soli amministratori.Le funzionalità 3 e 4, disponibili ai direttori di area e servizio, dovranno limitare la visualizzazione dei dati alle sole SIM (dispositivi) attualmente assegnate a referenti che afferiscono alla stessa area (servizio) del direttore di area (servizio).

4.2.2.9 Visualizzazione Referente

Il caso d’uso inizia quando un amministratore o un direttore cerca un referente. La ricerca dei referenti avviene per nome e cognome. Il sistema visualizza nome, cognome, area, servizio e ufficio di afferenza di tutti referenti attualmente assunti che soddisfano il criterio di ricerca. Il sistema deve poter fornire agli amministratori e ai direttori una vista di dettaglio sul referente desiderato. La vista di dettaglio riporta nome, cognome, matricola, mail, area, servizio e ufficio di afferenza del referente selezionato, codice ICCD e numero di telefono di tutte le SIM attualmente assegnate al referente, codice IMEI, marca e modello di tutti i dispositivi attualmente assegnati al referente.

48

4.3 Diagramma di attività per il caso d’uso “Assegnazione Dispositivo”

I diagrammi di attività consentono di modellare un comportamento (che riguarda una o più entità) come un insieme di azioni organizzate secondo un flusso.

Prendendo in esame il caso d’uso relativo all’assegnazione di un dispositivo, il punto di partenza è rappresentato dalla richiesta della funzionalità da parte di un referente.

Nel caso in cui il referente non sia autenticato dovrà venir indirizzato verso la pagina di login. Se l’utente è autenticato il sistema provvederà a verificare se possiede i permessi necessari (che nel caso specifico corrispondono al ruolo di amministratore). In caso affermativo, l’applicazione fornirà un Form in cui poter specificare codice IMEI del dispositivo da assegnare e nome e cognome del referente.

Il sistema controllerà la correttezza dei dati forniti e presenterà una schermata riepilogativa. A questo punto l’amministratore potrà confermare l’assegnazione, che comporterà il salvataggio dei dati nel database. Se l’inserimento è andato a buon fine l’applicazione visualizzerà un messaggio di avvenuta assegnazione, altrimenti genererà un messaggio di errore.

49

Figura 8 Diagramma attività per il caso d’uso "Assegnazione dispositivo"

4.4 Interfaccia utente

Tutte la pagine dell’applicazione sono accumunate dal menu principale sito nella parte alta. Esso è formato dalle voci: Referenti, Sim, Dispositivi e Report.

Per ogni voce del menù principale, con riferimento ai casi d’uso, è stato identificato un sotto menù orientato alle funzionalità che il sistema dovrà offrire. Nel caso dei dispositivi e delle SIM si avrà rispettivamente Ricerca, Inserimento, Modifica e Assegnazione. Per quanto riguarda i referenti si avrà la sola funzionalità di ricerca e per i Report non è stato necessario introdurre alcuna voce di menu.

50

Figura 9 - Interfaccia grafica

4.5 Strutturazione dell’applicazione

Durante la sviluppo si è sfruttato il paradigma di programmazione Convention Over Configuration offerto dal framework CakePHP. Le convenzioni non riguardano solo la posizione dei file su disco ma anche i nomi. (documentazione ufficiale: http://book.cakephp.org/2.0/en/getting-started/cakephp-conventions.html).

Posizione dei file su disco

TIPO DI FILE CARTELLA

Model [app/Model]

View [app/View]

Controller [app/Controller]

Template grafico [app/View/Elements] [app/View/Layouts]

File CSS [app/Webroot/css]

Immagini [app/Webroot/img]

Javascript [app/Webroot/js]

File di configurazione [app/Config/core.php]

51

http://book.cakephp.org/2.0/en/getting-started/cakephp-conventions.html

4.6 Implementazione

Verranno di seguito analizzate le pagine e le funzioni più significative relative al caso d’uso “assegnazione dispositivo”.

4.6.1 Caso d’uso Assegnazione Dispositivo

Lo scenario relativo a una nuova assegnazione è il seguente:

Il referente clicca la voce di menu “Assegna dispositivo”. Viene invocato il metodo assegna Dispositivo() del controller DispositiviController. Se la richiesta è pervenuta da un referente con ruolo di amministratore verrà visualizzata la View assegna_dispositivo.ctp.

View: “assegna_dispositivo.ctp”

La vista contiene il Form HTML per l’inserimento dei dati (cognome nome del referente, codice IMEI del dispositivo) e il codice Javascript (basato sul plugin autocomplete della libreria Jquery UI) per il completamento automatico del cognome nome e codice IMEI.

Cliccando sul pulsante continua la vista invocherà il metodo assegnaDispositivoRiepilogo() del controller DispositiviController.

<h3>Assegna dispositivo</h3>

<?php echo $this->Form->create(false, array('type' => 'put', 'action' => 'assegnaDispositivoRiepilogo')); echo $this->Form->input('dispid', array('id' => 'hiddenID_disp','value'=> $id_disp, 'type' => 'hidden')); echo $this->Form->input('imei', array('id' => 'ImeiSearch', 'placeholder' => 'Sono sufficienti le ultime cifre', 'value'=> $imei, 'label'=> 'Imei Dispositivo *')); echo $this->Form->input('nome', array('id' => 'NomeSearch', 'placeholder' => 'ROSSI MARIO', 'label'=> 'Seleziona Assegnatario (Cognome Nome) *')); echo $this->Form->input('nomeid', array('id' => 'hiddenID_ref', 'type' => 'hidden')); echo $this->Form->submit('Continua >'); echo $this->Form->end();?>

<script> $(document).ready(function() { $("#ImeiSearch").autocomplete({ minLength: 3, source: 'cercaImeiAjax', focus: function(event, ui) { $("#ImeiSearch").val(ui.item.label); return false; }, select: function(event, ui) {

52

$("#ImeiSearch").val(ui.item.label); $("#hiddenID_disp").val(ui.item.value); return false; } }); $("#NomeSearch").autocomplete({ source: '/Referenti/cercaNomeAjax', focus: function(event, ui) { $("#NomeSearch").val(ui.item.label); return false; }, select: function(event, ui) { $("#NomeSearch").val(ui.item.label); $("#hiddenID_ref").val(ui.item.value); return false; } });});

</script>

Tabella 3 – View: assegna_dispositivo.ctp

Controller: DispositiviController, metodo: assegnaDispositivoRiepilogo()

Il primo compito del metodo assegnaDispositivoRiepilogo() è quello di verificare i dati inseriti nel Form. Se i dati non sono corretti invocherà la View assegna_dispositivo.ctp (descritta a capitolo 4.6.1.1) visualizzando il relativo messaggio di errore.

Se i dati sono corretti invocherà la View assegna_dispositivo_riepilogo.ctp fornendole i dati relativi al dispositivo da assegnare, al futuro assegnatario e all’eventuale assegnatario attuale.

public function assegnaDispositivoRiepilogo(){ //(...) omiss if(isset($this->request['data']['dispid']) and isset ($this->request['data']['nomeid'])){ $id_disp = $this->request['data']['dispid']; $id_ref = $this->request['data']['nomeid']; $dettagli_disp = $this->Dispositivo->find('first', array( 'where' => "ID_DISPOSITIVO = :id", 'bind'=> array(':id' => $id_disp))); $dettagli_ref = $this->Referente->find('first', array( 'where' => "ID_REFERENTE = :id", 'bind'=> array(':id' => $id_ref))); $attuale_assegnatario = $this->AppModel->find('first', array( 'tables' => array("VW_DISPOSITIVI_ASSEGNATI"), 'where' => "ID_DISPOSITIVO = :id", 'bind' => array(':id' => $id_disp))); if($dettagli_disp and $dettagli_ref){

53

$this->set('disp',$dettagli_disp); $this->set('ref',$dettagli_ref); $this->set('attuale',$attuale_assegnatario); }else{ $this->Session->setFlash('I dati forniti non sono validi', 'default', array('class' => 'fail')); $this->redirect(Array('controller' => 'Dispositivi','action' => 'assegnaDispositivo')); } }else{ $this->Session->setFlash('Non sono stati specificati i dati relativi al referente o alla sim da assegnare', 'default', array('class' => 'fail')); $this->redirect(Array('controller' => 'Dispositivi','action' => 'assegnaDispositivo')); } }

Tabella 4 – Controller:DispositiviController, metodo: assegnaDispositivoRiepilogo()

View: “assegna_dispositivo_riepilogo.ctp”

La vista presenta all’amministratore una schermata in cui compaiono i dati relativi al dispositivo da assegnare (marca, modello, codice IMEI) al futuro referente (cognome, nome, area servizio e ufficio di afferenza) e, se presente, cognome e nome dell’attuale assegnatario. Sempre da questa schermata l’amministratore può inoltre selezionare la data dalla quale far partire l’assegnazione. La data proposta d’ufficio sarà quella corrente.

Cliccando sul pulsante Assegna Dispositivo la vista invocherà mediante una chiamata di tipo POST il metodo assegnaDispositivoRiepilogo() passandogli i dati presenti nel Form (ID dispositivo, ID referente e data assegnazione). Tale metodo invocherà a sua volta il metodo assegnaDispositivo() del model Dispositivo passando come parametri gli stessi dati.

<h3>Riepilogo assegnazione dispositivo</h3>

<table> <tr> <td class="TdSottoServizio" colspan="2"> <?php echo $this->Html->image(('mobi.png'), array('width'=>'35')); echo $disp['MARCA']." - ".$disp['MODELLO']; ?> </td> <td class="TdSottoServizio" colspan="2"> <?php echo $this->Html->image(('Dummy_user.png'), array('width'=>'25')); echo $ref['REFERENTE']; ?> </td> </tr> <tr>

54

<td><b>IMEI:</b></td> <td><?php echo $disp['IMEI']; ?></td> <td><b>UFFICIO:</b></td> <td><?php echo $ref['DESCR_AREA']; ?> -> <?php echo $ref['DESCR_SERVIZIO']; ?> -> <?php echo $ref['CEC_DESCR']; ?></td> </tr> <tr> <td><b>REFERENTE ATTUALE:</b></td> <td colspan="3"><?php if(isset($attuale['REFERENTE'])){echo $attuale['REFERENTE'];}else{echo "NON ASSEGNATO";}; ?></td> </tr></table>

<?php echo $this->Form->create(false, array('type' => 'post', 'action' => 'assegnaDispositivoRiepilogo')); echo $this->Form->input('dispid', array('id' => 'hiddenID','value'=> $disp['ID_DISPOSITIVO'], 'type' => 'hidden')); echo $this->Form->input('nomeid', array('id' => 'hiddenAllowSearch', 'value'=> $ref['ID_REFERENTE'], 'type' => 'hidden')); echo $this->Form->input('DataAssegnato', array( 'type' => 'date', 'minYear' => '2009', 'label' => 'Data assegnazione *', 'maxYear' => date('Y') )); echo $this->Form->submit('Assegna Dispositivo'); echo $this->Form->end();?>

Tabella 5- View: assegna_dispositivo_riepilogo.ctp

Model: Dispositivo, Metodo: assegnaDispositivo(Disp,Ref,Data)

A questo metodo viene affidato il compito di stabilire la connessione con il database e chiamare la stored procedure che si occupa di assegnare un dispositivo (PR_ASSEGNA_DISPOSITIVO). Se l’operazione non è andata a buon fine viene passato al chiamante l’errore verificatosi.

public function assegnaDispositivo($idDisp, $idRef, $dataAss){ $dataAss = $dataAss['day']."/".$dataAss['month']."/".$dataAss['year']; $conn = $this->connetti(); $sql = "BEGIN PR_ASSEGNA_DISPOSITIVO(:iddisp, :idref, :dataAss); END;"; $stmt = oci_parse($conn,$sql); oci_bind_by_name($stmt,':iddisp',$idDisp,strlen($idDisp)); oci_bind_by_name($stmt,':idref',$idRef,strlen($idRef)); oci_bind_by_name($stmt,':dataAss',$dataAss,strlen($dataAss)); if(!oci_execute($stmt)){ $e = oci_error($stmt); oci_rollback($conn); $risultato['errmessage'] = $e['message']; return $risultato; } return true; }

Tabella 6 - Model: Dispositivo, Metodo: assegnaDispositivo(Disp,Ref,Data)

55

5 Conclusioni

L’obiettivo della tesi era la completa migrazione dell’attuale applicazione client per la gestione dei dispositivi mobili e delle SIM telefoniche in possesso dal Comune di Trieste da un’applicazione desktop per sistemi MS Windows ad un’applicazione web in grado di gestire la multi utenza per mezzo di un sistema di autenticazione e autorizzazione.

L’obiettivo non è stato pienamente raggiunto nei tempi previsti. Le cause possono essere imputate alla necessità di rivedere pesantemente la base di dati attualmente in uso, sia dal punto di vista progettuale che di adeguamento/aggiornamento dei dati. Quest’ultimo punto, ancora in atto, non può essere svolto in modo automatizzato ed è legato a decisioni e autorizzazioni dell’ente ospitante.

L’ente ospitante inoltre non ha ancora fornito una parte del codice sorgente indispensabile per il completamento della parte relativa all’autenticazione dei referenti.

Il risultato a cui si è giunti può venir riassunto nella riprogettazione dell’attuale base di dati in funzione dei requisiti nuovi ed esistenti e lo sviluppo di un prototipo dell’applicazione web funzionante ma non adeguatamente testata.

Durante lo svolgimento del progetto sono state acquisite nuove conoscenze e approfondite quelle già esistenti, in particolare:

Utilizzo di Oracle 9.2 e del linguaggio SQL Sviluppo di applicazioni con il linguaggio PHP Utilizzo di un framework che implementa il paradigma MVC HTML e CSS

56

6 Bibliografia

Bibliografia libri:

ATZENI, CERI, PARABOSCHI, TORLONE: “Base di dati”- McGraw- Hill T. CONVERSE, J. PARK, C. MORGAN: “PHP & MYSQL la guida” - McGraw- Hill

Bibliografia in rete:

http://php.net http://www.oracle.com

57

http://www.oracle.com/

http://php.net/

Porting evolutivo dell'applicazione per la gestione dei dispositivi del Comune di Trieste

Documents

Transcript of Porting evolutivo dell'applicazione per la gestione dei dispositivi del Comune di Trieste