Progettto ed implementazione di un'applicazione per la gestione di badge di riconoscimento personale
1. Università degli Studi di Trieste
Facoltà di Ingegneria
Corso di laurea triennale in Ingegneria Informatica
Progetto ed implementazione di un’applicazione per la
gestione di Badge di riconoscimento personale
Relatore : Laureando :
Chiar.mo Prof. Maurizio Fermeglia Dagostin Manuel
Anno accademico : 2013-2014
3. 3
INTRODUZIONE
La presente tesi affronta la problematica della progettazione ed implementazione di
un’applicazione per la gestione dei Badge. Il Badge è una tessera che serve per l’identificazione
personale.
Il risultato finale è stato un’applicazione web, collegato con un DB, che gestisce tutte le
informazioni dei Badge. Per gestione dei Badge si intende la possibilità di visualizzare, inserire,
modificare ed eliminare tutte le informazioni in possesso.
La motivazione principale è stata la gestione delle informazioni per i Badge. C’è stata la necessità
di poter tenere evidenza di tutto il personale che entra in una Sezione di un Dipartimento, in modo
comodo ed sicuro.
Durante lo svolgimento del lavoro sono stati affrontati diversi punti essenziali. Innanzitutto il
primo punto è stato lo Studio di Tecnologie da usare. Gli strumenti di sviluppo usati sono stati SQL
Server 2012 per il DB, mentre per l’applicativo web è stato usato Visual Studio 2013. Il linguaggio
usato è stato C#, mentre per la pagine web è stato usato ASP.NET e web form. Un altro punto
fondamentale è stata l’Analisi. Qui sono stati raccolti tutti i requisiti necessari per la formazione
dell’applicativo web. Dopo il passo successivo è stata la progettazione dell’interfaccia in base ai
requisiti espressi in fase di analisi. Il passo successivo è stata la realizzazione sia del DB che
dell’applicativo web usando le tecnologie espresse sopra.
Il capitolo seguente riguarda la fase di Analisi. Qui sono stati analizzati tutti i requisiti espressi per
la formazione del DB. Il passo successivo è la progettazione concettuale, logica del DB e la
progettazione dell’interfaccia in base ai requisiti espressi in fase di Analisi. L’ultimo passo è stata la
progettazione fisica del DB (trasformazione dei schemi logici in tabelle) e la realizzazione
dell’interfaccia web .
4. 4
ANALISI
In questo capitolo viene analizzato il lavoro di Analisi per la costruzione di un sito web per la
gestione di badge.
Un badge di identificazione o solo badge (dall'inglese: distintivo) è una tessera in PVC o altro
materiale plastico (PET/ABS/Policarbonato) utilizzata per l'identificazione personale. Normalmente
ha le dimensioni di una carta di credito conforme alla norma ISO 7810 nel formato ID-1 e può
essere munito di banda magnetica o di altri dispositivi, quali ad esempio microcontrollori, RFID o
memorie EEPROM, per l'utilizzo con apparecchiature informatiche e elettroniche. I badge possono
riportare informazioni personali, fotografie e indicazioni utili allo scopo per cui sono utilizzati. Ad
esempio potrebbero essere indicati la mansione, i privilegi d'accesso o il reparto di competenza. Al
loro interno, su opportuni supporti, possono essere anche memorizzate informazioni quali
password, situazione clinica, codice addetto etc. In questo progetto i badge servono per
l’identificazione degli individui che sono presenti nei vari dipartimenti.
Si necessita la possibilità de gestire tramite interfaccia web la gestione delle informazioni relative
ai singoli badge. Questo sito sarà usato dal personale autorizzato per poter rilasciare o ritirare i
badge per poter visualizzare tutte le persone che hanno l’accesso ad un dipartimento.
REQUISITI SOFTWARE
Quello che si vuole realizzare è un sito che innanzitutto gestisca le informazioni dei singoli badge.
Ogni badge è provvisto di un numero identificativo, di una data di rilascio, di una data di scadenza
e di un parametro che evidenzia lo stati del badge. Il badge viene rilasciato dal personale
competente. Il personale competente avrà delle informazioni necessarie al sito per gestire tutti i
badge presenti. Tipicamente il personale sarà dotato di un username e una password che li
consentirà di accedere al sito.
Per ogni persona esiste un badge(per ogni dipartimento esiste un Badge specifico). Una persona
può avere più di un badge. Infatti deve esserci la possibilità di gestire più ingressi da parte di una
stessa persona. Le informazioni principali di un utente munito di badge sono Nome, Cognome,
Data di nascita, Luogo di nascita, Stato di nascita, Indirizzo di residenza, Città e Stato di residenza,
Telefono, E-mail, Qualifica (serve per identificare che tipo di utente si tratta : studente, docente,
ecc.), Data di inserimento e uno stato d’utente per sapere se quest’ultimo è attivo o meno.
Per ogni dipartimento esiste uno ed un solo badge. Le informazioni riguardo ad un dipartimento in
questo progetto sono le seguenti : Nome, Indirizzo, Responsabile e nome della facoltà di
appartenenza. Negli ultimi anni il concetto di facoltà è cambiato, ma nel DB sono presenti, questo
potrebbe aiutare se in un futuro il concetto verrà di nuovo ripreso.
5. 5
PROGETTAZIONE
DATABASE-progettazione concettuale
RAGRUPPAMENTO DI FRASI
FRASI RELATIVE AL BADGE
Ogni badge è provvisto di un numero identificativo, di una data di rilascio, di una data di scadenza
e di un parametro che evidenzia lo stati del badge. Il badge viene rilasciato dal personale
competente. Il personale competente avrà delle informazioni necessarie al sito per gestire tutti i
badge presenti. Tipicamente il personale sarà dotato di un username e una password che li
consentirà di accedere al sito.
FRASI RELATIVE ALL’UTENTE
Per ogni persona esiste un badge. Una persona può avere più di un badge. Infatti deve esserci la
possibilità di gestire più ingressi da parte di una stessa persona. Le informazioni principali di un
utente munito di badge sono Nome, Cognome, Data di nascita, Luogo di nascita, Stato di nascita,
Indirizzo di residenza, Città e Stato di residenza, Telefono, E-mail, Qualifica (serve per identificare
che tipo di utente si tratta : studente, docente, ecc.), Data di inserimento e uno stato d’utente per
sapere se quest’ultimo è attivo o meno.
FRASI RELATIVE AL DIPARTIMENTO
Per ogni dipartimento esiste uno ed un solo badge. Le informazioni riguardo ad un dipartimento
in questo progetto sono le seguenti : Nome, Indirizzo, Responsabile e nome della facoltà di
appartenenza.
GLOSSARIO DEI TERMINI
TERMINE DESCRIZIONE SINONIMO COLLEGAMENTO
badge Oggetto che identifica
la persona che ne fa
uso in quel momento
Tesserina Utente,Personale
Utente Persona che usa il
badge per accedere ai
dipartimenti
Personaggio Badge
Dipartimento è "l'organizzazione di
uno o più settori
di ricerca omogenei
per fini e per metodo,
e dei relativi
insegnamenti
Università Utente,Personale
Personale Persona autorizzata al
rilascio e gestione dei
badge
Dipendente Badge,Dipartimento
6. 6
ANALISI DI ENTITÀ E RELAZIONI
SCHEMA SCHELETRO
Dall’analisi effettuata sui requisiti software possiamo osservare immediatamente due entità
fondamentali che sono i BADGE e l’UTENTE.
L’entità Badge e l’entità Utente sono collegate con la relazione Badge_Utente come in figura :
BADGE UTENTE
BADGE_UTENTE
Figura 1 : Schema Scheletro
ANALISI DI ALTRE ENTITÀ E RELAZIONI
Dai requisiti espressi vediamo la necessità di definire due entità Dipartimento e Personale (che per
comodità progettuale chiamiamo LogIn) .
Le due entità sopra citate sono collegate con la relazione Dipartimento_Login come in figura :
DIPARTIMENTO LOGIN
DIPARTIMENTO_LOGIN
Figura 2 : Entità Dipartimento e LogIn
Poi vediamo la necessità di introdurre l’entità TipoBadge che sarà collegata con l’entità Badge
tramite la relazione TipoBadge_Badge, come in figura :
7. 7
BADGE
TIPOBADGE_BADGE TIPOBADGE
Figura 3 : Entità Badge e TipoBadge
DIAGRAMMA E-R FINALE
Tenuto conto dei requisiti possiamo definire lo E-R finale. Da tenere conto che per collegare le
entità Dipartimento e LogIn allo schema scheletro useremo la relazione Dipartimento_Badge per
collegare l’entità Dipartimento con l’entità Badge. Mentre collegheremo l’entità LogIn con l’entità
Badge con la relazione Badge_LogIn.
Di conseguenza lo schema E-R finale risulta essere il seguente :
DIPARTIMENTO LOGIN
DIPARTIMENTO_LOGIN
BADGE UTENTE
BADGE_UTENTE
DIPARTIMENTO_BADGE
BADGE_LOGIN
TIPOBADGE_BADGE
TIPOBADGE
Figura 4 : Schema E-R finale
8. 8
ANALISI DI ATTRIBUTI E CARDINALITÀ
In base ai requisiti sopra espressi in fase di analisi distinguiamo per l’entità badge i seguenti
attributi : Numero, Data rilascio, Data scadenza e Stato_badge.
Per l’entità Utente abbiamo i seguenti attributi : Nome, Cognome, Data nascita, Luogo nascita,
Stato nascita, Indirizzo residenza, Città di residenza, Stato di residenza, telefono, E-mail, Data
inserimento, Attivo e Qualifica.
Per quel che riguarda le cardinalità abbiamo una relazione uno-molti tra le due entità in quanto
dai requisiti sopra espressi possiamo definire più badge per massimo 1 utente.
Quindi possiamo definire lo schema scheletro con i seguenti attributi :
BADGE UTENTE
BADGE_UTENTE
NUMERO
DATA RILASCIO
DATA SCADENZA
STATO_BADGE
NOME
COGNOME
DATA DINASCITA
LUOGO DINASCITA
STATO DI NASCITA
INDIRIZZO DI RESIDENZA
CITTA DI RESIDENZA
STATO DI RESIDENZA
TELEFONOE-MAIL
DATA DIINSERIMENTO
ATTIVO
QUALIFICA
N-1
Figura 5 : Schema scheletro con attributi e cardinalità
Per l’entità Dipartimento possiamo definire i seguenti attributi : Nome, Indirizzo, Responsabile e
Facoltà. Per l’entità LogIn possiamo invece definire i attributi : Username, Password, Nome e
Cognome.
Per quel che riguarda le cardinalità possiamo verificare facilmente che la relazione che intercorre
tra le entità Dipartimento e LogIn è di cardinalità molti a molti.
Di conseguenza abbiamo il seguente schema :
9. 9
DIPARTIMENTO LOGIN
DIPARTIMENTO_LOGIN
NOME INDIRIZZO
RESPONSABILE FACOLTA
USERNAME PASSWORD
NOME
COGNOME
N-N
Figura 6 : Entità restanti con attributi e cardinalità
Vediamo che c’è una relazione tra l’entità Dipartimento e l’entità Badge che chiamiamo
Dipartimento_Badge. La cardinalità è di tipo uno a molti, infatti per 1 singolo dipartimento ci possono
essere diversi badge a disposizione.
BADGE
DIPARTIMENTO_BADGE
DIPARTIMENTO
NOME
INDIRIZZO
RESPONSABILE
FACOLTA
STATO_BADGE
NUMERO
N-1
DATA RILASCIO
DATA SCADENZA
Figura 7 : Entità restanti con attributi e cardinalità
Inoltre dobbiamo osservare la presenza della relazione Badge_LogIn tra l’entità Badge e LogIn. La
cardinalità sarà di tipo uno a molti, in quanto per il personale autorizzato al rilascio dei Badge (1
persona per esempio) può fornire più tesserine.
10. 10
BADGE
BADGE_LOGIN
NUMERO
DATA RILASCIO
DATA SCADENZA
STATO_BADGE
N-1
LOGIN
USERNAME
PASSWORD
NOME
Figura 8 : Entità restanti con attributi e cardinalità
Tra l’entità Badge e il Tipo_Badge abbiamo la cardinalità di 1-N, infatti un dipartimento può avere più di un
Badge rilasciato. L’entità Tipo_Badge ha un campo che si chiama Nome, come in figura :
TIPOBADGE_BADGE
1-N
TIPOBADGEBADGE
STATO_BADGE
DATA SCADENZA
DATA RILASCIO
NUMERO NOME
Lo schema E-R finale con attributi e cardinalità risulta essere il seguente :
11. 11
LOGIN
DIPARTIMENTO_LOGIN
BADGE
BADGE_UTENTE
DIPARTIMENTO_BADGE
BADGE_LOGIN
UTENTE
NOME
COGNOME
DATA DI NASCITA
LUOGO DI NASCITA
STATO DI NASCITA
INDIRIZZO DI RESIDENZA
CITTA DI RESIDENZA
STATO DI RESIDENZA
TELEFONOE-MAIL
DATA DI INSERIMENTO
ATTIVO
QUALIFICA
DIPARTIMENTO
NOME
INDIRIZZO
RESPONSABILE
FACOLTA
STATO_BADGE
DATA RILASCIO
DATA SCADENZA
NUMERO
USERNAMEPASSWORD
NOME COGNOME
N-1
N-N
N-1 N-1
TIPOBADGE_BADGE
1-N
TIPOBADGE
NOME
Figura 9 : Schema E-R finale della progettazione concettuale con attributi e cardinalità
12. 12
DATABASE-progettazione logica
TAVOLA DEI VOLUMI
Una possibile tavola dei volumi è la seguente
CONCETTO TIPO VOLUME
Badge E 20 000
Utente E 10 000
Dipartimento E 11
LogIn E 25
TAVOLA DELLE OPERAZIONI
Una possibile tavola delle operazioni è la seguente
OPERAZIONE TIPO FREQUENZA
Inserimento di dati S 100 volte al giorno
Modifica di dati S 10 volte al giorno
Lettura di dati L 10 volte al giorno
TAVOLA DEGLI ACCESSI
Una possibile tavola degli accessi, eseguendo un’operazione di inserimento di dati può essere la
seguente :
CONCETTI COSTRUTTO ACCESSO TIPO
Badge Entità 1 S
Utente Entità 1 S
Dipartimento Entità 1 S
LogIn Entità 1 S
Una possibile tavola degli accessi, eseguendo un’operazione di lettura di dati può essere la
seguente :
CONCETTI COSTRUTTO ACCESSO TIPO
13. 13
Badge Entità 1 L
Utente Entità 1 L
Dipartimento Entità 1 L
LogIn Entità 1 L
RISTRUTTURAZIONE DELLO SCHEMA E-R
Analizzando i requisiti sopra espressi vediamo che abbiamo necessità di separare il concetto di
attributo per alcune entità. In particolare nell’entità Utente osserviamo che l’attributo Qualifica
potrebbe essere definito come entità separata. Quindi per collegarla all’entità Utente useremo
una relazione Utente_Qualifica. La relazione avrà cardinalità di tipo molti a uno. Gli attributi
relativi sono il Nome e la Descrizione.
Di conseguenza possiamo trovare il seguente schema :
UTENTE
NOME
COGNOME
DATA DI NASCITA
LUOGO DI NASCITA
STATO DI NASCITA
INDIRIZZO DI RESIDENZA
CITTA DI RESIDENZA
STATO DI RESIDENZA
TELEFONOE-MAIL
DATA DI INSERIMENTO
ATTIVO
QUALIFICA
QUALIFICA
UTENTE_QUALIFICA
N-1
NOME
DESCRIZIONE
Figura 7 : Separazione entità Qualifica
Inoltre possiamo notare una netta separazione tra l’entità Dipartimento e l’attributo (che diventa
entità) Facoltà. L’attributo dell’entità Facoltà è Nome. La relazione che lega l’entità Facoltà con
l’entità Dipartimento è Dipartimento_Facoltà ed ha una cardinalità molti a molti.
Di conseguenza possiamo notare la figura :
14. 14
DIPARTIMENTO FACOLTA
DIPARTIMENTO_FACOLTA
NOME INDIRIZZO
RESPONSABILE NOME
N-N
Figura 8: Separazione delle entità Dipartimento e Facoltà
Di conseguenza possiamo vedere lo schema finale E-R ristrutturato considerando tutti i fattori
analizzati con attributi e cardinalità:
DIPARTIMENTO LOGIN
DIPARTIMENTO_LOGIN
BADGE BADGE_UTENTE
DIPARTIMENTO_BADGE
BADGE_LOGIN
UTENTE
NOME
COGNOME
DATADINASCITA
LUOGODINASCITA
STATODI NASCITA
INDIRIZZODI RESIDENZA
CITTADI RESIDENZA
STATODI RESIDENZA
TELEFONOE-MAIL
DATADIINSERIMENTO
ATTIVO
FACOLTA
DIPARTIMENTO_FACOLTA
NOME
INDIRIZZO
RESPONSABILE
NOME
N-N
QUALIFICA UTENTE_QUALIFICA
N-1
NOME
DESCRIZIONE
NUMERO
DATASCADENZA
DATARILASCIO
STATO_BADGE
USERNAME PASSWORD
NOME
COGNOME
1-N
1-N 1-N
N-1
TIPOBADGE_BADGE
1-N
TIPOBADGE
NOME
Figura 9 : Schema E-R finale ristrutturato
15. 15
SCELTA DEGLI IDENTIFICATORI PRIMARI
Ogni entità ha una sua chiave primaria che la identifica in modo univoco. Viene segnata con
PK_nome dell’entità per convezione. Sono segnate di colore rosso nella seguente figura.
DIPARTIMENTO LOGIN
DIPARTIMENTO_LOGIN
BADGE BADGE_UTENTE
DIPARTIMENTO_BADGE
BADGE_LOGIN
UTENTE
NOME
COGNOME
DATADINASCITA
LUOGODINASCITA
STATODI NASCITA
INDIRIZZODI RESIDENZA
CITTADI RESIDENZA
STATODI RESIDENZA
TELEFONOE-MAIL
DATADIINSERIMENTO
ATTIVO
FACOLTADIPARTIMENTO_FACOLTA
NOME
INDIRIZZO
RESPONSABILE
NOME
N-N
QUALIFICA UTENTE_QUALIFICA
N-1
NOME
DESCRIZIONE
NUMERO
DATASCADENZA
DATARILASCIO
STATO_BADGE
USERNAME PASSWORD
NOME
COGNOME
PK_FACOLTA
PK_LOGIN
PK_DIPARTIMENTO
PK_BADGE
PK_QUALIFICA
PK_UTENTE
N-1
N-1
N-1
N-1 TIPOBADGE_BADGE
1-N
TIPOBADGE
NOME
PK_TIPOBADGE
Figura 10 : Schema E-R finale con chiavi primarie
SCELTA DELLE CHIAVI ESTERNE
In relazione alle cardinalità espresse prima possiamo definire le chiavi esterne. L’entità Badge ha 3
chiavi esterne: la FK_Utente, FK_Dipartimento e FK_LogIn. L’entità Dipartimento ha 2 chiavi
16. 16
esterne FK_Facoltà,FK_LogIn. L’entità Utente ha una FK_Qualifica che la collega con l’entità
Qualifica. Le chiavi esterne sono segnalate in colore blu. Con la definizione dei vincoli di integrità
referenziale le relazioni che servono per collegare le entità spariscono (sono segnate con linea
trateggiata) :
DIPARTIMENTO LOGIN
DIPARTIMENTO_LOGIN
BADGE BADGE_UTENTE
DIPARTIMENTO_BADGE
BADGE_LOGIN
UTENTE
NOME
COGNOME
DATADINASCITA
LUOGODINASCITA
STATODINASCITA
INDIRIZZODIRESIDENZA
CITTADIRESIDENZA
STATODIRESIDENZA
TELEFONOE-MAIL
DATADIINSERIMENTO
ATTIVO
FACOLTADIPARTIMENTO_FACOLTA
NOME
INDIRIZZO
RESPONSABILE
NOME
QUALIFICA UTENTE_QUALIFICA
NOME
DESCRIZIONE
NUMERO
DATASCADENZA
DATARILASCIO
STATO_BADGE
USERNAME PASSWORD
NOME
COGNOME
PK_FACOLTA
PK_LOGIN
PK_DIPARTIMENTO
PK_BADGE
PK_QUALIFICA
PK_UTENTE
FK_FACOLTA
FK_LOGIN
FK_LOGIN
FK_UTENTE
FK_DIPARTIMENTO
FK_BADGE
FK_QUALIFICA
TIPOBADGE_BADGE
1-N
TIPOBADGE
NOME
PK_TIPOBADGE
FK_BADGE
Figura 11 : Schema E-R con chiavi primarie e chiavi esterne
17. 17
PROGETTAZIONE DELL’INTERFACCIA
L’interfaccia è stata fatta seguendo in modo dettagliato tutti i Requisiti che sono stati espressi in fase
di Analisi. Bisogna costruire un sito web. Siccome l’IDE di sviluppo è Visual Studio allora si è preferito
procedere programmando in ASP.NET.
Analizzando i requisiti e le necessità dell’utente finale come primo passo si ha la necessità di creare
una pagina di LogIn. Infatti questa serve per l’accesso al personale autorizzato per la gestione dei
badge.
Dopo l’accesso è previsto l’ingresso in una pagina dove si possono scegliere le varie opzioni come
l’aggiunta di nuovi badge,modifica o eliminazione di badge già esistenti. C’è sicuramente da progettare
una pagina per la modificare e/o aggiungere dipartimenti che viene chiamata Admin.
Quindi possiamo costruire una prima rappresentazione grafica del diragramma di uttilizzo
dell’applicazione, come in figura .
ADMIN
INGRESSO
LOGIN
MODIFICAELIMINA BADGE NUOVO BADGE
Figura 12 : Diagramma di uttlizzo dell’applicazione
18. 18
Di particolare interesse è senz’altro l’inserimento dei dati per un nuovo badge. Quando si chiede
l’inserimento di un nuovo badge si apre la pagina Dipartimenti. Si sceglie un dipartimento da
visitare fra tutti i possibili proposti. Infatti è stato progettato per ogni dipartimento un specifico
badge. Quindi i vari badge differiscono da dipartimento a dipartimento. Quindi in base al
dipartimento che si vuole visitare viene selezionato il corrispondente badge. Quindi una volta che
si è scelto quale dipartimento visitare si apre una nuova pagina, chiamata InfoBadge. Qui si
inseriscono i dati richiesti.
Una volta inseriti i dati richiesti si passa ad un’anteprima del badge e si dà la possibilità all’utente
autorizzato di stampare eo di fare delle modifiche.
ANTEPRIMA
INFOBADGE
TEMPLATE PER ILTIPO DI BADGE
Figura 13 : Inserimento di dati del nuovo Badge
E stata programmata anche una pagina di Errore per la gestione maldestra di dati da parte
dell’utente.
19. 19
REALIZZAZIONE
DATABASE-progettazione fisica
Tenuto conto della progettazione concettuale e logica, possiamo arrivare al seguente schema di
progettazione fisica che identifica in maniera molto reale il database.
tblFacolta
PK_FacoltaPK
Nome
tblDipartimento
PK_DipartimentoPK
FK_FacoltaFK
FK_LogInFK
Responsabile
Nome
Indirizzo
tblLogIn
PK_LogInPK
Username
Password
Nome
Cognome
tblBadge
PK_BadgePK
FK_DipartimentoFK
FK_LogInFK
FK_UtenteFK
Numero
Data scadenza
Data rilascio
Stato_Badge
tblQualifica
PK_QualificaPK
Descrizione
Nome
tblUtente
PK_UtentePK
FK_BadgeFK
Nome
Cognome
Data di nascita
Luogo di nascita
Stato di nascita
Indirizzo residenza
Citta residenza
Stato residenza
Telefono
E-mail
Data inserimento
Attivo
FK_QualificaFK
FK_TipoBAdgeFK
tblTipoBadge
PK_QualificaPK
Nome
Figura 14 : Progettazione fisica
20. 20
INTERFACCIA
Dalla progettazione dell’interfaccia possiamo notare la Home page che è rappresentata nella
figura seguente. Possiamo notare le seguenti possibilità che sono : Crea nuovo, Gestione badge e
Admin.
Figura 15 : Home page
Queste sono infatti le 3 operazioni fondamentali, creazione del nuovo badge, gestione del badge e
sezione Admin. Visitiamo tutte le sezioni disponibili. Sicuramente la più interessante è quella
rigaurdante la Creazione di un nuovo Badge.
21. 21
Nuovo Badge
Figura 16 : Badge generator
In questa sezione possiamo scegliere il template corrispondente. Ci sono 4 possibilità di scelta che
sono : Badge Studenti , Conferenza, Ospite dipartimento e Visita.
La pagina successiva serve per l’inserimento dei dati. La pagina è rapprsentata nella seguente
figura .
22. 22
Figura 17 : Pagina di inserimento dei dati
Il relativo codice Javascript presente qui sotto è quello che riempie automaticamente i campi di un
utente già presente.
1. self.inizializzaForm = function () {
a. $("#utenteEsistente").autocomplete({
i. source: function (request, response) {
ii. $('#utenteEsistente').addClass('ui-autocomplete-loading');
iii. $.ajax({
1. dataType: "json",
2. type: 'POST',
3. url: 'WS/WSCardGenerator.asmx/GetListaUtenti',
4. data: ko.toJSON({ termine: request.term }),
5. cache: false,
6. contentType: "application/json; charset=utf-8",
7. processData: false,
8. success: function (data) {
9. $('#utenteEsistente').removeClass('ui-autocomplete-loading');
10. response($.map(data.d, function (v, i) {
a. var text = v.Valore;
b. if (text) {
i. return {
ii. label: v.Valore,
iii. value: v.Chiave
iv. };
c. }
11. }));
12. },
13. error: function (data) {
23. 23
14. $('#utenteEsistente').removeClass('ui-autocomplete-loading');
15. }
iv. });
v. },
vi. minLength: 2,
vii. select: function (event, ui) {
viii. mostraFinestraCaricamento();
ix. $.ajax({
1. dataType: "json",
2. type: 'POST',
3. url: 'WS/WSCardGenerator.asmx/LoadUtente',
4. data: ko.toJSON({ idUtente: ui.item.value }),
5. cache: false,
6. contentType: "application/json; charset=utf-8",
7. processData: false,
8. success: function (data) {
9. self.newIdOspite(data.d.idOspite);
10. self.newNome(data.d.nome);
11. self.newCognome(data.d.cognome);
12. self.newEmail(data.d.email);
13. $('#dataNascita').val(formattaDataJSON(data.d.dataNascita));
14. self.newDataNascita(formattaDataJSON(data.d.dataNascita));
15. self.newTelefono(data.d.telefono);
16. self.newIndirizzo(data.indirizzo);
17. self.newCitta(data.d.citta);
18. self.newStato(data.d.stato);
19. self.newImageFile(data.d.fileImmagine);
20. self.files.removeAll();
21. self.files.push(new FileModel("", self.newImageFile()));
22. nascondiFinestraCaricamento();
23. },
24. error: function (data) {
25. nascondiFinestraCaricamento();
26. }
x. });
xi. $("#utenteEsistente").val(ui.item.label);
xii. return false;
xiii. }
b. });
2. };
Ora viene mostrata la schermata di selezione dell’immagine da web cam.
24. 24
Figura 18 : Selezione immagine da webcam
Il relativo codice html che si genera alla cattura dell’immagine è il seguente :
1. <div class="modal fade" id="modalWebcam" tabindex="-1" role="dialog" aria-
labelledby="modalWebcamLabel" aria-hidden="true">
2. <div class="modal-dialog">
a. <div class="modal-content">
b. <div class="modal-header">
i. <button type="button" class="close" data-dismiss="modal" aria-
label="Chiudi"><span aria-hidden="true">×</span></button>
ii. <h4 class="modal-title" id="modalWebcamLabel">Cattura foto via
Webcam</h4>
c. </div>
d. <div class="modal-body" style="height: 320px">
i. <div class="col-xs-8">
ii. <div id="webcam">
iii. </div>
iv. <div style="margin:5px;">
1. <img src="images/webcamlogo.png" style="vertical-align:text-
top"/>
2. <select id="cameraNames" size="1" data-bind="event: { change:
changeCamera }" style="width:245px;font-size:10px;height:25px;">
3. </select>
v. </div>
vi. </div>
vii. <div class="col-xs-4">
viii. <p><button class="btn btn-small" id="btn2" data-bind="click:
base64_toimage">
1. <span class="glyphicon glyphicon-camera" aria-
hidden="true"></span> Cattura immagine
ix. </button></p>
x. <p><label>Preview</label></p>
xi. <p><img id="image" style="width:180px;height:153px;"/></p>
xii. </div>
25. 25
e. </div>
f. <div class="modal-footer">
i. <button type="button" class="btn btn-default" data-
dismiss="modal">Chiudi</button>
ii. <button type="button" class="btn btn-primary" data-bind="click:
salvaImmagineDaWebcam, enable: tempImmagineDaWebcam().length >
1">Salva</button>
g. </div>
h. </div>
3. </div>
4. </div>
L’ultima pagina invece sulla quale si arriva prima della fine è la seguente :
Figura 19 : Ultima pagina
Si notano la possibilità di salvare sul DB i dati cliccando sull’immagine corrispondente il
floppy disk, inoltre c’è la possibilità di stampare il badge appena formato.
26. 26
Gestione Badge
Figura 20 : Pagina di Badge Generator
Il codice che genera questa pagina è il seguente :
1. <%@ Page Language="C#" MasterPageFile="~/Main.Master" AutoEventWireup="true"
CodeBehind="BadgeList.aspx.cs" Inherits="EcardGenerator.BadgeList" %>
2. <asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
3. <script src="../Js/BadgeListModel.js" type="text/javascript"></script>
4. <div class="container">
5. <div class="row">
a. <h3>Gestisci i badge</h3>
b. <table class="table table-striped">
i. <tr>
ii. <th>Numero Badge</th>
iii. <th>Nome Utente</th>
iv. <th>Data Rilascio</th>
v. <th></th>
vi. </tr>
vii. <tbody data-bind="foreach: listaBadge">
viii. <tr>
1. <td data-bind="text: Numero"></td>
2. <td data-bind="text: Nome_Utente"></td>
3. <td data-bind="text: Data_Rilascio"></td>
4. <td>
5. <a href="#" type="button" class="btn btn-primary" data-
bind="click: $root.EditBadge"><i class="glyphicon glyphicon-
edit"></i></a>
27. 27
6. <a href="#" type="button" class="btn btn-danger" data-
bind="click: $root.ConfirmDeleteBadge"><i class="glyphicon
glyphicon-trash"></i></a>
7. </td>
ix. </tr>
x. </tbody>
c. </table>
6. </div>
7. </div>
a. </asp:Content>
Di particolare interesse sono le righe 5.viii.5÷6 che sono quelle che servono per modificare le
informazioni già esistenti o per eliminarle dal DB.
Admin
La seguente pagina è riservata alla sezione Admin. Qui si possono gestire tutti i dati relativi alle
facoltà e ai dipartimenti.
Figura 21 : Pagina di Admin
Vediamo come ci sia la possibilità di aggiungere vari dipartimenti, e per ogni dipartimento si
possono aggiungere delle sezioni. Premendo il bottone “Aggiungi Sezione” compare la seguente
parziale schermata
28. 28
Figura 22 : Inserimento Sezione
Il relativo codice Javascript che esegue l’aggiunta di una Sezione è il seguente :
1. //Aggiunge un nuovo elemento alla lista dipartimento
2. self.addDipartimento = function (facolta) {
a. facolta.dipartimenti.push({
i. idDipartimento: 0,
ii. idDipartimentoNew: 0,
iii. nomeDipartimento: "",
iv. responsabile: "",
v. indirizzo: "",
vi. edit: true
b. });
3. };
4. //===================================================================================
============================//
5. //Rimuove l'elemento dalla lista dei dipartimenti
6. self.removeDipartimento = function (dip) {
a. $.callService("RemoveDipartimento", { dipartimento: dip },
removeDipartimentoOk, erroreGenerico);
7. };
8. //===================================================================================
============================//
9. //Funzione di conferma della rimozione dell'elemento dipartimento
10. var removeDipartimentoOk = function(dipartimento) {
a. $.each(self.facolta(), function() { this.dipartimenti.remove(dipartimento) });
11. };
12. //===================================================================================
============================//
13. //Abilita la modifica all'elemento
14. self.editDipartimento = function (dip) {
a. $.each(self.facolta(), function (i, v) {
i. if (v.idFacolta == dip.idFacolta) {
ii. $.each(v.dipartimenti(), function (k, value) {
1. if (value.idDipartimento == dip.idDipartimento) {
2. value.edit = true;
3. }
iii. });
iv. }
b. });
c. self.refresh();
15. };
16. //===================================================================================
============================//
17. //Salva le modifiche all'elemento dipartimento
18. self.salvaDipartimento = function (dip) {
29. 29
a. $.callService("SaveDipartimento", { dipartimento: dip }, saveDipartimentoOk,
erroreGenerico);
19. };
20. //===================================================================================
============================//
21. //Funzione di conferma del salvataggio dell'elemento dipartimento
22. var saveDipartimentoOk = function (dip) {
a. if (dip == null) {
i. $.growl({
ii. icon: "glyphicon glyphicon-remove",
iii. title: " Errore: ",
iv. message: "Si è verificato un errore durante il salvatggio dei dati"
v. }, {
vi. type: "danger"
vii. });
viii. return;
b. }
c. $.each(self.facolta(), function (i, v) {
i. if (v.idFacolta == dip.idFacolta) {
ii. $.each(v.dipartimenti(), function (k, value) {
1. if (value.idDipartimento == dip.idDipartimento) {
2. value.edit = false;
3. }
iii. });
iv. }
d. });
e. $.growl({
i. icon: "glyphicon glyphicon-ok",
ii. title: " Successo: ",
iii. message: "Salvataggio avvenuto con successo"
f. }, {
i. type: "success"
g. });
h. self.refresh();
23. }
30. 30
CONCLUSIONI
Gli obbiettivi che il progetto si era posto all’inizio sono stati raggiunti. Si è partiti dalla fase di
analisi,per proseguire con la progettazione del DB, la sua realizzazione e quella dell’interfaccia
web. L’applicazione sviluppata consiste in un data base, gestito da un DBMS MS-SQL server 2012 e
da un applicativo web sviluppato in Visual studio.
Per realizzare questo applicativo web sono state usate 7323 righe di codice, per il DB ci sono 6
tabelle e ci sono 3-4 record di prova.
Sono soddisfatto dell’esperienza che ho svolto. Mi ha permesso di capire intanto quanto sia
complicato gestire ambienti con tante informazioni.
Il progetto non è attualmente ancora operativo. Superata questa fase andrà sicuramente ad
aiutare a gestire il personale del dipartimento nella gestione delle informazioni per i relativi Badge
emessi. Inoltre, il prodotto potrebbe essere adottato da altre università o enti di ricerca per la
gestione del personale.
