1. 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

2. 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
2.3.2
Operazioni sui dati ........................................................................................ 14
2.3.3
3
Requisiti sui dati ............................................................................................ 13
Requisiti applicazione client.......................................................................... 15
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. 3.2.8
Schema E-R ristrutturato .............................................................................. 37
3.2.9
Schema logico finale ..................................................................................... 38
3.3
3.4
4
Documentazione aggiuntiva ................................................................................ 39
Adeguamento della base dati .............................................................................. 41
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

4. 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

5. 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

6. 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

7. Figura 1

8. Figura 2
8

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

10. 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
10

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.
11

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.
12

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.
13

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
14

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.
15

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.
16

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.
17

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
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 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’.
18

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
I referenti possono
essere direttori di
area, direttori di
servizio,
amministratore
oppure senza ruolo
specifico
(*)generalizzazione
totale ed esclusiva
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.
19

20. 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
20

21. 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).
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.
21

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
22

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
23

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_DISPOSITIVO
ID_GRUPPO_DISPOSITIVO
Identificatore numerico univoco (candidato chiave primaria)
GRUPPO_DISPOSITIVO
Gruppo a cui il dispositivo appartiene (es. elezioni, censimento,
fonia mobile …)
POSIZIONE_DISPOSITIVO
POSIZIONE
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)
24

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
25

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 assegnata
DATA_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
26

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 assegnato
DATA_REVOCA
Data in cui il dispositivo è stato revocato
APPARTENENZA M-D
Collega l’entità DISPOSITIVI con l’entità MODELLO_DISPOSITIVI
27

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
28

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.
29

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

31. 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

32. 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à.
32

33. Tavole degli accessi in
presenza di ridondanza
Tavole degli accessi in
assenza di ridondanza
OPERAZIONE 13
OPERAZIONE 13
CONCETTO
COSTR.
ACC.
TIPO
CONCETTO
COSTR.
ACC.
TIPO
SIM
E
0,25
L
ASSEGNAZIONE-
R
0,25
L
E
1
L
S CORRENTE
OPERAZIONE 4
SIM
CONCETTO
COSTR.
ACC.
TIPO
ASSEGNAZIONE-S
R
1
S
CORRENTE
OPERAZIONE 4
CONCETTO
COSTR.
ACC.
TIPO
R
1
S
SIM
E
1
L
ASSEGNAZIONE-S
SIM
E
1
S
CORRENTE
OPERAZIONE 6
OPERAZIONE 6
CONCETTO
COSTR.
ACC.
TIPO
CONCETTO
COSTR.
ACC.
TIPO
ASSEGNAZIONES 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
33

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
34

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.
35

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).
36

37. 3.2.8 Schema E-R ristrutturato
37

38. 3.2.9 Schema logico finale
Figura 5

39. 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_GRUP
PO_DISPOSITIVO"
AND
"DWH_ASSEGNAZIONE_D"."DATA_REVOCA" IS NULL;

40. 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"
BEFORE
UPDATE 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;
40

41. 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
non presenti nei campi “note” delle tabelle SIM e DISPOSITIVI) è un’operazione tuttora in
atto che può essere svolta solo dall’ente ospitante.
41

42. 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.
42

43. 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
Figura 6 - Diagramma degli attori
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.
43

44. 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
44

45. 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
45

46. 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.
46

47. 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.
47

48. 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.
48

49. 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]
49

50. 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à
assegnaDispositivoRiepilogo() del controller DispositiviController.
il
metodo
<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) {
50

51. $("#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){
51

52. $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>
52

53. <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)
53

54. 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
54

55. 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
55